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

Câu hỏi phỏng vấn về Prometheus xuất hiện trong hầu hết các vòng phỏng vấn DevOps và SRE, thường đi kèm câu hỏi tiếp theo "tại sao không dùng Grafana hay Datadog?". Ứng viên cần giải thích cách Prometheus scrape và lưu trữ metrics, viết PromQL chính xác và lập luận về đánh đổi so với một nền tảng managed. Nhà tuyển dụng dùng chủ đề này để phân biệt kinh nghiệm vận hành thực tế với kiến thức sách vở. Module phỏng vấn Prometheus và monitoring có cùng các chủ đề dưới dạng câu hỏi luyện tập.

Câu Hỏi Phỏng Vấn Prometheus Trong Các Vòng DevOps và SRE

Đây là những câu hỏi riêng về Prometheus xuất hiện nhiều nhất, kèm câu trả lời mà một ứng viên vững vàng đưa ra. Các câu trả lời giả định Prometheus 3.x: dòng stable hiện tại là 3.15 (tháng 9 năm 2026), còn 3.16 đang ở giai đoạn release candidate.

H: Tại sao Prometheus kéo (pull) metrics thay vì nhận dữ liệu được đẩy (push) đến?

Cơ chế pull giúp quan sát được tình trạng của target: mỗi lần scrape tạo ra một series up, nên một target bị chết sẽ hiện ra dưới dạng up == 0 thay vì im lặng. Server kiểm soát tần suất scrape, điều này bảo vệ server trước một client hoạt động sai, và có thể kiểm tra target thủ công bằng cách mở endpoint /metrics trên trình duyệt. Cái giá phải trả là Prometheus phải truy cập được mọi target qua mạng, đó là lý do các batch job ngắn hạn cần Pushgateway và các hệ thống liên mạng dùng remote write.

H: Bốn loại metric là gì, và khi nào summary là lựa chọn sai?

Counter (chỉ tăng, reset khi khởi động lại), gauge (tăng và giảm), histogram (các giá trị quan sát được đếm vào các bucket) và summary (quantile được tính ở phía client). Quantile của summary không thể tổng hợp: lấy trung bình p99 của mười pod không cho ra p99 của service. Histogram có thể được cộng gộp giữa các instance trước rồi mới chuyển thành quantile ở phía server, vì vậy histogram là lựa chọn mặc định cho độ trễ.

# 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])))

Quên le trong mệnh đề by của dạng classic là lỗi PromQL phổ biến nhất trong các vòng live coding: truy vấn không trả về kết quả nào dùng được.

H: rate(), irate() và increase() khác nhau như thế nào?

rate() trả về giá trị trung bình mỗi giây trên toàn bộ khoảng thời gian và xử lý được việc counter bị reset. irate() chỉ dùng hai sample cuối cùng trong khoảng, nên phản ứng nhanh nhưng nhiễu, phù hợp cho đồ thị phóng to nhưng không phù hợp cho cảnh báo. increase() là rate() nhân với độ dài khoảng thời gian. Vì Prometheus ngoại suy đến các biên của cửa sổ, increase() trên một counter số nguyên có thể trả về số không nguyên, và nhà tuyển dụng thích hỏi tại sao.

H: Cardinality là gì, và chẩn đoán hiện tượng bùng nổ cardinality như thế nào?

Mỗi tổ hợp duy nhất giữa tên metric và giá trị label là một time series riêng được giữ trong bộ nhớ. Một label như user_id, email hoặc một đường dẫn URL thô chứa ID sẽ nhân số lượng series lên cho đến khi server hết bộ nhớ. Việc chẩn đoán bắt đầu từ trang trạng thái TSDB (/tsdb-status) hoặc bằng một truy vấn:

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

Cách khắc phục nằm ở nguồn: loại bỏ hoặc viết lại label bằng metric_relabel_configs, hoặc đặt sample_limit cho scrape job để một lần deploy lỗi không thể làm sập server.

H: Recording rule dùng để làm gì?

Recording rule tính trước một biểu thức tốn kém ở mỗi chu kỳ evaluation và lưu kết quả thành một series mới. Dashboard và cảnh báo sau đó truy vấn series đã tính sẵn với chi phí thấp. Quy ước đặt tên là level:metric:operations:

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

H: Mệnh đề for trong một alerting rule có tác dụng gì?

Một cảnh báo có biểu thức trở thành true sẽ chuyển từ inactive sang pending, và chỉ đạt trạng thái firing khi điều kiện duy trì đủ thời gian for. Cơ chế này lọc bỏ các dao động chỉ kéo dài một lần scrape. keep_firing_for làm điều ngược lại: giữ cảnh báo ở trạng thái firing thêm một khoảng sau khi điều kiện hết, giúp các cảnh báo dao động không gửi page hai lần.

H: Làm thế nào để Prometheus có tính sẵn sàng cao (HA)?

Chạy hai replica giống hệt nhau cùng scrape các target, mỗi replica có một external label replica riêng. Cả hai gửi cảnh báo đến một cluster Alertmanager, cluster này loại bỏ thông báo trùng lặp thông qua giao thức gossip. Với truy vấn, Thanos Query hoặc Mimir loại bỏ trùng lặp giữa hai series bằng cách bỏ qua label replica. Bản thân Prometheus không có clustering: TSDB cục bộ của một server đơn lẻ không được nhân bản.

H: Federation hay remote write cho hệ thống nhiều cluster?

Federation cho phép một Prometheus toàn cục scrape các series được chọn, thường là đã tổng hợp, từ endpoint /federate của Prometheus ở từng cluster. Cách này phù hợp với một tập nhỏ các rollup. Remote write truyền liên tục mọi sample đến một kho lưu trữ trung tâm như Mimir, Thanos Receive hoặc backend của nhà cung cấp, và là câu trả lời chuẩn cho truy vấn toàn cục và lưu trữ dài hạn.

