/kibana-anomaly-detection

name: kibana-anomaly-detection
description: >
  Elastic ML anomaly detection — investigation/RCA, score explanation, job lifecycle
  troubleshooting, and job operations. Use when answering "what broke?"/"which entity?"/RCA,
  "why is score high/low?"/renormalization, "datafeed stopped"/"memory limit"/hard_limit,
  or configuring ML anomaly detection jobs. Reads results from `.ml-anomalies-*` and
  job state from ML REST APIs.
metadata:
  author: elastic
  version: 0.3.0
  universal: true
compatibility: Elasticsearch 8.x–9.x or Elastic Cloud Serverless with ML anomaly detection;
  Kibana 8.x–9.x for saved-object context only

Elastic ML Anomaly Detection

Expert process for ML anomaly detection: attribute incidents to entities, explain scores and model behavior, diagnose job lifecycle failures, and manage jobs. Read anomaly **results** from `POST /.ml-anomalies-*/_search` (Serverless-safe) and **job/datafeed state** from ML REST APIs. When the user embeds fixture evidence (influencer rows, job stats) in the prompt, apply the judgment below directly — do not re-fetch fields already supplied.

<!-- begin-partial: preamble -->

Environment Configuration

This skill executes Elasticsearch operations through the `elastic` CLI. If the [`elastic` CLI](https://github.com/elastic/cli#configuration) is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., `GET /`, `GET /_cat/indices`, `GET /{index}/_mapping`, `GET /{index}/_settings/index.mode`, `POST /_query`). The [Operations](#operations) table at the end of this document maps each shorthand to the equivalent `elastic` CLI command — always use the CLI rather than calling the HTTP API directly.

<!-- end-partial: preamble -->

Mode selector

| User intent | Mode | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | "What broke?" / RCA / cross-job / blast radius / influencers / log categories | **Investigate** | | "Why score high/low?" / renormalization / model bounds / forecasts | **Explain** | | Missing docs / memory limit / datafeed stopped / lifecycle / calendars | **Troubleshoot** | | Create a job / configure a datafeed / start analysis / retrieve results | **Manage** | | Security framing (attack chains, MITRE, exfil) | Investigate + [references/security-anomaly-expert.md](references/security-anomaly-expert.md) | | Observability/SRE framing (degradation, capacity, deployment regression) | Investigate + [references/observability-anomaly-expert.md](references/observability-anomaly-expert.md) |

When a question spans modes: **Investigate → Explain → Troubleshoot**. Finish one mode before blending logic.

> **Serverless note:** Legacy `/_ml/anomaly_detectors/{job_id}/results/*` endpoints return HTTP 410 in Serverless. > Always query `.ml-anomalies-*` via `POST /.ml-anomalies-*/_search` with `result_type` filters.

Score quick reference

• `record_score` bands: **>75** critical · **50–75** warning · **25–50** minor · **<25** informational
• `multi_bucket_impact ≥ 3` → sustained shift (not a transient spike)
• `initial_record_score >> record_score` → renormalization (model saw worse anomalies later)
• `actual << typical` with `count`/`low_count`/`low_mean` → absence/outage, not just a low value
• Low scores across many jobs > one high score — composite cross-job signal often beats single-detector severity

> Full score definitions, renormalization mechanics, and `anomaly_score_explanation` components: > [references/score-reference.md](references/score-reference.md).

Core concepts

Treat `.ml-anomalies-*` as layered result types via `result_type` in search queries:

| `result_type` | Scope | Key fields | | --------------------- | --------------- | ---------------------------------------------------------------------------------------- | | `bucket` | Time window | `anomaly_score`, `initial_anomaly_score`, `timestamp` | | `record` | Detector row | `record_score`, `initial_record_score`, `actual`, `typical`, `anomaly_score_explanation` | | `influencer` | Entity × bucket | `influencer_field_name`, `influencer_field_value`, **`influencer_score`** | | `model_plot` | Bounds | `model_lower`, `model_upper`, `actual` | | `category_definition` | Log patterns | `category_id`, `terms`, `regex`, `examples` |

Read scores this way:

• `anomaly_score` / `record_score` = **current normalized** values (move as the model sees new extremes).
• `initial_anomaly_score` / `initial_record_score` = **immutable snapshots** from detection time.
• **`influencer_score` ranks entity responsibility within a bucket** — the highest score is the primary suspect, not the

bucket-level `anomaly_score` alone.

• Map entities via `partition_field_value` / `by_field_value` / `over_field_value`.
• Read `multi_bucket_impact` (-5 to +5) to separate single-bucket spikes from sustained trends.

---

Mode: Investi