Ответ
Мой подход к просмотру логов зависит от среды и цели: ад-hoc отладка или расследование инцидента.
1. Локальная отладка (на конкретном сервере/ноде):
- Для systemd-сервисов:
journalctl -u nginx.service -f --since "10 minutes ago" - Для лог-файлов в
/var/log/:tail -f /var/log/nginx/access.log | grep "POST /api" - Для Docker-контейнеров:
docker logs --tail 100 -f my_app_container
2. В Kubernetes-кластере:
- Логи пода:
kubectl logs deployment/my-app -n production --tail=50 - Логи с предыдущего запуска пода (если он упал):
kubectl logs deployment/my-app --previous - Логи из всех подов по селектору:
kubectl logs -l app=my-app --tail=10 - Интерактивный просмотр с выбором пода: Использую
kubetailилиstern(например,stern my-app -n production).
3. В продакшене (централизованное логирование): Мы не смотрим логи непосредственно на нодах. Вся логика агрегируется в центральную систему. Я работаю с:
- Grafana Loki + Promtail: Выполняю запросы LogQL в Grafana.
{app="api-gateway", env="prod"} |= "error" | json | rate > 0.1 - ELK Stack (Elasticsearch, Logstash, Kibana): Использую Kibana Discover для поиска и визуализаций.
- Облачные решения: AWS CloudWatch Logs Insights, Google Cloud Logging.
Ключевая практика: Логи должны быть структурированными (JSON). При настройке конвейера логирования (Fluentd, Vector) мы парсим и обогащаем логи метаданными (pod_name, namespace, node), что сильно упрощает последующий поиск.