Prometheus Grafana Monitoring ระบบ Server แบบ Pro

ในโลกที่ทุกธุรกิจต้องพึ่งพาระบบดิจิทัล การรัน Server อย่างราบรื่นและมีประสิทธิภาพสูงสุดคือหัวใจสำคัญที่ไม่สามารถละเลยได้ครับ แต่จะรู้ได้อย่างไรว่า Server ของคุณกำลังทำงานได้ดีแค่ไหน? มีปัญหาคอขวดที่ส่วนใดหรือไม่? หรือกำลังจะเกิดเหตุการณ์ไม่คาดฝันที่อาจนำไปสู่ Downtime ที่มีค่าใช้จ่ายมหาศาล? คำตอบคือ การ Monitoring ระบบ Server อย่างมืออาชีพ ครับ

บทความนี้จะพาคุณเจาะลึกถึงชุดเครื่องมืออันทรงพลังอย่าง Prometheus และ Grafana ซึ่งเป็นมาตรฐานทองคำในโลกของการ Monitoring ระบบ Server ในปัจจุบันครับ เราจะมาดูกันว่าสองเครื่องมือนี้ทำงานร่วมกันอย่างไร และจะช่วยให้คุณเฝ้าระวัง วิเคราะห์ และตอบสนองต่อปัญหาได้อย่างรวดเร็วและแม่นยำแค่ไหน เพื่อยกระดับการดูแลระบบของคุณให้เป็น “Pro” อย่างแท้จริงครับ

ไม่ว่าคุณจะเป็น System Administrator, DevOps Engineer หรือเจ้าของธุรกิจที่ต้องการเพิ่มความมั่นคงและประสิทธิภาพให้กับโครงสร้างพื้นฐานดิจิทัลของคุณ บทความนี้จะมอบความรู้และแนวทางปฏิบัติที่ครอบคลุม เพื่อให้คุณสามารถนำ Prometheus และ Grafana ไปปรับใช้กับระบบของคุณได้อย่างมั่นใจครับ

สารบัญ

• ทำไมการ Monitoring ระบบ Server จึงสำคัญระดับ Pro?
  • ความสำคัญของการมองเห็น (Visibility)
  • ลด Downtime, เพิ่ม Uptime
  • เพิ่มประสิทธิภาพการทำงาน
  • การวางแผนและการขยายระบบในอนาคต
• Prometheus คืออะไร? หัวใจของการรวบรวม Metric ระดับองค์กร
  • สถาปัตยกรรม (Architecture): Pull Model, Time-series Database
  • ส่วนประกอบสำคัญของ Prometheus
  • คุณสมบัติเด่นของ Prometheus
  • Code Example: ติดตั้งและตั้งค่า Node Exporter เบื้องต้น
  • Code Example: กำหนดค่า Prometheus สำหรับ Scrape Node Exporter
• Grafana คืออะไร? สร้าง Dashboard ให้ข้อมูลพูดได้
  • ทำไมต้อง Grafana?
  • ความสามารถหลักของ Grafana
  • การเชื่อมต่อ Grafana กับ Prometheus
  • การสร้าง Dashboard เบื้องต้นด้วย PromQL
  • Code Example: ตัวอย่าง PromQL Query สำหรับ Grafana
• การผสานพลัง Prometheus และ Grafana: Monitoring ระบบ Server แบบ Pro
  • ภาพรวมการทำงานร่วมกัน
  • ขั้นตอนการติดตั้งและตั้งค่า (ภาพรวม)
  • ตารางเปรียบเทียบ: Prometheus (Pull Model) กับ Traditional Monitoring (Push Model)
• Monitoring Component สำคัญที่ควรมี (Exporters & Use Cases)
  • CPU, Memory, Disk I/O (Node Exporter)
  • Network Traffic (Node Exporter)
  • Process Monitoring
  • Database Monitoring
  • Web Server Monitoring
  • Container Monitoring (cAdvisor, Kube-state-metrics)
• การแจ้งเตือน (Alerting) อย่างมีประสิทธิภาพด้วย Alertmanager
  • หลักการทำงานของ Alertmanager
  • การตั้งค่า Prometheus Rule
  • การตั้งค่า Alertmanager
  • ช่องทางการแจ้งเตือน
  • Code Example: ตัวอย่าง Prometheus Alert Rule
  • Code Example: ตัวอย่าง Alertmanager Configuration
• เทคนิคขั้นสูงสำหรับการ Monitoring ระดับ Pro
  • Service Discovery
  • Custom Exporters
  • Federation
  • Long-term Storage (Thanos, Cortex)
  • Prometheus Operator ใน Kubernetes
• คำถามที่พบบ่อย (FAQ)
• สรุปและ Call-to-action

ทำไมการ Monitoring ระบบ Server จึงสำคัญระดับ Pro?

ในยุคที่ความเร็วและการตอบสนองของระบบคือหัวใจของความได้เปรียบทางธุรกิจ การ Monitoring ไม่ใช่แค่ทางเลือก แต่เป็น สิ่งจำเป็น ครับ โดยเฉพาะอย่างยิ่งสำหรับระบบ Server ที่เป็นรากฐานของทุกแอปพลิเคชันและบริการ การ Monitoring ในระดับ “Pro” ไม่ได้หมายถึงแค่การเปิดดูว่า Server รันอยู่หรือไม่ แต่เป็นการเจาะลึกถึงทุกรายละเอียดเพื่อทำความเข้าใจพฤติกรรมของระบบ คาดการณ์ปัญหา และแก้ไขได้อย่างทันท่วงทีครับ

ความสำคัญของการมองเห็น (Visibility)

ลองนึกภาพการขับรถโดยไม่มีมาตรวัดความเร็วหรือมาตรวัดน้ำมันดูสิครับ คุณจะไม่รู้เลยว่ากำลังไปเร็วแค่ไหน หรือน้ำมันใกล้หมดหรือยัง การ Monitoring ระบบก็เช่นกันครับ มันมอบ Visibility หรือความสามารถในการมองเห็นและเข้าใจสถานะปัจจุบันและแนวโน้มของระบบทั้งหมด ไม่ว่าจะเป็นการใช้งาน CPU, Memory, Disk I/O, Network Traffic หรือแม้กระทั่งสถานะของแอปพลิเคชันที่รันอยู่ การมีข้อมูลเหล่านี้ช่วยให้คุณสามารถตอบคำถามสำคัญๆ ได้ เช่น:

• Server กำลังทำงานหนักเกินไปหรือไม่?
• มีกระบวนการใดที่ใช้ทรัพยากรมากผิดปกติหรือเปล่า?
• Disk Space เหลือเท่าไหร่ และจะเต็มเมื่อไหร่?
• Network Latency สูงขึ้นผิดปกติหรือไม่?

การมองเห็นที่สมบูรณ์แบบนี้คือจุดเริ่มต้นของการแก้ไขปัญหาอย่างชาญฉลาดครับ

ลด Downtime, เพิ่ม Uptime

Downtime คือฝันร้ายของทุกธุรกิจครับ ไม่ว่าจะเป็นเว็บไซต์ล่ม ระบบการเงินหยุดชะงัก หรือบริการลูกค้าเข้าถึงไม่ได้ ทุกนาทีที่ระบบหยุดทำงานหมายถึงการสูญเสียรายได้ ความน่าเชื่อถือ และโอกาสทางธุรกิจ การ Monitoring แบบ Pro ช่วยให้คุณสามารถ:

• ตรวจจับปัญหาได้ตั้งแต่เนิ่นๆ: ก่อนที่ปัญหาจะบานปลายจนระบบล่ม
• รับการแจ้งเตือนทันที: เมื่อเกิดความผิดปกติ คุณจะได้รับการแจ้งเตือนผ่านช่องทางต่างๆ เช่น Email, Slack, Line ทันทีที่ปัญหาเกิดขึ้น
• ระบุสาเหตุได้อย่างรวดเร็ว: ด้วยข้อมูล Metric ที่ละเอียด คุณสามารถวิเคราะห์และค้นหาสาเหตุของปัญหาได้อย่างแม่นยำ ช่วยลดเวลาในการแก้ไข (Mean Time To Resolution – MTTR)

