Ответ
На последнем проекте с микросервисной архитектурой на Kubernetes мы построили централизованную систему логирования на основе стека EFK (Elasticsearch, Fluent Bit, Kibana).
Архитектура и поток данных:
- Источники: Все приложения писали структурированные логи в формате JSON в stdout/stderr. Это обязательное требование.
- Сбор на нодах: На каждой ноде Kubernetes в качестве DaemonSet работал Fluent Bit. Он собирал логи всех подов с этой ноды из
/var/log/containers/*.log. - Обработка и обогащение: Fluent Bit парсил JSON, добавлял метаданные (имя пода, неймспейс, имя ноды) и фильтровал чувствительные данные (например, маскировал поля с паролями в логах аутентификации).
- Буферизация и отправка: После обработки логи буферизировались и отправлялись в кластер Elasticsearch.
- Визуализация и поиск: Для анализа использовали Kibana. Там были настроены дашборды для ключевых сервисов, сохраненные поисковые запросы (Kibana Saved Searches) и алерты.
Пример конфигурации Fluent Bit для парсинга и обогащения:
# Фрагмент ConfigMap для Fluent Bit
apiVersion: v1
kind: ConfigMap
metadata:
name: fluent-bit-config
data:
fluent-bit.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
Port 9200
Logstash_Format On
Retry_Limit False
Дополнительные практики:
- Для логов бизнес-событий (например, «Пользователь совершил платеж») использовали отдельный индекс в Elasticsearch с увеличенным временем хранения.
- Настроили Curator для автоматической ротации и удаления старых индексов по политикам (например, логи приложений храним 30 дней, аудит-логи — 1 год).
- Критичные ошибки (HTTP 5xx, исключения уровня ERROR) триггерили алерты в Prometheus Alertmanager, который отправлял уведомления в Slack и PagerDuty.
- Все логи перед попаданием в Elasticsearch проходили через шифрование TLS, а доступ к Kibana был защищен через OAuth2 прокси.