H: Làm sao phát hiện một target đã biến mất khỏi service discovery?

up == 0 chỉ kích hoạt khi target vẫn còn được discovery. Nếu pod hoặc mục service discovery đã biến mất, series cũng không còn tồn tại và cảnh báo không bao giờ kích hoạt. absent(up{job="api-server"}) xử lý trường hợp này.

H: Prometheus 3 đã thay đổi những gì?

Prometheus 3.0 (tháng 11 năm 2024) ra mắt giao diện mới, cho phép ký tự UTF-8 trong tên metric và label, và bổ sung OTLP receiver tích hợp tại /api/v1/otlp/v1/metrics, được bật bằng --web.enable-otlp-receiver. Native histograms trở thành stable từ 3.8. Từ 3.9, feature flag cũ không còn tác dụng và việc ingest yêu cầu scrape_native_histograms: true trong cấu hình scrape hoặc global. Phiên bản 3.15 đưa XOR2 float chunk encoding lên stable và bổ sung khả năng scrape OpenMetrics 2.0.

Kiến Trúc và Mô Hình Dữ Liệu: Cách Mỗi Công Cụ Xử Lý Metrics

Sau khi nắm xong các kiến thức nền tảng về Prometheus, nhà tuyển dụng thường chuyển sang sự khác biệt về kiến trúc giữa ba công cụ.

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. Dòng 3.x bổ sung native histograms ở trạng thái stable, một OTLP receiver và Remote Write 2.0 để gửi sample về kho lưu trữ trung tâm.

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, gồm 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), cùng với Grafana tạo thành bộ LGTM mã nguồn mở. Grafana 13, được công bố tại GrafanaCON vào tháng 4 năm 2026, đưa Git Sync cho dashboard lên trạng thái GA, bật dynamic dashboards theo mặc định và loại bỏ các lệnh grafana-cli và grafana-server.

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, từ thu thập, lưu trữ, truy vấn, cảnh báo đến dashboard, đều nằm trong một nền tảng quản lý duy nhất. Engine Watchdog tự động đánh dấu các 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'
    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__

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, chỉ giữ lại các pod có annotation prometheus.io/scrape: "true", viết lại địa chỉ theo port được khai báo trong annotation và thu thập dữ liệu từ /metrics mỗi 15 giây. Rule thứ hai nối hai source label bằng dấu ;, đó là lý do regex khớp với chuỗi host:port;port.

PromQL và Ngôn Ngữ Truy Vấn Datadog: Cú Pháp và Khả Năng

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 (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 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 thuật toán tích hợp sẵn như anomalies() (thuật toán basic, agile, robust) và forecast() (linear, seasonal), 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ận cảnh báo từ các rule mà Prometheus đánh giá theo chu kỳ cố định, sau đó định tuyến chúng 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 (hệ thống unified alerting, mặc định từ Grafana 9) đá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 anomaly, outlier và forecast. 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. Các con số của Datadog dưới đây là giá niêm yết theo hình thức thanh toán hằng năm.

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

Prometheus là hệ thống metrics mặc định của hệ sinh thái Kubernetes, khiến đây trở thành chủ đề phỏng vấn chủ đạo 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. Việc ghi đè giá trị của chart theo cách này được trình bày chi tiết hơn trong hướng dẫn phỏng vấn về Helm chart.

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.x nhận trực tiếp OTLP metrics khi --web.enable-otlp-receiver được bật, nên không còn 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 Observability So Sánh Ba Công Cụ

Ngoài bản thân Prometheus, các câu hỏi sau kiểm tra xem ứng viên có lập luận được khi so sánh giữa các công cụ hay không. Mỗi câu trả lời làm rõ 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: hệ thống ưu tiên tính khả dụng của chính nó. 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 hoặc Cortex), dữ liệu tính phí theo từng request đòi hỏi độ chính xác 100% (cơ chế thu thập dựa trên scrape có thể bỏ sót sample), và hệ thống event-based cần thu thập push-based (Pushgateway có tồn tại, nhưng chỉ dành cho các batch job ở cấp service).

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.

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

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.

Nguồn Tham Khảo

• Các bản phát hành Prometheus: 3.15.0 (tháng 9 năm 2026) đưa XOR2 chunk encoding lên stable, bổ sung scrape OpenMetrics 2.0 và đánh dấu deprecated --log.level
• Đặc tả native histograms của Prometheus: stable từ 3.8, bắt buộc scrape_native_histograms từ 3.9
• Điểm mới trong Grafana 13.0: Git Sync GA, dynamic dashboards theo mặc định, các breaking change
• Bảng giá niêm yết Datadog: giá infrastructure, APM và log dùng trong bảng chi phí
• Hàm thuật toán của Datadog: cú pháp anomalies() và forecast()

Những Điều Cần Nhớ Cho Buổi Phỏng Vấn Prometheus và Observability

• Prometheus là chuẩn mực cho việc thu thập metrics trong môi trường Kubernetes; cần nắm chắc pull và push, bốn loại metric, rate() và irate(), cardinality và HA
• Từ Prometheus 3.9 trở đi, native histograms chỉ được ingest khi đặt scrape_native_histograms: true
• 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 tính năng phát hiện bất thường tích hợp sẵn, đổ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
• Để chuẩn bị rộng hơn, hướng dẫn các câu hỏi phỏng vấn DevOps thiết yếu bao quát các chủ đề liên quan mà nhà tuyển dụng thường nối tiếp sau phần monitoring