kibana-anomaly-detection

Kibana Anomaly Detection — официальный skill Elastic для работы с ML-аномалиями через Kibana Agent Builder MCP. Он рассчитан на запросы о том, что сломалось, какая сущность вызвала отклонение, почему оценка стала высокой или низкой, остановился datafeed, сработал memory limit или нужно создать и настроить ML job. Основной контур — Kibana Agent Builder по адресу {KIBANA_URL}/api/agent_builder/mcp, а read path проходит через ES|QL по системным индексам .ml-anomalies-*, .ml-config, .ml-notifications-* и .ml-annotations-*. Навык сначала выбирает режим. Investigate нужен для RCA, межзадачного сопоставления, blast radius, influencers и категорий логов. Explain разбирает score, границы модели, forecast и renormalization. Troubleshoot предназначен для пропавших документов, задержки ingestion, памяти, состояния datafeed, CCS и lifecycle. Manage создаёт job и datafeed, валидирует конфигурацию и запускает анализ после подтверждения. Если вопрос смешивает несколько причин, порядок источника — Investigate, затем Explain и только потом Troubleshoot; режимы не стоит смешивать в одну неуправляемую цепочку. В исследовании сначала читаются доступные метаданные и jobs, затем находятся связанные jobs и jobs по индексу datafeed, строится timeline и ранжируются общие сущности. Для глубокой проверки используются anomaly records, influencers, detector fingerprint, correlation, blast radius, entity profile и source evidence. Правила RCA требуют учитывать сущности, встречающиеся минимум в двух jobs, выбирать самый ранний timestamp как сигнал возможного источника, повышать вес multi_bucket_impact от 3 и выше и не завершать RCA без сырых документов source evidence. Итог должен отдельно назвать root cause entity, затронутые jobs, временную последовательность, fault class, severity и следующие действия. В модели данных bucket — агрегат необычности за bucket_span, record — детальная строка с actual, typical, probability и объяснением оценки, influencer — вклад сущности в bucket. Текущие anomaly_score и record_score могут меняться из-за нормализации; initial_anomaly_score и initial_record_score сохраняют состояние в момент обнаружения. Поэтому при объяснении падения оценки нужно показывать обе версии record_score и сначала проверять renormalization. Полезные признаки включают anomaly_length, single_bucket_impact, multi_bucket_impact, anomaly_characteristics_impact, high_variance_penalty и incomplete_bucket_penalty. Слишком низкая оценка может быть связана с шумом, неполным bucket, малым объёмом истории, неподходящим detector function или custom rules; слишком высокая — с ранним обучением, высокой cardinality или sparse-полем с use_null. Troubleshoot разделяет задержку данных и память. Для missing docs используются delayed-data annotations, gaps, оценка ingest latency и корректировка query_delay. Для soft_limit или hard_limit сначала проверяются model memory health, cardinality и требуемая память; эвристика peak_model_bytes умножить на 1.3 хуже, чем ad_estimate_memory_requirement, потому что не учитывает influencer и categorization memory. query_delay выбирается от P95 ingest latency с запасом, bucket_span согласуется с гранулярностью данных, а frequency зависит от query_delay и половины bucket_span. Изменение memory limit или query delay требует последовательности stop datafeed → close job → update config → open job → start datafeed. Перед запуском после изменений делается preview datafeed; повреждённый период можно восстановить через model snapshot, не сбрасывая всю модель. Manage использует явные тела API: сначала job, затем datafeed, потом open job и start datafeed, а результаты читаются из records. В source приведены разумные defaults — bucket_span 15m, time_field @timestamp, индекс logs-*, match_all query и query_delay 60s, но они должны быть заменены явным вводом пользователя. Detector function выбирается по намерению: high_mean или high_sum для больших значений, rare для редких событий и high_count для всплеска количества. До показа пользователю нужно проверить mapping и прогнать ad_validate_job_spec; полные тела job и datafeed показываются целиком, согласование запрашивается один раз, и только после подтверждения выполняется deploy. Для регистрации нужны Node.js 18+ и доступный Kibana; команда all register последовательно регистрирует tools, workflows и skills. MCP-ключ должен иметь read_onechat, space_read, чтение mapping и целевых ML-индексов, а для source evidence — доступ к исходным индексам. Skill не заменяет права доступа, качество входных логов или подтверждение оператора. Ошибки пустого результата сначала проверяются через ad_validate_ml_tool_permissions, а изменения жизненного цикла нельзя выполнять без проверки job, datafeed, индекса, временного окна и ожидаемого side effect.