คำถามสัมภาษณ์ Prometheus 2026: เปรียบเทียบ Prometheus vs Grafana vs Datadog

คำถามสัมภาษณ์เกี่ยวกับ Prometheus ปรากฏในการสัมภาษณ์งาน DevOps และ SRE แทบทุกรอบ และมักตามมาด้วยคำถามว่า "ทำไมไม่ใช้ Grafana หรือ Datadog" ผู้สมัครต้องอธิบายได้ว่า Prometheus scrape และจัดเก็บ metrics อย่างไร เขียน PromQL ได้ถูกต้อง และให้เหตุผลถึงข้อแลกเปลี่ยนเมื่อเทียบกับแพลตฟอร์มแบบ managed ผู้สัมภาษณ์ใช้หัวข้อนี้แยกประสบการณ์ operation จริงออกจากความรู้ในตำรา โมดูลคำถามสัมภาษณ์ Prometheus และ monitoring มีหัวข้อเดียวกันนี้ในรูปแบบคำถามสำหรับฝึกซ้อม

คำถามสัมภาษณ์ Prometheus ที่พบในรอบสัมภาษณ์ DevOps และ SRE

ต่อไปนี้คือคำถามเฉพาะเรื่อง Prometheus ที่ถูกถามบ่อยที่สุด พร้อมคำตอบที่ผู้สมัครซึ่งมั่นใจในความรู้ให้ได้ ทุกคำตอบอ้างอิง Prometheus 3.x โดยสาย stable ปัจจุบันคือ 3.15 (กันยายน 2026) และ 3.16 อยู่ในสถานะ release candidate

ถาม: ทำไม Prometheus จึงดึง (pull) metrics แทนที่จะรอรับการ push

การ pull ทำให้สุขภาพของ target ตรวจสอบได้ ทุกครั้งที่ scrape จะเกิด series ชื่อ up ดังนั้น target ที่ตายจะแสดงเป็น up == 0 แทนที่จะเงียบหายไป server เป็นผู้ควบคุมอัตราการ scrape จึงป้องกันตัวเองจาก client ที่ทำงานผิดปกติได้ และสามารถตรวจสอบ target ด้วยมือได้โดยเปิด endpoint /metrics ในเบราว์เซอร์ ข้อเสียคือ Prometheus ต้องเข้าถึงทุก target ผ่านเครือข่ายได้ จึงเป็นเหตุผลที่ batch job อายุสั้นต้องใช้ Pushgateway และการตั้งค่าข้ามเครือข่ายใช้ remote write

ถาม: metric มีสี่ประเภทอะไรบ้าง และเมื่อใดที่ summary เป็นตัวเลือกที่ผิด

Counter (เพิ่มขึ้นอย่างเดียว และ reset เมื่อ restart), gauge (เพิ่มและลดได้), histogram (นับค่าที่สังเกตได้ลงใน bucket) และ summary (คำนวณ quantile ฝั่ง client) quantile ของ summary นำมา aggregate ไม่ได้ การหาค่าเฉลี่ยของ p99 จากสิบ pod ไม่ได้ให้ p99 ของทั้ง service ส่วน histogram สามารถรวมข้าม instance ก่อนแล้วจึงแปลงเป็น quantile ที่ฝั่ง server ได้ histogram จึงเป็นค่าเริ่มต้นสำหรับ latency

# 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 ใน clause by ของรูปแบบ classic เป็นข้อผิดพลาด PromQL ที่พบบ่อยที่สุดในรอบ live coding เพราะ query จะไม่คืนผลลัพธ์ที่ใช้งานได้

ถาม: rate(), irate() และ increase() ต่างกันอย่างไร

