Алерти збоїв агентів

Ідея за 30 секунд

Failure alerting для AI-агентів дає ранній сигнал, коли система входить у деградацію.

Його мета не просто "сповістити про помилку", а вчасно показати, що саме ламається: tools, LLM-кроки, latency або health checks.

Без алертів команда зазвичай дізнається про проблему від користувачів, а не від системи.

Основна проблема

Логи й трейсинг добре пояснюють інцидент після факту.

Але без алертів складно помітити момент, коли проблема тільки починається: зростає timeout rate, падає synthetic success, росте p95 latency. Через це легко пропустити перехід від локальної деградації до каскадного збою.

Далі розберемо, як будувати алерти так, щоб вони були корисними, а не шумними.

У production це часто виглядає так:

• сигнал з’являється надто пізно, коли SLO вже порушено;
• алерти шумлять через тимчасові сплески і їх починають ігнорувати;
• одна проблема генерує десятки дублікатів у різних каналах;
• немає зрозумілого маршруту: хто має реагувати і що робити першим.

Саме тому alert-layer варто проєктувати як окремий елемент observability, а не як "додатковий webhook".

Як це працює

Failure alerting зазвичай складається з трьох рівнів:

• сигнали (error_rate, timeout_rate, latency_p95, health_score);
• правила (threshold, window, severity, cooldown);
• маршрутизація (on-call, team, playbook, escalation).

Ці рівні відповідають на питання «коли реагувати, хто реагує і як діяти». Логи й трейсинг потрібні, щоб швидко перейти від алерту до root cause. У production алерт зазвичай містить не лише severity, а й owner/team або playbook_link. Alert rules мають відображати порушення SLO, а не довільні thresholds.

Alert noise ≠ reliability. Якщо алерти спрацьовують часто й без пріоритету, команда починає їх ігнорувати.

Алерти з'являються там, де деградація вже зафіксована в метриках, latency або health checks. Synthetic alerts показують, що система "жива", але користувач уже не може виконати задачу.

Типові production-метрики для алертів

mtta і mttr зазвичай рахуються на рівні incident-платформи (PagerDuty/Opsgenie/власний incident log), а не напряму в runtime-коді агента.

Щоб алерти були корисними, їх зазвичай сегментують за severity, workflow, release і component.

Важливо: не додавай у labels висококардинальні поля (run_id, request_id, user_id), інакше alert-metrics швидко втрачають керованість.

Як читати alert-layer

Що спрацювало → чому спрацювало → хто і що має зробити. Це три рівні, які завжди потрібно дивитися разом.

Важливо дивитися на тренди і кореляцію сигналів, а не на один ізольований алерт.

Далі дивимось на комбінації сигналів:

• timeout_rate ↑ + latency_p95 ↑ → деградація сервісу вже впливає на користувачів;
• health_score ↓ + synthetic_run_success_rate ↓ → критичний workflow перестає працювати end-to-end;
• tool_error_rate ↑ + alert_fire_rate ↑ → нестабільний tool створює каскад алертів;
• false_positive_rate ↑ + mtta ↑ → команда втрачає довіру до алертів;
• missed_incident_rate ↑ + error_rate ↑ → є прогалини в правилах alerting.

Коли використовувати

Повний failure alerting не завжди потрібен.

Для простого прототипу інколи достатньо базового алерту на падіння сервісу.

Але системний alerting стає критичним, коли:

• агентна система вже в production;
• є SLO/SLA по доступності, latency або успішності workflow;
• система залежить від кількох tools і зовнішніх API;
• потрібна on-call реакція без ручного моніторингу дашбордів.

Приклад реалізації

Нижче — спрощений приклад alert-evaluator циклу. Приклад показує базовий підхід: threshold + window + cooldown + дедуплікація подій.

import time
from collections import defaultdict, deque

ALERT_RULES = {
    "high_timeout_rate": {
        "threshold": 0.05,
        "window_sec": 300,
        "severity": "high",
        "cooldown_sec": 600,
    },
    "latency_p95_regression": {
        "threshold": 2500,  # ms
        "window_sec": 300,
        "severity": "medium",
        "cooldown_sec": 600,
    },
    "synthetic_run_failed": {
        "threshold": 1,
        "window_sec": 120,
        "severity": "critical",
        "cooldown_sec": 300,
    },
}


