Питання про Prometheus на співбесіді 2026: порівняння Prometheus vs Grafana vs Datadog

Питання про Prometheus звучать майже на кожній співбесіді з DevOps і SRE, і зазвичай за ними йде наступне: «чому не Grafana або Datadog?». Кандидат має пояснити, як Prometheus скрапить і зберігає метрики, написати коректний PromQL та обґрунтувати компроміси порівняно з керованою платформою. Так інтерв'юери відрізняють реальний операційний досвід від книжкових знань. Ті самі теми у вигляді тренувальних питань містить модуль співбесід з Prometheus та моніторингу.

Питання про Prometheus на співбесідах з DevOps і SRE

Нижче наведено питання саме про Prometheus, які звучать найчастіше, разом із відповіддю впевненого кандидата. Вони виходять із Prometheus 3.x: поточна стабільна лінія 3.15 (вересень 2026), а 3.16 перебуває на стадії release candidate.

Питання: Чому Prometheus забирає метрики (pull), а не приймає їх через push?

Модель pull робить стан таргетів спостережуваним: кожен скрапінг створює ряд up, тож мертвий таргет видно як up == 0, а не як тишу. Частоту скрапінгу контролює сервер, що захищає його від клієнта з некоректною поведінкою, а таргет можна перевірити вручну, відкривши його ендпоінт /metrics у браузері. Ціна полягає в тому, що Prometheus має мати мережевий доступ до кожного таргета. Саме тому короткоживучим batch-задачам потрібен Pushgateway, а конфігурації між кількома мережами використовують remote write.

Питання: Які чотири типи метрик існують і коли summary є хибним вибором?

Counter (лише зростає, скидається після рестарту), gauge (зростає і спадає), histogram (спостереження підраховуються в бакетах) та summary (квантилі обчислюються на клієнті). Квантилі summary неможливо агрегувати: середнє значення p99 десяти подів не дає p99 сервісу. Гістограми можна спершу підсумувати між інстансами, а вже потім перетворити на квантиль на сервері, тому для затримок вони є вибором за замовчуванням.

