Prometheus vs Grafana vs Datadog 2026: So Sánh Monitoring và Câu Hỏi Phỏng Vấn DevOps

Prometheus vs Grafana vs Datadog là một trong những câu hỏi so sánh phổ biến nhất trong các buổi phỏng vấn DevOps. Việc nắm vững kiến trúc, ưu điểm và đánh đổi của từng công cụ cho thấy kinh nghiệm vận hành thực tế trong mắt nhà tuyển dụng, không chỉ đơn thuần là kiến thức lý thuyết.

Kiến Trúc và Mô Hình Dữ Liệu

Sự khác biệt về kiến trúc giữa ba công cụ này mang tính nền tảng, và nhà tuyển dụng thường xuyên kiểm tra kiến thức này để đánh giá mức độ hiểu biết sâu của ứng viên.

Prometheus sử dụng mô hình pull-based. Hệ thống chủ động gọi đến các HTTP endpoint (thường là /metrics) theo chu kỳ cấu hình sẵn, lưu trữ dữ liệu time-series trong TSDB nội bộ. Mỗi time series được xác định bởi tên metric và tập hợp các label dạng key-value. Với Prometheus 3.0 (phát hành tháng 11 năm 2024), native histograms đạt trạng thái stable trong phiên bản 3.8, OTLP ingestion được tích hợp sẵn và Remote Write 2.0 cải thiện khả năng federation giữa các cluster.

Grafana không thu thập hay lưu trữ metrics. Công cụ này kết nối đến các data source -- Prometheus, Loki, Tempo, InfluxDB, Elasticsearch và hơn 100 nguồn khác -- rồi hiển thị dashboard từ dữ liệu của chúng. Grafana Labs cũng duy trì Mimir (lưu trữ metrics dài hạn), Loki (tổng hợp log) và Tempo (distributed tracing), tạo thành một bộ observability mã nguồn mở hoàn chỉnh. Phiên bản 13 ra mắt vào tháng 5 năm 2026 với công cụ observability-as-code, Git Sync cho dashboard và SQL Expressions cho truy vấn liên nguồn dữ liệu.

Datadog hoạt động theo mô hình push-based SaaS. Agent được cài đặt trên các host sẽ đẩy metrics, log và trace lên backend đám mây của Datadog. Toàn bộ quy trình -- thu thập, lưu trữ, truy vấn, cảnh báo, dashboard -- đều nằm trong một nền tảng quản lý duy nhất. Engine Watchdog ML tự động phát hiện bất thường mà không cần cấu hình ngưỡng thủ công.

# 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}

File YAML trên định nghĩa mô hình pull của Prometheus: hệ thống khám phá các Kubernetes pod thông qua service discovery và thu thập dữ liệu từ endpoint /metrics mỗi 15 giây.

PromQL và Ngôn Ngữ Truy Vấn Datadog

Ngôn ngữ truy vấn là chủ đề thường xuyên xuất hiện trong phỏng vấn. Ứng viên cần thể hiện sự thành thạo ít nhất một ngôn ngữ, đồng thời giải thích được những đánh đổi giữa chúng.

PromQL (Prometheus Query Language) là chuẩn cho truy vấn metrics trong hệ sinh thái Prometheus và Grafana. PromQL hỗ trợ instant vector, range vector, toán tử tổng hợp và recording rule.

# 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

Ngôn ngữ truy vấn của Datadog sử dụng cú pháp khác biệt, xây dựng xoay quanh function và 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 có khả năng biểu đạt sâu hơn cho việc phân tích ad-hoc. Ngôn ngữ truy vấn của Datadog đánh đổi một phần sự linh hoạt để cung cấp các hàm ML tích hợp sẵn như anomaly() và forecast() -- những tính năng đòi hỏi công cụ bên ngoài nếu sử dụng Prometheus.

Chiến Lược Cảnh Báo: Quy Tắc Tĩnh và Phát Hiện Bằng ML

