Prometheus + Grafana: สถาปัตยกรรม Monitoring Stack สำหรับ Production

Prometheus กับ Grafana เป็นคู่หูที่ใช้กันแพร่หลายในการทำระบบ Monitoring ระดับ Production โดยระบบเก็บ Metrics ทำหน้าที่เก็บ Metrics จากระบบต่าง ๆ ส่วน Grafana ทำหน้าที่นำข้อมูลมาแสดงผลผ่าน Dashboard ที่สวยงามและตอบสนองรวดเร็ว การออกแบบสถาปัตยกรรมของสองเครื่องมือนี้ให้เหมาะสมกับปริมาณงานและความต้องการขององค์กรมีความสำคัญอย่างยิ่ง

บทความนี้จะอธิบายองค์ประกอบหลักของสถาปัตยกรรม Monitoring Stack วิธีการเชื่อมต่อส่วนประกอบต่าง ๆ การวางแผนด้านความพร้อมใช้งานสูง การจัดเก็บข้อมูลระยะยาว และแนวทางที่แนะนำสำหรับการใช้งานจริงใน Production

องค์ประกอบหลักของ Monitoring Stack

Monitoring Stack ที่สมบูรณ์ประกอบด้วยหลายส่วนที่ทำงานร่วมกัน แต่ละส่วนมีหน้าที่เฉพาะและสามารถปรับขยายได้ตามปริมาณงาน

Prometheus Server — หัวใจของระบบที่ดึง Metrics จาก Target และเก็บไว้ใน Time Series Database
Exporters — โปรแกรมขนาดเล็กที่แปลง Metrics จากแหล่งต่าง ๆ ให้อยู่ในรูปแบบที่ Prometheus เข้าใจ
Alertmanager — จัดการการแจ้งเตือนจาก Prometheus ส่งต่อไปยังช่องทางต่าง ๆ
Pushgateway — รองรับ Metrics จาก Job ที่รันระยะสั้นหรือ Batch Job
Grafana — แสดง Dashboard และตั้งค่า Alert ขั้นสูง
Service Discovery — ค้นหา Target โดยอัตโนมัติจาก Kubernetes, Consul, EC2

การไหลของข้อมูลในระบบ

ข้อมูลใน Monitoring Stack ไหลตามรูปแบบที่ออกแบบไว้อย่างชัดเจน เริ่มจาก Application หรือระบบที่ถูกตรวจสอบ ไปจบที่ผู้ใช้งานที่ดู Dashboard หรือได้รับ Alert

ขั้นตอนการไหลของข้อมูล

Application เปิด Endpoint /metrics เพื่อให้ Prometheus ดึงข้อมูล
Server ทำ Scrape ข้อมูลตามช่วงเวลาที่กำหนด (เช่น ทุก 15 วินาที)
ข้อมูลถูกเก็บใน Time Series Database ภายใน Prometheus
Grafana เชื่อมต่อกับ Prometheus เป็น Data Source
ผู้ใช้สร้าง Dashboard หรือ Alert Rule ใน Grafana
Alertmanager ส่งการแจ้งเตือนไปยัง Email, Slack, PagerDuty

สถาปัตยกรรมแบบ Single Node

สำหรับระบบขนาดเล็กถึงกลางที่มี Target ไม่เกิน 100-200 เครื่อง การใช้งานบนเซิร์ฟเวอร์เดียวเป็นทางเลือกที่เรียบง่ายและคุ้มค่า เหมาะสำหรับการเริ่มต้นหรือระบบภายในองค์กรที่ไม่ต้องการความพร้อมใช้งานสูงมาก

# docker-compose.yml สำหรับ Single Node Setup
version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=15d'
      - '--web.enable-lifecycle'
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=StrongPassword123
    restart: unless-stopped

  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

สถาปัตยกรรมแบบ High Availability

ในระบบ Production ที่ต้องการความพร้อมใช้งานสูง การใช้งานเพียงเครื่องเดียวอาจเสี่ยงต่อการสูญเสียข้อมูลและ Downtime การออกแบบแบบ HA จึงแนะนำให้รัน Instance อย่างน้อย 2 เครื่องคู่ขนานกัน ทำ Scrape เป้าหมายเดียวกัน เพื่อให้ข้อมูลซ้ำและทนต่อการล้มเหลว

องค์ประกอบสำหรับ HA

Prometheus HA Pair — 2 Instance รัน Scrape เป้าหมายเดียวกัน
Thanos หรือ Cortex — รวมข้อมูลจากหลาย Server และจัดเก็บระยะยาว
Load Balancer — กระจายโหลดและทำ Failover อัตโนมัติ
Alertmanager Cluster — รัน Alertmanager 3 Instance เพื่อ Deduplicate Alert
Grafana HA — ใช้ Database External (MySQL/PostgreSQL) ร่วมกับ Load Balancer

การเก็บข้อมูลระยะยาว (Long-term Storage)