rate() คืนค่าเฉลี่ยต่อวินาทีตลอดช่วงเวลาทั้งหมด และจัดการ counter reset ให้ irate() ใช้เพียงสอง sample สุดท้ายในช่วงเวลา จึงตอบสนองเร็วแต่มี noise สูง เหมาะกับกราฟที่ซูมเข้าดู แต่ไม่เหมาะกับการแจ้งเตือน increase() คือ rate() คูณด้วยความยาวของช่วงเวลา เนื่องจาก Prometheus ทำ extrapolation ไปถึงขอบของ window increase() บน counter ที่เป็นจำนวนเต็มจึงอาจคืนค่าที่ไม่ใช่จำนวนเต็ม และผู้สัมภาษณ์ชอบถามว่าเพราะอะไร

ถาม: cardinality คืออะไร และวินิจฉัย cardinality explosion อย่างไร

ทุกชุดค่าผสมที่ไม่ซ้ำกันของชื่อ metric และค่า label คือ time series แยกหนึ่งตัวที่ถูกเก็บไว้ในหน่วยความจำ label อย่าง user_id, email หรือ URL path ดิบที่มี ID อยู่ จะทวีจำนวน series จน server หน่วยความจำหมด การวินิจฉัยเริ่มจากหน้าสถานะ TSDB (/tsdb-status) หรือด้วย query

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

การแก้ไขต้องทำที่ต้นทาง: drop หรือเขียน label ใหม่ด้วย metric_relabel_configs หรือกำหนด sample_limit ให้ scrape job เพื่อไม่ให้ deployment ที่ผิดพลาดเพียงตัวเดียวทำให้ server ล่ม

ถาม: recording rule มีไว้ทำอะไร

recording rule คำนวณ expression ที่มีต้นทุนสูงไว้ล่วงหน้าในทุกรอบการประเมิน แล้วจัดเก็บผลลัพธ์เป็น series ใหม่ จากนั้น dashboard และ alert จะ query series ที่คำนวณไว้แล้วซึ่งมีต้นทุนต่ำ รูปแบบการตั้งชื่อคือ level:metric:operations

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

ถาม: clause for ใน alerting rule ทำหน้าที่อะไร

alert ที่ expression กลายเป็นจริงจะเปลี่ยนสถานะจาก inactive เป็น pending และจะเข้าสู่ firing ก็ต่อเมื่อเงื่อนไขคงอยู่ครบระยะเวลาของ for เท่านั้น กลไกนี้กรองความผิดปกติชั่วขณะที่เกิดใน scrape เดียวออกไป keep_firing_for ทำงานในทางกลับกัน คือคงสถานะ firing ไว้ระยะหนึ่งหลังเงื่อนไขหายไป ซึ่งป้องกันไม่ให้ alert ที่ขึ้นลงสลับไปมาส่ง page ซ้ำสองครั้ง

ถาม: ทำให้ Prometheus มี high availability ได้อย่างไร

รัน replica ที่เหมือนกันสองตัว scrape target ชุดเดียวกัน โดยแต่ละตัวมี external label replica ที่ต่างกัน ทั้งสองส่ง alert ไปยัง Alertmanager cluster ซึ่งทำ deduplication ของการแจ้งเตือนผ่าน gossip protocol สำหรับการ query นั้น Thanos Query หรือ Mimir จะ deduplicate series ทั้งสองโดยไม่สนใจ label replica ตัว Prometheus เองไม่มี clustering: TSDB แบบ local ของ server เดี่ยวไม่ได้ถูก replicate

ถาม: ระบบ multi-cluster ควรใช้ federation หรือ remote write

Federation ให้ Prometheus ส่วนกลาง scrape series ที่เลือกไว้ (โดยมากเป็นค่าที่ aggregate แล้ว) จาก endpoint /federate ของ Prometheus ในแต่ละ cluster เหมาะกับ rollup จำนวนไม่มาก ส่วน remote write จะ stream ทุก sample ไปยัง store ส่วนกลาง เช่น Mimir, Thanos Receive หรือ backend ของ vendor และเป็นคำตอบมาตรฐานสำหรับการ query ข้ามทุก cluster และการเก็บข้อมูลระยะยาว

ถาม: ตรวจจับ target ที่หายไปจาก service discovery ได้อย่างไร

