Какие инструменты используются для просмотра логов?
Что проверяют
Умеете ли вы искать причину в логах и знаете ли, что именно искать.
Как отвечать
По уровням.
На машине или в контейнере: tail -f для живого потока, grep для поиска, less для больших файлов, journalctl для системных служб, docker compose logs для контейнеров. Для JSON-логов удобен jq.
Агрегаторы, куда логи стекаются со всех сервисов: Kibana поверх Elasticsearch или OpenSearch, Grafana Loki, Graylog, Splunk, Datadog. Тут появляется поиск по всем сервисам сразу, фильтры и панели.
Ошибки отдельно: Sentry. Он не заменяет логи, а группирует одинаковые исключения, показывает частоту, число затронутых пользователей и версию сборки. Часто отвечает на вопрос «это массово или единичный случай» быстрее всего.
Трассировки: Jaeger, Tempo, встроенные средства наблюдения. Показывают всю цепочку вызовов между сервисами и где потерялось время. Логи говорят что произошло, трассировка где.
Клиентская сторона: консоль и вкладка сети в браузере, Logcat для Android, системная консоль и унифицированное логирование для iOS, Crashlytics для падений.
Метод работы важнее списка инструментов:
- искать по сквозному идентификатору запроса или трассировки. По нему собирается цепочка через все сервисы за секунды, тогда как поиск по времени вслепую занимает часы;
- сузить окно времени, отфильтровать по сервису и уровню, затем читать подряд вокруг найденной строки, а не только саму строку;
- в отчёт о дефекте класть точное время, идентификатор запроса и выдержку, а не скриншот.
И обратная проверка, про которую забывают: логируется ли ошибка вообще, и не утекают ли в логи токены и персональные данные. Это находка уровня инцидента.
Где спотыкаются
Ищут по времени, не зная про идентификатор запроса.
Прикладывают к дефекту скриншот вместо текста ошибки.
Не проверяют, что ошибки вообще попадают в журнал.
Не отличают логи от метрик и трассировок.