Анти-патерн No Monitoring: відсутність моніторингу

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

No Monitoring — це анти-патерн, коли агентна система працює майже "всліпу": без трейсів запуску, stop_reason і базових метрик.

У результаті будь-який збій виглядає як "модель повелася дивно", а команда не може швидко знайти корінь проблеми. Це збільшує час налагодження, вартість інцидентів і ризик повторних помилок.

Просте правило: кожен run має залишати зрозумілий слід — run_id, ключові події кроків, stop_reason і usage-метрики.

Приклад анти-патерну

Команда запускає support-агента в production, але логує лише фінальну відповідь.

Коли користувач скаржиться на помилку, команда не бачить, де саме вона виникла.

result = agent.run(user_message)
logger.info("answer=%s", result.text)

У такій схемі немає базового контексту run:

# немає run_id
# немає step trace
# немає tool status/duration
# немає stop_reason

Для цього кейсу потрібен мінімальний observability-шар:

run_id = create_run_id()
log_run_started(run_id, user_message)
...
log_stop(run_id, stop_reason, usage)

У цьому випадку відсутність моніторингу додає:

• "сліпий" дебаг через припущення
• довший час відновлення після інциденту
• повторення тих самих збоїв

Чому виникає і що йде не так

Цей анти-патерн часто з’являється, коли команда фокусується на фічах, а моніторинг відкладає "на потім".

Типові причини:

• логують лише фінальний output без run-level подій
• немає єдиної схеми подій для agent/tool/stop
• відсутні базові метрики по маршрутах (success rate, latency, cost per request)
• немає власника за observability у команді

У результаті виникають проблеми:

• довгий MTTR — важко швидко локалізувати корінь збою
• повторні інциденти — фікси роблять "наосліп" без перевірки причин
• прихована деградація — latency і вартість ростуть непомітно
• крихка якість — команда не бачить, де саме падає success rate
• слабка керованість — неможливо пояснити, чому run завершився саме так

На відміну від No Stop Conditions, тут головний збій у відсутності видимості: навіть якщо стоп-логіка є, команда не бачить, як вона спрацювала у конкретному запуску.

Типові production-сигнали, що моніторингу не вистачає:

• support дізнається про проблему раніше, ніж моніторинг
• команда не може відновити ланцюг подій по run_id
• у логах часто немає stop_reason або його неможливо зіставити з run
• cost per request або P95 ростуть, а команда помічає це запізно

Важливо, що кожен agent/tool крок — це частина виконання run. Без трейсів і метрик система стає чорним ящиком для команди, і причинно-наслідковий зв’язок між дією та збоєм втрачається.

Правильний підхід

Починайте з мінімального observability-базису і робіть його обов’язковим для кожного маршруту. Нові метрики додавайте тоді, коли вони закривають конкретні інциденти або сліпі зони.

Практична рамка:

• фіксуйте run_id і step_id для кожного запуску
• логуйте для tool-call: tool, status (ok/error), duration_ms, args_hash
• для кожного run логуйте stop_reason і usage-метрики
• відстежуйте ключові дашборди (наприклад, success rate, P95, cost per request) і ставте алерти на критичні відхилення

def run_support_agent(user_message: str):
    run_id = create_run_id()
    log_event("run_started", run_id=run_id, message=user_message)

    for step_id in range(MAX_STEPS):
        decision = agent.next_step(user_message)

        if decision.type == "tool_call":
            started = now_ms()
            try:
                result = run_tool(decision.tool, decision.args)
                log_event(
                    "tool_result",
                    run_id=run_id,
                    step_id=step_id,
                    tool=decision.tool,
                    duration_ms=now_ms() - started,
                    status="ok",
                )
            except Exception:
                log_event(
                    "tool_result",
                    run_id=run_id,
                    step_id=step_id,
                    tool=decision.tool,
                    duration_ms=now_ms() - started,
                    status="error",
                )
                raise
            continue

        if decision.type == "final_answer":
            log_event("stop", run_id=run_id, stop_reason="final_answer")
            return decision.output

    log_event("stop", run_id=run_id, stop_reason="max_steps_exceeded")
    return fallback_answer()  # safe default response or escalation

У такій схемі кожен run стає прозорим: команда бачить, що саме сталося, де з’явився збій і як перевірити фікс.

Швидкий тест

Якщо на ці питання відповідь "так", у вас є ризик анти-патерну No Monitoring:

• Чи складно за 1-2 хвилини пояснити, чому конкретний run завершився саме так?
• Чи support часто сигналізує про збої раніше, ніж ваші алерти?
• Чи неможливо відтворити останній невдалий run за логами і метриками?

Чим відрізняється від інших анти-патернів

No Stop Conditions vs No Monitoring

Якщо коротко: No Stop Conditions — про контроль циклу, а No Monitoring — про відсутність видимості того, що реально відбулося.

Overengineering Agents vs No Monitoring

Якщо коротко: Overengineering Agents збільшує складність системи, а No Monitoring робить цю складність невидимою і некерованою.

Agents Without Guardrails vs No Monitoring

Якщо коротко: Agents Without Guardrails — про відсутність контрольних меж, а No Monitoring — про відсутність видимості того, як ці межі (не) спрацювали в run.

Самоперевірка: чи немає у вас цього анти-патерну

Швидка перевірка на anti-pattern No Monitoring.
Відмічайте пункти під вашу систему і дивіться статус нижче.

Перевірте свою систему:

FAQ

Q: Достатньо просто писати application logs?
A: Ні. Для агентних систем потрібен run-level моніторинг: run_id, step-події, stop_reason, tool-трейси та метрики якості/вартості.

Q: З чого почати, якщо моніторингу майже немає?
A: Почніть із мінімуму: run_id, stop_reason, tool status/duration, success rate, P95, cost per request. Це вже різко зменшує сліпі зони.

Q: Чи потрібен replay одразу?
A: Повний replay не обов’язковий на старті, але хоча б часткове відтворення run за логами має бути, інакше перевірка фіксів лишається здогадкою.

Що далі

Схожі anti-patterns:

• No Stop Conditions — коли цикл агента не має чітких умов завершення.
• Agents Without Guardrails — коли агент працює без чітких policy boundaries.
• Overengineering Agents — коли архітектура обростає зайвими шарами.

Що будувати замість цього:

• Stop Conditions — як фіксувати кероване завершення run.
• Tool Execution Layer — де централізовано логувати і контролювати tool-calls.
• Agent Runtime — як робити виконання агента прозорим на рівні кроків і рішень.