up == 0 จะทำงานเฉพาะเมื่อ target ยังถูก discover อยู่ หาก pod หรือรายการใน service discovery หายไป series นั้นจะหยุดมีอยู่ และ alert จะไม่มีวัน fire absent(up{job="api-server"}) ครอบคลุมกรณีนี้

ถาม: Prometheus 3 มีอะไรเปลี่ยนแปลงบ้าง

Prometheus 3.0 (พฤศจิกายน 2024) มาพร้อม UI ใหม่ อนุญาตให้ใช้อักขระ UTF-8 ในชื่อ metric และ label และเพิ่ม OTLP receiver ในตัวที่ /api/v1/otlp/v1/metrics ซึ่งเปิดใช้ด้วย --web.enable-otlp-receiver native histogram ได้รับสถานะ stable ในเวอร์ชัน 3.8 ตั้งแต่ 3.9 เป็นต้นมา feature flag เดิมไม่มีผลใด ๆ และการรับข้อมูลต้องกำหนด scrape_native_histograms: true ใน scrape config หรือ global config ส่วน 3.15 ทำให้ XOR2 float chunk encoding เป็น stable และเพิ่มการ scrape แบบ OpenMetrics 2.0

สถาปัตยกรรมและ Data Model: แต่ละเครื่องมือจัดการ Metrics อย่างไร

เมื่อครอบคลุมพื้นฐานของ Prometheus แล้ว ผู้สัมภาษณ์มักต่อด้วยคำถามว่าเครื่องมือทั้งสามแตกต่างกันอย่างไรในเชิงสถาปัตยกรรม

Prometheus ใช้โมเดลแบบ pull-based กล่าวคือจะทำการ scrape HTTP endpoint (โดยทั่วไปคือ /metrics) ตามช่วงเวลาที่กำหนดไว้ แล้วจัดเก็บข้อมูล time-series ในฐานข้อมูล TSDB แบบ local ที่ออกแบบมาเฉพาะ time series แต่ละตัวถูกระบุด้วยชื่อ metric และชุดของ key-value label สาย 3.x เพิ่ม native histograms ที่ stable แล้ว OTLP receiver และ Remote Write 2.0 สำหรับส่ง sample ไปยัง storage ส่วนกลาง

Grafana ไม่ได้ทำหน้าที่เก็บรวบรวมหรือจัดเก็บ metrics แต่เชื่อมต่อกับ data source ต่าง ๆ ไม่ว่าจะเป็น Prometheus, Loki, Tempo, InfluxDB, Elasticsearch และอื่น ๆ อีกกว่า 100 ตัว จากนั้น render dashboard จากข้อมูลเหล่านั้น Grafana Labs ยังเป็นผู้ดูแล Mimir (สำหรับจัดเก็บ metrics ระยะยาว), Loki (สำหรับรวบรวม log) และ Tempo (สำหรับ distributed tracing) ซึ่งเมื่อรวมกับ Grafana จะเป็น LGTM stack แบบ open-source Grafana 13 ที่ประกาศในงาน GrafanaCON เมื่อเดือนเมษายน 2026 ทำให้ Git Sync สำหรับ dashboard เป็น generally available เปิดใช้ dynamic dashboard เป็นค่าเริ่มต้น และนำคำสั่ง grafana-cli และ grafana-server ออก

Datadog ทำงานแบบ push-based ในรูปแบบ SaaS โดย agent ที่ติดตั้งบน host จะส่ง metrics, log และ trace ไปยัง cloud backend ของ Datadog ทุกอย่างตั้งแต่การรับข้อมูล การจัดเก็บ การ query การแจ้งเตือน ไปจนถึง dashboard ทำงานอยู่ภายในแพลตฟอร์มเดียวที่จัดการให้ทั้งหมด engine Watchdog ตรวจจับ anomaly โดยอัตโนมัติโดยไม่ต้องตั้งค่า threshold ด้วยตนเอง

