Метрики говорят, что что-то не так (латентность выросла), логи — что конкретно упало, а трейс показывает, где по цепочке вызовов между сервисами реально ушло время. Tempo — бэкенд для хранения и поиска трейсов, принимает трейсы по OTLP (OpenTelemetry Protocol).
Запрос на TraceQL — язык, синтаксически близкий к PromQL/LogQL. Фигурные скобки выбирают набор спанов из доступных трейсов:
{ }
Без условий — вообще все спаны. Условие сужает выборку — например, конкретная операция конкретного сервиса:
{resource.service.name = "frontend" && name = "POST /api/orders"}
resource.service.name — атрибут ресурса (откуда пришёл спан), name — имя самой операции (span name). Найти трейсы с ошибкой на конкретной операции:
{resource.service.name = "frontend" && name = "POST /api/orders" && status = error}
Пайплайн-операторы (|) агрегируют уже выбранные спаны — например, оставить только трейсы, где больше двух спанов подряд отдали 5xx:
{ span.http.status_code >= 500 } | count() > 2
Технически TraceQL требует, чтобы блоки хранились в формате Apache Parquet — это формат хранения Tempo по умолчанию, отдельно настраивать обычно не приходится.
На практике самое полезное здесь не абстрактный поиск “по всем трейсам”, а конкретный сценарий: взял trace_id из строки лога (если он туда прокинут через логирование в приложении) или из ссылки в Grafana рядом с графиком латентности — и посмотрел полное дерево вызовов именно этого запроса, вместо того чтобы реконструировать путь запроса по обрывкам логов из разных сервисов вручную.
#prometheus #grafana #lgtm