Трейсы

Распределённый tracing — третий бэкенд L1 после Prom и Loki. Как и они, он следует ADR-014: edge'ы пушат напрямую, manager только запрашивает.

Плоскость данных

your apps (OTLP gRPC/HTTP)
    │
    ▼
edge:
  otelcol (subprocess plugin)
    └─ remote OTLP → tempo:4317
                          │
                          ├─ trace storage (S3-compatible blob)
                          │
                          └─ metrics_generator → traces_spanmetrics_*
                                                       │
                                                       ▼
                                                 prometheus:9090

otelcol запускается как плагин под edge-агентом (та же модель контроля, что и promtail — см. Логи). Коллектор принимает и gRPC (:4317), и HTTP (:4318) на хосте, батчит, и форвардит в облачный Tempo через HTTPS.

Приложениям не нужно знать про Ongrid

Сконфигурируйте OTel-экспортер вашего приложения на http://localhost:4318 (или gRPC-эквивалент). Локальный otelcol обрабатывает auth + батчинг + поход в облако. Удаление Ongrid означает удаление одной env-переменной — ваш код не тронут.

Генератор spanmetrics

Развёртывание Tempo в compose имеет включённый metrics_generator. Каждая партия span'ов производит три производные метрики, эмитированные обратно в тот же Prom:

Серия	Источник
traces_spanmetrics_calls_total	один counter на (service, operation, status_code)
traces_spanmetrics_latency_bucket	гистограмма длительности span'а
traces_spanmetrics_size_bucket	опционально, по умолчанию выкл

Это load-bearing трюк, который делает trace-алерты как metric-алерты: alert evaluator запрашивает Prom, данные живут в Tempo.

Типы алертов

trace_latency

{
  "kind": "trace_latency",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "operation": "POST /v1/charge",
    "quantile": "p95",
    "window": "5m",
    "threshold_ms": 800
  }
}

Компилируется в:

histogram_quantile(
  0.95,
  sum by (le) (rate(traces_spanmetrics_latency_bucket{
    service_name="payments-api", span_name="POST /v1/charge"
  }[5m]))
) * 1000 > 800

operation опционален — уберите его для service-wide latency. См. compileTraceLatencyRule.

Поддерживаемые квантили: p50 / p95 (по умолчанию) / p99. Строковая форма существует, чтобы picker UI-формы оставался лаконичным; компилятор мапит во float, который хочет histogram_quantile.

trace_error_rate

{
  "kind": "trace_error_rate",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "window": "5m",
    "operator": ">",
    "threshold_pct": 1.0
  }
}

Компилируется в:

100 * (
  sum by (service_name) (rate(traces_spanmetrics_calls_total{
    service_name="payments-api", status_code="STATUS_CODE_ERROR"
  }[5m]))
  / sum by (service_name) (rate(traces_spanmetrics_calls_total{
    service_name="payments-api"
  }[5m]))
) > 1.0

Литерал STATUS_CODE_ERROR — это то, что эмитит spanmetrics-генератор; альтернативные конвенции span status требуют своего kind.

Инструменты

query_traceql

Прямой проброс на TraceQL-эндпоинт Tempo (query_traceql_basetool.go). Используется персоной investigator, когда оператор просит конкретные trace ID — например, «найди медленный trace для payments-api за последние 30 минут».

{ resource.service.name="payments-api" } | duration > 800ms

Базовый клиент — internal/pkg/tracequery; имя пакета backend-decoupled намеренно — клиенты Jaeger / Zipkin могут подключиться позже без переименования поверхности.

correlate_incident

Композитный инструмент, с которого начинает персона investigator. Подтягивает Prom + Loki + Tempo сигналы вокруг fire-окна инцидента в одном fan-out вызове. Сокращает 4-5 последовательных вызовов инструментов до одного — важно, когда бюджет на расследование — 10 вызовов инструментов.

См. correlate_incident_basetool.go.

См. также

• Алерты — типы правил.
• Мониторинг — Prom-бэкенд, который запрашивают trace-алерты.
• Топология — service-to-service рёбра, которые metrics_generator Tempo выводит автоматически.
• Плоскость данных телеметрии — ADR-014 полностью.