Prometheus vs Grafana vs Datadog у 2026: порівняння моніторингу та питання для співбесід з DevOps

Порівняння Prometheus, Grafana та Datadog — одне з найпоширеніших питань на співбесідах з DevOps. Кандидат, який не просто поверхово знає ці інструменти, а здатен ґрунтовно пояснити їхню архітектуру, сильні сторони й компроміси, помітно вирізняється на тлі інших. Ця стаття зіставляє ключові відмінності, аналізує мови запитів і підходи до алертингу та готує до найчастіших питань щодо моніторингу й observability.

Архітектура та модель даних: як кожен інструмент працює з метриками

Архітектурні відмінності між цими трьома інструментами є фундаментальними, і інтерв'юери часто заглиблюються в цю тему, щоб оцінити глибину розуміння кандидата.

Prometheus використовує модель на основі pull (витягування). Сервер опитує HTTP-ендпоінти (зазвичай /metrics) із заданими інтервалами й зберігає часові ряди у власній локальній TSDB. Кожен часовий ряд ідентифікується назвою метрики та набором пар ключ-значення (labels). Prometheus 3.0, випущений у листопаді 2024 року, у версії 3.8 приніс стабільні нативні гістограми, вбудовану підтримку прийому OTLP та Remote Write 2.0 для покращеної федерації між кластерами.

Grafana сама не збирає й не зберігає метрики. Натомість вона під'єднується до джерел даних — Prometheus, Loki, Tempo, InfluxDB, Elasticsearch та понад 100 інших — і рендерить дашборди на основі їхніх даних. Grafana Labs також розвиває Mimir (довготривале зберігання метрик), Loki (агрегація логів) та Tempo (розподілене трасування). Разом ці компоненти утворюють так званий стек LGTM — повноцінну open-source платформу observability. Версія 13, що вийшла у травні 2026 року, додала інструментарій observability-as-code, Git Sync для дашбордів та SQL Expressions для запитів між кількома джерелами.

Datadog працює як SaaS на основі push (надсилання). Агенти, встановлені на хостах, надсилають метрики, логи й трейси до хмарного бекенду Datadog. Усе — прийом, зберігання, запити, алертинг, дашборди — існує в межах єдиної керованої платформи. ML-рушій Watchdog виконує автоматичне виявлення аномалій без ручного налаштування порогів.

Наведена нижче конфігурація Prometheus ілюструє pull-модель на прикладі інтеграції з Kubernetes:

# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}

Цей YAML визначає pull-модель Prometheus: сервіс автоматично виявляє поди Kubernetes через service discovery та опитує їхні ендпоінти /metrics кожні 15 секунд. Блок relabel_configs керує тим, які поди підлягають скрапінгу та на якому порту доступні метрики. Для порівняння, Datadog потребує лише встановлення агента у вигляді DaemonSet, а конфігурація здійснюється централізовано через вебінтерфейс.

PromQL проти мови запитів Datadog: синтаксис і можливості

Мови запитів — часта тема технічних співбесід із моніторингу. Від кандидатів очікують вільного володіння щонайменше однією мовою й уміння пояснити компроміси між ними.

PromQL (Prometheus Query Language) — стандарт для запитів метрик у всій екосистемі Prometheus і Grafana. Мова підтримує instant vectors, range vectors, оператори агрегації та recording rules. Її виразність дає змогу виконувати складний ad-hoc аналіз, проте потребує помітного часу на опанування.

# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0

Функція rate() обчислює середню швидкість зміни лічильника (counter) за часове вікно. На співбесідах регулярно запитують про різницю між rate() (згладжена швидкість за все вікно) та irate() (миттєва швидкість на основі двох останніх точок даних). Функція predict_linear() дозволяє на основі лінійної регресії передбачити, коли ресурс буде вичерпано — типовий сценарій планування ємності (capacity planning).

Мова запитів Datadog використовує інший підхід, побудований навколо викликів функцій та scoping:

# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)