# 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 model ของ Prometheus ซึ่งค้นหา Kubernetes pod ผ่าน service discovery เก็บไว้เฉพาะ pod ที่มี annotation prometheus.io/scrape: "true" เขียน address ใหม่ให้ชี้ไปยัง port ที่ระบุใน annotation แล้ว scrape /metrics ทุก 15 วินาที rule ที่สองนำ source label ทั้งสองมาต่อกันด้วย ; จึงเป็นเหตุผลที่ regex จับรูปแบบ host:port;port

PromQL vs Datadog Query Language: ไวยากรณ์และความสามารถ

ภาษา query เป็นหัวข้อที่ถูกถามบ่อยในการสัมภาษณ์ ผู้สมัครควรแสดงความชำนาญในอย่างน้อยหนึ่งภาษา และสามารถอธิบายข้อแลกเปลี่ยนระหว่างทั้งสองได้

PromQL (Prometheus Query Language) เป็นภาษามาตรฐานสำหรับ metrics query ใน ecosystem ของ Prometheus และ Grafana รองรับ instant vector, range vector, aggregation operator และ 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

ภาษา query ของ 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 ในขณะที่ภาษา query ของ Datadog แลกความยืดหยุ่นบางส่วนกับฟังก์ชันเชิงอัลกอริทึมที่มาพร้อมใช้งาน เช่น anomalies() (อัลกอริทึม basic, agile, robust) และ forecast() (linear, seasonal) ซึ่งหากใช้ Prometheus stack จะต้องพึ่งพาเครื่องมือภายนอก

กลยุทธ์การแจ้งเตือน: Rules-Based vs ML-Powered Detection

ปรัชญาการแจ้งเตือนมีความแตกต่างอย่างชัดเจนระหว่างเครื่องมือเหล่านี้ และการทำความเข้าใจความแตกต่างนี้แสดงถึงความพร้อมด้าน operational ในการสัมภาษณ์

Prometheus Alertmanager รับ alert จาก rule ที่ Prometheus ประเมินตามช่วงเวลาที่กำหนด แล้วส่งต่อผ่าน pipeline ที่ตั้งค่าได้ ซึ่งรองรับทั้ง 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

แนวทางนี้กำหนดให้ผู้ดูแลระบบต้องตั้ง threshold อย่างชัดเจน ข้อดีคือมีความโปร่งใสเต็มที่ เพราะทุก alert มี expression ที่สามารถตรวจสอบได้ ข้อเสียคือปัญหา threshold fatigue ซึ่งค่าคงที่มักต้องปรับตามฤดูกาลหรือรูปแบบการใช้งาน

Grafana Alerting (ระบบ unified alerting ซึ่งเป็นค่าเริ่มต้นตั้งแต่ Grafana 9) ประเมิน query จาก data source ที่เชื่อมต่อทุกตัว และรองรับ multi-dimensional alert พร้อม notification policy

Datadog Monitors ผสมผสาน static threshold เข้ากับ anomaly, outlier และ forecast monitor โดย Watchdog จะตรวจจับ performance anomaly โดยอัตโนมัติโดยไม่ต้องสร้าง rule ด้วยตนเอง วิธีนี้ลดภาระการตั้งค่า แต่แลกมาด้วยความโปร่งใสที่ลดลงในตรรกะการตรวจจับ

ราคาและ Total Cost of Ownership ในปี 2026

เรื่องราคาเป็นปัจจัยชี้ขาดในการเลือกเครื่องมือในสถานการณ์จริง และมักถูกถามในการสัมภาษณ์เกี่ยวกับ system design การทำความเข้าใจโครงสร้างต้นทุนแสดงถึงความตระหนักด้านธุรกิจของผู้สมัคร ตัวเลขของ Datadog ด้านล่างเป็นราคาตามรายการ (list price) แบบชำระรายปี

