Как вы собираете и храните данные (логи, метрики) в инфраструктуре?

В современных DevOps-стэках используется принцип Observability, основанный на трех столпах: логи, метрики и трейсы. Сбор и хранение строятся по единой схеме.

1. Сбор данных:

• Логи: Агенты (Fluent Bit, Filebeat) собирают логи с нод и контейнеров, парсят, обогащают метаданными (pod name, namespace) и отправляют дальше. Fluent Bit легковеснее, чем Fluentd, и идеален для sidecar-контейнеров в Kubernetes.

  # Пример команды Fluent Bit для отправки в Elasticsearch
  fluent-bit -i tail -p path=/var/log/containers/*.log -o es -p host=elasticsearch -p port=9200

• Метрики: Node Exporter собирает метрики хоста (CPU, память, диск). cAdvisor или kube-state-metrics собирают метрики контейнеров и объектов Kubernetes. Все это scrap'ится Prometheus.
• Трейсы: Инструментированные приложения (через OpenTelemetry) отправляют трейсы напрямую в коллектор (Jaeger, Tempo).

2. Хранение и анализ:

• Логи: Отправляются в Elasticsearch для индексации и поиска. Kibana — для визуализации. Долгосрочный архив — в объектное хранилище (S3, GCS) с помощью Curator для ILM (Index Lifecycle Management).
• Метрики: Prometheus хранит данные краткосрочно (обычно 15-30 дней). Для долгосрочного хранения и горизонтального масштабирования используется Thanos (sidecar + object storage) или VictoriaMetrics.
• Трейсы: Хранятся в Jaeger (собственное хранилище) или Tempo (использует объектное хранилище, дешевле).

3. Ключевые принципы архитектуры:

• Агенты на каждой ноде, а не в каждом поде (DaemonSet в k8s).
• Буферизация (например, в Kafka или Redis) перед системами хранения для устойчивости к сбоям.
• Структурированное логирование (JSON) на уровне приложения для упрощения парсинга.
• Тегирование и обогащение всех данных метаданными (источник, окружение, версия).