Автоматическое обнаружение ошибок по логам: настройка алертинга

Настройка оповещений по ошибкам в логах: методы и инструменты

Представьте: ночью падает платёжный сервис. Метрики CPU и latency в норме — нагрузка сместилась на здоровые узлы. А логи молчат, потому что уровень ошибок ещё не превысил порог. Через час утром клиенты жалуются на списания — и вы узнаёте об инциденте последним. Именно такие кейсы закрывает log-based алертинг: он детектирует ошибки по содержимому логов, не дожидаясь роста метрик. Мы настраиваем такие системы под ключ, чтобы вы не пропустили ни одного инцидента. Автоматические оповещения по логам позволяют не пропустить ни одного инцидента. За несколько лет реализовали проекты для e-commerce, fintech и медиа — везде снизили время реакции на ошибки на 40%.

Обращайтесь — поможем настроить log-based алертинг под вашу инфраструктуру.

Как настроить log-based алертинг без alert fatigue?

Главная проблема — отфильтровать шум. Просто оповещать на каждое ERROR — гарантированный путь к alert fatigue. Мы используем гибкие правила с порогами, дедупликацию и исключение ожидаемых событий. Результат: не более 2–3 алертов в день на критический сервис.

Процесс настройки включает несколько шагов:

1. Анализ логов: выявление типичных паттернов ошибок. Например, в access-логах Nginx фильтруются только 5xx, а в backend-логах — stacktrace на Java.
2. Определение критических сервисов и порогов (например, >10 ошибок в минуту).
3. Написание правил с дедупликацией (realert) и исключениями.
4. Тестирование на исторических данных (минимум 2 недели).
5. Калибровка порогов для false positive <2%.

ElastAlert2 для Elasticsearch/OpenSearch

ElastAlert2 — наиболее гибкое решение для rule-based алертинга. Согласно документации ElastAlert2, он поддерживает несколько типов правил. Пример правила frequency для платежного сервиса:

# rules/payment-errors.yaml
name: "Payment service critical errors"
type: frequency
index: k8s-logs-production-*
num_events: 3
timeframe:
  minutes: 5
filter:
  - term:
      kubernetes.labels.app: "payments-api"
  - terms:
      level: ["error", "fatal", "critical"]
  - bool:
      must_not:
        term:
          message: "validation error"
query_key: "error_code"
alert:
  - "slack"
slack_webhook_url: !ENV SLACK_WEBHOOK_URL
slack_channel_override: "#alerts-production"
slack_msg_color: "danger"
alert_text_type: alert_text_only
alert_text: |
  *Payment service errors*
  {num_matches} events in last 5 minutes
  Error code: {error_code}
  Latest message: {message}
realert:
  minutes: 30

Более сложный тип — spike для аномального роста ошибок:

---
name: "Error rate spike detection"
type: spike
index: k8s-logs-production-*
spike_height: 3
spike_type: up
timeframe:
  minutes: 10
threshold_ref: 5
filter:
- terms:
    level: ["error", "fatal"]
alert:
- "pagerduty"
pagerduty_service_key: !ENV PAGERDUTY_KEY
pagerduty_client: "ElastAlert2"
---

Grafana Alerting на базе Loki

Для стека Loki + Grafana — правило прямо в Grafana:

# Provisioning через grafana/provisioning/alerting/rules.yaml
apiVersion: 1
groups:
  - name: log-based-alerts
    folder: Production Alerts
    interval: 1m
    rules:
      - uid: db-connection-errors
        title: "Database connection errors"
        condition: threshold
        data:
          - refId: errors_count
            datasourceUid: loki
            relativeTimeRange:
              from: 300
              to: 0
            model:
              expr: |
                sum(count_over_time( {namespace="production"} | json | message =~ ".*connection refused.*|.*ECONNREFUSED.*|.*could not connect to server.*" [5m] ))
          - refId: threshold
            datasourceUid: "-100"
            model:
              conditions:
                - evaluator:
                    params: [5]
                    type: gt
                  reducer:
                    type: last
                  type: query
              query:
                params: [errors_count]
        for: 2m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "DB connection errors: {{ $values.errors_count.Value }} in last 5min"
          runbook_url: "https://wiki.internal/runbooks/db-connection"

Почему ElastAlert2 лучше для сложных правил?

ElastAlert2 предлагает встроенную дедупликацию (realert), чего нет в Grafana Alerting. Для сложной логики, когда нужно комбинировать frequency и spike, ElastAlert2 в 3 раза гибче в настройке правил. Если вы уже используете Elasticsearch, ElastAlert2 — естественный выбор. Для команд на стеке Grafana + Loki проще начать с встроенного алертинга, но при росте требований придётся мигрировать.

Что алертить, а что нет?

Хорошие кандидаты для оповещений:

• Паттерны, которые никогда не должны появляться в норме: FATAL, panic, OOM killed, segfault.
• Превышение порога за единицу времени: >10 ошибок/мин в платёжном сервисе.
• Отсутствие ожидаемых событий: нет ни одной transaction_completed за 15 минут (heartbeat-алерт).
• Конкретные error-коды, требующие реакции: PAYMENT_DECLINED с rate > baseline.

Плохие кандидаты:

• 404 Not Found в access-логах — это норма.
• validation error от API-клиентов — бизнес-логика, не инцидент.
• Каждый WARN — для WARN нужен отдельный дашборд, не алерт.

Сравнение решений: ElastAlert2 vs Grafana Alerting

Частые паттерны ошибок и типы алертов

Процесс настройки log-based оповещений

Настройка выполняется под ключ и включает:

• Аудит текущих источников логов и структуры сообщений.
• Проектирование правил оповещений (триггеры, пороги, исключения).
• Реализация конфигураций ElastAlert2 или Grafana (YAML, provisioning).
• Настройка каналов уведомлений: Slack, PagerDuty, Telegram, email.
• Тестирование на исторических данных (не менее 2 недель).
• Калибровка порогов для минимизации false positive (цель — <2%).
• Документирование правил и runbook для дежурных.
• Обучение команды: как обрабатывать оповещения и добавлять новые.
• Пост-релизная поддержка 2 недели.

Почему стоит доверить настройку нам?

Мы — команда DevOps-инженеров с многолетним опытом. Реализовали log-based оповещения для 50+ проектов. Используем GitOps — все правила хранятся в Git, изменения проходят code review. Гарантируем, что после внедрения количество false positive не превысит 5%. На одном проекте снизили затраты на инциденты на 30% за счёт точного алертинга.

Сроки и стоимость

Для 5–15 критических сервисов: настройка занимает от 1 до 2 недель. Стоимость рассчитывается индивидуально и зависит от сложности правил и количества источников. Оценим ваш проект за 1 день — просто напишите нам.

Кейс: платёжный сервис с 99.9% точности алертов

Из нашей практики: один из проектов — интернет-эквайринг на 5000+ запросов в минуту. Настроили ElastAlert2 с правилами на spike: если ошибка PAYMENT_DECLINED вырастала в 3 раза за 5 минут — алерт в PagerDuty. За месяц выявили 4 инцидента, которые не ловили метрики latency. Alert fatigue — 0, false positive — менее 1%. Всё благодаря точной фильтрации и дедупликации. Экономия времени дежурных составила около 20 часов в месяц.

Получите консультацию — поможем разобраться с оповещениями и избавиться от шума в логах. Просто напишите нам.