SkyWalking Horizon UI 1.0 отримав AI-асистента для розслідування збоїв — тільки читання і контроль прав

Apache SkyWalking представив AI Assistant у Horizon UI 1.0. Замість окремого чат-бота команда вбудувала інструмент у модель спостережуваності: він читає живі дані з OAP тим самим шляхом, що й звичайні дашборди, будує реальні графіки та пояснює їх у послідовності розслідування. Функція вимкнена за замовчуванням, працює з моделлю, яку обирає оператор, і не отримує більше прав, ніж має поточний користувач.

Одне запитання запускає послідовний аналіз тривог, latency та error rate на основі живих даних OAP.
Не текстова відповідь, а перевірювані фігури
Асистент спочатку орієнтується в доступних layers, services і каталозі метрик. Потім використовує MQE-вирази з конфігурації Horizon без самостійного конструювання вигаданих показників. У відповідь він може вставити line chart, single-value card, top-N, таблицю, список traces або logs. Кожна фігура нумерується, тож текст посилається на конкретний візуальний доказ.
Асистент показує інтерактивний one-hop topology тією ж компонентою, що й основний інтерфейс.
Для залежностей доступні one-hop topology, cross-layer hierarchy, deployment graph та instance map. Для сигналів — traces із waterfall, збережені logs і browser errors. Це важлива межа: модель не переказує приблизну картину, а керує визначеним набором інструментів, які повертають дані SkyWalking.
Перед побудовою графіків асистент звіряє доступні layers, services і metric catalog.
Як обмежено пошук першопричини
Для latency, error rate, saturation, middleware, Kubernetes і service mesh передбачено окремі playbook. Асистент може пройти графом залежностей до сервісу, де виникла проблема, а потім звузити пошук до instance, endpoint, trace або error stack. Коли наявних сигналів недостатньо, він має зупинитися, сформулювати найкращу підтверджену гіпотезу та перелічити, яких даних бракує.
Фінал містить підтверджені симптоми, імовірну причину та конкретні наступні перевірки.
Майже всі інструменти працюють тільки на читання. Profiling є єдиною дією, яку асистент може запропонувати: користувач бачить decision card із поясненням, а завдання запускається лише після схвалення й за наявності дозволу profile:enable. Окремо перевіряються metrics:read, alarms:read, topology:read, traces:read і logs:read.
Модель можна обрати самостійно
Horizon підтримує OpenAI-сумісний endpoint і Amazon Bedrock. Оператор задає model id, base URL та ключ через серверну конфігурацію або environment variables. Розробники наголошують, що знання про observability закладене в tools, metric catalog і playbook, тому для оркестрації не обов’язково використовувати найдорожчу frontier-модель. Temperature зафіксовано на нулі для стабільнішого tool calling.
Дані з логів, назв pod і повідомлень тривог трактуються як недовірений контент, а не як інструкції. Це зменшує ризик prompt injection через operational data. Ключ моделі не передається в браузер, редагується в логах, а історія діалогів зберігається локально в браузері й може бути видалена користувачем.
Що перевірити перед production
AI-пояснення не замінює якість телеметрії. Якщо layer не містить потрібної метрики або компонент logs/traces вимкнений, асистент не отримає доказів. Команді варто перевірити RBAC, ліміти запитів до моделі, витрати, політику зберігання діалогів, redaction чутливих полів і сценарії зловмисних рядків у логах. Особливо важливо не сприймати гіпотезу без фігур і trace як остаточний діагноз.
Автор першоджерела: Sheng Wu.
Ліцензія: Apache License 2.0 — https://github.com/apache/skywalking-website/blob/master/LICENSE. Матеріал перекладено, переказано й адаптовано українською мовою.