Настройка централизованного логирования в Kubernetes через Datadog Logs

Разработчик тратит часы на поиск ошибки в логах, разбросанных по сотням подов в Kubernetes. Централизованное логирование (Kubernetes logging) с Datadog Logs решает эту проблему: сбор, индексация и алертинг в реальном времени. Но стоимость может вырасти, если не контролировать объём. Опытный инженер знает, как настроить exclusion-фильтры и log-based метрики, чтобы снизить затраты на 40-60% без потери нужных данных. Мы настраиваем Datadog Logs под ключ за 3-7 дней — от деплоя агента до готовых дашбордов и алертов.

Как установить Datadog Agent в Kubernetes

# datadog-values.yaml для Helm datadog:
apiKey: ${DD_API_KEY}
site: "datadoghq.eu" # или datadoghq.com
logs:
  enabled: true
  containerCollectAll: true
  containerCollectUsingFiles: true
processAgent:
  enabled: false
apm:
  portEnabled: false
clusterAgent:
  enabled: true
agents:
  tolerations:
    - operator: Exists
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

helm upgrade --install datadog datadog/datadog \
  --namespace monitoring \
  --create-namespace \
  --values datadog-values.yaml \
  --set datadog.apiKey=$(kubectl get secret datadog-secret -o jsonpath='{.data.api-key}' | base64 -d)

Деплой занимает около часа. После этого агент автоматически собирает логи всех контейнеров — но без парсинга они приходят как JSON с кучей вложенных полей. Чтобы превратить их в структурированные данные, нужны аннотации и Log Pipelines. Как указано в официальной документации: "Datadog Agent automatically collects logs from your containers" — Datadog Documentation.

Как настроить аннотации для автопарсинга

Datadog поддерживает Pod-аннотации для автоматической настройки сбора и парсинга:

# Deployment с аннотациями для Datadog metadata:
annotations:
  ad.datadoghq.com/app.logs: |
    [{ "source": "python", "service": "payments-api", "log_processing_rules": [{ "type": "multi_line", "name": "python_traceback", "pattern": "Traceback|^\\s+File" }] }]

Для NGINX:

ad.datadoghq.com/nginx.logs: |
  [{ "source": "nginx", "service": "web-frontend", "tags": ["env:production", "team:frontend"] }]

Без указания log_processing_rules многострочные ошибки (traces) попадут в разные записи — их невозможно нормально проанализировать. Наш опыт показывает, что 80% проблем с агрегацией логов связаны именно с отсутствием multi-line правил.

Как снизить ingest с помощью exclusion-фильтров

Datadog Logs тарифицируется по ingested объёму. Фильтры исключения в datadog.yaml агента или через UI:

---
# /etc/datadog-agent/datadog.yaml
logs_config:
  processing_rules:
    - type: exclude_at_match
      name: exclude_health_checks
      pattern: "GET /health HTTP"
    - type: exclude_at_match
      name: exclude_debug_staging
      pattern: '"level":"debug"'

Через Datadog UI: Log Pipelines → Filters → добавить exclusion filter с условием env:staging AND status:debug. Это снижает ingest до 40-60% в staging-окружениях. На практике комбинация фильтров по env, status и source снижает ежемесячные расходы на Datadog на существенную сумму для проекта с 50 ГБ/день.

Почему log-based метрики экономят бюджет

Datadog позволяет строить метрики из логов без сохранения самих логов — полезно для трендов без роста стоимости хранения:

В Logs → Generate Metrics: создать payment.errors из фильтра service:payments-api status:error. Метрика доступна в Datadog Metrics и дашбордах наравне с системными.

Log-based метрики позволяют получить тренды ошибок, latency, количество запросов по статусу — без хранения самих логов. Это значит, что вы платите только за объем метрик (который значительно меньше), а не за гигабайты логов. В Datadog эта функция встроена: достаточно задать filter и measure. Мы настраиваем 5-10 ключевых метрик на проект — этого достаточно для базового мониторинга. Такая оптимизация приводит к существенной экономии бюджета на observability.

Типичные проблемы и их решение

Если агент не видит логи, проверьте в первую очередь RBAC: ClusterRole агента должен иметь доступ к pods/logs и events. Затем — tolerations: если агент не стоит на нодах, логи не собираются. Типичная ошибка — забыли указать tolerations: [operator: Exists] в values. Наш опыт: большинство случаев решаются за 15 минут после правильной конфигурации.

Процесс настройки под ключ

1. Аудит текущей инфраструктуры — какие окружения, какие приложения, какие форматы логов.
2. Проектирование pipeline — источники, exclusion-фильтры, retention, log-based метрики, дашборды.
3. Реализация — деплой агента, аннотации, настройка Pipelines, тестирование.
4. Передача документации — runbook по добавлению новых источников, troubleshooting.
5. Обучение команды — как пользоваться Datadog Logs, искать, строить алерты.

Сроки: от 3 до 7 дней в зависимости от количества сервисов. Стоимость рассчитывается индивидуально — оцениваем проект.

Что входит в работу

• Helm chart для Datadog Agent с оптимальными настройками под вашу инфраструктуру.
• Конфигурация Log Pipelines: парсинг, exclusion-фильтры, multi-line правила.
• Набор log-based метрик для ключевых сервисов (ошибки, latency, RPS).
• Дашборды в Datadog: сводка по логированию, алерты на ошибки.
• Runbook для команды: пошаговые инструкции по добавлению новых источников и типовым проблемам.
• Обучение команды (2-часовой воркшоп).

Сравнение подходов к логированию

Datadog выигрывает в простоте эксплуатации, но дороже при больших объёмах. Выбор зависит от бюджета и наличия DevOps-инженеров. Сравним с Elasticsearch: Datadog развёртывается в 2 раза быстрее (часы против дней) и не требует операционной нагрузки.

Рекомендуемые exclusion-фильтры

За плечами наших инженеров более 5 лет работы с Datadog Logs и 50+ проектов по настройке observability. Мы гарантируем, что логи будут собираться корректно, дашборды отразят ключевые метрики, а exclusion-фильтры сэкономят ваш бюджет. Получите консультацию по вашему проекту. Закажите аудит текущей схемы логирования — мы подготовим предложение с детальным планом.