Схема продакшн-лога: поля, которые несёт каждая строка

Два сервиса одной команды называют одно поле “status_code” в одном и “http_status” в другом. Каждый дашборд, который их соединяет, ломается. Фикс — не regex, а общая схема, которую проверяют до того, как код уехал в прод.

Что несёт каждая продакшн-log-строка

Продакшн-grade структурная log-строка в 2026 содержит как минимум эти поля, примерно в таком приоритете:

1. timestamp — ISO-8601 UTC с sub-second точностью: 2026-04-12T14:02:11.482Z. Основной sort-ключ любого backend’а.
2. level — строковый enum: TRACE / DEBUG / INFO / WARN / ERROR / FATAL. Контролирует, что хранится и кого пейджат.
3. service.name — OTel-каноничный ключ, идентифицирующий эмиттер. Join-ключ обратно к метрикам и трейсам.
4. trace_id и span_id — когда лог эмитится внутри traced-запроса, это join-ключи к tracing-backend’у. Без них pivot log → trace не работает.
5. message — короткое читаемое резюме. Единственное поле, которое скимят люди; остальное — для машин.
6. Event-specific поля — плоское key-value-дерево по OTel Semantic Conventions: http.route, http.response.status_code, db.system, error.type и т. д.
7. Resource-атрибуты — ставятся один раз на старте: host.name, cloud.region, service.version, deployment.environment. Описывают эмиттер, не событие.

OTel Logs Data Model

OpenTelemetry Logs specification (стабильный API конец 2023, SDK конец 2024) формализует это разделение. Log-record содержит:

• Timestamp — когда событие фактически произошло (ставится приложением).
• ObservedTimestamp — когда collector увидел запись. При clock-skew или backpressure они расходятся; senior-команды алертят на расхождение как pipeline-health-метрику.
• SeverityNumber — числовая лестница (TRACE=1-4, DEBUG=5-8, INFO=9-12, WARN=13-16, ERROR=17-20, FATAL=21-24), чтобы backend мог сравнивать severity через библиотеки с разными текстовыми label.
• Body — человекочитаемое сообщение.
• Attributes — flat key-value-карта event-specific-данных.
• Resource — ставится один раз на эмиттер (service.name, host.name, cloud.region).
• TraceId / SpanId / TraceFlags — W3C traceparent-контекст, наследуемый от активного span’а на emit-time.

Принять эту форму — даже на не-OTel-backend’е — даёт forward compatibility: можно менять backend без переписывания инструментации, и каждый дашборд и on-call-runbook может говорить одним словарём полей.

OTel Semantic Conventions: одно имя поля для всех сервисов

Semantic Conventions определяют канонические имена для общих полей: http.route (не route, не path, не url), http.response.status_code (не status, не http_status), db.system (не db_type), error.type. Это значит:

• Дашборд, запрашивающий http.response.status_code, работает одинаково для Node- и Go-сервисов.
• Alert-правило, ссылающееся на error.type:timeout, работает без per-service конфигурации.
• Новый сервис, принявший схему, наследует все существующие запросы.

Цена несоблюдения conventions — в incident response: когда checkout называет поле status, а payment-gateway — http_status, join-запрос ломается, и кто-то должен знать маппинг под давлением в 03:00.