Журнал сохраняет отдельные события, метрика агрегирует числа по своей семантике. Число событий внутреннего журнала не становится числом неуспешных операций клиента без правила связи.
Запись журнала
Определение
Запись журнала — сохранённое описание одного события: его время, содержимое, уровень важности и сведения о ресурсе, где оно произошло. Порядок доставки не всегда совпадает с порядком событий, поэтому записи сопоставляют по времени события и связи с запросом.
Также ищут: Log record · application log entry · структурированный лог · system log entry
Зачем это знать
Порядок доставки не всегда совпадает с порядком событий. Одинаковый текст не устанавливает общий запрос, а несколько записей об ошибке могут относиться к одной операции и её попыткам.
Карта понятия
Что подтверждено
Модель LogRecord в OpenTelemetry включает время события, уровень важности, содержимое, ресурс, атрибуты и необязательные TraceId и SpanId.
Граница применимости: Стабильная модель журналов OpenTelemetry; способ хранения и кодирования может отличаться.
Записи журнала можно сопоставлять с трассировками и метриками по времени, контексту трассировки и атрибутам ресурса.
Граница применимости: Сигналы с согласованными часами, атрибутами ресурса и переданным контекстом.
Событие А произошло в 10:00 и получено в 10:05; Б произошло в 10:02 и получено в 10:03. В порядке доставки Б будет раньше А, но по согласованным временам событий А произошло первым.
Граница применимости: Редакторский пример для двух известных событий и согласованных часов. При неизвестном смещении часов точный причинный порядок по одним временным отметкам не объявляется доказанным.
Два узла записали одинаковый текст «истёк срок ожидания» в одну секунду. Без общего контекста запроса эти записи нельзя уверенно объявить этапами одной операции. Нужны идентичность ресурса и переданная связь с запросом.
Граница применимости: Редакторская граница сопоставления журналов. Даже корректная связь записей показывает принадлежность, а не автоматически доказывает первопричину ошибки.
Одна клиентская операция породила три записи об ошибках внутренних попыток, после чего завершилась успешно. Три записи не означают три неуспешные клиентские операции. Уровень события и конечный результат услуги считают по разным правилам.
Граница применимости: Условный пример с известной связью всех записей и одним конечным успехом. Он не предлагает исключать ошибки из показателя, если согласованная модель считает сами попытки.
Не путать
Контекст TraceId и SpanId связывает запись с участком запроса. Трассировка показывает связанные участки, но полнота обоих сигналов зависит от сбора и сохранения.
Что проверить
- Сохраните время события и время получения отдельно.
- Укажите узел, ресурс и операцию.
- Проверьте согласованность часов перед сравнением времён.
- Ищите связь с запросом по контексту.
- Не связывайте события только по одинаковому тексту.
- Различайте внутренние попытки и конечную операцию.
- Сверяйте итог клиента независимо от числа строк об ошибках.
Первоисточники
- OpenTelemetry Logs Data Model
Определяет Timestamp, severity, body, resource, attributes, TraceId и SpanId LogRecord.
- OpenTelemetry Logging and Correlation
Описывает correlation logs, traces и metrics по time, trace context и resource context.
- Implementing SLOs
Описывает построение SLI/SLO от пользовательской цели, measurement window и error-budget policy.
Утверждения: 05
- OpenTelemetry Specification Overview
Описывает signals, raw measurements, aggregation, resources и context propagation.
- Signals
Определяет traces, metrics и logs как разные telemetry signals.