การลด Downtime และเพิ่ม Uptime ไม่เพียงแต่ช่วยประหยัดค่าใช้จ่าย แต่ยังช่วยรักษาความพึงพอใจของลูกค้าและชื่อเสียงขององค์กรด้วยครับ

เพิ่มประสิทธิภาพการทำงาน

นอกจากการป้องกันปัญหาแล้ว การ Monitoring ยังเป็นเครื่องมือสำคัญในการเพิ่มประสิทธิภาพของระบบครับ การวิเคราะห์ข้อมูล Metric ในระยะยาวช่วยให้คุณสามารถ:

• ค้นหาจุดคอขวด (Bottlenecks): ระบุส่วนของระบบที่ทำงานได้ไม่เต็มประสิทธิภาพ เช่น CPU ที่โอเวอร์โหลด, Disk I/O ช้า, หรือ Query ฐานข้อมูลที่ไม่เหมาะสม
• ปรับแต่งทรัพยากร: ตัดสินใจได้อย่างชาญฉลาดว่าจะเพิ่มทรัพยากร (CPU, RAM) ส่วนไหน หรือลดส่วนไหนที่ไม่ได้ใช้งานเต็มที่ เพื่อประหยัดค่าใช้จ่าย
• ปรับปรุงโค้ดและสถาปัตยกรรม: ข้อมูล Metric สามารถชี้ให้เห็นถึงปัญหาในโค้ดแอปพลิเคชันหรือการออกแบบสถาปัตยกรรมที่ไม่เหมาะสม ซึ่งนำไปสู่การปรับปรุงและพัฒนาในอนาคตครับ

การวางแผนและการขยายระบบในอนาคต

เมื่อธุรกิจเติบโต ระบบ Server ก็ต้องขยายตามครับ การมีข้อมูล Metric ย้อนหลังช่วยให้คุณสามารถทำ Capacity Planning ได้อย่างแม่นยำ:

• คาดการณ์ความต้องการทรัพยากร: ดูแนวโน้มการใช้งาน CPU, Memory, Disk และ Network เพื่อประเมินว่าเมื่อไหร่ที่ต้องเพิ่มทรัพยากร หรืออัปเกรด Server
• วางแผนการลงทุน: ตัดสินใจลงทุนใน Hardware หรือ Cloud Resources ได้อย่างมีเหตุผล ไม่มากไป ไม่น้อยไป
• รับมือกับโหลดที่เพิ่มขึ้น: เตรียมพร้อมรับมือกับ Traffic ที่สูงขึ้นในช่วงเทศกาล, แคมเปญการตลาด, หรือการเปิดตัวผลิตภัณฑ์ใหม่ได้อย่างมั่นใจครับ

จะเห็นได้ว่าการ Monitoring ระบบ Server ระดับ Pro นั้นเป็นมากกว่าแค่การตรวจสอบ แต่เป็นการลงทุนที่คุ้มค่าเพื่อความมั่นคง ประสิทธิภาพ และการเติบโตของธุรกิจในระยะยาวครับ

Prometheus คืออะไร? หัวใจของการรวบรวม Metric ระดับองค์กร

Prometheus คือระบบ Monitoring และ Alerting แบบ Open Source ที่โด่งดังและเป็นที่ยอมรับอย่างกว้างขวางในอุตสาหกรรม โดยเฉพาะในโลกของ Cloud-Native และ Kubernetes ครับ มันถูกออกแบบมาเพื่อการรวบรวมข้อมูลแบบ Time-series Metrics ซึ่งหมายถึงข้อมูลตัวเลขที่ถูกประทับเวลา (timestamped) ไว้ เพื่อให้สามารถวิเคราะห์แนวโน้มและพฤติกรรมของระบบได้อย่างแม่นยำครับ

สถาปัตยกรรม (Architecture): Pull Model, Time-series Database

สิ่งที่ทำให้ Prometheus แตกต่างจากเครื่องมือ Monitoring แบบดั้งเดิมคือ “Pull Model” ครับ

• Pull Model: แทนที่จะรอให้ Agent บน Server ส่งข้อมูล (Push) มาให้ Prometheus แต่ Prometheus จะเป็นฝ่าย “ดึง” (Scrape) ข้อมูล Metric จาก Endpoint ที่กำหนดเองครับ Endpoint เหล่านี้มักจะเป็น HTTP Endpoint ที่เปิดเผยข้อมูล Metric ในรูปแบบที่ Prometheus เข้าใจได้
• Time-series Database (TSDB): Prometheus มีฐานข้อมูล Time-series ในตัว ที่ถูกออกแบบมาเพื่อเก็บข้อมูลตัวเลขที่มี timestamp พร้อมกับการบีบอัดข้อมูลที่มีประสิทธิภาพ ทำให้สามารถเก็บข้อมูลจำนวนมหาศาลได้อย่างมีประสิทธิภาพและ Query ได้อย่างรวดเร็วครับ

ส่วนประกอบสำคัญของ Prometheus

Prometheus ไม่ได้เป็นเพียงแค่ Server ตัวเดียว แต่เป็นชุดเครื่องมือที่ทำงานร่วมกันเพื่อสร้างระบบ Monitoring ที่สมบูรณ์แบบครับ

• Prometheus Server:
  • Scraper: ส่วนที่ทำหน้าที่ดึงข้อมูล Metric จาก Exporters หรือ Endpoint ต่างๆ
  • TSDB: ฐานข้อมูล Time-series สำหรับจัดเก็บข้อมูลที่ Scrape มาได้
  • HTTP Server: สำหรับให้ผู้ใช้ Query ข้อมูล (ผ่าน PromQL) และดูสถานะ
• Exporters:

  โปรแกรมขนาดเล็กที่รันอยู่บน Server หรือแอปพลิเคชันเป้าหมาย ทำหน้าที่รวบรวม Metric จากระบบภายในและเปิดเผยข้อมูลเหล่านั้นผ่าน HTTP Endpoint ในรูปแบบที่ Prometheus สามารถ Scrape ได้ครับ มี Exporter มากมายสำหรับระบบและแอปพลิเคชันต่างๆ เช่น:

  • Node Exporter: สำหรับดึง Metric จากระบบปฏิบัติการ Linux/Unix ทั่วไป (CPU, Memory, Disk, Network)
  • cAdvisor: สำหรับ Monitoring Container (Docker, Kubernetes)
  • MySQL Exporter, PostgreSQL Exporter: สำหรับฐานข้อมูล
  • Blackbox Exporter: สำหรับ Monitoring Endpoint ภายนอก (HTTP, Ping, TCP)
  • Custom Exporters: คุณสามารถเขียน Exporter ของตัวเองได้สำหรับแอปพลิเคชันเฉพาะทาง
• Pushgateway:

  สำหรับกรณีพิเศษที่ Target ไม่สามารถให้ Prometheus Scrape ได้โดยตรง เช่น Jobs ที่ทำงานระยะสั้น (Short-lived Jobs) หรือ Batch Jobs ที่รันแล้วจบไป Pushgateway จะทำหน้าที่เป็นตัวกลางให้ Jobs เหล่านั้น “Push” Metric มาเก็บไว้ แล้ว Prometheus จะไป Scrape จาก Pushgateway อีกทีครับ

• Alertmanager:

  ส่วนประกอบที่แยกออกมาจาก Prometheus Server ทำหน้าที่จัดการและส่งการแจ้งเตือน (Alerts) ที่ถูกสร้างขึ้นจาก Prometheus ครับ Alertmanager มีความสามารถในการ Grouping, Silencing และ Routing Alerts ไปยังช่องทางต่างๆ (Email, Slack, PagerDuty, Line) ได้อย่างยืดหยุ่น

