Как бы собирал логи с определенных приложений в Kuberentes кластере

Архитектура сбора логов в Kubernetes

Сбор логов в Kubernetes требует системного подхода, учитывающего распределенную архитектуру. Я строил решение на основе следующих ключевых компонентов:

1. Выбор стратегии сбора

В Kubernetes существует два основных подхода:

• Sidecar-контейнер с агентами сбора логов (Fluent Bit, Logstash) в каждом Pod.
• Сбор логов через узловые агенты (DaemonSet), которые читают логи из /var/log/pods на каждом узле.

Я предпочитаю подход с DaemonSet, так как он менее ресурсоемкий и не требует изменения спецификаций приложений. Для этого использую Fluent Bit в качестве легковесного агента, запущенного как DaemonSet. Он собирает логи всех Pods на узле, фильтрует и отправляет в центральную систему.

Пример манифеста DaemonSet для Fluent Bit:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
spec:
  selector:
    matchLabels:
      name: fluent-bit
  template:
    metadata:
      labels:
        name: fluent-bit
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:latest
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch-logging"
        - name: FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

2. Централизация и агрегация логов

Собранные логи отправляются в систему агрегации. Я чаще всего использовал:

• Elasticsearch как хранилище и индексер.
• Grafana Loki для более экономичного хранения (особенно если нужны только текстовые логи).
• ClickHouse для сложной аналитики и высокой производительности.

Для передачи данных от Fluent Bit до Elasticsearch применяется буферный слой Fluentd, который обеспечивает надежность и дополнительные возможности трансформации.

3. Сбор логов из определенных приложений

Для фильтрации логов конкретных приложений в Fluent Bit используются:

• Match-правила в конфигурации, основанные на тегах (например, kube.*).
• Фильтры по namespace, имени Pod или label-селекторам.

Пример конфигурации Fluent Bit для приложения в namespace production:

[INPUT]
    Name              tail
    Path              /var/log/containers/*production*.log
    Tag               kube.production.*
    Mem_Buf_Limit     5MB

[FILTER]
    Name              kubernetes
    Match             kube.production.*
    Kube_Tag_Prefix   kube.production.

[OUTPUT]
    Name              es
    Match             kube.production.*
    Host              elasticsearch-logging
    Port              9200

4. Логирование приложений в стандартизированном формате

Для эффективного анализа критически важно, чтобы приложения логировали в структурированном формате (JSON). Это позволяет:

• Легко парсить и фильтровать логи.
• Использовать обогащение логов метаданными Kubernetes (namespace, Pod name, labels).
• Реализовывать сложные запросы в Elasticsearch/Kibana.

Я внедрял в разработку стандарты логирования, где каждый лог-сообщение содержит минимальный набор полей: timestamp, level, message, application, transaction_id.

5. Мониторинг и алертинг на основе логов

Собранные логи не просто хранятся — они интегрируются в систему мониторинга:

• В Elasticsearch создаются индекс-паттерны и Kibana-дашборды для каждого приложения.
• Настраиваются логовые алерты через ElastAlert или встроенные механизмы Kibana.
• Логи могут направляться в SIEM-системы (Splunk, QRadar) для безопасности.

6. Обеспечение надежности и масштабирования

Решение должно быть устойчивым:

• Резервирование Elasticsearch через несколько узлов с репликацией индексов.
• Настройка retention-политик для управления объемом данных (например, удаление логов старше 30 дней).
• Мониторинг самого процесса сбора логов — чтобы не пропустить сбой агентов.

Ключевые практики

• Использование helm-чартов для deployment всех компонентов (Elasticsearch, Fluent Bit, Kibana).
• Тегирование логов по приложениям и environments для быстрой навигации.
• Регулярный review конфигураций фильтров для оптимизации ресурсов.
• Интеграция с CI/CD для автоматического создания Kibana-дашбордов при деплое нового приложения.

Таким образом, сбор логов с определенных приложений в Kubernetes — это не просто установка агента, а построение end-to-end pipeline от генерации лога в контейнере до его визуализации и алертинга, с учетом специфики каждого приложения через фильтрацию и тегирование.