Наблюдаемость: метрики, алерты, логи / Ступень 8 из 9 · шаг 5 из 6

Сайт отдаёт 500

~25 мин

Не запущена Запускается обычно ~20 с

Ситуация

Сайт бронирования гостиницы — http://booking.lab.test/: nginx принимает запросы и передаёт их приложению lab-booking. Гости пишут, что сайт отвечает «500 Internal Server Error». Дежурный уже открыл error.log сайта — там пусто. Руководитель просит короткий отчёт: с какого момента сайт сломан и какая строка в логах это объясняет. И сайт надо вернуть.

Логи сайта — /var/log/nginx/booking.access.log и /var/log/nginx/booking.error.log; приложение пишет в журнал systemd. И те и другие читаются через sudo.

Задача

Запиши в ~/incident.txt: - первой строкой — время начала сбоя с точностью до секунды (с этого момента сайт отдаёт 500) в виде, как в журнале или в access.log: 2026-10-22 04:41:25 или 22/Oct/2026:04:41:25; - ниже — строку из журнала приложения, которая показывает причину ответов 500.
http://booking.lab.test/ снова отвечает 200, и страницу отдаёт приложение lab-booking.
Сайт отвечает 200 и после перезапуска приложения: sudo systemctl restart lab-booking.

Ограничения

Код приложения /opt/booking/booking.py не меняй — причину ищи и устраняй в его настройках.
Проверка сама перезапускает lab-booking и запрашивает сайт с меткой в адресе: ответ должно дать приложение, а не nginx.

Посетители заходят на сайт и пока ты разбираешься — в логах прибавляются строки.

Цели лабы

0 из 4

http://booking.lab.test/ отвечает 200 — страницу отдаёт приложение lab-booking, его код не изменён — ещё не проверялась
В первой строке ~/incident.txt — время начала сбоя с точностью до секунды, с этого момента сайт отдаёт 500 — ещё не проверялась
В ~/incident.txt есть строка из журнала приложения, которая показывает причину ответов 500 — ещё не проверялась
Сайт отвечает 200 и после перезапуска приложения: sudo systemctl restart lab-booking — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Логи и аудит · подобрано по лабе

journalctl — логи и журнал systemd

Шпаргалка

$_ — вставить в терминал

journalctl -u nginx -f хвост логов службы
journalctl -xeu nginx разбор сбоя
journalctl -p err -b ошибки за текущую загрузку
journalctl -k сообщения ядра
journalctl _COMM=sshd -g fail по процессу + совпадение в тексте
journalctl -b -1 прошлая загрузка
journalctl --vacuum-time=7d чистка

Флаг	Смысл
`-u <unit>`	только эта служба
`-f` / `-e`	follow / сразу к концу
`-x`	пояснения к сообщениям
`-p <prio>`	приоритет: emerg..debug (или err, warning)
`-b [N]`	за текущую (или N-ю) загрузку
`-k`	сообщения ядра
`-g RE`	grep по тексту
`-o <fmt>`	формат: short, json, json-pretty, cat, verbose
`--since/--until`	временной диапазон

Фильтр по структурным полям (без службы):

bash

journalctl _PID=1234              # по PID
journalctl _COMM=sshd             # по имени процесса
journalctl _UID=1000 --since today
journalctl _SYSTEMD_UNIT=ssh.service -p warning
journalctl -o json-pretty -u nginx -n 1   # все поля одной записи
journalctl --user -u myapp        # пользовательская служба

Команды

bash

journalctl -u nginx               # записи службы nginx
journalctl -u nginx -f            # следить, как tail -f
journalctl -u nginx --since "10 min ago"
journalctl -xeu nginx             # хвост и пояснения при сбое
journalctl -p err -b              # только ошибки за текущую загрузку
journalctl -k                     # сообщения ядра (= dmesg)
journalctl --since today --until "1 hour ago"
journalctl -b -1                  # прошлая загрузка, до ребута
journalctl -g 'pattern'           # grep по сообщениям (регэксп)
journalctl --disk-usage           # сколько занимает
sudo journalctl --vacuum-time=7d  # подчистить старше 7 дней

По времени: --since и --until

bash

journalctl -u nginx --since '10 min ago'
journalctl --since '-5min' -t lab-app
journalctl --since '2026-10-22 05:10' --until '2026-10-22 05:20'
journalctl --since today --until '1 hour ago'
journalctl --since yesterday -p err

