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

Расследование по журналам

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

Шаг 5 из 6 · лаба · 25 мин

Сайт отдаёт 500

Сайт бронирования гостиницы с какого-то момента отвечает гостям ошибкой 500, а в error.log nginx пусто. Установи по логам, когда начался сбой и что его вызвало, запиши это и верни сайт в строй.

Ситуация

Сайт бронирования гостиницы — 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 — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

0 из 4

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

node1 Ubuntu 24.04

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

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

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

Цели лабы

0 из 4

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

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

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).