Natural language query через весь observability стек

Що робить автоматизація

AI-агент працює єдиною точкою входу до всього observability-стеку. Інженер пише запитання в Slack, веб-чат або через CLI — агент розбирає намір, звертається до потрібних джерел через MCP-конектори, збирає дані та повертає відповідь із прямими посиланнями на dashboards і рядки логів.

Конкретні сценарії

1. Діагностика інциденту. «Що змінилося за останні 30 хвилин?» — агент збирає deploy events, alert history, аномальні метрики, повертає хронологічну відповідь.
2. Пошук кореневої причини. «Чому 500-і зросли на checkout-service?» — агент шукає по error logs, пов'язує з нещодавніми комітами, показує trace з найдовшим span.
3. Контекст для on-call. «Що зараз горить?» — агент агрегує відкриті інциденти, SLO burn rate, останні релізи.
4. Звіти для stakeholders. «Збери статус для щотижневого синку» — агент формує чернетку за SLO, uptime, інцидентами, ключовими метриками.
5. Онбординг інженера. «Як влаштований payment-flow?» — агент пояснює за кодом, docs, трейсами.

Особливість: агент не просто агрегує дані, а пов'язує їх контекстно. Запит про checkout автоматично підтягує і метрики, і логи, і останні коміти до відповідного сервісу.

Що НЕ робить автоматизація

Межі важливо провести одразу:

• Не замінює чергових інженерів. Агент дає гіпотези, рішення приймає людина.
• Не виправляє інциденти. Агент не запускає runbooks і не робить деплой — лише читає.
• Не замінює алертинг. PagerDuty, Opsgenie, Sentry продовжують працювати як раніше.
• Не дає 100% точних відповідей. Галюцинації можливі — агент завжди повертає джерела для перевірки.
• Не мігрує стек. Усі наявні інструменти залишаються на місці, агент працює поверх.

Типові варіанти налаштування

Solo / команда 1–5 осіб. Мінімальна збірка: підключити 2–3 ключові джерела — зазвичай логи, моніторинг і git. Агент відповідає в одному Slack-каналі або через CLI. Для маленької команди окупається за рахунок економії часу засновника-інженера, який відповідає за все одразу. Налаштування — один вихідний, без складної рольової моделі. Достатньо мовної моделі через API і простого RAG-індексу. Обмеження: якщо джерел більше п'яти, без structured routing починаються галюцинації. На цьому рівні простіше тримати фокус на одному кластері й одному типі інцидентів.

SMB / команда 6–30 осіб. Повноцінний observability-агент: 5–8 джерел (logs, metrics, traces, errors, git, CI/CD, incident management, docs). Agent router за типом запиту, окремі MCP-сервери для кожного джерела. Відповіді в Slack з розміткою по командах (backend, frontend, data). Додається audit log і role-based access для prod vs staging. На цьому рівні з'являється сенс у fine-tuning prompt templates під специфіку стеку. Типова економія — години на тиждень на команду за рахунок зникнення hunt-and-peck між консолями.

Enterprise / команда 30+ осіб. Мульти-агентна архітектура: спеціалізовані агенти для Kubernetes, database, security, networking. Центральний router визначає, до якого агента скерувати запит. Інтеграція з внутрішнім каталогом сервісів, compliance-фільтри (PII, secrets), окремий tenant на команду. Потрібна dedicated група підтримки (2–3 інженери) і відчутний бюджет на LLM-токени. ROI — не стільки економія часу, скільки зниження MTTR на критичних інцидентах і прискорення онбордингу нових команд у великій структурі.

Як це працює

Технічно автоматизація — це компоновка з чотирьох шарів.

1. Інтерфейс — Slack-бот, веб-чат або CLI. Інженер пише запитання природною мовою.
2. Маршрутизатор запитів — LLM-оркестратор визначає, які джерела потрібні для відповіді, які фільтри застосувати, чи потрібен follow-up.
3. MCP-конектори до джерел даних — окремий конектор для кожного інструменту: logs, metrics, traces, errors, git, docs.
4. Синтезатор відповіді — LLM збирає дані з джерел, пояснює зв'язки, повертає відповідь із посиланнями на вихідні дані.

Покроковий flow

Для типового запитання «чому латенсі чекаута зріс після 14:07?» агент робить наступне:

1. Парсить намір: це root cause analysis по конкретному сервісу та вікну часу.
2. Визначає потрібні джерела: metrics (latency), logs (error patterns), deploy history (що змінювалось), traces (який span гальмує).
3. Формує паралельні запити через MCP-конектори до кожного джерела.
4. Збирає результати, знаходить перетини — наприклад, deploy в 14:06 → зростання latency на p95 checkout-service → в логах помилка DB timeout → trace показує повільний query в new feature flag.
5. Генерує зв'язну відповідь: гіпотеза + докази + посилання + пропозиція наступного кроку.

Весь цикл займає секунди замість хвилин ручного hunt-and-peck.

Роль LLM