Triết lý cảnh báo khác nhau rõ rệt giữa các công cụ, và việc hiểu rõ sự khác biệt này thể hiện mức độ trưởng thành về vận hành trong phỏng vấn.

Prometheus Alertmanager đánh giá các quy tắc theo chu kỳ cố định và định tuyến cảnh báo thông qua một pipeline có thể cấu hình với các tính năng grouping, silencing và 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

Cách tiếp cận này yêu cầu người vận hành định nghĩa ngưỡng cụ thể. Ưu điểm là tính minh bạch hoàn toàn -- mọi cảnh báo đều có biểu thức có thể kiểm tra. Nhược điểm là hiện tượng "mệt mỏi ngưỡng": các giá trị tĩnh thường cần điều chỉnh theo mùa vụ.

Grafana Alerting (thống nhất từ Grafana 12 trở lên) đánh giá truy vấn trên mọi data source được kết nối và hỗ trợ cảnh báo đa chiều với notification policy linh hoạt.

Datadog Monitors kết hợp ngưỡng tĩnh với các monitor phát hiện bất thường, outlier và dự đoán dựa trên ML. Watchdog tự động đánh dấu các anomaly về hiệu năng mà không cần tạo quy tắc thủ công. Điều này giảm khối lượng cấu hình nhưng đồng thời giảm tính minh bạch trong logic phát hiện.

Chi Phí và Tổng Chi Phí Sở Hữu Năm 2026

Chi phí là yếu tố quyết định trong việc lựa chọn công cụ thực tế và thường xuất hiện trong các buổi phỏng vấn thiết kế hệ thống. Việc hiểu rõ cấu trúc chi phí thể hiện nhận thức về mặt kinh doanh của ứng viên.

| Dimension | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | License | Free (AGPL / Apache 2.0) | $15-31/host/month (annual) | | Metrics storage | Self-managed (Mimir/Thanos) | Included, retention-based pricing | | Log management | Loki (self-hosted) | $0.10/GB ingested + indexing | | APM / Traces | Tempo (self-hosted) | $31/host/month | | Infrastructure cost | Compute + storage for stack | None (SaaS) | | Operational overhead | High (upgrades, scaling, HA) | Minimal | | Typical annual cost (50 hosts) | $20K-60K (infra + engineering) | $50K-150K | | Vendor lock-in risk | Low (OpenTelemetry, PromQL) | Higher (proprietary query language) |

Bộ công cụ mã nguồn mở có vẻ rẻ hơn trên giấy, nhưng đòi hỏi thời gian kỹ sư chuyên trách cho việc nâng cấp, lập kế hoạch dung lượng và cấu hình high-availability. Mô hình quản lý của Datadog chuyển gánh nặng đó sang nhà cung cấp. Đối với các đội ngũ có dưới 5 kỹ sư phụ trách hạ tầng, giải pháp quản lý thường có tổng chi phí thấp hơn khi tính cả thời gian kỹ sư.

Giám Sát Kubernetes: So Sánh Mức Độ Tích Hợp

Hơn 80% các cluster Kubernetes sử dụng Prometheus để thu thập metrics, khiến đây trở thành chủ đề phỏng vấn quan trọng nhất về giám sát điều phối container.

Prometheus + Grafana tích hợp nguyên bản với Kubernetes thông qua kube-prometheus-stack Helm chart. Chart này triển khai Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics và các Grafana dashboard dựng sẵn trong một lần cài đặt:

# 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

Lệnh trên triển khai một bộ monitoring production-grade với persistent storage và lưu trữ dữ liệu 30 ngày. Prometheus Operator sử dụng Custom Resource Definition (ServiceMonitor, PodMonitor) để cấu hình scrape target theo hướng khai báo.

Datadog triển khai agent DaemonSet và Cluster Agent. Cluster Agent xử lý giao tiếp với API server một cách tập trung, giảm tải lên Kubernetes API. Giao diện Live Containers của Datadog cung cấp khả năng quan sát trạng thái pod theo thời gian thực, và Orchestrator Explorer ánh xạ mối quan hệ giữa các deployment, service và pod.