# Classic histogram: aggregate the buckets, keep the le label
histogram_quantile(0.99,
  sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

# Native histogram: no _bucket suffix, no le label
histogram_quantile(0.99,
  sum by (job) (rate(http_request_duration_seconds[5m])))

Пропущений le у клаузі by класичної форми є найпоширенішою помилкою PromQL під час live coding: запит не повертає нічого придатного.

Питання: Чим відрізняються rate(), irate() та increase()?

rate() повертає середню швидкість за секунду на всьому діапазоні й коректно обробляє скидання лічильників. irate() використовує лише два останні семпли в діапазоні, тому реагує швидко, але дає шумний результат: підходить для збільшеного графіка й не підходить для алертингу. increase() дорівнює rate(), помноженому на тривалість діапазону. Оскільки Prometheus екстраполює значення до меж вікна, increase() на цілочисловому лічильнику може повернути неціле значення, і інтерв'юери люблять питати чому.

Питання: Що таке cardinality і як діагностувати її вибух?

Кожна унікальна комбінація назви метрики та значень labels є окремим часовим рядом, який зберігається в пам'яті. Label на кшталт user_id, email чи сирого шляху URL з ідентифікаторами множить кількість рядів, доки серверу не забракне пам'яті. Діагностика починається зі сторінки статусу TSDB (/tsdb-status) або із запиту:

# Top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

Виправлення робиться на джерелі: label видаляють або переписують через metric_relabel_configs, або задають sample_limit для scrape job, щоб один невдалий деплоймент не міг покласти сервер.

Питання: Для чого потрібні recording rules?

Вони попередньо обчислюють дорогий вираз на кожному інтервалі оцінювання й зберігають результат як новий ряд. Дашборди та алерти потім запитують дешевий попередньо обчислений ряд. Конвенція іменування має вигляд level:metric:operations:

groups:
  - name: api-recording-rules
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

Питання: Що робить клауза for у правилі алерту?

Алерт, вираз якого стає істинним, переходить зі стану inactive у pending і досягає firing лише тоді, коли умова трималася протягом тривалості for. Це відфільтровує одноразові сплески з одного скрапінгу. keep_firing_for діє навпаки: утримує алерт у стані firing ще деякий час після зникнення умови, щоб алерт, який мерехтить, не будив чергового двічі.

Питання: Як забезпечити високу доступність Prometheus?

Запускають дві ідентичні репліки, які скрапять ті самі таргети, кожна з окремим external label replica. Обидві надсилають алерти до кластера Alertmanager, який дедуплікує сповіщення через протокол gossip. Для запитів Thanos Query або Mimir дедуплікують два ряди, ігноруючи label репліки. Сам Prometheus не має кластеризації: локальна TSDB окремого сервера не реплікується.

Питання: Федерація чи remote write для кількох кластерів?

Федерація дозволяє глобальному Prometheus скрапити вибрані, зазвичай агреговані ряди з ендпоінта /federate Prometheus у кожному кластері. Вона підходить для невеликого набору агрегатів. Remote write передає кожен семпл до центрального сховища, як-от Mimir, Thanos Receive або бекенд постачальника, і є стандартною відповіддю для глобальних запитів і довготривалого зберігання.

Питання: Як виявити таргет, що зник із service discovery?

up == 0 спрацьовує лише доти, доки таргет ще виявляється. Якщо под або запис service discovery зник, ряд перестає існувати й алерт ніколи не спрацює. Цей випадок покриває absent(up{job="api-server"}).

Питання: Що змінилося в Prometheus 3?

Prometheus 3.0 (листопад 2024) приніс новий інтерфейс, дозволив символи UTF-8 у назвах метрик і labels та додав вбудований приймач OTLP за адресою /api/v1/otlp/v1/metrics, який вмикається через --web.enable-otlp-receiver. Нативні гістограми стали стабільними у 3.8. Починаючи з 3.9, старий feature flag нічого не робить, а для прийому потрібно задати scrape_native_histograms: true у конфігурації скрапінгу або глобальній конфігурації. Версія 3.15 зробила стабільним кодування float-чанків XOR2 і додала скрапінг у форматі OpenMetrics 2.0.

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

Після основ Prometheus інтерв'юери зазвичай переходять до архітектурних відмінностей між трьома інструментами.

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

Grafana сама не збирає й не зберігає метрики. Вона під'єднується до джерел даних (Prometheus, Loki, Tempo, InfluxDB, Elasticsearch та понад 100 інших) і рендерить дашборди на основі їхніх даних. Grafana Labs також розвиває Mimir (довготривале зберігання метрик), Loki (агрегація логів) та Tempo (розподілене трасування), які разом із Grafana утворюють open-source стек LGTM. Grafana 13, анонсована на GrafanaCON у квітні 2026 року, вивела Git Sync для дашбордів у статус GA, увімкнула динамічні дашборди за замовчуванням і прибрала команди grafana-cli та grafana-server.

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

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

scrape_configs:
  - job_name: 'api-server'
    scrape_native_histograms: true
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

Цей YAML визначає pull-модель Prometheus: поди Kubernetes виявляються через service discovery, залишаються лише ті, що мають анотацію prometheus.io/scrape: "true", адреса переписується на порт з анотації, а /metrics скрапиться кожні 15 секунд. Друге правило з'єднує обидва вихідні labels символом ;, тому регулярний вираз зіставляє формат host:port;port.

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

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

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

# 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

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

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

# Anomaly detection (no built-in PromQL equivalent)
anomalies(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 жертвує частиною гнучкості на користь вбудованих алгоритмічних функцій, як-от anomalies() (алгоритми basic, agile, robust) та forecast() (linear, seasonal), для яких у стеку Prometheus знадобився б зовнішній інструментарій.

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

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

Prometheus Alertmanager отримує алерти з правил, які Prometheus оцінює з фіксованими інтервалами, і маршрутизує їх через конфігурований конвеєр із групуванням (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, яку можна переглянути. Недолік полягає в так званій threshold fatigue, оскільки статичні значення часто потребують сезонного коригування.

Grafana Alerting (уніфікована система алертингу, стандартна починаючи з Grafana 9) оцінює запити до будь-якого під'єднаного джерела даних і підтримує багатовимірні алерти з notification policies.

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

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

Ціноутворення на практиці є вирішальним фактором під час вибору інструмента й часто порушується на співбесідах із проєктування систем. Розуміння структури витрат демонструє бізнес-обізнаність. Наведені нижче суми для Datadog є прейскурантними цінами за річної оплати.

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

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

Prometheus є системою метрик за замовчуванням в екосистемі Kubernetes, тому на співбесідах щодо моніторингу оркестрації контейнерів ця тема домінує.

Prometheus + Grafana інтегрується з Kubernetes нативно через 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-таргетів. Перевизначення значень чарта у такий спосіб детальніше розглядає посібник для співбесід з Helm-чартів.

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

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

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

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

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

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

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

Окрім самого Prometheus, ці питання перевіряють, чи вміє кандидат міркувати на рівні кількох інструментів. Кожна відповідь підкреслює концепцію, яку перевіряє інтерв'юер.

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

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

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

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

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

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

Питання: Що таке біллінг Datadog за принципом high-watermark і чому це важливо?

Datadog вимірює кількість хостів щогодини, відкидає верхній один відсоток годин і виставляє рахунок за піком на рівні 99-го перцентиля. Через це тимчасові сплески автомасштабування (наприклад, трафік Black Friday) збільшують місячний рахунок навіть після зупинки інстансів. Кандидати, які згадують про це, демонструють реальний операційний досвід керування витратами, якого дедалі частіше вимагають ролі SRE.

Питання: Чим відрізняється стратегія алертингу на основі 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.

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

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

Джерела

• Релізи Prometheus: 3.15.0 (вересень 2026) робить стабільним кодування чанків XOR2, додає скрапінг OpenMetrics 2.0 і позначає --log.level як застарілий
• Специфікація нативних гістограм Prometheus: стабільні з 3.8, scrape_native_histograms обов'язковий з 3.9
• What's new in Grafana 13.0: Git Sync у статусі GA, динамічні дашборди за замовчуванням, несумісні зміни
• Прейскурант Datadog: ціни на інфраструктуру, APM і логи, використані в таблиці витрат
• Алгоритмічні функції Datadog: синтаксис anomalies() і forecast()

Що запам'ятати перед співбесідою з Prometheus та observability

• Prometheus є стандартом збору метрик у середовищах Kubernetes; pull проти push, чотири типи метрик, rate() проти irate(), cardinality та HA треба знати напам'ять
• У Prometheus 3.9 і новіших версіях нативні гістограми приймаються лише за умови scrape_native_histograms: true
• Grafana є шаром візуалізації, а не базою даних метрик: вона під'єднується до понад 100 джерел даних, включно з Prometheus, а стек LGTM (Loki, Grafana, Tempo, Mimir) утворює повноцінну open-source платформу observability
• Datadog пропонує найшвидший шлях до full-stack observability з вбудованим виявленням аномалій, проте коштом вищої ціни та vendor lock-in
• Поширення OpenTelemetry робить вибір бекенду менш остаточним: інструментування лишається тим самим незалежно від того, який інструмент зберігає й запитує дані
• На співбесідах важливо показати вміння зважувати компроміси (вартість, контроль, складність), а не обстоювати єдиний інструмент
• Для ширшої підготовки посібник з ключових питань для співбесід з DevOps охоплює суміжні теми, які інтерв'юери пов'язують із моніторингом