Production и облако · Production and cloud · урок 7 · 13 мин

Наблюдаемость: traces, logs, четыре сигнала

Observability: traces, logs, the four golden signals

Пройдено

Зачем

После урока ты перечислишь, что записывать про каждый запрос к агенту, чтобы неверный ответ можно было разобрать по шагам, переложишь четыре сигнала мониторинга на LLM-систему и объяснишь, как отлаживать, не записывая персональные данные. Это вопросы «how would you monitor this agent in production?» и «a customer complains about a wrong answer yesterday — what do you look at?».

Logs, metrics, traces: три разных вопроса

Metrics (метрики) — числа во времени: запросов в секунду, p95 latency, доля ошибок. Отвечают на вопрос «что-то не так?» и питают alerts (автоматические оповещения).
Logs (журналы) — записи о событиях: «tool block_card вернул ошибку 409». Отвечают «что произошло в этой точке?».
Traces (следы запросов) — дерево шагов одного запроса. Каждый шаг — span (отрезок с началом, концом и атрибутами): retrieval, rerank, вызов модели, вызов tool. Отвечают «где именно в цепочке сломалось?».

Для агента traces важнее всего. Один вопрос клиента — это 5–15 шагов, и неверный ответ почти всегда рождается на одном из них: retrieval не нашёл документ, rerank выкинул нужный chunk, модель выбрала не тот tool. Без trace диагностика превращается в гадание по финальному тексту.

Что писать в trace одного запроса

Минимальный набор полей для RAG-агента:

Поле	Зачем
request ID, conversation ID	связать все шаги и все реплики
ID release bundle	какая версия ответила (урок a7-3)
язык, сегмент, канал	считать метрики по срезам
модель и её параметры	что именно отвечало
хэш prompt template	какая версия prompt, без текста
input и output tokens, стоимость	деньги и длина context
latency каждого span, время до первого token	где тратится время
ID chunks, версии документов, оценки (scores) до и после rerank	разобрать retrieval
вызовы tools: имя, статус, длительность	разобрать действия
вердикты guardrails	что заблокировано и почему
finish reason, отказ, передача человеку	чем закончилось
оценка пользователя	связать жалобу с trace

Стандарт для таких полей — OpenTelemetry GenAI semantic conventions. Они живут в отдельном репозитории и на 10.10.2026 помечены как Development, то есть ещё меняются. Там описаны имена атрибутов вида gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.conversation.id и имена spans вида execute_tool {gen_ai.tool.name}. Зачем стандарт: traces в этом формате понимают разные платформы, и сменить инструмент наблюдения можно без переписывания кода.

Сколько это стоит хранить — посчитай заранее. 100 000 запросов в день × 10 spans × 2 КБ на span = 2 ГБ в день, около 60 ГБ за месяц (допущения для примера). Обычная политика: traces с ошибкой, срабатыванием guardrail, передачей человеку или низкой оценкой хранят все, успешные — выборкой, например 10 %. Агрегированные метрики живут долго, сырые traces — недели.

Не писать в журнал то, что нельзя потерять

Журналы читает много людей и систем, и живут они долго. Поэтому в них не пишут сырые персональные данные, секреты и полные тексты разговоров. Те же conventions OpenTelemetry говорят прямо: инструкции, сообщения пользователя и ответы модели чувствительны, инструментация «SHOULD NOT capture them by default», запись включается только явно.

Отсюда вопрос из интервью: зачем в журнале хэш prompt, а не сам prompt? Хэш однозначно указывает на версию шаблона в Git — её можно открыть и воспроизвести. Сам текст с подставленными данными клиента сделал бы журнал хранилищем персональных данных: большой, долгоживущий и доступный слишком многим.

Как тогда отлаживать: - в trace — ID и хэши: chunk IDs, версии документов, bundle ID; по ним восстанавливается, что видела модель; - значения маскируются до записи (номер карты → ****1234); - полные тексты — только для выборки и только в отдельном хранилище с ограниченным доступом, шифрованием и коротким сроком хранения; - воспроизведение: тот же bundle плюс те же входы, прогнанные несколько раз, потому что генерация случайна.

В облаке это видно по умолчаниям: в Amazon Bedrock полное журналирование вызовов выключено, пока его не включат, и пишет только в хранилище того же аккаунта и региона (урок a7-5). Включая его, команда сама создаёт хранилище персональных данных и отвечает за его защиту.

Четыре сигнала, переложенные на агента

Google SRE book называет четыре «golden signals» — то, что мерить, если можно мерить только четыре вещи: latency, traffic, errors, saturation. Для LLM-агента они выглядят так:

Сигнал	В обычном сервисе	В LLM-агенте
Latency	время ответа	время до первого token и до конца ответа, по шагам; p95 и p99
Traffic	запросов в секунду	разговоров и tokens в секунду, по языкам и каналам
Errors	HTTP 500	явные: таймауты, ошибки tools; неявные: срабатывания guardrails, отказы, битая схема, неверные ответы на выборке judge
Saturation	загрузка CPU	очередь сервера модели, занятость KV cache, остаток квоты API по tokens

Три поправки из той же главы SRE book. Latency успешных и неудачных запросов считают отдельно: быстрые ошибки занижают среднее, а «a slow error is even worse than a fast error». Среднее прячет хвост: сервис со средним 100 мс может отвечать 1 % запросов за 5 с, поэтому смотрят перцентили. И saturation начинается раньше 100 %: система тормозит задолго до полной загрузки.

