Запити природною мовою через весь стек спостережуваності

AI-агент працює єдиною точкою входу до всього стеку спостережуваності.

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

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

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

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

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

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

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

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

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

SMB / команда 6–30 осіб. Повноцінний агент спостережуваності: 5–8 джерел (логи, метрики, трейси, помилки, git, CI/CD, управління інцидентами, документація). Маршрутизатор агентів за типом запиту, окремі MCP-сервери для кожного джерела. Відповіді в Slack з розміткою по командах (бекенд, фронтенд, дані). Додається журнал аудиту і доступ за ролями для прод проти стейджингу. На цьому рівні з'являється сенс у тонкому налаштуванні шаблонів запитів під специфіку стеку. Типова економія — години на тиждень на команду за рахунок зникнення ручного перебирання вкладок між консолями.

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

Як це працює

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

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

Покроковий процес

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

1. Парсить намір: це аналіз першопричин по конкретному сервісу та вікну часу.
2. Визначає потрібні джерела: метрики (затримка), логи (патерни помилок), історія деплоїв (що змінювалось), трейси (який span гальмує).
3. Формує паралельні запити через MCP-конектори до кожного джерела.
4. Збирає результати, знаходить перетини — наприклад, deploy в 14:06 → зростання затримки на p95 checkout-service → в логах помилка DB timeout → трейс показує повільний запит у новому функціональному прапорці.
5. Генерує зв'язну відповідь: гіпотеза + докази + посилання + пропозиція наступного кроку.

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

Роль LLM

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

• Довгий контекст дозволяє одночасно аналізувати витяги з 5+ джерел без перевантаження.
• Якісне використання інструментів — MCP-конектори викликаються через структуровані виклики інструментів без парсингу вільного тексту.
• Здатність до покрокового міркування для складних кореляцій між метриками та подіями.
• Акуратне поводження з посиланнями — агент повертає джерела, а не вигадує.

MCP-конектори

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

• 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 — внутрішні сценарії реагування, Notion, Confluence.

Кожен конектор — окремий процес із доступом лише для читання і власним обмеженням частоти запитів.

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

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

Безпека та відповідність вимогам

Дані спостережуваності часто містять чутливу інформацію: PII в логах, токени, внутрішні URL. Три базові вимоги до налаштування:

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

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

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

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

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

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

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

• DevOps / SRE лід — налаштовує MCP-конектори, валідує доступи.
• Техлід — визначає типи запитань, збирає зворотний зв'язок щодо якості відповідей.
• Безпека — перевіряє налаштування відповідності вимогам, PII-фільтри, журнал аудиту.
• Продуктовий інженер — адаптує шаблони запитів під специфіку команди.

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

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