Где смотрите логи
Что проверяют
Умеете ли вы сами дойти до причины бага, а не ограничиваться скриншотом с ошибкой. Хотят услышать конкретные места и инструменты с вашего проекта. Следом обычно просят рассказать, как по логам нашли причину конкретного дефекта.
Как отвечать
Идите от клиента к серверу и называйте то, чем пользовались на самом деле:
- браузер: DevTools, вкладка Console для ошибок JS и Network для запросов. Смотрите статус, тело ответа, заголовки, время. HAR-файл удобно прикладывать к баг-репорту;
- мобильные клиенты:
adb logcatили Logcat в Android Studio, для iOS Console.app и Xcode. Трафик через Charles или Proxyman; - серверные логи: централизованный сбор, чаще всего Kibana или OpenSearch Dashboards, Grafana Loki, в части компаний Splunk. Без централизации
kubectl logs <pod>илиdocker logs, на старой инфраструктуреtail -fиgrepпо файлу на сервере; - сквозной поиск: по
request_idилиtrace_idиз заголовка ответа находите все записи одного запроса во всех сервисах, трассировку показывают Jaeger или Tempo; - ошибки и падения: Sentry для бэкенда и фронта, Firebase Crashlytics для мобильных;
- база и очереди: лог медленных запросов, консоль Kafka или RabbitMQ, когда сообщение «потерялось» между сервисами.
Покажите связку с работой тестировщика: нашли ошибку в UI, взяли идентификатор запроса, нашли стектрейс в Kibana, приложили ссылку и фрагмент лога в задачу. Разработчику не нужно воспроизводить баг заново.
Prometheus и Grafana показывают метрики, а не логи. Упомянуть их можно, но как отдельный инструмент: по графику видно, что выросло число 500-х, а причину ищут уже в логах.
Где спотыкаются
Перечисляют ELK, Splunk и Prometheus списком, но не могут сказать, как составить запрос в Kibana по полю и временному окну. Интервьюер это быстро проверяет.
Смешивают метрики и логи и называют Grafana «местом, где смотрят логи». С Loki это верно, без него нет.
Ограничиваются консолью браузера. Для QA на проекте с бэкендом это слабый ответ: баг на клиенте часто лишь следствие ошибки в соседнем сервисе.