Đối với các đội ngũ đã đầu tư sâu vào hệ sinh thái Kubernetes, cách tiếp cận native với Prometheus tránh việc đưa vào phụ thuộc bên ngoài. Các đội ngũ ưu tiên tốc độ triển khai với ít chi phí vận hành sẽ nghiêng về Datadog.

OpenTelemetry và Tính Trung Lập Với Nhà Cung Cấp

OpenTelemetry (OTel) đã trở thành chuẩn công nghiệp cho instrumentation, và nhà tuyển dụng ngày càng hỏi nhiều về OTel bên cạnh việc so sánh các công cụ monitoring.

Prometheus 3.0 trở lên chấp nhận OTLP metrics nguyên bản -- không cần Collector làm trung gian. Grafana Alloy (kế nhiệm Grafana Agent) đóng vai trò vừa là OTel Collector vừa là Prometheus scraper. Datadog hỗ trợ nhận OTLP nhưng khuyến nghị sử dụng agent độc quyền để "truy cập đầy đủ tính năng", tạo ra một dạng lock-in mềm.

Việc áp dụng OTel có ý nghĩa quan trọng vì nó tách biệt instrumentation khỏi việc chọn backend. Mã ứng dụng được instrument bằng OTel SDK có thể gửi telemetry đến Prometheus, Grafana Cloud, Datadog hoặc bất kỳ backend tương thích nào mà không cần thay đổi mã nguồn. Sự linh hoạt này là luận điểm mạnh trong phỏng vấn thiết kế hệ thống khi thảo luận về chiến lược observability dài hạn.

Câu Hỏi Phỏng Vấn DevOps Về Monitoring và Observability

Các câu hỏi sau xuất hiện thường xuyên trong các buổi phỏng vấn DevOps và SRE. Mỗi câu trả lời làm rõ các khái niệm mà nhà tuyển dụng muốn kiểm tra.

H: Giải thích sự khác biệt giữa monitoring, observability và alerting.

Monitoring theo dõi các metrics đã định nghĩa trước và kiểm tra các lỗi đã biết. Observability cho phép điều tra các lỗi chưa biết thông qua metrics, log và trace ("ba trụ cột"). Alerting kích hoạt thông báo khi các điều kiện vượt ngưỡng định nghĩa hoặc đường cơ sở bất thường. Monitoring trả lời "hệ thống có khỏe không?" Observability trả lời "tại sao hệ thống không khỏe?"

H: Khi nào Prometheus không phải là lựa chọn phù hợp cho monitoring?

Prometheus được tối ưu cho độ tin cậy hơn là độ bền -- ưu tiên tính khả dụng của chính hệ thống monitoring. Các trường hợp Prometheus gặp khó khăn: lưu trữ dài hạn quá 30 ngày (cần Thanos/Mimir/Cortex), dữ liệu tính phí theo yêu cầu đòi hỏi độ chính xác 100% (Prometheus có thể loại bỏ sample khi quá tải), và hệ thống event-based cần thu thập push-based (dù pushgateway tồn tại như giải pháp thay thế).

H: Triết lý "Big Tent" của Grafana ảnh hưởng đến kiến trúc observability như thế nào?

Grafana kết nối đến mọi data source mà không yêu cầu di chuyển dữ liệu. Điều này cho phép các đội ngũ truy vấn Prometheus, Elasticsearch, CloudWatch và Datadog từ một dashboard duy nhất. Đánh đổi là độ phức tạp vận hành -- việc duy trì nhiều backend đòi hỏi chuyên môn hạ tầng cao hơn so với cách tiếp cận một nhà cung cấp. Nhà tuyển dụng kiểm tra xem ứng viên có thể trình bày rõ ràng đánh đổi này hay không.

H: Mô hình tính phí high-watermark của Datadog là gì và tại sao quan trọng?