Ключова відмінність полягає в наборі функцій: PromQL пропонує глибшу виразність для математичних операцій та ad-hoc аналізу. Мова Datadog жертвує частиною цієї гнучкості на користь вбудованих ML-функцій, як-от anomaly() та forecast(). У стеку Prometheus такі функції потребували б додаткового зовнішнього інструментарію. Для співбесід діє правило: хто вміє точно пояснити семантику rate() у PromQL і водночас знає межі обох мов, демонструє справжній практичний досвід.

Стратегії алертингу: на основі правил проти виявлення на основі ML

Філософія алертингу суттєво відрізняється між цими інструментами, і розуміння цих відмінностей демонструє на співбесідах операційну зрілість.

Prometheus Alertmanager оцінює правила з фіксованими інтервалами й маршрутизує алерти через конфігурований конвеєр із групуванням (grouping), приглушенням (silencing) та інгібуванням (inhibition):

# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning

Цей підхід вимагає явного визначення порогів. Перевага — повна прозорість: кожен алерт має перевіряну expression, яку можна відстежити під час code review та аудитів. Недолік — так звана threshold fatigue: статичні значення часто потребують сезонного коригування та адаптації до зростаючої інфраструктури, що з сотнями сервісів стає дедалі трудомісткішим.

Grafana Alerting (уніфікований у Grafana 12+) оцінює запити до будь-якого під'єднаного джерела даних і підтримує багатовимірні алерти з notification policies. Починаючи з версії 13, визначення алертів можна версіонувати як код та керувати ними через Git Sync, що суттєво спрощує робочі процеси Infrastructure-as-Code.

Datadog Monitors поєднують статичні пороги з ML-керованими моніторами аномалій, викидів (outlier) та прогнозів (forecast). Watchdog автоматично виявляє аномалії продуктивності без створення ручних правил. Це суттєво знижує обсяг конфігурації, проте йде коштом меншої прозорості логіки виявлення. У регульованих галузях, як-от фінанси чи охорона здоров'я, це може бути проблемою, оскільки аудитори очікують зрозумілих і задокументованих правил алертингу.

Ціноутворення та сукупна вартість володіння (TCO) у 2026 році

Ціноутворення на практиці є вирішальним фактором під час вибору інструмента й регулярно порушується на співбесідах із проєктування систем. Кандидати, які розуміють і вміють артикулювати структуру витрат, демонструють бізнес-обізнаність.

| Вимір | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Ліцензія | Безкоштовно (AGPL / Apache 2.0) | $15-31/хост/місяць (річна оплата) | | Зберігання метрик | Самостійне керування (Mimir/Thanos) | Включено, ціна залежить від retention | | Керування логами | Loki (self-hosted) | $0.10/ГБ прийнятих даних + індексація | | APM / Трейси | Tempo (self-hosted) | $31/хост/місяць | | Інфраструктурні витрати | Compute + сховище для стеку | Немає (SaaS) | | Операційне навантаження | Високе (оновлення, масштабування, HA) | Мінімальне | | Типова річна вартість (50 хостів) | $20K-60K (інфра + інженери) | $50K-150K | | Ризик vendor lock-in | Низький (OpenTelemetry, PromQL) | Вищий (пропрієтарна мова запитів) |

На папері open-source стек виглядає дешевшим, проте потребує виділеного інженерного часу на обслуговування, оновлення, планування ємності та конфігурацію високої доступності (HA). Керована модель Datadog перекладає це навантаження на постачальника. Як показує досвід, для команд із менш ніж п'ятьма інженерами інфраструктури керовані рішення часто мають нижчу сукупну вартість, щойно враховується інженерний час.

Часто недооцінюваний аспект — це біллінг Datadog за принципом high-watermark: кількість хостів вимірюється щогодини, верхній один відсоток годин відкидається, а за основу розрахунку береться пік на рівні 99-го перцентиля. Тимчасові сплески автомасштабування — наприклад, під час трафіку Black Friday — збільшують місячний рахунок навіть після того, як інстанси вже було зупинено.

Моніторинг Kubernetes: порівняння глибини інтеграції