• Service Discovery:

  Prometheus สามารถทำงานร่วมกับระบบ Service Discovery ต่างๆ เช่น Consul, Kubernetes, EC2 เพื่อค้นหา Target ที่จะ Scrape ได้โดยอัตโนมัติ ทำให้การจัดการระบบขนาดใหญ่เป็นไปได้ง่ายขึ้นครับ

คุณสมบัติเด่นของ Prometheus

• PromQL (Prometheus Query Language):

  ภาษา Query ที่ทรงพลังและยืดหยุ่น ออกแบบมาเพื่อทำงานกับ Time-series Data โดยเฉพาะ ทำให้คุณสามารถ Query, Filter, Aggregate และคำนวณ Metric ต่างๆ ได้อย่างซับซ้อน เช่น หาค่าเฉลี่ย, อัตราการเปลี่ยนแปลง, หรือเปรียบเทียบข้อมูลย้อนหลัง

• Scalability:

  Prometheus สามารถ Scaling ได้ในหลายรูปแบบ ไม่ว่าจะเป็นการรัน Server หลายตัวเพื่อ Scrape ระบบที่แตกต่างกัน หรือใช้ Federation สำหรับการรวบรวมข้อมูลจาก Prometheus Server หลายตัวเข้าด้วยกัน

• Open Source & Community:

  Prometheus เป็นโครงการ Open Source ที่มีการพัฒนาอย่างต่อเนื่องและมี Community ที่แข็งแกร่ง ทำให้มีเอกสาร, Exporters และเครื่องมือสนับสนุนมากมายครับ

Prometheus is a powerful monitoring system that collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.

การเข้าใจส่วนประกอบและการทำงานของ Prometheus คือก้าวแรกสู่การ Monitoring ระบบ Server แบบ Pro ที่มีประสิทธิภาพครับ

Code Example: ติดตั้งและตั้งค่า Node Exporter เบื้องต้น

Node Exporter เป็น Exporter พื้นฐานและสำคัญที่สุดสำหรับการ Monitoring ระบบปฏิบัติการ Linux/Unix ครับ

ขั้นตอนที่ 1: ดาวน์โหลด Node Exporter บน Server เป้าหมาย (เช่น Ubuntu Server)

# สร้าง Directory สำหรับ Exporter
sudo mkdir -p /etc/prometheus/exporters
sudo mkdir -p /var/lib/node_exporter

# ดาวน์โหลด Node Exporter (เลือกเวอร์ชันล่าสุดจาก https://prometheus.io/download/)
# ในที่นี้ใช้ตัวอย่างเวอร์ชัน 1.7.0
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz

# แตกไฟล์
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz

# ย้าย Binary ไปยัง Path ที่เหมาะสม
sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/

# ลบไฟล์ที่ดาวน์โหลดและ Directory ชั่วคราว
rm -rf node_exporter-1.7.0.linux-amd64.tar.gz node_exporter-1.7.0.linux-amd64

ขั้นตอนที่ 2: สร้าง Service File สำหรับ systemd เพื่อให้ Node Exporter รันอัตโนมัติ

sudo nano /etc/systemd/system/node_exporter.service

จากนั้นเพิ่มเนื้อหาดังนี้ลงไปครับ:

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=root
ExecStart=/usr/local/bin/node_exporter \
    --web.listen-address=":9100" \
    --collector.filesystem.mount-points-exclude="^/(sys|proc|dev|host|etc)($|/)" \
    --collector.filesystem.fs-types-exclude="^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|selinuxfs|sysfs|tmpfs)$"
Restart=always

[Install]
WantedBy=multi-user.target

อธิบาย:

• --web.listen-address=":9100": Node Exporter จะเปิดพอร์ต 9100 เพื่อให้ Prometheus มา Scrape
• --collector.filesystem.mount-points-exclude="..." และ --collector.filesystem.fs-types-exclude="...": เป็นการยกเว้น Filesystem บางประเภทและ Mount Point ที่ไม่จำเป็น เพื่อไม่ให้เก็บ Metric ที่ไม่เกี่ยวข้องและลดโหลดครับ

ขั้นตอนที่ 3: เปิดใช้งานและ Start Service

sudo systemctl daemon-reload
sudo systemctl enable node_exporter
sudo systemctl start node_exporter
sudo systemctl status node_exporter

คุณควรจะเห็นสถานะเป็น “active (running)” ครับ

ขั้นตอนที่ 4: ทดสอบการเข้าถึง Metric

ลองเปิดเบราว์เซอร์ไปที่ http://[IP_SERVER_เป้าหมาย]:9100/metrics คุณควรจะเห็น Metric จำนวนมากในรูปแบบ Text ครับ

Code Example: กำหนดค่า Prometheus สำหรับ Scrape Node Exporter

เมื่อ Node Exporter ทำงานอยู่บน Server เป้าหมายแล้ว ขั้นตอนต่อไปคือการบอกให้ Prometheus Server ของคุณไป Scrape ข้อมูลจาก Exporter นั้นครับ

สมมติว่าคุณมี Prometheus Server ติดตั้งอยู่แล้ว คุณจะต้องแก้ไขไฟล์ prometheus.yml ครับ

# global settings
global:
  scrape_interval:     15s # Scrape targets every 15 seconds.
  evaluation_interval: 15s # Evaluate rules every 15 seconds.

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

# A list of scrape configurations.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to all metrics scraped from this config.
  - job_name: 'prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
    - targets: ['localhost:9090'] # Prometheus Server ตัวเอง

  - job_name: 'node_exporter' # ตั้งชื่อ Job เพื่อระบุแหล่งที่มาของ Metric
    static_configs:
    - targets: ['<IP_ของ_SERVER_เป้าหมาย>:9100'] # IP ของ Server ที่รัน Node Exporter
      labels:
        instance: 'web-server-01' # กำหนด Label เพิ่มเติมเพื่อระบุ Server ได้ง่ายขึ้น
    - targets: ['<IP_ของ_SERVER_เป้าหมาย_2>:9100'] # หากมีหลาย Server ก็เพิ่มได้เลยครับ
      labels:
        instance: 'db-server-01'

อธิบาย:

• global.scrape_interval: กำหนดช่วงเวลาในการ Scrape Metric (ในที่นี้คือทุก 15 วินาที)
• job_name: 'node_exporter': เป็นการสร้าง “Job” สำหรับการ Scrape Node Exporter
• targets: ['<IP_ของ_SERVER_เป้าหมาย>:9100']: ระบุ IP Address และ Port ของ Server ที่รัน Node Exporter
• labels: instance: 'web-server-01': เป็นการเพิ่ม Label ที่กำหนดเองให้กับ Metric ที่ Scrape มาจาก Target นี้ ซึ่งมีประโยชน์มากในการ Query ข้อมูลในภายหลังครับ

หลังจากแก้ไขไฟล์ prometheus.yml แล้ว อย่าลืม Restart Prometheus Server เพื่อให้การตั้งค่าใหม่มีผลครับ

sudo systemctl restart prometheus
sudo systemctl status prometheus