Stack แบบ open-source ดูเหมือนจะถูกกว่าเมื่อพิจารณาจากตัวเลข แต่ต้องใช้เวลาของวิศวกรในการอัปเกรด วางแผนความจุ และตั้งค่า high-availability ส่วนโมเดลแบบ managed ของ Datadog โอนภาระเหล่านั้นให้ผู้ให้บริการ สำหรับทีมที่มีวิศวกรดูแล infrastructure ไม่ถึง 5 คน โซลูชันแบบ managed มักมีต้นทุนรวมที่ต่ำกว่าเมื่อนับรวมเวลาของวิศวกรเข้าไปด้วย

Kubernetes Monitoring: เปรียบเทียบความลึกของการ Integration

Prometheus เป็นระบบ metrics มาตรฐานของ ecosystem Kubernetes ทำให้หัวข้อนี้เป็นประเด็นหลักในการสัมภาษณ์เกี่ยวกับ container orchestration monitoring

Prometheus + Grafana ทำงานร่วมกับ Kubernetes ได้โดยตรงผ่าน kube-prometheus-stack Helm chart ซึ่ง deploy Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics และ Grafana dashboard สำเร็จรูปในครั้งเดียว

# 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

คำสั่งนี้ deploy monitoring stack ระดับ production พร้อม persistent storage และ retention 30 วัน Prometheus Operator ใช้ Custom Resource Definition (ServiceMonitor, PodMonitor) เพื่อกำหนดค่า scrape target แบบ declarative การ override ค่าของ chart ในลักษณะนี้อธิบายไว้ละเอียดกว่าในคู่มือสัมภาษณ์เรื่อง Helm chart

Datadog ใช้การ deploy agent DaemonSet และ Cluster Agent โดย Cluster Agent จัดการการสื่อสารกับ API server แบบรวมศูนย์ ลดภาระบน Kubernetes API ฟีเจอร์ Live Containers ของ Datadog ให้การมองเห็น pod state แบบ real-time และ Orchestrator Explorer แสดงความสัมพันธ์ระหว่าง deployment, service และ pod

สำหรับทีมที่ลงทุนใน Kubernetes ecosystem อยู่แล้ว แนวทาง Prometheus-native ช่วยหลีกเลี่ยงการพึ่งพา dependency ภายนอก ส่วนทีมที่ต้องการความรวดเร็วในการติดตั้งพร้อมภาระดูแลน้อยมักเลือก Datadog

OpenTelemetry และความเป็นกลางต่อ Vendor

OpenTelemetry (OTel) กลายเป็นมาตรฐานอุตสาหกรรมสำหรับ instrumentation และผู้สัมภาษณ์มักถามเกี่ยวกับ OTel ควบคู่กับการเปรียบเทียบเครื่องมือ monitoring

Prometheus 3.x รับ OTLP metrics ได้โดยตรงเมื่อกำหนด --web.enable-otlp-receiver จึงไม่จำเป็นต้องใช้ Collector เป็นตัวกลางอีกต่อไป Grafana Alloy (ตัวต่อจาก Grafana Agent) ทำหน้าที่เป็นทั้ง OTel Collector และ Prometheus scraper ส่วน Datadog รองรับ OTLP ingestion แต่แนะนำให้ใช้ agent ของตนเองเพื่อ "การเข้าถึงฟีเจอร์เต็มรูปแบบ" ซึ่งสร้าง soft lock-in ในทางปฏิบัติ

การนำ OTel มาใช้มีความสำคัญเพราะแยก instrumentation ออกจากตัวเลือก backend โค้ดของแอปพลิเคชันที่ instrument ด้วย OTel SDK สามารถส่ง telemetry ไปยัง Prometheus, Grafana Cloud, Datadog หรือ backend ที่เข้ากันได้อื่น ๆ โดยไม่ต้องเปลี่ยนโค้ด ความยืดหยุ่นนี้เป็นเหตุผลที่แข็งแกร่งในการสัมภาษณ์ system design เมื่อพูดถึงกลยุทธ์ observability ระยะยาว

คำถามสัมภาษณ์ Observability ที่เปรียบเทียบเครื่องมือทั้งสาม