Понад 80% усіх кластерів Kubernetes використовують Prometheus для збору метрик. Тому на співбесідах щодо оркестрації контейнерів ця тема практично неминуча.

Prometheus + Grafana інтегрується нативно через Helm-чарт kube-prometheus-stack. Цей чарт розгортає Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics та попередньо налаштовані дашборди Grafana в одній інсталяції:

# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

Ця команда розгортає готовий до продакшену стек моніторингу з постійним сховищем і 30-денним retention даних. Prometheus Operator використовує Custom Resource Definitions (ServiceMonitor, PodMonitor) для декларативного налаштування scrape-таргетів. Команди можуть самостійно створювати конфігурації моніторингу для своїх сервісів без доступу до центральної конфігурації Prometheus — суттєва організаційна перевага у великих компаніях.

Datadog розгортає агент-DaemonSet і Cluster Agent. Cluster Agent централізовано бере на себе взаємодію з API-сервером Kubernetes, зменшуючи навантаження на API. Подання Live Containers надає моніторинг стану подів у реальному часі, а Orchestrator Explorer візуалізує зв'язки між деплойментами, сервісами та подами. Обсяг налаштування менший, проте виникає залежність від зовнішнього SaaS-сервісу.

Для команд, які вже глибоко занурені в екосистему Kubernetes, Prometheus-нативний підхід дозволяє уникнути введення зовнішньої залежності. Команди, що надають пріоритет швидкому налаштуванню з меншим операційним навантаженням, схиляються радше до Datadog або Grafana Cloud.

OpenTelemetry та нейтральність до постачальника

OpenTelemetry (OTel) утвердився як галузевий стандарт для інструментування застосунків. На співбесідах дедалі частіше запитують про роль OTel у контексті порівняння інструментів моніторингу.

Prometheus 3.0+ приймає метрики OTLP нативно, без потреби в окремому Collector як проміжному шарі. Grafana Alloy, наступник Grafana Agent, водночас виконує роль OTel Collector і Prometheus scraper. Datadog підтримує прийом OTLP, проте рекомендує пропрієтарні агенти для «повного набору функцій» — форма м'якого vendor lock-in.

Стратегічне значення OTel полягає у відокремленні інструментування від вибору бекенду. Код застосунку, інструментований за допомогою OTel SDK, може надсилати телеметрію до Prometheus, Grafana Cloud, Datadog чи будь-якого іншого сумісного бекенду без змін у коді. Ця гнучкість — вагомий аргумент на співбесідах із проєктування систем, особливо коли йдеться про довгострокові стратегії observability. Хто вміє пояснити, чому OTLP переважає над пропрієтарними інтеграціями, демонструє архітектурну далекоглядність.

Питання для співбесід з DevOps щодо моніторингу та observability

Наведені нижче питання регулярно трапляються на співбесідах з DevOps та SRE. Кожна відповідь підкреслює концепції, які цілеспрямовано перевіряють інтерв'юери.

Питання: Чим відрізняються моніторинг, observability та алертинг?

Моніторинг відстежує наперед визначені метрики й перевіряє відомі режими відмов. Observability дає змогу досліджувати невідомі режими відмов через метрики, логи й трейси — так звані «три стовпи». Алертинг запускає сповіщення, коли умови перевищують визначені пороги або базові лінії аномалій. Моніторинг відповідає на питання «Чи система справна?», тоді як observability відповідає на питання «Чому система несправна?».

Питання: У яких сценаріях Prometheus є поганим вибором?

Prometheus оптимізований на надійність, а не на довговічність — пріоритет має доступність самої системи моніторингу. Сценарії, у яких Prometheus сягає своїх меж: довготривале зберігання понад 30 днів (потребує Thanos, Mimir або Cortex), біллінгові дані з вимогою 100% точності (Prometheus може відкидати семпли під навантаженням) та системи на основі подій, які потребують push-збору (хоча Pushgateway існує як обхідний варіант).

Питання: Як філософія «Big Tent» від Grafana впливає на архітектуру observability?