class AlertEngine:
    def __init__(self):
        self.series = defaultdict(deque)  # metric_name -> [(ts, value), ...]
        self.last_fired_at = {}  # rule_name -> ts

    def ingest(self, metric_name, value, ts=None):
        ts = ts or time.time()
        self.series[metric_name].append((ts, value))

    def evaluate(self, ts=None):
        ts = ts or time.time()
        fired = []

        for rule_name, rule in ALERT_RULES.items():
            if self._in_cooldown(rule_name, ts, rule["cooldown_sec"]):
                continue

            if rule_name == "high_timeout_rate":
                value = self._latest_in_window("timeout_rate", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

            if rule_name == "latency_p95_regression":
                value = self._latest_in_window("run_latency_p95_ms", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

            if rule_name == "synthetic_run_failed":
                value = self._latest_in_window("synthetic_run_failed", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

        return fired

    def _latest_in_window(self, metric_name, now_ts, window_sec):
        # NOTE:
        # Цей приклад перевіряє лише останню точку (спайки можуть викликати алерти).
        # У production (Prometheus/Datadog) зазвичай перевіряють
        # тривалість аномалії (наприклад, "for: 5m"),
        # щоб уникнути алертів на короткі сплески.
        # Альтернатива: перевіряти sustained breach упродовж усього window,
        # а не лише в останній точці.
        points = self.series[metric_name]
        while points and now_ts - points[0][0] > window_sec:
            points.popleft()
        return points[-1][1] if points else None

    def _sustained_breach(self, metric_name, now_ts, window_sec, threshold):
        points = self.series[metric_name]
        while points and now_ts - points[0][0] > window_sec:
            points.popleft()
        return points and all(v >= threshold for _, v in points)

    def _in_cooldown(self, rule_name, now_ts, cooldown_sec):
        last_ts = self.last_fired_at.get(rule_name)
        return last_ts is not None and now_ts - last_ts < cooldown_sec

    def _build_alert(self, rule_name, value, rule, now_ts):
        self.last_fired_at[rule_name] = now_ts
        return {
            "rule": rule_name,
            "severity": rule["severity"],
            "value": value,
            "timestamp": now_ts,
        }

У production алерт спрацьовує не від спайка, а коли поріг тримається протягом усього window.

Ось як alert-метрики виглядають у реальному дашборді:

Investigation

Коли спрацьовує алерт:

1. перевірити severity і чи це не дублікат у cooldown-вікні;
2. знайти корельовані сигнали в метриках (latency, timeout, health);
3. відкрити проблемні runs у трейсингу;
4. підтвердити root cause в логах і запустити playbook.

Типові помилки

Навіть коли алерти вже є, вони часто не працюють як треба через типові помилки нижче.

Занадто багато алертів без пріоритизації

Якщо всі алерти однаково критичні, команда швидко перестає їм довіряти.

Немає cooldown і дедуплікації

Одна проблема породжує десятки однакових сповіщень, що ускладнює реакцію on-call.

Немає synthetic-based алертів

Алерти тільки по інфраструктурних метриках не гарантують, що workflow реально працює. Через це можна пропустити ранній хаос мультиагентної системи.

Алерти не прив'язані до playbook

Сповіщення є, але команда не знає, що робити далі. Це збільшує MTTR під час інциденту.

Висококардинальні labels у alert-metrics

Додавання run_id або request_id у labels швидко перевантажує систему метрик і ускладнює аналіз.

Самоперевірка

Нижче — короткий checklist базового failure alerting перед релізом.

FAQ

Q: Чим failure alerting відрізняється від health checks?
A: Health checks показують стан системи зараз, а failure alerting визначає, коли і кого потрібно сповістити, щоб вчасно відреагувати.

Q: Який мінімум алертів потрібен на старті?
A: Почни з timeout_rate, error_rate, latency_p95 і synthetic_run_success_rate.

Q: Як зменшити шум від алертів?
A: Додай severity-рівні, cooldown, дедуплікацію і прибери правила, які часто дають false positive.

Q: Як зрозуміти, що алерти покривають реальні ризики?
A: Перевіряй missed_incident_rate після інцидентів і оновлюй правила там, де система деградувала без сповіщення.

Пов'язані сторінки

Далі за темою:

• Health checks агентів — ранні сигнали деградації до інциденту.
• Метрики агентів — системні сигнали для правил алертів.
• Моніторинг затримок агентів — як будувати latency-based алерти.
• Трейсинг агента — як перейти від алерту до проблемного кроку.
• Логування агентів — дані для швидкого root-cause аналізу.