Собрать журнал инцидента без чужой загрузки: boot ID и cursor

После перезагрузки команда journalctl -u worker показывает свежий успешный запуск, хотя сбой случился до неё. При расследовании сначала нужно выбрать правильную историю. Номер загрузки, временное окно и курсор записи решают разные задачи и помогают не смешать несколько экземпляров сервиса.

Найти загрузку с инцидентом

journalctl --list-boots
journalctl -b -1 -u worker.service --no-pager
journalctl -b -1 -u worker.service --since "2026-11-02 21:10:00" --until "2026-11-02 21:20:00" -o short-iso-precise --no-pager

-b -1 выбирает предыдущую доступную загрузку относительно текущей истории. Для отчёта надёжнее сохранить её конкретный boot ID из list-boots: относительный номер изменится после следующей перезагрузки. Если прошлых загрузок нет, проверьте хранение журнала, ротацию и доступ пользователя, прежде чем считать, что событий не было.

Указывайте, в каком часовом поясе задан интервал. При передаче данных между командами полезен вывод с точным временем и смещением либо согласованный UTC. После изменений системных часов порядок по календарному времени может быть сложнее; внутри одной загрузки монотонное время помогает видеть последовательность.

Сохранить позицию последней записи

journalctl -u worker.service -b --since "-10 min" --show-cursor --no-pager
journalctl -u worker.service -b --after-cursor='CURSOR_FROM_PREVIOUS_OUTPUT' --no-pager

Во вторую команду переносится полное значение cursor из первой, без замены его временем. Это непрозрачный идентификатор позиции журнала. --after-cursor продолжает после указанной записи; обычный --cursor имеет другой смысл включения начальной позиции. Значение в примере — обозначение для подстановки, не реальный курсор.

Параметры описаны в journalctl. Для автоматического сохранения позиции есть --cursor-file при поддержке локальной версии. При первом запуске и выборе исходного интервала заранее определите, какую историю нужно читать.

Сохранить контекст запуска

Одинаковое имя службы может относиться к нескольким перезапускам внутри одной загрузки. В структурированном выводе смотрите _BOOT_ID, _SYSTEMD_INVOCATION_ID, PID и время. PID без boot ID и времени не является уникальным ключом инцидента. Для точечной проверки используйте journalctl -o verbose с подходящими фильтрами.

Например, в 21:14 один invocation завершился, в 21:15 другой успешно стартовал. Если взять только последние двадцать строк, причина предыдущего отказа исчезнет из выборки. Сохраните сообщения перед завершением вместе с событиями менеджера, чтобы видеть связь ошибки и рестарта.

Проверить полноту выгрузки

Откройте первую и последнюю запись сохранённого интервала и убедитесь, что обе относятся к нужной загрузке. Учитывайте права доступа: обычный пользователь может видеть только часть системного журнала. Ротация тоже может удалить старые записи, а cursor не восстанавливает утраченную историю.

В отчёте оставьте boot ID, временное окно, часовой пояс, фильтр unit и формат выгрузки. Такой набор позволяет коллеге повторить поиск, пока данные сохранены. Для длительного хранения используйте принятую в организации систему сбора журналов, а не надежду на бесконечный локальный retention.

Откройте программу Linux и Bash для DevOps-инженеров. Чтение журналов и разбор воспроизводимых сбоев учебного сервиса помогут собирать историю, которая объясняет причину, а не только показывает последний успешный запуск.

Ещё по теме

• Посчитать ошибки по сервисам в awk: агрегируем журнал за один проход
• Пустая колонка TSV сдвинула значение: выбираем разделитель awk