Метрики, логи и трассировка — Примеры

Пример 1 — Метка, которая называет каждый запрос

Сервис оформления заказов инструментирован счётчиком, и кто-то добавил идентификатор запроса как метку, чтобы отказы находились напрямую. Число рядов выросло настолько, что метрику стало дорого хранить, а график по ней нечитаем. Сохраните вопрос, на который должна была ответить метка, и исправьте инструментирование.

иллюстративные числа
http_requests_total{route="/checkout", status="200", request_id="a41f9c"} 3418
http_requests_total{route="/checkout", status="200", request_id="b7d2e0"} 1
http_requests_total{route="/checkout", status="200", request_id="c9f1a2"} 1

система мониторинга сообщает примерно 48 000 рядов для этой одной метрики

Решение

http_requests_total{route="/checkout", status="200", instance="api-3"} 3418
http_requests_total{route="/checkout", status="500", instance="api-3"} 12

помечено по: route, status, instance — измерения, по которым команда группирует
идентификатору запроса место в строке лога, где и живёт подробность

Метки разбивают ряд на измерения, поэтому метка с неограниченным множеством значений создаёт новый ряд на каждый запрос и ничего не отвечает, как только значение увидено. Ограничение метрики маршрутом, статусом и инстансом возвращает ей дешевизну и полезность для трендов и переносит подробность по каждому запросу в лог. Обычная ошибка — добавить идентификатор ради отладки и узнать о цене только когда хранилище вырастет.

Пример 2 — Две строки лога, которые нельзя соединить

Запрос проходит через шлюз и сервис оформления заказов; платёжный вызов отклонён, и расследованию приходится сводить логи двух сервисов по метке времени. Добавьте недостающий идентификатор и скажите, что он даёт.

{"time":"t1","service":"gateway","msg":"запрос получен","route":"/checkout"}
{"time":"t2","service":"checkout","msg":"платёж отклонён","route":"/checkout"}

Решение

{"time":"t1","service":"gateway","trace_id":"<trace-id>","msg":"запрос получен","route":"/checkout"}
{"time":"t2","service":"checkout","trace_id":"<trace-id>","span":"charge","duration_ms":810,"msg":"платёж отклонён"}

<trace-id> обозначает идентификатор, который платформа выдаёт в точке входа; подставьте свой.

участки трассировки для <trace-id>: gateway 12 мс -> checkout 940 мс -> charge 810 мс

Идентификатор задаётся один раз в точке входа и распространяется дальше, поэтому обе строки лога и участки трассировки описывают один запрос, а не два несвязанных события. Именно длительность участка указывает на медленный шаг, чего одни метки времени не могут. Обычная ошибка — записать идентификатор только в первом сервисе, оставив трассировку частичной и непригодной дальше по цепочке.