เมื่อ Prometheus Server ทำงานแล้ว คุณสามารถเข้าไปที่หน้า UI ของ Prometheus (โดยปกติคือ http://localhost:9090/targets) เพื่อตรวจสอบว่า Node Exporter ของคุณปรากฏอยู่ในรายการ “Up” หรือไม่ครับ

อ่านเพิ่มเติมเกี่ยวกับการตั้งค่า Prometheus

Grafana คืออะไร? สร้าง Dashboard ให้ข้อมูลพูดได้

หาก Prometheus คือสมองที่รวบรวมข้อมูล Metric ทั้งหมด Grafana ก็คือ สายตาและเสียง ที่ทำให้ข้อมูลเหล่านั้นมีชีวิตชีวาและเข้าใจง่ายครับ Grafana เป็นแพลตฟอร์ม Open Source สำหรับการ Visualization และ Dashboarding ที่ได้รับความนิยมอย่างสูง สามารถเชื่อมต่อกับ Data Source ได้หลากหลาย รวมถึง Prometheus ด้วย

ทำไมต้อง Grafana?

Prometheus มี UI พื้นฐานที่สามารถ Query ข้อมูลด้วย PromQL ได้ แต่การแสดงผลยังจำกัดครับ Grafana เข้ามาเติมเต็มส่วนนี้ด้วย:

• Visualization ที่สวยงามและยืดหยุ่น: สร้างกราฟ, ตาราง, เกจ, แผนที่ความร้อน และอื่นๆ ได้อย่างหลากหลายและปรับแต่งได้เต็มที่
• รวมข้อมูลจากหลายแหล่ง: สามารถดึงข้อมูลจาก Prometheus, InfluxDB, Elasticsearch, SQL databases และอื่นๆ มาแสดงผลใน Dashboard เดียวกันได้
• Dashboard ที่ปรับแต่งได้: ออกแบบ Dashboard ให้เหมาะสมกับความต้องการเฉพาะของทีมหรือโปรเจกต์
• Alerting: สามารถตั้งค่าการแจ้งเตือนจาก Grafana ได้โดยตรง (หรือเชื่อมต่อกับ Alertmanager ของ Prometheus)
• Community & Templates: มี Dashboard Template ที่สร้างโดย Community จำนวนมากให้ดาวน์โหลดและใช้งานได้เลย

ความสามารถหลักของ Grafana

• Data Sources:

  หัวใจของ Grafana คือความสามารถในการเชื่อมต่อกับแหล่งข้อมูลหลากหลายประเภท คุณสามารถเพิ่ม Prometheus เป็น Data Source หนึ่งใน Grafana เพื่อดึงข้อมูล Metric มาแสดงผลครับ

• Dashboards & Panels:

  Dashboard คือหน้าจอที่คุณใช้ในการจัดเรียงและแสดงผลข้อมูลต่างๆ ในรูปแบบของ “Panels” ครับ แต่ละ Panel สามารถแสดงผล Metric เดียวหรือหลาย Metric ได้ในรูปแบบที่แตกต่างกัน:

  • Graph: แสดงแนวโน้มของ Metric ในช่วงเวลาหนึ่ง
  • Stat: แสดงค่าตัวเลขปัจจุบันหรือค่าสรุป
  • Gauge: แสดงค่าตัวเลขในรูปแบบเกจวัด
  • Table: แสดงข้อมูลในรูปแบบตาราง
  • Heatmap: แสดงการกระจายของข้อมูล
  • และอื่นๆ อีกมากมาย
• Alerting:

  Grafana มีระบบ Alerting ในตัวที่สามารถสร้างเงื่อนไขการแจ้งเตือนจากข้อมูล Metric ที่แสดงผลอยู่ได้ และสามารถส่งการแจ้งเตือนไปยังช่องทางต่างๆ เช่น Email, Slack, Microsoft Teams, Webhooks ครับ (สำหรับการผสาน Prometheus/Grafana แบบ Pro เรามักจะใช้ Prometheus Alertmanager เป็นหลัก และให้ Grafana เป็นแค่ตัวแสดงผลสถานะ Alert ครับ)

• Templating, Variables:

  Grafana มีความสามารถในการสร้าง Template และใช้ Variables เพื่อทำให้ Dashboard ของคุณมีความยืดหยุ่นและนำกลับมาใช้ใหม่ได้ง่ายขึ้นครับ เช่น การสร้าง Dropdown list เพื่อเลือก Server หรือ Environment ที่ต้องการดูข้อมูล ทำให้ไม่ต้องสร้าง Dashboard แยกสำหรับแต่ละ Server

• Plugins:

  Grafana มีระบบ Plugin ที่ช่วยเพิ่มความสามารถในการเชื่อมต่อ Data Source ใหม่ๆ หรือเพิ่มประเภทของ Panel ที่ใช้แสดงผลครับ

การเชื่อมต่อ Grafana กับ Prometheus

การเชื่อมต่อ Grafana กับ Prometheus นั้นตรงไปตรงมาครับ

1. ติดตั้ง Grafana (ดูเอกสารอย่างเป็นทางการสำหรับแพลตฟอร์มของคุณ)
2. เข้าสู่ระบบ Grafana UI (โดยปกติคือ http://localhost:3000)
3. ไปที่เมนู “Configuration” > “Data Sources”
4. คลิก “Add data source” และเลือก “Prometheus”
5. ตั้งค่า URL ของ Prometheus Server (เช่น http://localhost:9090 หาก Grafana และ Prometheus อยู่บน Server เดียวกัน)
6. คลิก “Save & Test” คุณควรจะเห็นข้อความ “Data source is working” ครับ

การสร้าง Dashboard เบื้องต้นด้วย PromQL

เมื่อเชื่อมต่อ Data Source แล้ว คุณก็พร้อมที่จะสร้าง Dashboard แรกของคุณครับ

1. ไปที่เมนู “Dashboards” > “New dashboard”
2. คลิก “Add new panel”
3. ในหน้า Panel Editor ให้เลือก Prometheus เป็น Data Source
4. ในช่อง “Query” ให้ใส่ PromQL Query ที่ต้องการ (ดูตัวอย่างด้านล่าง)
5. เลือกประเภทของ Visualization (เช่น “Graph”)
6. ปรับแต่งชื่อ Panel, แกน X/Y, สีสัน และอื่นๆ
7. คลิก “Apply” และ “Save dashboard” ครับ

การสร้าง Dashboard ที่ดีคือศิลปะที่ต้องอาศัยทั้งความเข้าใจในข้อมูลและความสามารถในการนำเสนอครับ Grafana มอบเครื่องมือที่ทรงพลังให้คุณสร้างสรรค์ Dashboard ที่ตอบโจทย์การ Monitoring ของคุณได้อย่างแท้จริง

Code Example: ตัวอย่าง PromQL Query สำหรับ Grafana

นี่คือตัวอย่าง PromQL Query ที่คุณสามารถใช้ใน Grafana เพื่อแสดง Metric ต่างๆ ที่ได้จาก Node Exporter ครับ

1. การใช้งาน CPU (เปอร์เซ็นต์รวม)

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

อธิบาย: คำนวณเปอร์เซ็นต์การใช้งาน CPU โดยรวม โดยหักลบจากโหมด “idle” ในช่วง 5 นาทีที่ผ่านมา

2. การใช้งาน Memory (เป็น GB)

(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / (1024 * 1024 * 1024)

อธิบาย: คำนวณ Memory ที่ใช้งานจริง (Total – Available) และแปลงเป็น GB

3. Disk Space ที่ใช้งาน (เป็นเปอร์เซ็นต์)

100 - (node_filesystem_avail_bytes{fstype!="rootfs", mountpoint!="/boot"} / node_filesystem_size_bytes{fstype!="rootfs", mountpoint!="/boot"} * 100)

อธิบาย: คำนวณเปอร์เซ็นต์ Disk Space ที่ใช้งาน โดยยกเว้น rootfs และ /boot เพื่อให้ได้ข้อมูลที่เกี่ยวข้องกับการใช้งานจริงครับ

4. Network Receive Rate (bytes/sec)

rate(node_network_receive_bytes_total{device!="lo"}[5m])

อธิบาย: คำนวณอัตราการรับข้อมูลผ่าน Network Interface (ไม่รวม localhost) ในช่วง 5 นาที

5. จำนวน Process ที่รันอยู่

node_processes_running

ในการใช้งานจริง คุณอาจจะต้องการใช้ instance label เพื่อ Filter ข้อมูลสำหรับ Server เฉพาะเจาะจง เช่น node_cpu_seconds_total{mode="idle", instance="web-server-01"} ครับ

อ่านเพิ่มเติมเกี่ยวกับ PromQL ที่น่าสนใจ

การผสานพลัง Prometheus และ Grafana: Monitoring ระบบ Server แบบ Pro

การนำ Prometheus และ Grafana มารวมกันคือการสร้างชุดเครื่องมือ Monitoring ที่สมบูรณ์แบบและทรงพลังครับ Prometheus ทำหน้าที่เป็น Data Collector และ Data Storage ที่มีประสิทธิภาพ ในขณะที่ Grafana แปลงข้อมูลดิบเหล่านั้นให้เป็นภาพที่เข้าใจง่ายและนำไปใช้ประโยชน์ได้

ภาพรวมการทำงานร่วมกัน

ลองนึกภาพกระบวนการทำงานแบบง่ายๆ ดังนี้ครับ:

1. Exporters (บน Server เป้าหมาย): รวบรวม Metric จาก Server, แอปพลิเคชัน, หรือ Database และเปิดเผยผ่าน HTTP Endpoint (เช่น Node Exporter ที่ Port 9100)
2. Prometheus Server: ทำหน้าที่ “Scrape” หรือดึงข้อมูล Metric จาก Exporters เหล่านั้นตามช่วงเวลาที่กำหนด จัดเก็บลงใน Time-series Database ของตัวเอง และประมวลผล Alert Rule
3. Grafana Server: เชื่อมต่อกับ Prometheus Server ในฐานะ Data Source
4. ผู้ใช้งาน (ผ่าน Grafana UI): สร้าง Dashboard โดยใช้ PromQL เพื่อ Query ข้อมูลจาก Prometheus และแสดงผลในรูปแบบกราฟ, ตาราง หรืออื่นๆ ที่สวยงามและเข้าใจง่าย
5. Alertmanager (หากมีการแจ้งเตือน): หาก Prometheus ตรวจพบเงื่อนไขการแจ้งเตือน Alertmanager จะทำหน้าที่ Grouping, Deduplicating และส่งการแจ้งเตือนไปยังช่องทางที่กำหนดครับ

การทำงานร่วมกันนี้สร้างวงจรการ Monitoring ที่ครอบคลุมตั้งแต่การเก็บข้อมูล การจัดเก็บ การวิเคราะห์ การแสดงผล ไปจนถึงการแจ้งเตือน ทำให้คุณมี “Single Pane of Glass” ในการมองเห็นสถานะของระบบทั้งหมดครับ

ขั้นตอนการติดตั้งและตั้งค่า (ภาพรวม)

เพื่อให้เห็นภาพรวมของการเริ่มต้นใช้งาน Prometheus และ Grafana ผมจะสรุปขั้นตอนหลักๆ ให้ฟังนะครับ

1. วางแผนโครงสร้างพื้นฐาน:
   • ตัดสินใจว่าจะรัน Prometheus และ Grafana บน Server แยกต่างหาก หรือบน Server เดียวกัน (สำหรับระบบขนาดเล็ก)
   • ระบุ Server เป้าหมายที่ต้องการ Monitoring
2. ติดตั้ง Prometheus Server:
   • ดาวน์โหลดและติดตั้ง Prometheus Binary บน Server ที่เลือก
   • กำหนดค่า prometheus.yml เพื่อระบุ Exporters ที่ต้องการ Scrape
   • รัน Prometheus Server และตรวจสอบว่าสามารถเข้าถึง UI ได้
3. ติดตั้ง Exporter บน Server เป้าหมาย:
   • บน Server ที่ต้องการ Monitoring ให้ติดตั้ง Exporter ที่เหมาะสม (เช่น Node Exporter)
   • กำหนดค่า Exporter ให้รันเป็น Service และเปิด Port ที่จำเป็น
   • ตรวจสอบว่า Prometheus Server สามารถ Scrape Metric จาก Exporter ได้
4. ติดตั้ง Grafana Server:
   • ดาวน์โหลดและติดตั้ง Grafana บน Server ที่เลือก
   • รัน Grafana Server และตรวจสอบว่าสามารถเข้าถึง UI ได้
5. เชื่อมต่อ Grafana กับ Prometheus:
   • ใน Grafana UI เพิ่ม Prometheus เป็น Data Source โดยระบุ URL ของ Prometheus Server
   • ทดสอบการเชื่อมต่อ
6. สร้าง Dashboard ใน Grafana:
   • เริ่มสร้าง Dashboard ใหม่ใน Grafana
   • เพิ่ม Panel และใช้ PromQL Query เพื่อดึง Metric จาก Prometheus มาแสดงผล
   • ปรับแต่ง Dashboard ให้สวยงามและมีประโยชน์
   • อาจลองดาวน์โหลด Dashboard Template ที่มีอยู่แล้วจาก Grafana Labs (เช่น “Node Exporter Full”) มาปรับใช้เป็นจุดเริ่มต้นครับ
7. ตั้งค่า Alerting ด้วย Alertmanager (ตัวเลือกเสริมแต่แนะนำ):
   • ติดตั้ง Alertmanager บน Server ที่แยกต่างหาก (แนะนำ)
   • กำหนดค่า alertmanager.yml เพื่อระบุ Receivers และ Routing rules
   • กำหนดค่า Alert Rule ใน prometheus.yml เพื่อให้ Prometheus สร้าง Alerts เมื่อเงื่อนไขเป็นจริง
   • เชื่อมต่อ Alertmanager กับ Prometheus Server

กระบวนการเหล่านี้อาจดูซับซ้อนในตอนแรก แต่เมื่อคุณเข้าใจหลักการทำงานและได้ลองทำจริงแล้ว จะพบว่ามันมีเหตุผลและยืดหยุ่นมากครับ

ตารางเปรียบเทียบ: Prometheus (Pull Model) กับ Traditional Monitoring (Push Model)

เพื่อเน้นย้ำถึงความได้เปรียบของ Prometheus ในบริบทของการ Monitoring สมัยใหม่ เรามาดูตารางเปรียบเทียบกับระบบ Monitoring แบบดั้งเดิมที่ใช้ “Push Model” กันครับ

จากตารางจะเห็นได้ว่า Prometheus มีข้อได้เปรียบที่สำคัญหลายประการ โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่ทันสมัยและมีการเปลี่ยนแปลงบ่อย ทำให้เป็นตัวเลือกที่ดีเยี่ยมสำหรับการ Monitoring ระบบ Server ในระดับมืออาชีพครับ

Monitoring Component สำคัญที่ควรมี (Exporters & Use Cases)

การ Monitoring ระบบ Server แบบ Pro ไม่ได้จำกัดอยู่แค่การดู CPU หรือ Memory เท่านั้นครับ แต่ยังรวมถึงการเจาะลึกไปในส่วนประกอบต่างๆ ของระบบ เพื่อให้ได้ภาพรวมที่สมบูรณ์และสามารถแก้ไขปัญหาได้อย่างตรงจุด Exporters คือพระเอกในส่วนนี้ครับ พวกมันทำหน้าที่เป็น “ตัวกลาง” ในการดึง Metric จากแหล่งต่างๆ มาให้ Prometheus

CPU, Memory, Disk I/O (Node Exporter)

นี่คือ Metric พื้นฐานที่สุดและสำคัญที่สุดสำหรับการ Monitoring Server ใดๆ ครับ Node Exporter คือเครื่องมือมาตรฐานที่ใช้ในการดึงข้อมูลเหล่านี้

• CPU Usage:

  คุณต้องการทราบว่า CPU ทำงานหนักแค่ไหน และในโหมดใด (user, system, idle, iowait) CPU ที่สูงผิดปกติอาจบ่งชี้ถึงปัญหาในแอปพลิเคชันหรือ Process ที่ทำงานหนักเกินไป PromQL: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

• Memory Usage:

  การใช้งาน RAM ทั้งหมด, RAM ที่ว่าง, Buffer, Cache และ Swap Memory การใช้ Memory สูงอาจทำให้ระบบช้าลงและส่งผลให้เกิดการใช้ Swap Disk ซึ่งช้ากว่ามาก PromQL: node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

• Disk I/O:

  อัตราการอ่าน/เขียนข้อมูลบน Disk (Read/Write Bytes per second) และ Latency ของ Disk I/O Disk I/O ที่สูงหรือ Latency ที่ไม่ดีอาจบ่งชี้ถึงปัญหาด้านประสิทธิภาพของ Storage หรือ Database PromQL: rate(node_disk_read_bytes_total[5m]), rate(node_disk_write_bytes_total[5m])

• Disk Space:

  ปริมาณพื้นที่ว่างและพื้นที่ที่ใช้ไปบน Disk การที่ Disk เต็มเป็นสาเหตุอันดับต้นๆ ของระบบล่ม PromQL: node_filesystem_avail_bytes / node_filesystem_size_bytes * 100 (เปอร์เซ็นต์ที่เหลือ)

Network Traffic (Node Exporter)

Node Exporter ยังให้ Metric เกี่ยวกับ Network Traffic ด้วยครับ

• Network Bandwidth:

  อัตราการรับ/ส่งข้อมูลผ่าน Network Interface (bytes per second) ช่วยให้คุณทราบว่ามี Traffic เข้า-ออกระบบมากน้อยเพียงใด PromQL: rate(node_network_receive_bytes_total[5m]), rate(node_network_transmit_bytes_total[5m])

• Network Errors/Drops:

  จำนวน Packet ที่มีข้อผิดพลาดหรือถูก Drop สิ่งนี้บ่งชี้ถึงปัญหาใน Network Interface หรือสภาพ Network ที่ไม่ดี PromQL: rate(node_network_receive_errs_total[5m])

Process Monitoring

การ Monitoring แต่ละ Process หรือ Service ที่สำคัญบน Server ก็มีความจำเป็นครับ

• Process State:

  จำนวน Process ที่รันอยู่, Zombie Processes หรือ Process ที่ใช้ทรัพยากรผิดปกติ (CPU, Memory) Node Exporter มี Metric พื้นฐาน (node_processes_running) แต่สำหรับ Metric ที่ละเอียดขึ้น คุณอาจต้องใช้ Exporter เฉพาะทาง หรือ Custom Exporter ครับ

• Service Status:

  ตรวจสอบว่า Service สำคัญๆ เช่น Web Server (Nginx, Apache), Database (MySQL, PostgreSQL) ยังคงรันอยู่หรือไม่ และตอบสนองต่อ Request ได้ดีแค่ไหน สามารถใช้ Blackbox Exporter เพื่อตรวจสอบสถานะของ HTTP Endpoint หรือ TCP Port ได้ครับ

Database Monitoring

Database คือหัวใจของแอปพลิเคชันส่วนใหญ่ การ Monitoring Database จึงมีความสำคัญอย่างยิ่ง

• MySQL Exporter / PostgreSQL Exporter:

  Exporters เหล่านี้จะดึง Metric เฉพาะของ Database มาให้ เช่น:

  • จำนวนการเชื่อมต่อ (Connections)
  • จำนวน Query ต่อวินาที (QPS)
  • Latency ของ Query
  • สถานะ Replication
  • การใช้ Cache

  Metric เหล่านี้ช่วยให้คุณระบุ Query ที่ช้า, ปัญหา Replication, หรือการใช้ทรัพยากร Database ที่ผิดปกติได้ครับ

Web Server Monitoring

สำหรับ Server ที่ทำหน้าที่เป็น Web Server (Nginx, Apache)

• Nginx Exporter / Apache Exporter:

  ดึง Metric เช่น:

  • จำนวน Request ต่อวินาที
  • จำนวน Connection ที่ Active
  • อัตรา Error (4xx, 5xx)
  • Bandwidth ที่ใช้

  ช่วยให้คุณเข้าใจโหลดของ Web Server และตรวจจับปัญหาที่อาจส่งผลกระทบต่อผู้ใช้งานได้ครับ

Container Monitoring (cAdvisor, Kube-state-metrics)

ในยุคของ Containerization (Docker, Kubernetes) การ Monitoring ต้องลงลึกไปถึงระดับ Container ด้วยครับ

• cAdvisor:

  เป็นเครื่องมือของ Google ที่รวบรวม Metric การใช้ทรัพยากรของ Container (CPU, Memory, Network, Disk) และเปิดเผยให้ Prometheus Scrape ได้ มักจะถูกรวมอยู่ใน Kubelet บน Kubernetes Node ครับ

• Kube-state-metrics:

  เป็น Exporter ที่รวบรวม Metric เกี่ยวกับสถานะของ Objects ใน Kubernetes API (เช่น จำนวน Pods, Deployments, ReplicaSets) ไม่ใช่ Metric ทรัพยากร แต่เป็น Metric ที่บอกสถานะของ Kubernetes Cluster ครับ

การเลือก Exporter ที่เหมาะสมและการกำหนดค่าที่ถูกต้องคือกุญแจสำคัญในการสร้างระบบ Monitoring ที่ครอบคลุมและมีประสิทธิภาพสูงสุดครับ

การแจ้งเตือน (Alerting) อย่างมีประสิทธิภาพด้วย Alertmanager

การมี Dashboard ที่สวยงามนั้นดีครับ แต่การที่คุณต้องเฝ้ามองตลอดเวลานั้นไม่ยั่งยืน ระบบ Monitoring ที่ดีต้องสามารถ แจ้งเตือน (Alert) คุณได้เมื่อมีสิ่งผิดปกติเกิดขึ้น Alertmanager คือส่วนประกอบของ Prometheus Ecosystem ที่ถูกออกแบบมาเพื่อจัดการเรื่องนี้โดยเฉพาะครับ

หลักการทำงานของ Alertmanager

Alertmanager ทำหน้าที่เป็นศูนย์กลางในการรับ Alerts จาก Prometheus Server และจัดการพวกมันอย่างชาญฉลาดก่อนที่จะส่งไปยังผู้รับที่เหมาะสมครับ

• Grouping: รวม Alerts ที่คล้ายกันเข้าด้วยกัน เพื่อลดจำนวนการแจ้งเตือนที่อาจท่วมท้น (เช่น ถ้า Server หลายตัวล่มพร้อมกัน Alertmanager จะรวมเป็น Alert เดียว)
• Inhibition: ระงับการแจ้งเตือนบางอย่างหากมี Alert ที่สำคัญกว่าเกิดขึ้นแล้ว (เช่น ถ้า Cluster ล่ม คุณอาจไม่ต้องการ Alert แยกสำหรับทุก Pod ที่ล่ม)
• Silencing: การปิดเสียง Alerts ชั่วคราวในช่วงเวลาที่กำหนด (เช่น ในช่วง Maintenance)
• Routing: ส่ง Alerts ไปยังผู้รับหรือช่องทางที่แตกต่างกัน ขึ้นอยู่กับ Label ของ Alert นั้นๆ (เช่น Alerts ที่เกี่ยวกับ Database ไปหาทีม DBA, Alerts เกี่ยวกับ Web Server ไปหาทีม Web Dev)

การตั้งค่า Prometheus Rule

ก่อนที่ Alertmanager จะทำงานได้ Prometheus จะต้องสร้าง Alert ขึ้นมาก่อนครับ ซึ่งทำได้โดยการกำหนด Alert Rule ในไฟล์ prometheus.yml หรือในไฟล์ Rule แยกต่างหาก (แนะนำ) ครับ

Alert Rule จะประกอบด้วย:

• ALERT: ชื่อของ Alert
• EXPR: PromQL Query ที่กำหนดเงื่อนไขการเกิด Alert
• FOR: ระยะเวลาที่เงื่อนไขต้องเป็นจริงก่อนที่จะส่ง Alert (เพื่อหลีกเลี่ยงการแจ้งเตือนชั่วคราว)
• LABELS: Label เพิ่มเติมสำหรับ Alert (ใช้ในการ Routing)
• ANNOTATIONS: รายละเอียดเพิ่มเติมเกี่ยวกับ Alert (เช่น คำอธิบาย, Runbook URL)

การตั้งค่า Alertmanager

Alertmanager มีไฟล์ alertmanager.yml สำหรับการกำหนดค่า โดยมีส่วนประกอบหลักดังนี้ครับ

• Receivers: กำหนดปลายทางของการแจ้งเตือน เช่น Email, Slack, Webhook, PagerDuty
• Routes: กำหนดเงื่อนไข (ตาม Label) ว่า Alert ใดจะถูกส่งไปยัง Receiver ใด และมีพฤติกรรมการ Grouping, Inhibition อย่างไร
• Global: การตั้งค่าทั่วไป เช่น SMTP Server สำหรับ Email

ช่องทางการแจ้งเตือน

Alertmanager รองรับช่องทางการแจ้งเตือนที่หลากหลาย ทำให้คุณสามารถเลือกช่องทางที่เหมาะสมกับทีมของคุณได้ครับ

• Email: พื้นฐานและใช้งานได้ทั่วไป
• Slack: ยอดนิยมสำหรับทีม DevOps/SRE
• Microsoft Teams: อีกทางเลือกสำหรับทีมที่ใช้ Microsoft Ecosystem
• Line Notify (ผ่าน Webhook): เป็นที่นิยมมากในประเทศไทย
• PagerDuty, Opsgenie: สำหรับการจัดการ Incident ที่จริงจังและ On-call rotation
• Webhook: สามารถส่งไปยัง Endpoint ที่กำหนดเองเพื่อเชื่อมต่อกับระบบอื่นๆ ได้

Code Example: ตัวอย่าง Prometheus Alert Rule

คุณสามารถสร้างไฟล์ rules.yml (หรือชื่ออื่น) และนำเข้าใน prometheus.yml ครับ

ไฟล์: alert_rules.yml

groups:
- name: node_alerts
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "CPU Usage High on {{ $labels.instance }}"
      description: "{{ $labels.instance }} CPU usage is currently at {{ $value }}% for 5 minutes. Consider investigating running processes."

  - alert: LowDiskSpace
    expr: (node_filesystem_avail_bytes{fstype!="rootfs", mountpoint!="/boot"} / node_filesystem_size_bytes{fstype!="rootfs", mountpoint!="/boot"} * 100) < 15
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Low Disk Space on {{ $labels.instance }} ({{ $labels.mountpoint }})"
      description: "{{ $labels.instance }} {{ $labels.mountpoint }} has less than 15% disk space remaining. Current usage: {{ printf "%.2f" (100 - ($value)) }}%."

  - alert: HighMemoryUsage
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
    for: 5m
    labels:
      severity: critical
    annotations:
        summary: "High Memory Usage on {{ $labels.instance }}"
        description: "{{ $labels.instance }} memory usage is currently at {{ printf "%.2f" $value }}% for 5 minutes. Possible memory leak or heavy load."

จากนั้นใน prometheus.yml ให้เพิ่มบรรทัดนี้เพื่อโหลด Rule ครับ:

# ในส่วน global:
rule_files:
  - "alert_rules.yml" # หรือ Path เต็มของไฟล์

อย่าลืม Restart Prometheus Server หลังแก้ไขไฟล์ prometheus.yml ครับ

Code Example: ตัวอย่าง Alertmanager Configuration

ไฟล์: alertmanager.yml

global:
  resolve_timeout: 5m # กำหนดว่า Alert จะถูกแก้ไขภายใน 5 นาที หากไม่มีการแจ้งซ้ำ

route:
  group_by: ['alertname', 'instance', 'severity'] # Group alerts based on these labels
  group_wait: 30s # รอ 30 วินาทีเพื่อรวบรวม Alerts ก่อนส่ง
  group_interval: 5m # หากมี Alerts ใหม่ในกลุ่มเดิม จะรอ 5 นาทีเพื่อส่งอีกครั้ง
  repeat_interval: 1h # ส่งซ้ำทุก 1 ชั่วโมงหาก Alert ยังคงค้างอยู่
  receiver: 'default-receiver' # กำหนด Receiver เริ่มต้น

  routes:
  - match:
      severity: 'critical' # ถ้า Alert มี Label severity เป็น critical
    receiver: 'critical-alerts' # ส่งไปหา critical-alerts receiver
    group_wait: 10s
    repeat_interval: 30m

  - match:
      severity: 'warning' # ถ้า Alert มี Label severity เป็น warning
    receiver: 'warning-alerts' # ส่งไปหา warning-alerts receiver

receivers:
- name: 'default-receiver'
  webhook_configs:
  - url: 'http://localhost:9001/webhook' # ตัวอย่าง Webhook สำหรับรับ Alerts ทั่วไป

- name: 'critical-alerts'
  email_configs:
  - to: '[email protected]'
    send_resolved: true # ส่ง Email เมื่อ Alert ถูกแก้ไขแล้ว
    html: true
  slack_configs:
  - channel: '#critical-alerts'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    send_resolved: true
    title: '[FIRING] {{ .CommonLabels.alertname }} on {{ .CommonLabels.instance }}'
    text: 'Severity: {{ .CommonLabels.severity }} Summary: {{ .CommonAnnotations.summary }} Description: {{ .CommonAnnotations.description }}'

- name: 'warning-alerts'
  slack_configs:
  - channel: '#warning-alerts'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    send_resolved: true
    title: '[WARNING] {{ .CommonLabels.alertname }} on {{ .CommonLabels.instance }}'
    text: 'Severity: {{ .CommonLabels.severity }} Summary: {{ .CommonAnnotations.summary }} Description: {{ .CommonAnnotations.description }}'

อธิบาย:

• route: คือ Root ของ Routing Tree ครับ
• group_by: กำหนดว่า Alertmanager จะรวม Alerts ที่มี Label เหล่านี้เหมือนกันเข้าด้วยกัน
• routes: คุณสามารถกำหนด Sub-routes เพื่อจัดการ Alerts ที่มี Label แตกต่างกันได้ เช่น Alerts ที่มี severity: 'critical' จะถูกส่งไปที่ critical-alerts receiver
• receivers: ส่วนนี้กำหนดรายละเอียดของแต่ละปลายทาง เช่น Email Address, Slack Webhook URL

เมื่อแก้ไขไฟล์ alertmanager.yml แล้ว ให้ Restart Alertmanager Service ครับ

sudo systemctl restart alertmanager
sudo systemctl status alertmanager

การตั้งค่า Alerting ที่ดีจะช่วยให้ทีมของคุณตอบสนองต่อปัญหาได้อย่างรวดเร็วและมีประสิทธิภาพ ลดผลกระทบต่อธุรกิจได้อย่างมหาศาลครับ

อ่านเพิ่มเติมเกี่ยวกับการตั้งค่า Alertmanager

เทคนิคขั้นสูงสำหรับการ Monitoring ระดับ Pro

เมื่อคุณคุ้นเคยกับการใช้งาน Prometheus และ Grafana ในระดับพื้นฐานแล้ว ก็ถึงเวลาสำรวจเทคนิคขั้นสูงที่จะช่วยยกระดับการ Monitoring ระบบของคุณให้เป็นระดับ “Pro” อย่างแท้จริงครับ

Service Discovery

ในสภาพแวดล้อมสมัยใหม่ เช่น Microservices หรือ Kubernetes ที่ Server หรือ Service เกิดขึ้นและหายไปตลอดเวลา การกำหนด Target ให้ Prometheus Scrape ด้วยมือเป็นเรื่องที่ไม่สามารถทำได้ครับ Service Discovery เข้ามาช่วยแก้ปัญหานี้

Prometheus สามารถทำงานร่วมกับ Service Discovery Mechanism ต่างๆ ได้ เช่น:

• Kubernetes Service Discovery: Prometheus สามารถค้นหา Pods, Services, Endpoints, Nodes ใน Kubernetes Cluster ได้โดยอัตโนมัติ ทำให้การ Monitoring Kubernetes เป็นเรื่องง่าย
• Consul Service Discovery: สำหรับระบบที่ใช้ HashiCorp Consul เป็น Service Registry
• EC2 Service Discovery: สำหรับการค้นหา EC2 Instances ใน AWS
• File-based Service Discovery: กำหนด Target ในไฟล์ JSON หรือ YAML ที่ Prometheus จะคอยตรวจสอบการเปลี่ยนแปลง

การใช้ Service Discovery ช่วยลดภาระการดูแล Manual Config และทำให้ระบบ Monitoring ของคุณมีความยืดหยุ่นสูงครับ

Custom Exporters

แม้ว่าจะมี Exporter สำเร็จรูปมากมาย แต่บางครั้งคุณอาจมีแอปพลิเคชันหรือระบบเฉพาะทางที่ไม่มี Exporter ให้ใช้งาน การสร้าง Custom Exporter ของตัวเองจึงเป็นสิ่งสำคัญครับ

Custom Exporter คือโปรแกรมเล็กๆ ที่เขียนขึ้นมาเพื่อดึง Metric จากแอปพลิเคชันของคุณ และเปิดเผย Metric เหล่านั้นผ่าน HTTP Endpoint ในรูปแบบที่ Prometheus เข้าใจ (Text-based format) คุณสามารถเขียน Custom Exporter ได้ด้วยภาษาโปรแกรมใดก็ได้ เช่น Go, Python, Node.js โดยใช้ Prometheus Client Library ที่มีให้ครับ

ตัวอย่างการใช้งาน:

• ดึงจำนวนผู้ใช้งานที่ Active จาก Database
• สถานะของ Batch Job ที่รันอยู่
• Metric ธุรกิจเฉพาะทาง เช่น จำนวนออเดอร์ที่สำเร็จ

Federation

สำหรับองค์กรขนาดใหญ่ที่มี Prometheus Server หลายตัวกระจายอยู่ตาม Datacenter หรือ Environment ต่างๆ การใช้ Federation ช่วยให้คุณสามารถรวบรวม Metric จาก Prometheus Server ย่อยๆ เหล่านั้นมาไว้ที่ Prometheus Server กลาง (Global Prometheus) ได้ครับ

ประโยชน์ของ Federation:

• Global View: มีมุมมองภาพรวมของ Metric ทั้งหมดในที่เดียว
• ลดโหลด: Prometheus Server ย่อยยังคงทำงานแบบ Local ไม่ต้องส่ง Metric ทั้งหมดไปที่ Server กลาง
• การทำ Centralized Alerting: สามารถตั้ง Alert Rule บน Global Prometheus สำหรับ Metric จากหลายแหล่ง

Long-term Storage (Thanos, Cortex)

Prometheus ถูกออกแบบมาให้เก็บข้อมูลแบบ Local และมีข้อจำกัดเรื่องระยะเวลาการเก็บข้อมูล (Retention) และ Scalability สำหรับระบบที่ต้องการเก็บข้อมูล Metric ระยะยาว (Long-term Storage) หรือต้องการ High Availability และ Global View ของ Metric มีเครื่องมือที่เข้ามาช่วยเติมเต็มส่วนนี้ครับ

• Thanos:

  เป็นชุดคอมโพเนนต์ที่ทำงานร่วมกับ Prometheus ช่วยให้สามารถเก็บข้อมูลระยะยาวใน Object Storage (เช่น S3, GCS), สร้าง Global Query View, และเพิ่ม High Availability ให้กับ Prometheus ได้ครับ

• Cortex:

  เป็นโปรเจกต์ที่มุ่งเน้นการสร้าง Multi-tenant, Highly Available, Long-term Storage สำหรับ Prometheus Metrics โดยใช้ Object Storage เป็น Backend เหมาะสำหรับผู้ให้บริการ SaaS หรือองค์กรขนาดใหญ่

Prometheus Operator ใน Kubernetes

สำหรับผู้ที่ใช้งาน Kubernetes Prometheus Operator เป็นเครื่องมือที่ขาดไม่ได้ครับ มันคือ Kubernetes Operator ที่ช่วยในการ Deploy, Config และจัดการ Prometheus และ Alertmanager ใน Kubernetes Cluster ได้อย่างอัตโนมัติและง่ายดาย

ความสามารถหลัก:

• Automated Deployment: Deploy Prometheus Server, Alertmanager, และ Exporters ได้อย่างง่ายดาย
• ServiceMonitor/PodMonitor: ใช้ Custom Resources (CRDs) เพื่อกำหนด Target ที่ Prometheus จะ Scrape ได้อย่างสะดวกสบายและ Dynamic
• PrometheusRule CRD: จัดการ Alert Rule ในรูปแบบของ Kubernetes Objects

การใช้ Prometheus Operator ทำให้การ Monitoring Kubernetes Cluster เป็นเรื่องที่ง่ายขึ้นและเป็นไปตามหลักปฏิบัติของ Cloud-Native อย่างแท้จริงครับ

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

คำถามที่พบบ่อย (FAQ)

Prometheus เหมาะกับระบบเล็กๆ ไหมครับ?

ตอบ: เหมาะสมอย่างยิ่งครับ! แม้ว่า Prometheus และ Grafana จะเป็นเครื่องมือระดับ Enterprise แต่ก็สามารถนำมาใช้กับระบบขนาดเล็กได้โดยมี Overhead ไม่มากนักครับ สำหรับ Server เพียงเครื่องเดียว การติดตั้ง Node Exporter, Prometheus และ Grafana บน Server เดียวกันก็เป็นเรื่องที่ทำได้ง่ายและให้ประโยชน์มหาศาลในการมองเห็นสถานะของ Server นั้นๆ ครับ

Prometheus เก็บข้อมูลได้นานแค่ไหนครับ?

ตอบ: โดยค่าเริ่มต้น Prometheus จะเก็บข้อมูลแบบ Local Disk และมี Retention Period ที่กำหนดได้ (เช่น 15 วัน, 30 วัน หรือมากกว่า) ขึ้นอยู่กับขนาดของ Disk และจำนวน Metric ที่เก็บครับ หากต้องการเก็บข้อมูลระยะยาวมากๆ (เช่น หลายเดือนหรือหลายปี) สำหรับการวิเคราะห์แนวโน้มในอดีต คุณจะต้องใช้โซลูชัน Long-term Storage เพิ่มเติม เช่น Thanos หรือ Cortex ที่จะจัดเก็บข้อมูลลงใน Object Storage (เช่น S3, Google Cloud Storage) ครับ

มีค่าใช้จ่ายในการใช้งาน Prometheus/Grafana ไหมครับ?

ตอบ: Prometheus และ Grafana เป็น Open Source Software ครับ ดังนั้นคุณสามารถดาวน์โหลดและใช้งานได้ฟรี ไม่มีค่าใช้จ่ายด้าน License ครับ อย่างไรก็ตาม คุณอาจมีค่าใช้จ่ายเกี่ยวกับทรัพยากร Infrastructure (เช่น Server, Disk Space) ที่ใช้ในการรัน Prometheus และ Grafana รวมถึงค่าใช้จ่ายสำหรับบริการเสริมต่างๆ เช่น Cloud Object Storage สำหรับ Long-term Storage หรือบริการแจ้งเตือนอย่าง PagerDuty ครับ

Prometheus ต่างจาก Zabbix/Nagios อย่างไรครับ?