# После перезапуска неверное время: TLS-ошибки и порядок событий в логах

Диагностика: После перезапуска неверное время: TLS-ошибки и порядок событий в логах. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/clock-skew-tls-telemetry/
Language: ru

Неверные часы узла способны вызвать TLS not yet valid и исказить порядок событий в логах. Сначала сравните текущее время и certificate validity. Для телеметрии различайте Timestamp источника и ObservedTimestamp сборщика: они не являются двумя измерениями одного и того же момента.

## Найдите часы, которыми проверяют сертификат

Сохраните UTC-время узла, контейнера и доверенного контрольного источника, учитывая доступные полномочия. Контейнер обычно зависит от времени хоста, но приложение может преобразовывать часовые пояса и форматировать логи отдельно. Ошибка отображения timezone не обязательно означает неверный system clock. Запишите сырой timestamp и его единицу. Для TLS важен момент проверки относительно notBefore/notAfter, а не локально отформатированная строка времени в интерфейсе оператора или dashboard.


[Официальный источник 1](https://www.rfc-editor.org/rfc/rfc5280.html).

## Проверьте validity и identity отдельно

RFC 5280 задаёт период валидности сертификата от notBefore до notAfter включительно. Сравните его с фактическими часами клиента, затем отдельно проверьте цепочку и имя сервиса. Не перевыпускайте сертификат автоматически при каждом not yet valid: проблема может быть в узле после восстановления или старта. В то же время корректные часы не исправляют действительно истёкший сертификат. Сохраните fingerprint, чтобы сравнение до и после касалось одного и того же leaf.


[Официальный источник 2](https://opentelemetry.io/docs/specs/otel/logs/data-model/).

## Разберите два времени логирования

OpenTelemetry Timestamp отражает время события по часам источника, ObservedTimestamp — время, когда событие увидел сборщик. В учебном случае worker ошибается по времени на 5 минут, а Collector принимает записи с правильными часами. Сортировка по Timestamp меняет видимую последовательность между узлами. Сортировка по ObservedTimestamp показывает приём, но не восстанавливает истинную причинность при сетевой задержке и buffering. Число 5 минут иллюстрирует расхождение, а не допустимый эксплуатационный порог.

| Поле | Значение в расследовании |
| --- | --- |
| System UTC | Основа клиентской проверки времени |
| Certificate validity | Разрешённый интервал сертификата |
| Timestamp | Часы источника события |
| ObservedTimestamp | Часы места наблюдения |

## Исправьте источник времени

Проверьте предусмотренный механизм синхронизации узла и состояние после reboot/restore. Не двигайте системные часы произвольно в рабочем окружении без оценки влияния на процессы и наблюдаемость. Отдельно исправьте неверное преобразование timezone, если raw timestamps корректны. В отчёте укажите, какой слой изменён: host synchronization, application formatting или Collector processing. Это разные операции, и их результаты нельзя объединять в один недоказанный вывод о восстановлении времени всего распределённого сервиса.

## Сохраните проверяемую последовательность

Повторите TLS-подключение тем же клиентом и сравните события по обеим временным шкалам. Сохраните исходные raw записи, величину расхождения и момент исправления. Если часы делали скачок, отметьте границу, за которой прежние сравнения длительности ненадёжны. Артефакт позволяет интерпретировать исторические логи без их молчаливого переписывания. Успех состоит в корректной новой проверке и понятной истории старых событий, а не в искусственно красивом порядке строк на dashboard.

Связанные разборы: [gpu owner network outage log](/ru/journal/gpu-owner-network-outage-log/); [gpu monitoring scorecard](/ru/journal/gpu-monitoring-scorecard/).