นอกเหนือจากตัว Prometheus เอง คำถามต่อไปนี้ทดสอบว่าผู้สมัครสามารถให้เหตุผลข้ามเครื่องมือได้หรือไม่ คำตอบแต่ละข้อเน้นแนวคิดที่ผู้สัมภาษณ์ต้องการตรวจสอบ

ถาม: อธิบายความแตกต่างระหว่าง monitoring, observability และ alerting

Monitoring ติดตาม metrics ที่กำหนดไว้ล่วงหน้าและตรวจสอบรูปแบบความล้มเหลวที่รู้จัก Observability ช่วยให้สามารถสืบสวนรูปแบบความล้มเหลวที่ไม่รู้จักผ่าน metrics, log และ trace ("สามเสาหลัก") ส่วน alerting คือการส่งการแจ้งเตือนเมื่อเงื่อนไขเกิน threshold ที่กำหนดหรือ baseline ของ anomaly Monitoring ตอบคำถามว่า "ระบบทำงานปกติหรือไม่" Observability ตอบคำถามว่า "ทำไมระบบจึงทำงานผิดปกติ"

ถาม: Prometheus ไม่เหมาะกับสถานการณ์ใดบ้าง

Prometheus ถูกออกแบบมาให้เน้น reliability มากกว่า durability กล่าวคือให้ความสำคัญกับ availability ของระบบ monitoring เป็นหลัก สถานการณ์ที่ Prometheus มีข้อจำกัด ได้แก่ การจัดเก็บข้อมูลระยะยาวเกิน 30 วัน (ต้องใช้ Thanos, Mimir หรือ Cortex) ข้อมูลการเรียกเก็บเงินแบบ per-request ที่ต้องการความแม่นยำ 100% (การเก็บข้อมูลด้วยการ scrape อาจพลาด sample ได้) และระบบแบบ event-based ที่ต้องการ push-based collection (Pushgateway มีอยู่ แต่ใช้ได้เฉพาะกับ batch job ระดับ service เท่านั้น)

ถาม: ปรัชญา "Big Tent" ของ Grafana ส่งผลต่อสถาปัตยกรรม observability อย่างไร

Grafana เชื่อมต่อกับ data source ใดก็ได้โดยไม่ต้อง migrate ข้อมูล ทำให้ทีมสามารถ query Prometheus, Elasticsearch, CloudWatch และ Datadog จาก dashboard เดียวกัน ข้อแลกเปลี่ยนคือความซับซ้อนด้าน operation เนื่องจากการดูแล backend หลายตัวต้องใช้ความเชี่ยวชาญด้าน infrastructure มากกว่าแนวทาง single-vendor ผู้สัมภาษณ์ต้องการทดสอบว่าผู้สมัครสามารถอธิบายข้อแลกเปลี่ยนนี้ได้ชัดเจนหรือไม่

ถาม: High-watermark billing ของ Datadog คืออะไร และมีความสำคัญอย่างไร

Datadog วัดจำนวน host รายชั่วโมง ตัดชั่วโมงที่สูงที่สุด 1% ออก แล้วคิดเงินตาม peak ที่ percentile ที่ 99 หมายความว่า auto-scaling spike ชั่วคราว (เช่น ช่วง Black Friday) จะทำให้ค่าใช้จ่ายรายเดือนสูงขึ้นแม้ว่า instance จะถูกยุติไปแล้ว ผู้สมัครที่กล่าวถึงเรื่องนี้แสดงให้เห็นว่ามีประสบการณ์จริงด้านการบริหารต้นทุน ซึ่งตำแหน่ง SRE ในปัจจุบันให้ความสำคัญมากขึ้น

ถาม: กลยุทธ์ SLO-based alerting แตกต่างกันอย่างไรระหว่าง Prometheus และ Datadog

