Розробник витрачає години на пошук помилки в логах, розкиданих по сотнях подів у 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 анотації)
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 правил.
Приклад налаштування multi-line правила для Python traceback
Для збору traceback вкажіть в анотації rule: `{"type": "multi_line", "name": "python_traceback", "pattern": "Traceback|^\\s+File"}`. Це об'єднає всі рядки виключення в один запис.Як знизити ingest за допомогою exclusion-фільтрів Datadog?
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 на $200-300 для проекту з 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 — в 2-3 рази порівняно зі зберіганням усіх логів.
Типові проблеми та їх вирішення
Якщо агент не бачить логи, перевірте в першу чергу RBAC: ClusterRole агента повинен мати доступ до pods/logs та events. Потім — tolerations: якщо агент не стоїть на нодах, логи не збираються. Типова помилка — забули вказати tolerations: [operator: Exists] у values. Наш досвід: більшість випадків вирішуються за 15 хвилин після правильної конфігурації.
Процес налаштування під ключ
- Аудит поточної інфраструктури — які оточення, які додатки, які формати логів.
- Проектування pipeline — джерела, exclusion-фільтри, retention, log-based метрики, дашборди.
- Реалізація — деплой агента, анотації, налаштування Pipelines, тестування.
- Передача документації — runbook по додаванню нових джерел, troubleshooting.
- Навчання команди — як користуватися Datadog Logs, шукати, будувати алерти.
Строки: від 3 до 7 днів залежно від кількості сервісів. Вартість розраховується індивідуально — оцінюємо проект.
Що входить в роботу
- Helm chart для Datadog Agent з оптимальними налаштуваннями під вашу інфраструктуру.
- Конфігурація Log Pipelines (Datadog Logs pipeline): парсинг, exclusion-фільтри, multi-line правила.
- Набір log-based метрик для ключових сервісів (помилки, latency, RPS).
- Дашборди в Datadog: зведення по логуванню, алерти на помилки.
- Runbook для команди: покрокові інструкції по додаванню нових джерел і типових проблем.
- Навчання команди (2-годинний воркшоп).
Порівняння підходів до логування
| Параметр | Datadog Logs | Elasticsearch | Loki |
|---|---|---|---|
| Управління | SaaS, zero-ops | Self-hosted, потрібен адмін | Self-hosted, легше ES |
| Вартість при 50 ГБ/д | ~$500/міс | $200-400 + залізо | $150-300 + S3 |
| Індексація | Автоматична | Налаштовувана | Тільки метадані |
| Multi-line | Так (анотації) | Так (pipeline) | Так (pipeline) |
| Exclusion фільтри | Так (UI + config) | Так (ILM) | Так (predicate) |
Datadog виграє у простоті експлуатації, але дорожчий при великих об'ємах. Вибір залежить від бюджету та наявності DevOps-інженерів. Порівняно з Elasticsearch: Datadog розгортається в 2 рази швидше (години проти днів) і не потребує операційного навантаження.
Рекомендовані exclusion-фільтри
| Тип логу | Pattern | Економія |
|---|---|---|
| Health-чеки | GET /health |
10-15% |
| Debug-логи в staging | env:staging status:debug |
30-40% |
| Логи системних компонентів | source:kubernetes.audit |
5-10% |
| Access-логи з низьким пріоритетом | source:nginx status:2.. |
20-25% |
За плечима наших інженерів понад 5 років роботи з Datadog Logs і 50+ проектів з налаштування observability Kubernetes. Ми гарантуємо, що логи будуть збиратися коректно, дашборди відобразять ключові метрики, а exclusion-фільтри зекономлять ваш бюджет. Отримайте консультацію по вашому проекту. Замовте аудит поточної схеми логування — ми підготуємо пропозицію з детальним планом.
Завдяки Datadog Logs налаштування, моніторинг логів Datadog стає простішим та дешевшим. Ми забезпечуємо збір логів контейнерів та централізоване логування Kubernetes з оптимальними витратами.
