Сигналы OTel, Semantic Conventions и проводной формат OTLP

Ваши метрики идут в vendor-A, логи — в vendor-B, трассировки — в vendor-C. Запрос падает, но ни один бэкенд не согласен с другим по имени поля для сервиса. Кросс-сигнальная корреляция превращается в работу со спредшитом. Semantic Conventions OTel — это решение.

Три сигнала, одна модель данных

OTel охватывает три типа сигналов в стабильной форме. Каждый имеет собственный API, SDK-пайплайн и форму OTLP-сообщения, но все три разделяют два концепта: Resource (атрибуты эмиттера — service.name, host.name, cloud.region, устанавливаются один раз при старте сервиса) и Trace Context (trace_id, span_id), позволяющий перейти от строки лога к соответствующей трассировке.

Трассировки — GA с 2021 года. Основной рабочий инструмент. Каждый бэкенд поддерживает их. Трассировка — это дерево спанов, каждый из которых имеет время начала, длительность, статус и атрибуты. Ключ объединения между сервисами — trace_id, передаваемый через заголовок W3C traceparent.

Метрики — GA с 2023 года. API поддерживает счётчики, gauge, гистограммы и экспоненциальные гистограммы (новый стандарт для высокоточной задержки, заменяющий фиксированные бакеты). Метрики агрегируются внутри SDK перед экспортом; проводной формат содержит resource-metrics батчи.

Логи — API стабилен с конца 2023, SDK стабилен с конца 2024. Библиотеки-мосты (“OTel log bridge” для slf4j, structlog, pino) позволяют существующему коду отправлять OTel-логи без переписывания. Проводной формат содержит resource-logs батчи с теми же полями trace_id/span_id, что и у трассировок.

Профили — экспериментальные в конце 2024/2025, GA ожидается в 2026 году как четвёртый сигнал.

Semantic Conventions: общий словарь

Независимо от четырёхкомпонентной архитектуры, OTel публикует Semantic Conventions — нормативный набор имён атрибутов для типовых операций.

• Resource: service.name, service.version, deployment.environment, host.name, cloud.region
• HTTP: http.request.method, http.route, http.response.status_code, url.full
• Базы данных: db.system, db.operation, db.namespace
• Очереди сообщений: messaging.system, messaging.destination.name, messaging.operation

Это ключи объединения, благодаря которым метрики, логи и трассировки компонуются. Соблюдение Semantic Conventions — наиболее высокоуровневая практика в OTel: каждый авто-дашборд бэкенда и каждый кросс-командный запрос зависят от консистентного заполнения атрибутов. Зрелые платформенные команды создают языково-специфичную обёртку вокруг OTel SDK, которая предварительно конфигурирует извлечение атрибутов так, что о них нельзя забыть.

OTLP: проводной формат, связывающий всё вместе

OTLP — это определённый через protobuf проводной протокол с двумя транспортами:

• OTLP/gRPC — бинарный protobuf поверх HTTP/2. Предпочтительный вариант. Примерно на 50-70% меньше JSON, кодируется в 2-5 раз быстрее. Поддерживает стриминг.
• OTLP/HTTP — protobuf или JSON поверх HTTP/1.1. Существует для сред, где gRPC заблокирован (некоторые файрволы), или для браузерной телеметрии.

Три OTLP-сообщения: ExportTraceServiceRequest, ExportMetricsServiceRequest и ExportLogsServiceRequest. Каждый OTel-совместимый бэкенд предоставляет OTLP-эндпоинт. Проводной формат стабилен уже несколько лет и развивается с обратной совместимостью.

Контракт vendor-нейтральности: если ваш edge (приложение или его sidecar) отправляет OTLP — вы vendor-нейтральны. Если edge отправляет проприетарный формат — нет, даже если шлюз позже конвертирует.