Время — абсолютное ('2026-10-22 05:10', секунды необязательны; время без даты — '05:10' — значит сегодня), unix-время после @ (@1792640000) или относительное ('10 min ago', -5min, today, yesterday, now). Зону задаёт часовой пояс машины, --utc показывает и понимает время в UTC. Неверное время журнал не угадывает: --since '25:00' — Failed to parse timestamp: 25:00.

Чтобы сопоставить журнал с логами nginx и приложения, выведи время с долями секунды и зоной — как в ISO-формате других логов:

text

$ journalctl -t lab-test -n 1 -o short-iso-precise
2026-10-22T05:18:46.155480+00:00 ubuntu lab-test[1536]:
  hello from forward

JSON: -o json и jq

-o json печатает каждую запись строкой JSON со всеми полями:

text

$ journalctl -t lab-test -n 1 -o json | jq -c '{__REALTIME_TIMESTAMP,
    _PID, PRIORITY, SYSLOG_IDENTIFIER, MESSAGE, _HOSTNAME}'
{"__REALTIME_TIMESTAMP":"1792646326155727","_PID":"1536","PRIORITY":"5",
  "SYSLOG_IDENTIFIER":"lab-test","MESSAGE":"hello from forward",
  "_HOSTNAME":"ubuntu"}

Вывод здесь перенесён. Все значения — строки, и число в них тоже: PRIORITY — "5". Поэтому в jq сравнивают со строкой: select(.PRIORITY == "3"); select(.PRIORITY == 3) не найдёт ничего.

Поле	Что в нём
`__REALTIME_TIMESTAMP`	время записи в микросекундах unix-времени, по UTC
`__MONOTONIC_TIMESTAMP`	микросекунды с загрузки машины
`MESSAGE`	текст
`PRIORITY`	уровень числом: 3 — `err`, 4 — `warning`, 5 — `notice`, 6 — `info`
`SYSLOG_IDENTIFIER`	метка программы, как у `-t`
`_SYSTEMD_UNIT`	служба, которая записала строку
`_PID`, `_COMM`, `_HOSTNAME`	процесс, его имя, машина
`_TRANSPORT`	откуда запись: `journal`, `syslog`, `stdout`, `kernel`

SYSLOG_IDENTIFIER — имя программы: у службы на Python это python3, а не имя службы; службу называет _SYSTEMD_UNIT. У записей ядра (_TRANSPORT — kernel) нет ни _SYSTEMD_UNIT, ни _PID.

-o json-pretty — то же с отступами, чтобы прочитать глазами. Время записи — в дату через jq:

text

$ journalctl -t lab-test -n 1 -o json \
  | jq -r '.__REALTIME_TIMESTAMP | tonumber / 1000000 | floor | todate'
2026-10-22T05:18:46Z

Время и текст столбцами для sort и grep:

bash

journalctl --since '-5min' -t lab-app -o json \
  | jq -r '[.__REALTIME_TIMESTAMP, .MESSAGE] | @tsv'

Свои строки в журнале: logger и -t

text

student@ubuntu:~$ logger -t cleanup "removed 3 files"
student@ubuntu:~$ journalctl -t cleanup --no-pager -n 2
Oct 20 10:50:48 ubuntu cleanup[1143]: removed 3 files

logger -t метка пишет строку в журнал от имени метки, journalctl -t метка показывает только её. Вывод скрипта, запущенного службой, идёт с меткой по имени скрипта: journalctl -t clean.sh. Без групп adm или systemd-journal student видит только свои записи — чужие и системные читай через sudo.

Журнал пустой после ребута

journald не persistent. Создай /var/log/journal (см. «Обзор»). journalctl -b -1 тогда покажет прошлую загрузку.

Диск забит журналом

journalctl --disk-usage, затем --vacuum-time=7d или --vacuum-size=500M. Постоянный лимит — /etc/systemd/journald.conf (SystemMaxUse=500M).

Нужны логи конкретного сбоя

journalctl -xeu <unit> --since "5 min ago" — самый частый диагностический запрос (см. systemctl).

Время в журнале «не то»

journald пишет в UTC внутри, показывает в локальной TZ. Сверь timedatectl; journalctl --utc для UTC.

Failed to parse timestamp

--since или --until не разобрал время. Формы, которые он понимает, — в journalctl: '2026-10-22 05:10', '10 min ago', -5min, today. Время с пробелом бери в кавычки.

Логи службы идут и в /var/log (дубли)

journald + rsyslog могут дублировать. Где смотреть — rsyslog (текстовые файлы) vs journalctl (структурно по -u).