Зачем нужна централизованная агрегация логов и почему недостаточно просто смотреть логи на каждом сервере через `ssh` + `tail`?

Короткий ответ

При нескольких серверах/подах логи физически разбросаны по разным машинам и теряются при перезапуске или пересоздании контейнера; централизованная агрегация (например, стек ELK/EFK или Loki) собирает логи в одно место, где их можно искать, фильтровать и коррелировать между сервисами без ручного обхода каждого узла.

Как это работает подробнее

на каждом узле или рядом с каждым приложением работает агент сбора логов (Filebeat, Fluent Bit, Promtail), который читает файлы логов или stdout контейнера, добавляет метаданные (имя пода, namespace, контейнер) и отправляет их в центральное хранилище (Elasticsearch или Loki), откуда их можно искать через Kibana или Grafana.

Пример кода

commands.shКопировать

# Логи текущего контейнера пода
kubectl logs my-pod
# Логи предыдущего (упавшего) экземпляра контейнера в этом же поде
kubectl logs my-pod --previous

Что использовать на практике

• Практика. в Kubernetes логи контейнера по умолчанию хранятся на узле и пропадают при удалении пода — особенно важно централизовать сбор логов до того, как понадобится разобрать инцидент с уже перезапущенным подом. Централизация также даёт единый поиск по всем инстансам сервиса сразу, а не по одному серверу за раз.
• Практика. Если под уже пересоздан (новый под с другим именем), обе команды не найдут нужные логи — их можно будет найти только в централизованной системе (например, по запросу {namespace="prod", pod=~"my-pod.*"} в Loki), что подтверждает необходимость агрегации логов, а не только локального доступа.

Подводные камни

• Частые ошибки. полагаться только на kubectl logs для расследования инцидентов — после CrashLoopBackOff и пересоздания пода предыдущие логи могут быть недоступны без флага --previous, а после удаления пода — недоступны вовсе; не настраивать политики ретеншена логов, из-за чего индекс логов переполняет диск хранилища.