ใน Prometheus การแจ้งเตือนแบบ SLO ใช้ recording rule เพื่อคำนวณ error budget และ burn rate alert ล่วงหน้า (แนวทาง multi-window, multi-burn-rate จากหนังสือ SRE ของ Google) ส่วน Datadog มี SLO widget และ monitor ที่ติดตาม burn rate โดยอัตโนมัติ ทั้งสองแนวทางใช้แนวคิดเดียวกัน แต่ Prometheus ต้องตั้งค่าด้วยตนเองมากกว่า ในขณะที่ Datadog มี workflow ที่จัดการให้ ผู้สมัครควรอ้างอิง burn rate window (1 ชั่วโมง, 6 ชั่วโมง, 3 วัน) และอัตราการใช้ error budget ในคำตอบ

Decision Framework: การเลือก Stack ที่เหมาะสม

การเลือกที่เหมาะสมขึ้นอยู่กับตัวแปรสามประการ ได้แก่ ขนาดทีม ความพร้อมด้าน operation และข้อจำกัดด้านงบประมาณ ไม่มีคำตอบที่ถูกต้องสากล และผู้สัมภาษณ์คาดหวังให้ผู้สมัครวิเคราะห์ข้อแลกเปลี่ยนอย่างเป็นเหตุเป็นผลมากกว่าที่จะยืนยันว่าเครื่องมือใดเครื่องมือหนึ่งดีที่สุด

แหล่งข้อมูลอ้างอิง

• Prometheus releases: 3.15.0 (กันยายน 2026) ทำให้ XOR2 chunk encoding เป็น stable เพิ่มการ scrape แบบ OpenMetrics 2.0 และประกาศเลิกใช้ --log.level
• ข้อกำหนด native histograms ของ Prometheus: stable ตั้งแต่ 3.8 และต้องกำหนด scrape_native_histograms ตั้งแต่ 3.9
• What's new in Grafana 13.0: Git Sync GA, dynamic dashboard เป็นค่าเริ่มต้น และ breaking change
• ราคาตามรายการของ Datadog: ราคา infrastructure, APM และ log ที่ใช้ในตารางต้นทุน
• ฟังก์ชันเชิงอัลกอริทึมของ Datadog: ไวยากรณ์ของ anomalies() และ forecast()

สิ่งที่ควรจำสำหรับการสัมภาษณ์ด้าน Prometheus และ Observability

• Prometheus เป็นมาตรฐานสำหรับการเก็บรวบรวม metrics ใน Kubernetes environment ผู้สมัครควรรู้เรื่อง pull vs push, metric สี่ประเภท, rate() vs irate(), cardinality และ HA อย่างแม่นยำ
• บน Prometheus 3.9 ขึ้นไป native histogram จะถูกรับเข้าระบบก็ต่อเมื่อกำหนด scrape_native_histograms: true เท่านั้น
• Grafana คือ visualization layer ไม่ใช่ metrics database เชื่อมต่อกับ data source กว่า 100 ตัวรวมถึง Prometheus และ LGTM stack (Loki, Grafana, Tempo, Mimir) ประกอบเป็นแพลตฟอร์ม observability แบบ open-source ครบวงจร
• Datadog ให้เส้นทางที่เร็วที่สุดสู่ full-stack observability พร้อม anomaly detection ในตัว แลกกับราคาที่สูงกว่าและ vendor lock-in
• การนำ OpenTelemetry มาใช้ทำให้ตัวเลือก backend มีความยืดหยุ่นมากขึ้น เพราะ instrumentation ยังคงเหมือนเดิมไม่ว่าจะใช้เครื่องมือใดจัดเก็บและ query ข้อมูล
• ในการสัมภาษณ์ ควรแสดงความสามารถในการวิเคราะห์ข้อแลกเปลี่ยน (ต้นทุน การควบคุม ความซับซ้อน) มากกว่าการสนับสนุนเครื่องมือใดเครื่องมือเดียว
• สำหรับการเตรียมตัวในวงกว้างขึ้น คู่มือคำถามสัมภาษณ์ DevOps ที่จำเป็น ครอบคลุมหัวข้อใกล้เคียงที่ผู้สัมภาษณ์มักถามต่อจากเรื่อง monitoring