Автоматичне виявлення помилок за логами: налаштування алертингу

---
# 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 для аномального зростання помилок. Такі правила — основа для spike detection та frequency rule.

---
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 рази гнучкіший в налаштуванні правил, ніж Grafana Alerting. Крім того, завдяки дедуплікації ElastAlert2 в 5 разів ефективніше знижує alert fatigue, ніж стандартне налаштування. Загалом, ElastAlert2 краще підходить для складних правил в 3 рази у порівнянні з Grafana Alerting. Якщо ви вже використовуєте Elasticsearch, ElastAlert2 — природний вибір. Для команд на стеку Grafana + Loki простіше почати з вбудованого алертингу, але при зростанні вимог доведеться мігрувати.

Чи варто сповіщати про WARN?

Ні, не варто. Рівень WARN зазвичай означає попередження, яке не потребує негайної реакції. Краще використовувати окремий дашборд для моніторингу WARN, а алерти налаштовувати тільки на ERROR та вище.

Критерії для сповіщень

Хороші кандидати для сповіщень:

• Патерни, які ніколи не повинні з'являтися в нормі: 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 тижнів. Вартість налаштування для 5–15 критичних сервісів — від $2 000. Економія від зниження часу реакції на інциденти оцінюється в $500/місяць. Початкове налаштування для одного сервісу може коштувати від $300. Оцінимо ваш проект за 1 день — просто напишіть нам.

Наш кейс: платіжний сервіс з 99.9% точністю алертів

Це наш кейс. З нашої практики: один з наших клієнтів — інтернет-еквайринг на 5000+ запитів за хвилину. Налаштували ElastAlert2 з правилами на spike: якщо помилка PAYMENT_DECLINED зростала в 3 рази за 5 хвилин — алерт в PagerDuty. За місяць виявили 4 інциденти, які не ловили метрики latency. Alert fatigue — 0, false positive — менше 1%. Все завдяки точній фільтрації та дедуплікації. Економія часу чергових склала близько 20 годин на місяць, що еквівалентно $1 200 економії.

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