Был ли опыт подключения через SSH и какие команды используете для просмотра логов
Что проверяют
Сможете ли вы сами дойти до причины бага на тестовом стенде, а не ограничиться скриншотом с ошибкой 500. Следом просят показать, как найти в логе конкретный запрос, или спрашивают, чем tail отличается от less.
Как отвечать
Начните с подключения: ssh user@host, вход по ключу, а не по паролю (ключ создаётся ssh-keygen -t ed25519, публичная часть уходит админу или через ssh-copy-id), частые хосты прописаны в ~/.ssh/config. Если стенд за бастионом, упомяните ssh -J.
Дальше команды по задачам:
- следить в реальном времени:
tail -f app.logилиtail -n 200 -f, пока воспроизводите баг; - листать и искать:
less, внутри/для поиска,nдля следующего совпадения,Shift+Fдля режима слежения; - фильтровать:
grep -i error,grep -C 5для контекста вокруг строки, поиск по request id или trace id, чтобы собрать историю одного запроса; - старые логи: после ротации они сжаты в
.gz, для них естьzgrepиzless; - сервисы systemd:
journalctl -u имя -f, выборка по времени через--since; - контейнеры:
docker logs -f --tail 100 имя, в Kuberneteskubectl logs -f pod, аkubectl logs --previousпокажет лог упавшего контейнера до рестарта.
Сильный ответ показывает применение: воспроизвели баг, по времени и id запроса нашли стектрейс, приложили фрагмент лога к баг-репорту, и разработчику не пришлось повторять шаги. Примеры берите из своих проектов. Если с SSH вы не работали, так и скажите, покажите знание базовых команд и расскажите, как искали причины иначе: через Kibana, Grafana или вкладку Network в DevTools.
Где спотыкаются
Называют только tail -f /var/log/syslog. Логи приложения обычно лежат в своём каталоге, в контейнере или в journald, а на системах без rsyslog файла syslog может не быть вовсе.
Грепают по слову ERROR весь файл без привязки ко времени и id запроса и тонут в чужих ошибках.
Открывают гигабайтный лог через cat на общем стенде или правят там конфиги без согласования. На чужом сервере тестировщик работает в режиме чтения.