ระบบถูกออกแบบมาให้เก็บข้อมูลแบบ Local Storage ซึ่งเหมาะกับการใช้งานระยะสั้น (15-90 วัน) แต่ในองค์กรที่ต้องการดูข้อมูลย้อนหลังเป็นปีหรือต้องปฏิบัติตามข้อกำหนดด้านการเก็บข้อมูล จำเป็นต้องใช้ Remote Storage

ตัวเลือก Long-term Storage

Thanos — ใช้ Object Storage (S3, GCS) เก็บข้อมูลระยะยาว รองรับ Query ข้ามหลาย Instance
Cortex / Mimir — Multi-tenant as a Service จาก Grafana Labs
VictoriaMetrics — Drop-in Replacement ที่ใช้ Storage น้อยกว่าและเร็วกว่า
InfluxDB — Time Series Database ที่รองรับ Prometheus Remote Write
TimescaleDB — PostgreSQL Extension สำหรับ Time Series

การตั้งค่าไฟล์ Configuration เบื้องต้น

ไฟล์ prometheus.yml คือหัวใจของการกำหนดค่าระบบ กำหนด Target ที่ต้อง Scrape ช่วงเวลา และกฎการแจ้งเตือน

# prometheus.yml — ตัวอย่างสำหรับ Production
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: 'production'
    region: 'ap-southeast-1'

# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager:9093'

# Alert rules
rule_files:
  - "/etc/prometheus/rules/*.yml"

# Scrape configs
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets:
          - 'node1:9100'
          - 'node2:9100'
          - 'node3:9100'

  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

# Remote write สำหรับ Long-term Storage
remote_write:
  - url: "https://thanos-receive:10908/api/v1/receive"

การเลือกขนาดของเซิร์ฟเวอร์

ขนาดของเซิร์ฟเวอร์ที่เหมาะสมขึ้นอยู่กับปริมาณ Metrics, จำนวน Target, และระยะเวลาการเก็บข้อมูล ตารางด้านล่างเป็นแนวทางสำหรับการเลือกขนาดเบื้องต้น

ขนาดระบบ	Target	Metrics/s	CPU	RAM	Disk
เล็ก	< 100	< 10K	2 Core	4 GB	50 GB SSD
กลาง	100-500	10K-50K	4 Core	16 GB	200 GB SSD
ใหญ่	500-2000	50K-200K	8 Core	32 GB	500 GB SSD
ใหญ่มาก	> 2000	> 200K	16+ Core	64+ GB	1+ TB NVMe

แนวทางการออกแบบที่ดี

การวางระบบ Monitoring ให้ทำงานได้ดีในระยะยาวต้องคำนึงถึงหลายปัจจัย ไม่ใช่แค่การติดตั้งเครื่องมือแล้วเปิดใช้งาน แต่ต้องวางแผนการขยาย การดูแลรักษา และการใช้งานจริง

แยก Instance สำหรับแต่ละ Environment (Dev, Staging, Production)
ใช้ Service Discovery แทน Static Config เพื่อรองรับการเปลี่ยนแปลง
วางแผน Data Retention ตั้งแต่เริ่มต้น ป้องกัน Disk เต็ม
ตั้ง Recording Rules สำหรับ Query ที่ใช้บ่อยเพื่อลดภาระ
ใช้ Label อย่างสม่ำเสมอ หลีกเลี่ยง Label ที่มีค่าหลากหลาย (High Cardinality)
Monitor ตัวระบบเอง (Meta-Monitoring)

ข้อควรระวังเมื่อใช้งานใน Production

Cardinality Explosion — การใส่ Label ที่มีค่าเยอะ (เช่น User ID) จะทำให้ Memory เต็ม
Scrape Timeout — ตั้ง scrape_timeout ให้น้อยกว่า scrape_interval เสมอ
Disk Space — ตรวจสอบพื้นที่ Disk ต่อเนื่องและตั้ง Alert
Alert Fatigue — อย่าตั้ง Alert มากเกินไป จะทำให้ทีมเพิกเฉย
Time Drift — เซิร์ฟเวอร์ทุกเครื่องต้อง Sync NTP ตรงกัน

สรุป

การออกแบบสถาปัตยกรรม Monitoring Stack ด้วย Prometheus และ Grafana ต้องเริ่มจากการเข้าใจองค์ประกอบหลักของระบบ การไหลของข้อมูล และความต้องการขององค์กร สำหรับระบบเล็กสามารถเริ่มจาก Single Node ได้ แต่เมื่อระบบเติบโตควรวางแผนสู่ HA และ Long-term Storage ตั้งแต่เนิ่น ๆ

การเลือกขนาดเซิร์ฟเวอร์ที่เหมาะสม การตั้งค่า prometheus.yml ที่ยืดหยุ่น และการปฏิบัติตามแนวทางที่ดีจะช่วยให้ระบบ Monitoring ทำงานได้อย่างเสถียร รองรับการเติบโต และเป็นรากฐานสำคัญของการดูแลระบบ Production ที่มีคุณภาพ