observability-llm-obs

Официальный навык Elastic предназначен для вопросов о наблюдаемости LLM и приложений с AI-агентами, если данные уже собраны в Elastic. Его область охватывает четыре связанных направления: производительность, использование токенов и стоимость, качество ответов, а также цепочки вызовов и оркестрацию агентных рабочих процессов. Навык задаёт важное ограничение источника: выводы нужно строить только по данным, которые действительно поступили в Elastic, а не по предположениям о том, что должно находиться в конкретном развёртывании. Поэтому перед запросом сначала выясняют доступный путь поступления данных и фактические имена полей. Для трассировки используются шаблоны traces*. При сборе через Elastic APM Agent данные могут находиться в traces*, а при OpenTelemetry — в traces-generic.otel-default и похожих потоках; общий шаблон traces* помогает искать трассы независимо от способа отправки. Метрики могут находиться в metrics-apm* или metrics-generic. Если применяются интеграции Elastic для OpenAI, Azure OpenAI, Azure AI Foundry, Amazon Bedrock, Bedrock AgentCore или GCP Vertex AI, связанные метрики и логи размещаются в потоках интеграций с шаблонами metrics* и logs*, а точное имя индекса зависит от пакета интеграции. Нельзя заранее считать, что в каждом окружении присутствуют и APM, и интеграционные данные. Рабочий процесс начинается с обнаружения данных. Сначала перечисляют data streams через Elasticsearch API, затем проверяют mapping для traces* и metrics* и при необходимости читают небольшой пример документа. Так можно установить, какие сигналы реально доступны: модель, провайдер, длительность, токены, ошибки и идентификаторы трасс. В трассах могут встречаться атрибуты OpenTelemetry GenAI, например gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.response.model, gen_ai.usage.input_tokens и gen_ai.usage.output_tokens. Но эти имена не гарантированы: конкретная инструментализация может использовать другие поля, поэтому источник требует подтвердить их по mapping или sample document. Стоимость также не является полем, гарантированным спецификацией OpenTelemetry; некоторые инструментирования добавляют собственный атрибут, например оценку стоимости в долларах. Для анализа производительности ES|QL или Elasticsearch API применяют к traces* или метрикам с ограничением по времени и, когда это возможно, по service.name и service.environment. Длительность и event.outcome позволяют оценить задержку, пропускную способность и долю ошибок, а группировка по модели, сервису или времени помогает сравнивать нагрузку. Для расхода агрегируют входные и выходные токены по времени, модели или сервису; стоимость суммируют только если соответствующее поле реально есть в данных. Для качества и безопасности проверяют event.outcome, error.type, finish reasons, content-filter и guardrail-события, но промпты и ответы используют лишь тогда, когда они захвачены и не редактированы. Агентные цепочки анализируются по иерархии трасс: trace.id, span.id и parent.id связывают корневой span с дочерними вызовами LLM, инструментов и оркестратора. Это позволяет увидеть последовательность шагов, количество spans и узкие места по времени. Для SLO и оповещений навык предусматривает Observability APIs: SLOs API и Alerting API помогают найти правила, связанные с LLM-данными, и увидеть активные или недавно сработавшие сигналы. Открывать Kibana UI для самого процесса не требуется — предпочтительны Elasticsearch, ES|QL и API. Навык не является готовым универсальным дашбордом и не обещает одинаковые поля для всех провайдеров. ES|QL доступен в Elasticsearch 8.11 и новее, а источником рекомендуются только обнаруженные данные конкретного окружения. Перед большим запросом следует ограничивать временной диапазон, применять LIMIT и грубые временные интервалы; для больших потоков нельзя без проверки выполнять полный скан. Практический порядок такой: определить data streams, подтвердить mapping и пример документа, выбрать один согласованный путь данных для нужного сценария, выполнить запрос, затем учесть связанные SLO и alerts. Если в окружении нет нужных полей или интеграции, это ограничение результата, а не основание выдумывать отсутствующие метрики.