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

Архитектура сбора логов с клиентских машин и сервисов

В нашей инфраструктуре используется гибридный подход к сбору логов, который включает в себя несколько уровней и инструментов, чтобы обеспечить полноту сбора, минимальные накладные расходы и гибкость анализа. Основная философия — собирать логи как можно ближе к источнику, но обрабатывать централизованно.

1. Агентский уровень на клиентских машинах и серверах

На каждой машине (виртуальной, физической, контейнере) развернут легковесный агент, ответственный за сбор и первичную обработку логов.

• Основной инструмент: Fluent Bit. Мы выбрали его за:

    *   **Эффективность по ресурсам (C, низкое потребление CPU/RAM).**
    *   **Встроенная буферизация и надежная доставка** (retry, backoff).
    *   **Мощные возможности парсинга и фильтрации** на месте (регулярные выражения, парсинг JSON, изменение структуры).
    *   Поддержка множества **входных плагинов** (tail, systemd, exec, tcp) и **выходных** (в наш центральный кластер).

Пример типичной конфигурации fluent-bit на клиентской машине (упрощенно):

# Тег для логов nginx
[SERVICE]
    flush        5
    daemon       off
    log_level    info

[INPUT]
    name              tail
    path              /var/log/nginx/access.log
    tag               nginx.access
    parser            nginx

[INPUT]
    name              systemd
    tag               system.journal
    read_from_tail    true

[FILTER]
    name record_modifier
    match *
    record hostname ${HOSTNAME}
    record environment production

[OUTPUT]
    name          forward
    match         *
    host          log-aggregator.prod.internal
    port          24224
    tls           on
    shared_key    your_shared_secret

2. Транспортный и агрегирующий уровень

Агенты Fluent Bit не отправляют логи напрямую в систему хранения, а пересылают их в кластер Fluentd-аггрегаторов.

• Роль Fluentd-аггрегаторов:

    *   **Прием и балансировка** входящего потока от тысяч агентов.
    *   **Обогащение** данных (добавление тегов, ссылок на топологию инфраструктуры из Consul/Kubernetes API).
    *   **Маршрутизация** по логическим потокам (`routing rules`). Например, логи приложений — в Elasticsearch, метрики Nginx — в Prometheus (через statsd), критические ошибки — в Slack/Telegram.
    *   **Буферизация на стороне сервера** перед отправкой в бэкенды. Мы используем файловый буфер для устойчивости к сбоям конечных систем.

Фрагмент конфигурации Fluentd-аггрегатора для маршрутизации:

# Конфигурация Fluentd (аггрегатор)
<source>
  @type forward
  port 24224
  bind 0.0.0.0
  <transport tls>
    # ... настройки TLS ...
  </transport>
  <security>
    self_hostname aggregator01
    shared_key your_shared_secret
  </security>
</source>

# Обогащение всех логов полем cluster_name
<filter **>
  @type record_transformer
  <record>
    cluster_name "production-aws"
  </record>
</filter>

# Маршрут для логов приложений в Elasticsearch
<match app.**>
  @type elasticsearch
  host els-prod.internal
  port 9200
  logstash_format true
  logstash_prefix fluentd
  buffer_type file
  buffer_path /var/buffer/elasticsearch.*.buffer
  flush_interval 5s
  retry_limit 17
  retry_wait 1.0
</match>

# Маршрут для метрик доступа Nginx в StatsD для Prometheus
<match nginx.access>
  @type statsd
  host prometheus-statsd-exporter.internal
  port 9125
  metric_type count
  count_key request_count
  tag_key nginx.access
</match>

3. Слой хранения и анализа (бэкенды)

В зависимости от типа и цели использования логи направляются в разные системы:

1. Elasticsearch + Kibana (ELK Stack): Основное хранилище для логов приложений, системных и веб-серверов. Обеспечивает полнотекстовый поиск, структурированные запросы (KQL), дашборды и расследования инцидентов. Индексы строятся по схеме logstash-YYYY.MM.DD с политикой ротации ILM (Hot-Warm-Cold-Delete).
2. Prometheus + VictoriaMetrics/Grafana Loki: Для метрик, извлеченных из логов (например, количество 5xx ошибок, latency перцентили). Fluentd через плагины (prometheus, statsd) агрегирует метрики на лету и отправляет их. Для логов, которые критичны именно как метрики времени выполнения запросов, также используем Grafana Loki как легковесную альтернативу Elasticsearch для pure logging.
3. Объектное хранилище (S3-совместимое): Все сырые (raw) логи в обязательном порядке через Fluentd (@type s3) дублируются в долгосрочное холодное хранилище (минимально на 90 дней, для аудита — до года). Формат — gzip-сжатые файлы, разделенные по датам и тегам.
4. Системы оповещения (Alerting):

    *   **Elasticsearch Watcher / Kibana Alerting:** для триггеров на основе сложных запросов к логам.
    *   **Prometheus Alertmanager:** для оповещений на основе метрик, порожденных из логов.
    *   **Прямая интеграция Fluentd с Slack/Telegram/MS Teams** для мгновенных уведомлений о критических паттернах (`@type webhook`).

4. Ключевые принципы и практики

• Структурированное логирование (JSON): Мы обязываем разработчиков выводить логи приложений сразу в структурированном формате (JSON). Это позволяет Fluent Bit парсить их без regexp и сразу индексировать в Elasticsearch с полной поддержкой полей.
• Единая схема обогащения: Каждое событие лога обогащается стандартным набором полей: hostname, environment, service_name, pod_name (для k8s), cluster_name, log_level.
• Контроль объема и ротация: Жесткие квоты на стороне агентов (Mem_Buf_Limit в Fluent Bit) и агрегаторов. Использование парсеров и фильтров для вычленения только полезной информации, отсекая шум.
• Безопасность: Все соединения между компонентами шифруются с помощью TLS (mTLS где возможно). Чувствительные данные (персональные данные, токены) маскируются или не логируются вообще с помощью фильтров (record_modifier, grep) еще на этапе агента или агрегатора.
• Инфраструктура как код (IaC): Конфигурации для Fluent Bit (DaemonSet в k8s, Ansible-роли для ВМ) и Fluentd (Helm-чарты) хранятся в Git, проходят code review и деплой через CI/CD пайплайны.

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