Ответ
Мой подход к просмотру логов зависит от среды и цели: ад-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), что сильно упрощает последующий поиск.
Ответ 18+ 🔞
Давай я тебе расскажу, как я обычно с этими логами разбираюсь, а то там, блядь, подходов — овердохуища, и всё зависит от того, где пожар и что горит.
1. Когда всё хуёво прямо тут, на сервере (ад-хок отладка): Тут всё просто, как три копейки. Если сервис на systemd — сразу в журнал.
- Для 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— чтобы сразу со всех. - А для полного счастья и агрегации ставлю
sternилиkubetail. Командаstern my-app -n production— это красота, она тебе в одном потоке логи со всех подов приложения сливает, просто ядрёна вошь!
3. Нормальный, взрослый продакшен (централизованное логирование): Тут уже на ноды не лезем, это моветон. Всё летит в одну кучу, а мы там умными запросами ищем.
- Если у нас Grafana Loki: Открываю Grafana, пишу запрос на ихнем LogQL. Выглядит страшно, но мощно.
{app="api-gateway", env="prod"} |= "error" | json | rate > 0.1 - Если старый добрый ELK Stack (Elasticsearch, Logstash, Kibana): Там всё в Kibana ищем. Сделал сохранённый поиск — и потом в два клика.
- Ну или если в облаке сидим: AWS CloudWatch Logs Insights, GCP Logging — интерфейсы разные, но суть одна.
Главная мысль, которую я усвоил, чувак: Логи должны быть структурированными, желательно в JSON. Потому что когда ты настраиваешь сборщик (типа Fluentd или Vector), ты можешь каждую запись обогатить метаданными: имя пода, неймспейс, нода. И тогда потом искать — одно удовольствие, а не ебать копать в рот мне чих-пых. Иначе будешь как слепой кот, сука, в коровнике искать иголку.