Datadog đo số lượng host theo giờ, loại bỏ 1% giờ cao nhất và tính phí theo đỉnh percentile thứ 99. Điều này có nghĩa là các đợt auto-scaling tạm thời (ví dụ như lưu lượng Black Friday) làm tăng hóa đơn hàng tháng ngay cả sau khi các instance đã được tắt. Ứng viên đề cập đến điểm này thể hiện kinh nghiệm vận hành thực tế về quản lý chi phí, một kỹ năng ngày càng được yêu cầu trong các vị trí SRE.

H: Chiến lược cảnh báo dựa trên SLO khác nhau như thế nào giữa Prometheus và Datadog?

Trong Prometheus, cảnh báo SLO sử dụng recording rule để tính trước error budget và cảnh báo burn rate (phương pháp multi-window, multi-burn-rate từ sách SRE của Google). Datadog cung cấp SLO widget và monitor tích hợp sẵn để theo dõi burn rate tự động. Cả hai cách tiếp cận đều triển khai cùng một khái niệm, nhưng Prometheus đòi hỏi cấu hình thủ công nhiều hơn trong khi Datadog cung cấp quy trình quản lý sẵn. Ứng viên nên đề cập đến các cửa sổ burn rate (1 giờ, 6 giờ, 3 ngày) và tốc độ tiêu thụ error budget trong câu trả lời.

Để luyện tập sâu hơn về các chủ đề monitoring, module phỏng vấn Prometheus và monitoring bao gồm các tình huống bổ sung với giải thích chi tiết.

Khung Quyết Định: Chọn Đúng Bộ Công Cụ

| Scenario | Recommended Stack | Rationale | |----------|------------------|----------| | Startup, < 10 engineers | Datadog or Grafana Cloud | Minimize operational overhead | | Large org with platform team | Prometheus + Grafana + Loki | Full control, lower per-unit cost at scale | | Multi-cloud / hybrid | Prometheus + Grafana | Vendor-neutral, consistent across environments | | Compliance-heavy (finance, healthcare) | Self-hosted Prometheus + Grafana | Data stays in-house | | Rapid scaling, unpredictable growth | Grafana Cloud (managed Mimir) | Scales without infrastructure management | | Need ML-powered anomaly detection | Datadog | Watchdog requires no configuration |

Lựa chọn phù hợp phụ thuộc vào ba biến số: quy mô đội ngũ, mức độ trưởng thành vận hành và giới hạn ngân sách. Không có câu trả lời đúng duy nhất, và nhà tuyển dụng mong đợi ứng viên lập luận về các đánh đổi thay vì chọn một người chiến thắng.

Kết Luận

• Prometheus là chuẩn mực cho việc thu thập metrics trong môi trường Kubernetes, với phiên bản 3.x mang đến hỗ trợ OTLP nguyên bản và native histograms ổn định trong năm 2026
• Grafana là tầng trực quan hóa, không phải cơ sở dữ liệu metrics -- kết nối được với hơn 100 data source bao gồm Prometheus, và bộ LGTM (Loki, Grafana, Tempo, Mimir) tạo thành một nền tảng observability mã nguồn mở hoàn chỉnh
• Datadog cung cấp con đường nhanh nhất đến observability toàn diện với cảnh báo dựa trên ML, đổi lại là chi phí cao hơn và rủi ro vendor lock-in
• Việc áp dụng OpenTelemetry làm cho việc chọn backend trở nên ít mang tính vĩnh viễn hơn -- instrumentation giữ nguyên bất kể công cụ nào lưu trữ và truy vấn dữ liệu
• Trong phỏng vấn, hãy thể hiện khả năng lập luận về đánh đổi (chi phí, quyền kiểm soát, độ phức tạp) thay vì ủng hộ một công cụ duy nhất
• Để luyện tập thực hành, hãy sử dụng module câu hỏi phỏng vấn DevOps và tìm hiểu thêm về các khái niệm CI/CD pipeline để củng cố kiến thức liên quan