С какими системами логирования вы работали

Что проверяют

Умеете ли вы находить причину дефекта в логах сами, а не пересылать разработчику скриншот с ошибкой.

Как отвечать

Назовите инструменты и сразу скажите, что в них делали:

• ELK или OpenSearch (Elasticsearch, Filebeat или Logstash, Kibana): поиск по индексу, фильтры по сервису и уровню, запросы на языке KQL или Lucene, сохранённые панели;
• Grafana Loki: запросы на LogQL, обычно рядом с метриками в той же Grafana;
• Graylog, Splunk: то же назначение, другой интерфейс и синтаксис;
• Sentry: не логи, а агрегированные ошибки со стеком, группировкой и версией сборки. Отдельно полезен тем, что показывает частоту и число затронутых пользователей;
• Kibana APM, Jaeger, Datadog: трассировки, где видно всю цепочку вызовов между сервисами.

Дальше расскажите про метод работы, это ценнее списка:

• ищу по идентификатору запроса или трассировки (X-Request-Id, traceparent), потому что по нему собирается цепочка через все сервисы;
• сначала сужаю окно времени, потом фильтрую по сервису и уровню error, потом читаю подряд вокруг найденной строки;
• в отчёт о дефекте кладу не скриншот, а точное время, идентификатор запроса и выдержку из лога;
• проверяю обратное тоже: что ошибка вообще логируется, что в логи не утекают токены и персональные данные, что уровень выбран верно.

Полезно отличать три вещи: логи отвечают на «что именно произошло», метрики на «как часто и насколько плохо», трассировки на «где в цепочке время потерялось».

Где спотыкаются

Называют инструмент, но не могут показать, как искали бы конкретную ошибку.

Не знают про сквозной идентификатор запроса и ищут по времени вслепую.

Путают логи и метрики.

Не проверяют, что чувствительные данные в логи не попадают.