Источник зависит от компонента: файлы приложения, journald, вывод контейнера, журналы прокси или централизованная система. Начните с времени сбоя и часового пояса, окружения, сервиса и request ID. Сопоставляйте события до и после ошибки, учитывайте ротацию и скрывайте секреты при передаче логов.
Как и где вы смотрите логи?
Как выбирать источник логов, ограничивать поиск временем и идентификатором запроса, восстанавливать последовательность событий и безопасно передавать результаты диагностики.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Выбор источника зависит от того, какой компонент исследуется и куда настроена запись событий. У приложения это могут быть файлы, у службы Linux — журнал journald, у контейнера — стандартный вывод, доступный через docker logs. Также полезны журналы веб-сервера, прокси и централизованная система сбора логов, если она используется в конкретной среде.
Сначала уточняют время проблемы и часовой пояс, окружение, затронутый сервис, действие пользователя и идентификатор запроса. Затем ограничивают выборку нужным интервалом и ищут связанные события по request_id или trace_id, если такие идентификаторы есть. Важно читать не только строку ERROR, но и контекст до и после нее: первая видимая ошибка может оказаться следствием более раннего сбоя.
Для локальной диагностики подходят less, tail и поиск по файлу; для службы — journalctl -u <service>, для контейнера — docker logs --since <time> <container>. Успех этих команд зависит от прав доступа и конфигурации журналирования. Также учитывают ротацию, срок хранения и возможные различия часов между системами.
В ответе на интервью называйте только знакомые вам инструменты, отделяя практический опыт от теории. Перед передачей фрагментов логов убирайте токены, пароли и персональные данные. Полученные наблюдения сопоставляйте с метриками и трассировками: сами по себе логи не всегда доказывают причину инцидента.