Ответ
Мониторинг ошибок — это практика непрерывного отслеживания приложений и инфраструктуры с целью обнаружения, агрегации, анализа и оповещения о сбоях (exceptions, errors, crashes). В отличие от метрик (CPU, память) или логов, он фокусируется на пользовательском опыте и функциональных сбоях, позволяя быстро находить root cause.
Чем отличается от логирования и метрик?
- Логи: Неструктурированный/полуструктурированный поток событий. Требуют парсинга и агрегации для поиска ошибок.
- Метрики (Prometheus): Числовые данные о работе системы (запросов в секунду, latency). Показывают что система замедлилась, но не всегда почему.
- Мониторинг ошибок (Sentry, Datadog APM): Контекстуализированные данные об отдельных сбоях: стектрейс, состояние окружения, пользователь, предшествующие события. Показывает почему упал конкретный запрос.
Типичный стек для мониторинга ошибок в DevOps:
- Инструмент для приложений: Sentry, Rollbar, Elastic APM. Интегрируется в код.
- Инструмент для инфраструктуры и сетевых ошибок: Prometheus + Alertmanager (отслеживает метрики типа
rate(http_requests_total{status=~"5xx"}[5m])), специализированные агенты для мониторинга сетевых устройств. - Логирование как дополнение: ELK Stack или Loki для глубокого анализа контекста вокруг ошибки.
Пример настройки оповещения в Prometheus для мониторинга ошибок 5xx на ingress-контроллере Nginx в Kubernetes:
# prometheus-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: app-error-rules
spec:
groups:
- name: http-errors
rules:
- alert: High5xxErrorRate
expr: rate(nginx_ingress_controller_requests{status=~"5.."}[5m]) > 0.05
for: 2m
labels:
severity: critical
tier: frontend
annotations:
summary: "High 5xx error rate on {{ $labels.ingress }}"
description: "5xx error rate is {{ $value }} per second for ingress {{ $labels.ingress }}. This affects service {{ $labels.service }}."
runbook: "https://wiki.internal/runbooks/5xx-errors"Ключевые DevOps-метрики в мониторинге ошибок:
- Error Rate/SLO: Процент запросов, завершившихся ошибкой, относительно общего числа. Цель — держать ниже целевого значения (например, < 0.1%).
- MTTR (Mean Time To Resolution): Среднее время от обнаружения ошибки до ее исправления. Снижается за счет качественных алертов и runbook'ов.
- Уникальные ошибки за период: Помогает оценивать стабильность релиза.
Итог: Мониторинг ошибок — это не просто "получить стектрейс". Это процесс, который связывает сбой в коде с бизнес-метриками (потерянные транзакции, недовольные пользователи) и позволяет командам DevOps и разработки проактивно улучшать надежность системы.
