OTel Logs Data Model и audit-логи как подсистема

Команда проходит SOC 2 аудит. На следующий год они меняют log-backend. Переписывают log-схему, передеплоивают collector и ломают audit-log-запросы, от которых зависит compliance-команда. Log-схема была vendor-proprietary, не OTel. Разделение audit-логов никогда не было формализовано. Следуют два месяца remediation.

OTel Logs Data Model

OpenTelemetry Logs specification (API стабилен: конец 2023; SDK стабилен в большинстве языков: конец 2024) определяет log-запись как типизированную структуру со следующими полями:

• Timestamp: когда событие произошло (выставляется приложением).
• ObservedTimestamp: когда collector наблюдал запись. При clock skew или backpressure collector’а они расходятся — senior-команды алертят на (ObservedTimestamp - Timestamp) p99 > 60s как pipeline-health-метрику.
• SeverityNumber: числовая лестница (TRACE=1-4, DEBUG=5-8, INFO=9-12, WARN=13-16, ERROR=17-20, FATAL=21-24) для сравнения severity между библиотеками с разными text-label (DEBUG vs Debug vs debug vs trace).
• SeverityText: human-readable label (например "INFO", "ERROR").
• Body: human-readable log-message.
• Resource: per-emitter атрибуты, выставляемые один раз при старте сервиса — service.name, host.name, cloud.region, service.version, deployment.environment. Это OTel Resource-концепция, не per-event поля.
• Attributes: flat key-value-карта event-specific данных с OTel Semantic Conventions — http.route, http.response.status_code, db.system, error.type, exception.type.
• TraceId, SpanId, TraceFlags: наследуются от активного span’а на emit-time (рассмотрено в уроке 06).

Wire-формат — OTLP/Logs: protobuf поверх gRPC или HTTP/1.1. Compressed OTLP на 30-50% меньше эквивалентного JSON, что важно в масштабе парка.

Почему vendor portability важна

Принятие OTel Logs Data Model сегодня означает, что смена backend — изменение конфига collector’а, не переписывание инструментации. Сервис, эмитирующий OTel-shaped логи сегодня, может направить OTel Collector на Honeycomb, ClickHouse, Loki, Datadog (через OTLP-receiver) или Splunk (через OTel-ingest path), изменив один exporter-блок. Никаких изменений application-кода.

Обратное — эмиссия в vendor-proprietary схему — залочивает каждый log-call-site на field-names и ingest-формат этого вендора. Cost миграции — по сути реинструментация каждого сервиса.

Комбинация «дёшево принять» (каждый современный logger SDK OTel-compatible или имеет тонкий адаптер) и «дорого отложить» — определение no-regret архитектурного выбора.

Audit-логи как подсистема первого порядка

Операционные логи отвечают «почему сервис медленный?» Audit-логи — «кто, что, когда, с каким ресурсом?»

Они разделяют JSON-схему и trace_id. Но отличаются по трём осям, делающим их смешивание compliance failure:

Retention: операционные логи хранятся 7-90 дней (hot/warm/cold tier’ы). Audit-логи хранятся 1-7 лет (SOC 2: 1 год; HIPAA / PCI DSS: 7 лет). Единый индекс с 30-дневным retention тихо удаляет audit-события, которые compliance требует хранить годами.

Immutability: операционные логи можно удалять (retention policies, right-to-erasure, cost control). Audit-логи обязаны быть append-only — hash-chained или криптографически подписанными — чтобы tampering было обнаружимым. Многие compliance-фреймворки явно требуют верифицируемой целостности audit-логов.

Access: операционные логи читаемы dev- и on-call-командой. Audit-логи читаемы узкой ролью (platform security team + внешние аудиторы) с audit-of-audits: доступ к audit-log-индексу сам логируется.

Архитектурный паттерн: эмитировать audit-события через тот же logger SDK, что и операционные, но с атрибутом category: "audit". Collector маршрутизирует строки category=audit через отдельный pipeline в dedicated backend-индекс с более строгими свойствами retention, immutability и access. Всё остальное идёт в операционный pipeline. Маршрутизация прозрачна для приложения — оно просто выставляет поле.

Что принадлежит audit-логам: auth-события (login, logout, failed login), изменения авторизации (role grants, permission changes), доступ к данным на регулируемых записях (чтение health или financial data клиента), изменения конфигурации (ротация secrets, изменения access control list). Схема уже, чем у операционных логов: типично who, what, when, resource, outcome, trace_id.