Prometheus vs Grafana vs Datadog ในปี 2026: เปรียบเทียบระบบ Monitoring และคำถามสัมภาษณ์ DevOps

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

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

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

Prometheus ใช้โมเดลแบบ pull-based กล่าวคือจะทำการ scrape HTTP endpoint (โดยทั่วไปคือ /metrics) ตามช่วงเวลาที่กำหนดไว้ แล้วจัดเก็บข้อมูล time-series ในฐานข้อมูล TSDB แบบ local ที่ออกแบบมาเฉพาะ time series แต่ละตัวถูกระบุด้วยชื่อ metric และชุดของ key-value label ใน Prometheus 3.0 (เปิดตัวเมื่อเดือนพฤศจิกายน 2024) native histograms ได้รับสถานะ stable ในเวอร์ชัน 3.8 การรับข้อมูลผ่าน OTLP กลายเป็นฟีเจอร์ built-in และ Remote Write 2.0 ช่วยปรับปรุง federation ระหว่าง cluster

Grafana ไม่ได้ทำหน้าที่เก็บรวบรวมหรือจัดเก็บ metrics แต่เชื่อมต่อกับ data source ต่าง ๆ ไม่ว่าจะเป็น Prometheus, Loki, Tempo, InfluxDB, Elasticsearch และอื่น ๆ อีกกว่า 100 ตัว จากนั้น render dashboard จากข้อมูลเหล่านั้น Grafana Labs ยังเป็นผู้ดูแล Mimir (สำหรับจัดเก็บ metrics ระยะยาว), Loki (สำหรับรวบรวม log) และ Tempo (สำหรับ distributed tracing) ซึ่งเมื่อรวมกันจะเป็น observability stack แบบ open-source ครบวงจร Grafana เวอร์ชัน 13 ที่เปิดตัวในเดือนพฤษภาคม 2026 มาพร้อมเครื่องมือ observability-as-code, Git Sync สำหรับ dashboard และ SQL Expressions สำหรับ query ข้ามแหล่งข้อมูล

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

# 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 model ของ Prometheus ซึ่งทำการค้นหา Kubernetes pod ผ่าน service discovery แล้ว scrape endpoint /metrics ของแต่ละ pod ทุก 15 วินาที

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

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

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

Prometheus Alertmanager ประเมิน rule ตามช่วงเวลาที่กำหนด แล้วส่ง alert ผ่าน 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 (รวมเป็นระบบเดียวตั้งแต่ Grafana 12 เป็นต้นไป) ประเมิน query จาก data source ที่เชื่อมต่อทุกตัว และรองรับ multi-dimensional alert พร้อม notification policy ที่ยืดหยุ่น

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

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

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

| Dimension | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | License | ฟรี (AGPL / Apache 2.0) | $15-31/host/เดือน (สัญญารายปี) | | Metrics storage | จัดการเอง (Mimir/Thanos) | รวมอยู่ในแพ็กเกจ คิดราคาตาม retention | | Log management | Loki (self-hosted) | $0.10/GB ที่ ingest + indexing | | APM / Traces | Tempo (self-hosted) | $31/host/เดือน | | Infrastructure cost | Compute + storage สำหรับ stack ทั้งหมด | ไม่มี (SaaS) | | Operational overhead | สูง (อัปเกรด, scaling, HA) | น้อยมาก | | ค่าใช้จ่ายรายปีโดยประมาณ (50 host) | $20K-60K (infra + engineering) | $50K-150K | | ความเสี่ยง vendor lock-in | ต่ำ (OpenTelemetry, PromQL) | สูงกว่า (ภาษา query เฉพาะของตนเอง) |

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

Kubernetes Monitoring: ความลึกของการ Integration

กว่า 80% ของ Kubernetes cluster ใช้ Prometheus สำหรับการเก็บรวบรวม metrics ทำให้หัวข้อนี้เป็นประเด็นหลักในการสัมภาษณ์เกี่ยวกับ 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

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.0 ขึ้นไปรับ OTLP metrics ได้โดยตรงโดยไม่ต้องใช้ 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 ระยะยาว

คำถามสัมภาษณ์ DevOps ด้าน Monitoring และ Observability

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

ถาม: อธิบายความแตกต่างระหว่าง 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% (Prometheus อาจทิ้ง sample เมื่อมี load สูง) และระบบแบบ event-based ที่ต้องการ push-based collection (แม้จะมี pushgateway เป็นทางออก)

ถาม: ปรัชญา "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 ในคำตอบ

สำหรับการฝึกฝนหัวข้อ monitoring เพิ่มเติม โมดูลคำถามสัมภาษณ์ Prometheus และ monitoring ครอบคลุมสถานการณ์จำลองเพิ่มเติมพร้อมคำอธิบายโดยละเอียด

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

| Scenario | Recommended Stack | Rationale | |----------|------------------|----------| | Startup ทีมวิศวกร < 10 คน | Datadog หรือ Grafana Cloud | ลดภาระด้าน operation ให้น้อยที่สุด | | องค์กรขนาดใหญ่ที่มี platform team | Prometheus + Grafana + Loki | ควบคุมได้เต็มที่ ต้นทุนต่อหน่วยต่ำกว่าเมื่อ scale | | Multi-cloud / hybrid | Prometheus + Grafana | เป็นกลางต่อ vendor ทำงานเหมือนกันทุก environment | | อุตสาหกรรมที่ต้อง compliance สูง (การเงิน, สาธารณสุข) | Self-hosted Prometheus + Grafana | ข้อมูลอยู่ภายในองค์กร | | Scaling รวดเร็ว การเติบโตไม่แน่นอน | Grafana Cloud (managed Mimir) | Scale ได้โดยไม่ต้องจัดการ infrastructure | | ต้องการ anomaly detection แบบ ML | Datadog | Watchdog ทำงานโดยไม่ต้องตั้งค่า |

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

สรุป

• Prometheus เป็นมาตรฐานสำหรับการเก็บรวบรวม metrics ใน Kubernetes environment โดยเวอร์ชัน 3.x ใน 2026 มาพร้อม native OTLP support และ native histogram ที่เสถียร
• Grafana คือ visualization layer ไม่ใช่ metrics database เชื่อมต่อกับ data source กว่า 100 ตัวรวมถึง Prometheus และ LGTM stack (Loki, Grafana, Tempo, Mimir) ประกอบเป็นแพลตฟอร์ม observability แบบ open-source ครบวงจร
• Datadog ให้เส้นทางที่เร็วที่สุดสู่ full-stack observability พร้อม alerting ที่ขับเคลื่อนด้วย ML แลกกับราคาที่สูงกว่าและ vendor lock-in
• การนำ OpenTelemetry มาใช้ทำให้ตัวเลือก backend มีความยืดหยุ่นมากขึ้น เพราะ instrumentation ยังคงเหมือนเดิมไม่ว่าจะใช้เครื่องมือใดจัดเก็บและ query ข้อมูล
• ในการสัมภาษณ์ ควรแสดงความสามารถในการวิเคราะห์ข้อแลกเปลี่ยน (ต้นทุน การควบคุม ความซับซ้อน) มากกว่าการสนับสนุนเครื่องมือใดเครื่องมือเดียว
• สำหรับการเตรียมตัวเชิงปฏิบัติ สามารถฝึกฝนได้ที่โมดูลคำถามสัมภาษณ์ DevOps และศึกษาเพิ่มเติมเกี่ยวกับแนวคิด CI/CD pipeline เพื่อเสริมความรู้ในหัวข้อที่เกี่ยวข้อง