мовна модель — ключовий компонент. Її сильні сторони для цього завдання:

• Довгий контекст дозволяє одночасно аналізувати витяги з 5+ джерел без перевантаження.
• Хороша робота з tool use — MCP-конектори викликаються через структуровані tool calls без парсингу вільного тексту.
• Здатність до chain-of-thought reasoning для складних кореляцій між метриками та подіями.
• Акуратне поводження з посиланнями — агент повертає джерела, а не вигадує.

MCP-конектори

Model Context Protocol (MCP) — стандарт підключення LLM до зовнішніх джерел. Для observability-сценарію типовий набір конекторів:

• logs-mcp — читає лог-агрегатор (Loki, Elastic, CloudWatch Logs).
• metrics-mcp — PromQL/Prometheus та/або Grafana API.
• traces-mcp — Tempo, Jaeger або OpenTelemetry-сумісний бекенд.
• errors-mcp — Sentry, Rollbar, Honeybadger.
• git-mcp — історії комітів та deploy events.
• docs-mcp — внутрішні runbooks, Notion, Confluence.

Кожен конектор — окремий процес з read-only доступом і власним rate limit.

Альтернативні підходи

Ручний розбір працює, поки команда маленька і стек простий. Коли джерел більше трьох і інженерів більше п'яти, кожен інцидент перетворюється на полювання за контекстом. No-code рішення від вендорів добре працюють всередині своєї екосистеми, але погано з'єднують різні джерела — а реальний observability-стек зазвичай зібраний з кількох інструментів різних постачальників. AI-автоматизація на MCP працює поверх того, що вже є, і не вимагає мігрувати на один vendor-стек. Мінус — потрібна внутрішня експертиза для налаштування та моніторингу якості відповідей.

Безпека та compliance

Observability-дані часто містять чутливу інформацію: PII в логах, tokens, внутрішні URL. Три базові вимоги до setup-у:

1. Read-only доступ. Агент не повинен мати прав на зміну даних або на запуск runbooks. Лише читання через API-токени з мінімальними scope-ами.
2. Фільтрація на рівні конектора. PII-редагування та маскування secrets до того, як дані потрапляють у LLM-контекст.
3. Audit log. Всі запити та відповіді логуються — для розбору інцидентів та для compliance (SOC 2, GDPR, HIPAA за необхідності).

Якщо команда працює з персональними даними користувачів, використовуйте LLM-провайдера з політикою zero retention (AI-модель через Anthropic API це підтримує) або self-hosted інференс для чутливих контурів.

Що потрібно заздалегідь

Перед запуском агента зберіть інфраструктуру та команду.

Технічні передумови

1. Список observability-джерел. Які інструменти використовуються: Grafana, Datadog, Sentry, CloudWatch, Prometheus, щось інше. Мінімум два джерела — інакше агент перетворюється на обгортку над одним API.
2. API-токени з read-only scope. Для кожного джерела окремий токен. Без прав на запис, без admin-привілеїв.
3. MCP-конектори. Або готові (для популярних інструментів вони є), або написати власні — день-два роботи на інструмент.
4. LLM-провайдер. LLM через Anthropic API — робочий дефолт завдяки довгому контексту та якісному tool use.
5. Канал доступу. Slack, Microsoft Teams, веб-чат або CLI — де команда задаватиме запитання. Slack — типовий вибір.
6. Sandbox на pre-prod. Протестувати запити та відповіді два тижні, перш ніж надати доступ усій команді.

Ролі та відповідальність

• DevOps / SRE lead — налаштовує MCP-конектори, валідує доступи.
• Tech lead — визначає типи запитань, збирає feedback щодо якості відповідей.
• Security — ревʼює compliance-налаштування, PII-фільтри, audit log.
• Product engineer — адаптує prompt templates під специфіку команди.

Можливі підводні камені

• Галюцинації без джерел. Якщо не налаштувати обовʼязкову видачу посилань на вихідні дані, агент починає фантазувати цифри та events. Фікс: вимагати в system prompt показувати джерело кожного факту, відхиляти відповіді без посилань.
• Перевантаження контексту. Якщо тягнути в LLM весь лог за останню годину, контекст забивається і відповіді деградують. Фікс: фільтрація на рівні конектора, лише релевантні фрагменти потрапляють до LLM.
• Фантомні кореляції. Агент може знайти «зв'язок» між двома випадковими подіями. Фікс: явно просити гіпотези, а не твердження, додавати confidence score, валідувати на регресійному наборі запитів.
• Секрети в контексті. API-ключі, tokens, passwords з логів потрапляють у LLM-промпт. Фікс: regex-фільтри на конекторі + політика zero retention у LLM-провайдера + ротація скомпрометованих ключів при витоку.
• Дрейф якості. Через місяць джерела змінюються, схеми логів еволюціонують — відповіді деградують без видимих помилок. Фікс: щотижневий sample review 10–20 запитів, регресійні тести на типові сценарії, алерт на падіння confidence.