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

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

Идёте ли вы в логи сами или несёте разработчику скриншот с ошибкой. Умение снять доказательство отличает баг-репорт, который берут в работу, от того, который возвращают с вопросом «а что было в логах».

Как отвечать

Расскажите и про инструменты, и про маршрут.

• Kibana поверх Elasticsearch или OpenSearch: поиск по индексу, фильтры по уровню и сервису, сохранённые запросы под регресс;
• Grafana с Loki: выборка по меткам, панели рядом с метриками;
• Graylog и Splunk: централизованный сбор, потоки, оповещения по шаблону сообщения;
• Sentry: сгруппированные исключения со стеком и версией сборки;
• локально: docker logs, kubectl logs, journalctl, tail -f на стенде, grep и jq по выгрузке.

Маршрут важнее названий: воспроизвели, зафиксировали время и идентификатор запроса, собрали по нему цепочку через все сервисы, отделили ошибку приложения от инфраструктурной, приложили к дефекту фрагмент лога и трассировку. Скажите про сквозной идентификатор и структурированный формат: без них поиск по подстроке в микросервисах не складывается в историю. Хорошо звучит и то, что вы просили добавить логирование там, где его не хватало.

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

Копируют в баг одну последнюю строку с исключением. Без предыдущих записей и точного времени разработчик не восстановит контекст, а корневая причина обычно выше по цепочке.

Смотрят только уровень ошибок. Предупреждения о повторных попытках и таймаутах объясняют деградацию, при которой ошибок в логе нет вовсе.

Путают часовые пояса и окружения. Лог в UTC, отчёт в местном времени, препрод перепутан с тестовым стендом, и по времени ничего не находится. Пояс и адрес стенда фиксируются вместе с шагами.