Пример. Агент отвечает в среднем за 3 с, но p99 — 25 с. Trace показывает: долгие запросы — те, где модель трижды вызывает поиск по базе транзакций. Это не проблема GPU, а проблема инструмента: tool возвращает слишком много строк, модель переспрашивает. Метрики сказали «что-то не так», trace сказал «где».

От сигнала к действию

Alert ставят на то, что видит клиент: рост p95, рост доли ошибок, рост передач человеку, а не на загрузку CPU. Каждый alert ведёт к dashboard (панели) со срезом по версии и языку, оттуда — к конкретным traces. Раз в неделю люди читают выборку разговоров: неявные ошибки — уверенный неверный ответ — метрики не поймают. Эти разобранные разговоры становятся новыми задачами в eval-наборе, и круг замыкается.

Схема

alert по метрике (p95, ошибки, передачи)

dashboard: срез по версии и языку

trace: span retrievalrerankmodeltool

шаг, где сломалосьfixзадача в eval-набор

Термины · Key terms

metrics: числа во времени для alerts и графиков
logs: записи о событиях в конкретной точке системы
trace: дерево шагов одного запроса
span: один шаг trace с началом, концом и атрибутами
OpenTelemetry: открытый стандарт для traces, metrics и logs
GenAI semantic conventions: стандартные имена атрибутов для вызовов моделей и агентов
golden signals: latency, traffic, errors, saturation
p95 / p99: время, в которое укладываются 95 % / 99 % запросов
time to first token: время до первого кусочка ответа модели
saturation: насколько загружен самый узкий ресурс системы
redaction: маскировка чувствительных значений до записи

Сделай сам

Выпиши не меньше десяти полей trace одного запроса к RAG-агенту банка («какая комиссия за перевод в евро?») и у каждого поля пометь: можно писать как есть, писать только хэш или ID, или не писать вовсе. Затем для каждого из четырёх golden signals назови одну метрику этого агента.

Обсуди с тьютором: покажи список и спроси, по каким полям ты найдёшь причину, если клиент пожаловался, что вчера ассистент назвал неверную комиссию.

Проверь себя · ответ под вопросом

1Зачем в журнале хэш prompt, а не сам prompt?

Хэш однозначно указывает на версию шаблона в Git, по нему prompt можно открыть и воспроизвести. Полный текст с подставленными данными клиента превратил бы журнал в долгоживущее хранилище персональных данных, доступное многим. Тексты держат отдельно, выборочно и под ограниченным доступом.

2Переложи четыре сигнала мониторинга на LLM-агента.

Latency — время до первого token и до конца ответа по шагам, в перцентилях. Traffic — разговоры и tokens в секунду по языкам. Errors — явные (таймауты, ошибки tools) и неявные (отказы, срабатывания guardrails, неверные ответы на выборке). Saturation — очередь сервера модели, занятость KV cache, остаток квоты API.

3Что нельзя писать в logs и как тогда отлаживать?

Сырые персональные данные, секреты и полные тексты разговоров. Вместо них пишут ID и хэши: request ID, bundle ID, chunk IDs, версии документов, маскированные значения. Полные тексты — только выборочно, в отдельном защищённом хранилище с коротким сроком, а воспроизводят по тому же bundle и тем же входам.

Interview questions · US / UK

1How would you monitor an LLM agent in production? What signals and what alerts?

Strong answer: the four golden signals mapped to LLMs: time to first token and total latency in percentiles, conversations and tokens per second, explicit and implicit errors, queue and KV cache saturation; alerts on customer-visible symptoms; slices by version and language; weekly human review because confident wrong answers don't show in metrics.

2A customer says the assistant gave a wrong fee yesterday. What must already be in place to find out why?

Strong answer: a trace per request with request and conversation IDs, release bundle ID, model, prompt hash, chunk IDs with document versions and rerank scores, tool calls and guardrail verdicts; find the failing span; reproduce with the same bundle and inputs several times; add the case to the eval set.

3How do you debug without logging customer data?

Strong answer: log IDs and hashes, not content; redact before writing; full content only for a sample in a restricted, encrypted store with short retention; OpenTelemetry GenAI conventions make content capture opt-in; reproduce from versioned inputs rather than raw transcripts.

Ключевые фразы · Say it aloud

Metrics tell me something is wrong; traces tell me whereметрики говорят «что-то не так», traces — «где»
Every trace carries the release bundle IDв каждом trace есть ID версии
I log the prompt hash, not the promptпишу хэш prompt, а не сам prompt
Content capture is opt-inзапись содержимого включается только явно
A slow error is worse than a fast errorмедленная ошибка хуже быстрой
I alert on symptoms customers see, not on CPUоповещение на то, что видит клиент, а не на CPU

Материалы

Google SRE book — Monitoring Distributed Systems — раздел «The Four Golden Signals» и про хвост latency (12 мин)
OpenTelemetry — GenAI spans — имена spans и атрибутов, запись содержимого только по opt-in (10 мин)
Hamel Husain — Your AI Product Needs Evals — почему смотреть в traces руками и как это превращается в eval (15 мин)
Amazon Bedrock — Model invocation logging — полное журналирование выключено по умолчанию, что пишется и куда (6 мин)