Логи, метрики и трейсы: что на какой вопрос отвечает
Трейсы, метрики и логи — три вида телеметрии, которые отвечают на разные вопросы. Метрика показывает, что что-то идёт не так и насколько сильно. Трейс — на каком участке запрос потерял время или сломался. Лог — что именно произошло в этом месте кода. Это рабочее упрощение, а не закон: трейс с атрибутами может ответить и на «почему», а лог с длительностью — и на «где». Трейс здесь — запись трассировки одного запроса, а не стек вызовов при ошибке. Три сигнала — соглашение, а не полный перечень видов телеметрии. Слово «сигнал» в материале о четырёх базовых метриках значит другое: там это одна из метрик, здесь — вид телеметрии.
Короткий ответ и его оговорки
Метрика — это число, которое меняется во времени и снабжено метками. Метки — пары «ключ — значение», которые описывают контекст измерения: например, service="auth", status="500". Метки позволяют разрезать данные по разным измерениям: посмотреть число ошибок только для одного сервиса или только для одного метода.
Метрики бывают трёх основных видов: счётчик, мгновенная величина и гистограмма. Счётчик только растёт: число запросов, число ошибок. В накопительной схеме передачи счётчик обнуляется при перезапуске процесса, а скорость вычисляется как разность соседних значений. Мгновенная величина показывает состояние на момент съёма: длина очереди, занятая память. Гистограмма раскладывает наблюдения по корзинам с заранее выбранными границами: например, длительности запросов — по диапазонам длительности.
Счётчик между двумя съёмами событий не теряет: число запросов метрика сохраняет, теряет она их порядок и то, какие именно это были запросы. Мгновенная величина теряет всплеск, случившийся между двумя съёмами. Гистограмма теряет точное значение каждого наблюдения: внутри корзины все они неразличимы, а о тех, что оказались выше последней границы, известно лишь, что они больше неё.
Цена метрик определяется не потоком запросов, а числом временных рядов — числом реально встретившихся сочетаний значений меток. Сверху оно ограничено произведением числа значений по каждой метке. Гистограмма умножает это число ещё на количество корзин. Дальше цену умножают частота съёма и срок хранения. Метка с неограниченным множеством значений — идентификатор пользователя, идентификатор запроса, полный адрес — порождает отдельный ряд на каждое значение. Ряд, переставший обновляться, занимает место до конца срока хранения.
Метрика отвечает только на вопросы, предусмотренные заранее: разрез возможен лишь по тем меткам, что поставлены при инструментировании, а исходные события из агрегата восстановить нельзя. Какие четыре метрики заводить первыми, разбирается в материале «С каких метрик начинать».
Лог: запись об одном событии
Лог — это запись об одном событии с подробностями. Запись может быть текстовой или структурированной — из полей «ключ — значение». Структурированный лог устойчив к смене формулировки: счёт идёт по полю, а не по тексту. Идентификатор запроса собирает записи разных сервисов вместе, но не даёт ни вложенности, ни длительностей участков: длительность есть в записи, только если звено само записало её отдельным полем.
Объём и цена логов растут вместе с потоком запросов, а полнота логов не гарантирована. Записи отсекаются уровнем логирования, теряются при переполнении буфера доставки и при падении процесса до сброса буфера. Запись лога без идентификатора запроса не привязана ни к какому запросу.
Трейс и выборка: дерево спанов одного запроса
Трейс — это дерево спанов одного запроса. Спан — участок пути запроса с отметками начала и конца; спаны связаны отношением «родитель — потомок». На вопрос, на каком участке ушло время, отвечают длительности спанов, а не сравнение отметок между сервисами: отметки ставят часы той машины, где спан выполнялся, а часы разных машин могут расходиться.
Трейс через несколько сервисов собирается, только если идентификатор трейса и идентификатор родительского спана передаются с каждым вызовом — в заголовках запроса или в метаданных сообщения очереди. Внутри процесса контекст тоже приходится переносить — при передаче работы в пул потоков, в отложенную задачу и в обратный вызов: там, где его не перенесли, дерево рвётся так же, как на непересланном заголовке. Рвёт трейс звено, не переславшее заголовки дальше. Звено, которое само спанов не пишет, но заголовки пересылает нетронутыми, трейс не рвёт — в нём просто нет его участка.
В распространённой схеме инструментирования спан отправляется при завершении операции. В такой схеме от запроса, который завис или чей процесс упал, в трейсе остаются только успевшие завершиться участки либо не остаётся ничего. Запись лога, уже ушедшая из процесса до падения, сохраняется. Зависший участок виден в логе и в метрике числа запросов в работе, а в трейсе его нет, пока он не завершился.
Выборка — правило, по которому решают, какие трейсы сохранять, а какие отбросить. Это настройка, а не свойство трейсов: включена ли она и какая задана доля, смотрят у себя — в настройках инструментирования и сборщика, промежуточного звена, которое принимает спаны от сервисов и передаёт их в хранилище. Решение принимают либо в начале запроса, когда ещё неизвестно, окажется ли он ошибочным или медленным, либо в конце — в распространённой схеме в сборщике, который судит по спанам, успевшим прийти за заданное время.
Число запросов и долю ошибок по трейсам можно получить одной общей поправкой только при вероятностной выборке в начале, где вероятность сохранения известна. При выборке в конце сохранённое смещено намеренно: ошибочные и медленные трейсы представлены в хранилище гуще, чем в потоке. Без веса, записанного у каждого трейса, считать по ней нельзя. Поэтому там, где выборка включена, число запросов и долю ошибок нельзя считать прямо по сохранённым трейсам: число сохранённых — уже не число запросов, а при выборке в конце и доля ошибочных среди сохранённых — не доля ошибок в потоке. Для счёта служат метрики.
Подробности о модели трейсов, передаче контекста и выборке — в материалах «Трассировка шагов вместо логов» и «OpenTelemetry: что стало стандартом, а что ещё нет». Что писать в трассировку, а что нет, разбирается в «Что писать в трассировку, а что нет».
Как сигналы связывают
Идентификатор трейса и спана в каждой записи лога и образец трейса у измерения метрики дают переход от всплеска на графике к конкретному запросу и к его записям. Оба приёма работают, если ваш инструмент это умеет.
Переход работает только на пересечении. Логи и метрики выборкой не прорежены и рассчитаны на каждый запрос, хотя полноты не гарантируют. Трейс сохраняется только для запросов, попавших в выборку. Идентификатор в записи лога — мост между сигналами, который трассировку не заменяет. В материале «Трассировка шагов вместо логов» идентификатор в каждой строке подаётся как тупик — замена трассировке, здесь — как связка сигналов.
Тупик: почему одних логов недостаточно
Первым пробуют обойтись одними логами: писать всё, при сбое искать по слову «ошибка», а графики и оповещения строить подсчётом строк. Не помогает: счёт поиском по тексту молча ломается при смене формулировки. У структурированного лога, где счёт идёт по полю, остаются цена, растущая вместе с потоком, и потеря записей под нагрузкой. Записи с общим идентификатором собираются в кучу, а не в дерево, и на вопрос «где запрос потерял время» отвечают лишь настолько, насколько каждое звено само записало свою длительность.
Обратная крайность — идентификатор пользователя в метке метрики, чтобы «всё видеть на графике». Это ломает хранилище метрик числом рядов.
Позиция редакции
Три сигнала не взаимозаменяемы. Заводить их надо не все сразу «для полноты», а по вопросу, на который сейчас нет ответа. Метрики на входе и структурированные логи с идентификатором запроса — первыми из трёх видов телеметрии. Трассировку — когда запрос проходит больше одного сервиса или когда выполнение внутри одного процесса ветвится и повторяется. Порядок работы в инциденте — от метрики к трейсу и от трейса к записям лога.
Позиция неверна, если хранилище событий позволяет при вашем потоке считать агрегаты прямо по сырым подробным событиям за время, пригодное для оповещения. Тогда отдельный контур метрик дублирует то, что выводится из событий, а события к тому же отвечают на вопросы, которых заранее не предвидели. В части «не взаимозаменяемы» позиция неверна и для одного процесса с одной базой и линейным выполнением: там лог с длительностями заменяет трейс, который почти ничего к нему не добавляет.