Чем собираешь логи с контейнеров микросервисов?

В микросервисной архитектуре на основе контейнеров (Kubernetes/Docker Swarm) я использую централизованное логирование, чтобы агрегировать, хранить и анализировать логи со всех подов/сервисов. Основные стэки:

1. EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana) — классический и мощный.

• Fluentd/Fluent Bit (Data Shippers): Легковесные агенты-сборщики, которые разворачиваются как DaemonSet на каждой ноде Kubernetes. Они читают логи контейнеров из /var/log/containers/, парсят, обогащают метаданными (pod name, namespace, labels) и отправляют дальше.
• Elasticsearch (Storage & Search): Распределенный search-движок для хранения и индексации логов. Обеспечивает быстрый полнотекстовый поиск.
• Kibana (Visualization & UI): Веб-интерфейс для построения дашбордов, графиков и поиска по логам в Elasticsearch.

Пример конфигурации Fluent Bit DaemonSet для K8s (упрощенно):

# fluent-bit-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: logging
data:
  fluent-bit.conf: |
    [SERVICE]
        Parsers_File parsers.conf
    [INPUT]
        Name tail
        Path /var/log/containers/*.log
        Parser docker
        Tag kube.*
        Mem_Buf_Limit 5MB
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        K8S-Logging.Parser On
    [OUTPUT]
        Name es
        Match *
        Host elasticsearch.logging.svc.cluster.local
        Port 9200
        Logstash_Format On
        Retry_Limit False

2. Loki Stack (Loki, Promtail, Grafana) — современный, легковесный, "как Prometheus, но для логов".

• Promtail (Data Shipper): Агент, аналогичный Fluent Bit, но оптимизированный специально для Loki. Также разворачивается как DaemonSet.
• Loki (Storage & Index): Хранит логи в сжатом виде и индексирует только метки (labels), а не содержимое. Это делает его гораздо дешевле в эксплуатации и проще в масштабировании, чем Elasticsearch.
• Grafana (Visualization & UI): Единая панель для просмотра как метрик (из Prometheus), так и логов (из Loki) в одном месте, с возможностью перехода от графика к соответствующим логам (корреляция).

Почему часто выбираю Loki для новых проектов:

• Экономичность: Меньшие требования к ресурсам и стоимости хранения.
• Интеграция с Grafana: Единый стек для мониторинга и логов.
• Логическая группировка: Легко фильтровать логи по тем же лейблам, что и в Kubernetes (pod=frontend-abc123, namespace=production).

3. Cloud-Native Решения (для AWS/GCP/Azure).

• AWS: Контейнеры -> CloudWatch Logs Driver (встроен в ECS/EKS) -> CloudWatch Logs. Для анализа можно использовать CloudWatch Logs Insights или отправлять в OpenSearch (managed Elasticsearch).
• GCP: Контейнеры -> Stackdriver (Google Cloud Operations) Logging.

Критически важные практики:

• Логи в stdout/stderr: Контейнеры должны писать логи только в стандартные потоки вывода и ошибок. Docker/Kubernetes автоматически перехватывают их.
• Structured Logging (JSON): Приложения должны выводить логи в формате JSON. Это позволяет сборщикам (Fluentd/Promtail) автоматически парсить поля, что сильно упрощает последующий поиск и фильтрацию.
• Тэгирование и обогащение: Автоматически добавлять метаданные (namespace, pod_name, container_name, labels) на этапе сбора.
• Retention Policy: Обязательно настраивать политику хранения (например, удалять логи старше 30 дней) как в Loki, так и в Elasticsearch, чтобы избежать неконтролируемого роста затрат.