Grafana під'єднується до будь-якого джерела даних, не потребуючи міграції даних. Команди можуть об'єднати Prometheus, Elasticsearch, CloudWatch та Datadog в одному дашборді. Компроміс полягає в операційній складності: обслуговування кількох бекендів потребує більше експертизи з інфраструктури, ніж підхід із єдиним постачальником. Інтерв'юери перевіряють, чи здатен кандидат чітко сформулювати цей компроміс.

Питання: Чим відрізняється стратегія алертингу на основі SLO між Prometheus та Datadog?

У Prometheus алертинг на основі SLO використовує recording rules для попереднього обчислення error budgets та алертів за burn rate — підхід multi-window, multi-burn-rate із книги Google про SRE. Datadog пропонує вбудовані SLO-віджети та монітори, що автоматично відстежують burn rate. Обидва підходи реалізують одну й ту саму концепцію, проте Prometheus потребує більше ручного налаштування, тоді як Datadog надає керований робочий процес. У хорошій відповіді слід конкретно назвати вікна burn rate (1h, 6h, 3d) та швидкість витрачання error budget.

Питання: Яку роль відіграє cardinality у контексті Prometheus і чому вона проблематична?

Cardinality означає кількість унікальних часових рядів у Prometheus. Кожна комбінація назви метрики та значень labels створює окремий часовий ряд. Labels із високою кардинальністю — наприклад, ідентифікатори користувачів чи request ID — можуть експоненційно збільшити кількість часових рядів і суттєво погіршити як споживання пам'яті, так і продуктивність запитів. Найкращі практики охоплюють обмеження значень labels, застосування recording rules для попередньої агрегації та моніторинг власної TSDB Prometheus через prometheus_tsdb_head_series.

Для поглибленої підготовки до тем моніторингу модуль співбесід з Prometheus та моніторингу пропонує додаткові сценарії з докладними поясненнями.

Фреймворк ухвалення рішень: як обрати правильний стек

| Сценарій | Рекомендований стек | Обґрунтування | |----------|------------------|----------| | Стартап, < 10 інженерів | Datadog або Grafana Cloud | Мінімізувати операційне навантаження | | Велика організація з платформенною командою | Prometheus + Grafana + Loki | Повний контроль, нижча вартість за одиницю при масштабуванні | | Multi-cloud / гібрид | Prometheus + Grafana | Нейтральність до постачальника, узгодженість між середовищами | | Галузі з високими вимогами до compliance (фінанси, охорона здоров'я) | Self-hosted Prometheus + Grafana | Дані залишаються всередині компанії | | Швидке масштабування, непередбачуване зростання | Grafana Cloud (керований Mimir) | Масштабується без управління інфраструктурою | | Потрібне ML-виявлення аномалій | Datadog | Watchdog не потребує налаштування |

Правильний вибір залежить від трьох змінних: розміру команди, операційної зрілості та бюджетних обмежень. Універсально правильної відповіді не існує, і інтерв'юери очікують, що кандидати системно зважать компроміси, а не проголосять єдиного переможця.

Висновок

• Prometheus — де-факто стандарт для збору метрик у середовищах Kubernetes; версія 3.x у 2026 році приносить нативну підтримку OTLP та стабільні нативні гістограми
• Grafana — це шар візуалізації, а не база даних метрик; стек LGTM (Loki, Grafana, Tempo, Mimir) утворює повноцінну open-source платформу observability з понад 100 інтеграціями джерел даних
• Datadog пропонує найшвидший шлях до full-stack observability з ML-керованим алертингом, проте коштом вищої ціни та сильнішого vendor lock-in
• OpenTelemetry відокремлює інструментування від вибору бекенду й робить рішення на користь конкретного інструмента менш остаточним
• Керування cardinality — критичний операційний аспект у середовищах Prometheus і часта тема співбесід
• На співбесідах важливо продемонструвати здатність системно зважувати компроміси між вартістю, контролем і складністю, а не подавати єдиний інструмент як панацею
• Для практичної підготовки радимо модуль питань для співбесід з DevOps та поглиблення суміжних тем, як-от концепції CI/CD-конвеєрів