elastic / elastic/integrations
[anthropic_metrics] ECS GenAI Field Support for detections
- Dominant language
- Handlebars
- Stars
- 333
- Forks
- 647
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 209
Description
**Related issues:**
- https://github.com/elastic/integrations/issues/20737
- https://github.com/elastic/integrations/issues/20743 (anthropic — log-based sibling package)
TRaDE is requesting that ECS \`gen_ai.*\` fields be added to this integration for security detections.
The \`anthropic_metrics\` package collects API usage, cost, and rate limit metrics from the Anthropic Admin API across three data streams: \`usage\`, \`cost\`, and \`rate_limit\`. These are aggregated time-bucket metrics rather than per-request logs, so message-level fields (\`gen_ai.input.messages\`, \`gen_ai.output.messages\`, \`gen_ai.response.id\`, etc.) do not apply. The relevant gen_ai fields are model identification and token counts.
## \`usage\` data stream — Requested fields
| Field | Availability | Status |
|---|---|---|
| \`gen_ai.provider.name\` | ✅ Inferable — provider is Anthropic | ❌ Not implemented |
| \`gen_ai.request.model\` | ✅ \`anthropic.usage.model\` present in source data | ❌ Not implemented |
| \`gen_ai.usage.input_tokens\` | ⚠️ Available as sum of \`anthropic.usage.uncached_input_tokens\` + \`anthropic.usage.cached_input_tokens\` + \`anthropic.usage.cache_creation_input_tokens\` — granular breakdown already preserved in vendor-specific fields | ❌ Not implemented |
| \`gen_ai.usage.output_tokens\` | ✅ \`anthropic.usage.output_tokens\` present in source data | ❌ Not implemented |
## \`cost\` data stream — Requested fields
| Field | Availability | Status |
|---|---|---|
| \`gen_ai.provider.name\` | ✅ Inferable — provider is Anthropic | ❌ Not implemented |
| \`gen_ai.request.model\` | ✅ \`anthropic.cost.model\` present in source data | ❌ Not implemented |
| \`gen_ai.token.type\` | ✅ \`anthropic.cost.token_type\` present in source data (e.g., \`uncached_input_tokens\`, \`output_tokens\`, \`cache_read_input_tokens\`) | ❌ Not implemented |
## \`rate_limit\` data stream — Requested fields
| Field | Availability | Status |
|---|---|---|
| \`gen_ai.provider.name\` | ✅ Inferable — provider is Anthropic | ❌ Not implemented |
| \`gen_ai.request.model\` | ✅ \`anthropic.rate_limit.models\` present in source data (array of model names per rate limit group) | ❌ Not implemented — note: this is an array; verify correct ECS handling during development |
## Likely not possible (verify on development)
| Field | Availability | Status |
|---|---|---|
| \`gen_ai.input.messages\` / \`gen_ai.output.messages\` | ❌ Aggregated metrics — no per-request message content | ❌ Not implemented |
| \`gen_ai.response.id\` / \`gen_ai.response.finish_reasons\` | ❌ Aggregated metrics — no per-request response detail | ❌ Not implemented |
| \`gen_ai.request.temperature\`, \`gen_ai.request.max_tokens\`, etc. | ❌ Not present in Admin API usage/cost/rate-limit data | ❌ Not implemented |
| \`gen_ai.operation.name\` | ❌ Not meaningful for admin-level usage aggregates | ❌ Not implemented |
| \`gen_ai.agent.*\`, \`gen_ai.tool.*\`, \`gen_ai.conversation.id\` | ❌ Not applicable to metrics data | ❌ Not implemented |
## Summary of changes needed
### All three data streams
- Add \`gen_ai.provider.name\` field definition and pipeline processor (set to \`"anthropic"\`)
- Update \`sample_event.json\` to include \`gen_ai.*\` fields
### \`usage\` data stream
- Add \`gen_ai.request.model\`, \`gen_ai.usage.input_tokens\`, \`gen_ai.usage.output_tokens\` field definitions and pipeline processors
### \`cost\` data stream
- Add \`gen_ai.request.model\`, \`gen_ai.token.type\` field definitions and pipeline processors
### \`rate_limit\` data stream
- Add \`gen_ai.request.model\` field definition and pipeline processor (sourced from \`anthropic.rate_limit.models\` array)
Contributor guide
Research direction
Start by inspecting the anthropic_metrics package's usage, cost, and rate_limit data streams, their field definitions, and pipeline processors. Update each stream's sample_event.json while checking ECS handling for the rate_limit models array. Done means the requested provider, model, token, and usage fields are mapped where applicable across all three streams, with unsupported fields left out.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- handlebars
- Domain
- observability-sre, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100