Home » Prometheus Grafana Monitoring ระบบ Server แบบ Pro
ไม่มีหมวดหมู่

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

March 16, 2026
0 Views

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

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

สารบัญ

ทำไมต้อง Monitoring ระบบ Server แบบ Pro?

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

ความสำคัญของการ Monitoring ในโลกธุรกิจปัจจุบัน

ลองจินตนาการถึงเว็บไซต์ E-commerce ที่ล่มระหว่างช่วงโปรโมชั่น Black Friday หรือระบบธนาคารออนไลน์ที่ไม่สามารถทำธุรกรรมได้ในวันสิ้นเดือนครับ สถานการณ์เหล่านี้ล้วนชี้ให้เห็นถึงความจำเป็นของการมีระบบ Monitoring ที่แข็งแกร่งครับ

  • ป้องกันการหยุดชะงัก: ตรวจจับปัญหาได้ก่อนที่จะส่งผลกระทบวงกว้าง
  • เพิ่มประสิทธิภาพ: ระบุจุดคอขวด (bottleneck) และปรับปรุงประสิทธิภาพของระบบ
  • ลดค่าใช้จ่าย: ลดเวลาที่ระบบหยุดทำงาน (downtime) ซึ่งส่งผลต่อรายได้
  • เพิ่มความพึงพอใจลูกค้า: มั่นใจได้ว่าบริการของคุณพร้อมใช้งานเสมอ
  • วางแผนทรัพยากร: ใช้ข้อมูลเชิงลึกในการตัดสินใจขยายหรือลดทรัพยากรได้อย่างเหมาะสม
  • ปฏิบัติตามข้อกำหนด: ช่วยให้ธุรกิจปฏิบัติตามมาตรฐานและข้อกำหนดด้านความปลอดภัยได้ครับ

ความแตกต่างระหว่าง Basic กับ Pro Monitoring

การ Monitoring ทั่วไปอาจจะบอกได้แค่ว่า Server “เปิดอยู่” หรือ “ปิดอยู่” หรือ CPU Load สูงผิดปกติเล็กน้อย แต่การ Monitoring แบบ Pro จะให้ข้อมูลที่ละเอียดและนำไปสู่การแก้ไขปัญหาได้อย่างตรงจุดครับ

  • Basic Monitoring:
    • เน้นสถานะ Up/Down ของ Server หรือบริการ
    • ข้อมูลมักจะเป็นภาพรวม ไม่ละเอียดมาก
    • การแจ้งเตือนมักจะเกิดขึ้นเมื่อปัญหารุนแรงแล้ว
    • ส่วนใหญ่เป็น Script ง่ายๆ หรือเครื่องมือพื้นฐาน
  • Pro Monitoring:
    • ข้อมูลเชิงลึก (Granular Data): เก็บข้อมูลแบบ Time-series พร้อม Label ที่ละเอียด ช่วยให้สามารถเจาะลึกถึงสาเหตุของปัญหาได้
    • การแจ้งเตือนอัจฉริยะ (Intelligent Alerting): กำหนด Rule ที่ซับซ้อนได้ เช่น CPU Load สูงต่อเนื่องนาน 5 นาที ร่วมกับ Disk I/O สูง และ Memory เหลือน้อย
    • Dashboard ที่ปรับแต่งได้ (Customizable Dashboards): สร้าง Dashboard ที่แสดงข้อมูลสำคัญในรูปแบบที่เข้าใจง่าย และเหมาะกับความต้องการของแต่ละทีม
    • รองรับการขยายตัว (Scalability): ออกแบบมาเพื่อรองรับระบบขนาดใหญ่และซับซ้อน
    • Integration หลากหลาย: เชื่อมต่อกับระบบอื่นๆ ได้ง่าย เช่น Kubernetes, Cloud Providers, Message Queues
    • Historical Data Analysis: สามารถย้อนดูข้อมูลในอดีตเพื่อวิเคราะห์แนวโน้ม คาดการณ์ปัญหา และวางแผนในอนาคตครับ

เมื่อใดที่ระบบ Monitoring แบบเดิมๆ ไม่เพียงพอ

ระบบ Monitoring แบบเก่าๆ เช่น Nagios หรือ Zabbix (แม้จะยังใช้งานได้ดีในบางกรณี) อาจเริ่มมีข้อจำกัดเมื่อระบบของคุณเติบโตและมีความซับซ้อนมากขึ้นครับ

  • ระบบ Microservices: การมี Service จำนวนมากที่สื่อสารกันทำให้การติดตามปัญหาเป็นเรื่องยากหากไม่มีเครื่องมือที่ออกแบบมาเพื่อสิ่งนี้โดยเฉพาะ
  • Dynamic Environment: ในสภาพแวดล้อม Cloud หรือ Kubernetes ที่ Server หรือ Container เกิดและดับไปอย่างรวดเร็ว ระบบแบบเก่าที่ต้องกำหนดค่า Target ด้วยมืออาจไม่ตอบโจทย์
  • ปริมาณข้อมูลมหาศาล: ระบบแบบเดิมอาจมีปัญหาในการจัดเก็บและประมวลผลข้อมูล Time-series จำนวนมาก
  • ความต้องการ Real-time: ธุรกิจต้องการข้อมูลแบบใกล้เคียง Real-time เพื่อตอบสนองต่อปัญหาได้อย่างรวดเร็ว
  • ความยืดหยุ่นในการ Query: การวิเคราะห์ข้อมูลที่ซับซ้อนต้องการภาษา Query ที่ทรงพลังและยืดหยุ่นครับ

ประโยชน์ของการ Monitoring ที่แม่นยำและทันท่วงที

การลงทุนในระบบ Monitoring ระดับโปรอย่าง Prometheus และ Grafana จะนำมาซึ่งประโยชน์มากมายครับ

  • ลด Downtime: ตรวจพบและแก้ไขปัญหาได้เร็วกว่า ช่วยให้ระบบกลับมาทำงานได้ไวขึ้น
  • เพิ่มประสิทธิภาพการทำงาน: ทีม Ops และ Dev สามารถระบุสาเหตุของปัญหาและปรับปรุงประสิทธิภาพได้อย่างมีหลักการ
  • ประหยัดค่าใช้จ่าย: หลีกเลี่ยงค่าปรับจาก SLA (Service Level Agreement) ที่ไม่เป็นไปตามข้อกำหนด และลดความจำเป็นในการเพิ่มทรัพยากรโดยไม่จำเป็น
  • ข้อมูลเชิงลึกสำหรับการตัดสินใจ: ใช้ข้อมูลแนวโน้มในการวางแผนการขยายระบบ การจัดสรรงบประมาณ และการพัฒนาผลิตภัณฑ์ในอนาคตครับ

เพื่อเจาะลึกความแตกต่างระหว่างระบบ Monitoring ต่างๆ คุณสามารถ อ่านเพิ่มเติมเกี่ยวกับประเภทของ Monitoring Tools ได้เลยครับ

ทำความรู้จักกับ Prometheus: หัวใจหลักของระบบ Monitoring

Prometheus ได้รับการยอมรับอย่างกว้างขวางว่าเป็นหนึ่งในเครื่องมือ Monitoring ที่ทรงพลังและยืดหยุ่นที่สุด โดยเฉพาะในสภาพแวดล้อม Cloud-native และ Microservices ครับ มาทำความรู้จักกับมันอย่างละเอียดกันครับ

Prometheus คืออะไร?

Prometheus คือระบบ Monitoring และ Alerting แบบโอเพนซอร์สที่พัฒนาขึ้นครั้งแรกโดย SoundCloud ในปี 2012 และถูกบริจาคให้กับ Cloud Native Computing Foundation (CNCF) ในปี 2016 ครับ Prometheus ได้รับการออกแบบมาเพื่อเก็บข้อมูลแบบ Time-series ที่มีมิติ (dimensional data) ซึ่งหมายความว่าทุกๆ ค่า Metric จะมาพร้อมกับชุดของ Label ที่ช่วยให้การ Query และการวิเคราะห์ข้อมูลมีความยืดหยุ่นและทรงพลังอย่างมากครับ

สถาปัตยกรรมและหลักการทำงาน: Pull Model และ Time-series Database

หัวใจสำคัญของ Prometheus คือหลักการทำงานแบบ Pull Model และการใช้ Time-series Database (TSDB) ครับ

  • Pull Model:

    แตกต่างจากระบบ Monitoring แบบเก่าที่ Agent จะ “Push” ข้อมูลไปยัง Server กลาง Prometheus จะใช้วิธี “Pull” หรือดึงข้อมูลจาก Endpoint ที่เปิดเผย Metric ออกมาเองครับ โดย Service หรือ Server ที่ต้องการ Monitoring จะต้องติดตั้ง Exporters ซึ่งเป็นโปรแกรมขนาดเล็กที่เปิด HTTP Endpoint สำหรับให้ Prometheus เข้ามาดึงข้อมูลได้ตามช่วงเวลาที่กำหนดครับ

    ข้อดีของ Pull Model:

    • ลดภาระบน Target: Target ไม่ต้องกังวลเรื่องการส่งข้อมูลไปที่ไหน แต่แค่เปิด Endpoint ไว้
    • ตรวจจับ Target ที่ล่มได้ง่าย: ถ้า Prometheus ดึงข้อมูลไม่ได้ ก็แสดงว่า Target มีปัญหา
    • ความยืดหยุ่นในการกำหนดค่า: สามารถควบคุมได้ว่าต้องการดึงข้อมูลจาก Target ใดบ้าง
  • Time-series Database (TSDB):

    Prometheus จัดเก็บข้อมูลทั้งหมดในฐานข้อมูลแบบ Time-series โดยแต่ละ Metric จะถูกบันทึกพร้อมกับ Timestamp และชุดของ Label ครับ Label เหล่านี้เป็นคู่ของ Key-Value ที่ใช้ในการระบุลักษณะของ Metric นั้นๆ ได้อย่างละเอียด เช่น {instance="server1", job="node_exporter", device="sda"} ซึ่งทำให้สามารถกรองและรวมข้อมูลได้อย่างทรงพลังด้วยภาษา PromQL ครับ

    Prometheus เก็บข้อมูลในรูปแบบ Block ซึ่งแต่ละ Block จะมี Index และข้อมูล Time-series ของช่วงเวลาหนึ่งๆ ครับ

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

ระบบนิเวศของ Prometheus ประกอบด้วยส่วนประกอบหลักหลายอย่างที่ทำงานร่วมกันครับ

  • Prometheus Server:

    เป็นหัวใจหลักของระบบ มีหน้าที่หลัก 3 อย่างครับ

    • Scraping: ดึงข้อมูล Metric จาก Exporter หรือ Service Endpoint ต่างๆ
    • Storage: จัดเก็บข้อมูล Time-series ลงในฐานข้อมูลภายใน
    • Querying: ประมวลผลและตอบสนองต่อ Query ด้วยภาษา PromQL
  • Exporters:

    โปรแกรมขนาดเล็กที่รันอยู่บน Target Server หรือ Application เพื่อเปิด HTTP Endpoint ให้ Prometheus ดึงข้อมูล Metric ออกมาได้ครับ มี Exporter หลากหลายประเภทสำหรับ Monitoring ระบบปฏิบัติการ (Node Exporter), Container (cAdvisor), ฐานข้อมูล, และ Application ต่างๆ ครับ

  • Pushgateway:

    สำหรับกรณีที่ Target ไม่สามารถถูก Prometheus ดึงข้อมูลได้โดยตรง หรือเป็น Short-lived Job ที่รันแล้วจบไปอย่างรวดเร็ว Pushgateway จะทำหน้าที่เป็นตัวกลางในการรับข้อมูล Metric จาก Job เหล่านี้ แล้วเปิด Endpoint ให้ Prometheus ดึงข้อมูลไปอีกทอดหนึ่งครับ

  • Alertmanager:

    ทำหน้าที่จัดการและส่งการแจ้งเตือน (Alerts) ที่ถูกสร้างขึ้นโดย Prometheus Server ครับ Alertmanager สามารถ Group Alert ที่คล้ายกัน, Deduplicate, Silence และส่งไปยังปลายทางต่างๆ เช่น Email, Slack, PagerDuty ได้อย่างชาญฉลาดครับ

  • Service Discovery:

    กลไกที่ Prometheus ใช้ในการค้นหา Target ที่จะดึงข้อมูลโดยอัตโนมัติครับ ในสภาพแวดล้อม Dynamic เช่น Kubernetes, AWS EC2, หรือ Consul Service Discovery จะช่วยให้ Prometheus ไม่ต้องกำหนดค่า Target ด้วยมือ ซึ่งช่วยลดภาระในการบริหารจัดการได้อย่างมากครับ

ข้อดีและข้อจำกัดของ Prometheus

เหมือนกับทุกเครื่องมือ Prometheus ก็มีทั้งข้อดีและข้อจำกัดครับ

ข้อดี

  • Model ที่ทรงพลัง: การใช้ Label ทำให้การ Query และ Aggregation ข้อมูลมีความยืดหยุ่นสูง
  • PromQL ที่ยืดหยุ่น: ภาษา Query ที่ออกแบบมาเพื่อ Time-series โดยเฉพาะ ทำให้สามารถวิเคราะห์ข้อมูลที่ซับซ้อนได้อย่างง่ายดาย
  • ระบบนิเวศที่กว้างขวาง: มี Exporter และ Integration มากมายสำหรับเกือบทุกประเภทของระบบ
  • Open Source และ Community ที่แข็งแกร่ง: พัฒนาและสนับสนุนโดยชุมชนขนาดใหญ่ มีทรัพยากรและตัวอย่างให้ศึกษาเยอะ
  • เหมาะสำหรับ Cloud-native: ทำงานได้ดีเยี่ยมกับ Kubernetes และ Microservices
  • ใช้งานร่วมกับ Grafana ได้อย่างลงตัว: สร้าง Dashboard ที่สวยงามและทรงพลังได้ง่าย

ข้อจำกัด

  • ไม่มี Long-term Storage ในตัว: Prometheus Server ถูกออกแบบมาเพื่อเก็บข้อมูลระยะสั้น (ประมาณ 15 วันถึง 1 ปี ขึ้นอยู่กับการตั้งค่า) สำหรับข้อมูลระยะยาวต้องใช้โซลูชันภายนอก เช่น Thanos, Cortex, หรือ M3DB ครับ
  • ไม่เหมาะกับการเก็บ Log: Prometheus เน้นการเก็บ Metric ที่เป็นตัวเลข ไม่ใช่ Log Event
  • ไม่รองรับ Distributed Tracing: ต้องใช้เครื่องมืออื่นเช่น Jaeger หรือ Zipkin
  • ไม่มี UI สำหรับ Dashboard: ต้องพึ่ง Grafana ในการสร้าง Visualization ที่สวยงาม
  • ไม่เหมาะกับการ Monitoring แบบ Agent-less: ต้องติดตั้ง Exporter บน Target Server ครับ

การติดตั้ง Prometheus เบื้องต้น

การติดตั้ง Prometheus นั้นไม่ซับซ้อนครับ เราจะใช้ Docker เพื่อความง่ายในการสาธิตนะครับ (ใน Production อาจจะใช้ Binary โดยตรง หรือ Kubernetes Operator)

ขั้นตอนที่ 1: สร้างไฟล์ Configuration (prometheus.yml)

global:
  scrape_interval: 15s # ดึงข้อมูลทุก 15 วินาที
  evaluation_interval: 15s # ประเมิน Alert Rule ทุก 15 วินาที

scrape_configs:
  - job_name: 'prometheus'
    # ดึงข้อมูลจาก Prometheus Server เอง
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    # ตัวอย่างการดึงข้อมูลจาก Node Exporter (สมมติรันอยู่บนพอร์ต 9100)
    static_configs:
      - targets: ['localhost:9100'] # หรือ IP ของ Server ที่มี Node Exporter

ขั้นตอนที่ 2: รัน Prometheus ด้วย Docker

ตรวจสอบให้แน่ใจว่าคุณมี Docker ติดตั้งอยู่บนเครื่องของคุณนะครับ

docker run \
  -d \
  --name prometheus \
  -p 9090:9090 \
  -v /path/to/your/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

อธิบาย Code:

  • -d: รัน Container ในโหมด Detached (ทำงานเบื้องหลัง)
  • --name prometheus: กำหนดชื่อ Container
  • -p 9090:9090: Map พอร์ต 9090 ของ Container ไปยังพอร์ต 9090 บน Host (Prometheus Web UI)
  • -v /path/to/your/prometheus.yml:/etc/prometheus/prometheus.yml: Mount ไฟล์คอนฟิกของคุณเข้าไปใน Container
  • prom/prometheus: Image ของ Prometheus จาก Docker Hub

หลังจากรันแล้ว คุณสามารถเข้าถึง Prometheus Web UI ได้ที่ http://localhost:9090 ครับ

Exporters สำหรับการดึงข้อมูลที่หลากหลาย

Exporters คือกุญแจสำคัญที่ทำให้ Prometheus สามารถดึงข้อมูล Metric จากแหล่งต่างๆ ได้อย่างยืดหยุ่นและหลากหลายครับ ไม่ว่าจะเป็นระบบปฏิบัติการ, ฐานข้อมูล, แอปพลิเคชัน, หรือแม้กระทั่งอุปกรณ์เครือข่าย Exporters จะทำหน้าที่เป็นสะพานเชื่อมระหว่างระบบเหล่านั้นกับ Prometheus ครับ

บทบาทของ Exporters ในระบบ Prometheus

Exporters เป็นโปรแกรมขนาดเล็กที่รันอยู่บน Server หรือใน Container ที่เราต้องการ Monitoring ครับ หน้าที่หลักของมันคือ:

  • รวบรวม Metric: ดึงข้อมูล Metric ที่เกี่ยวข้องจากระบบภายใน เช่น การใช้งาน CPU, Memory, Disk I/O, Network Traffic, จำนวน Request ของ Web Server, หรือสถานะของ Database Connection Pool ครับ
  • แปลงเป็นรูปแบบ Prometheus: แปลงข้อมูลที่รวบรวมได้ให้อยู่ในรูปแบบที่ Prometheus เข้าใจ ซึ่งเป็น Plain Text ที่มี Metric Name, Labels และ Value
  • เปิด HTTP Endpoint: สร้าง HTTP Endpoint (โดยทั่วไปคือ /metrics) เพื่อให้ Prometheus Server สามารถเข้ามา “Scrape” หรือดึงข้อมูลไปได้ตามช่วงเวลาที่กำหนดครับ

Node Exporter: หัวใจของการ Monitoring Server OS

Node Exporter เป็น Exporter ที่ได้รับความนิยมมากที่สุดตัวหนึ่งครับ ใช้สำหรับรวบรวม Metric ระดับระบบปฏิบัติการ (OS-level metrics) จาก Linux และ Unix-like systems ครับ

Metric ที่ Node Exporter รวบรวมได้ เช่น:

  • CPU Usage: node_cpu_seconds_total (idle, user, system, iowait)
  • Memory Usage: node_memory_MemTotal_bytes, node_memory_MemFree_bytes
  • Disk I/O: node_disk_reads_completed_total, node_disk_writes_completed_total
  • Network Traffic: node_network_receive_bytes_total, node_network_transmit_bytes_total
  • Disk Space: node_filesystem_avail_bytes, node_filesystem_size_bytes
  • Load Average: node_load1, node_load5, node_load15
  • Uptime: node_boot_time_seconds

การติดตั้ง Node Exporter (ตัวอย่างบน Linux):

# ดาวน์โหลด Node Exporter (ตรวจสอบเวอร์ชันล่าสุดบน GitHub ของ Prometheus)
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

# ย้ายไฟล์ไปยังตำแหน่งที่เหมาะสม
sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/

# สร้าง User สำหรับ Node Exporter (เพื่อความปลอดภัย)
sudo useradd -rs /bin/false node_exporter

# สร้าง Service File สำหรับ systemd
sudo vim /etc/systemd/system/node_exporter.service

เนื้อหาใน /etc/systemd/system/node_exporter.service:

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

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target
# Reload systemd, Start และ Enable service
sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter

# ตรวจสอบสถานะ
sudo systemctl status node_exporter

เมื่อ Node Exporter ทำงานแล้ว คุณจะสามารถเข้าถึง Metric ได้ที่ http://<your_server_ip>:9100/metrics ครับ

cAdvisor: Monitoring Container อย่างมีประสิทธิภาพ

สำหรับระบบที่ใช้ Containerize อย่าง Docker หรือ Kubernetes, cAdvisor (Container Advisor) เป็น Exporter ที่ยอดเยี่ยมครับ cAdvisor จะรวบรวมข้อมูลประสิทธิภาพและการใช้งานทรัพยากรของ Container ต่างๆ บน Host นั้นๆ ครับ

Metric ที่ cAdvisor รวบรวมได้ เช่น:

  • CPU usage per container
  • Memory usage per container
  • Network I/O per container
  • Filesystem usage per container

การรัน cAdvisor ด้วย Docker:

docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  gcr.io/cadvisor/cadvisor:latest

cAdvisor จะเปิด Endpoint ที่พอร์ต 8080 ครับ

Blackbox Exporter: ตรวจสอบความพร้อมของ Endpoint ภายนอก

Blackbox Exporter ใช้สำหรับ “Probe” หรือตรวจสอบความพร้อมและประสิทธิภาพของ Endpoint ภายนอก เช่น HTTP, HTTPS, TCP, ICMP หรือ DNS ครับ ไม่ได้ติดตั้งบน Target ที่ถูกตรวจสอบ แต่รันแยกต่างหาก

ใช้ตรวจสอบ:

  • เว็บไซต์ล่มหรือไม่ (HTTP 200 OK)
  • SSL Certificate หมดอายุ
  • พอร์ต TCP เปิดอยู่หรือไม่
  • Latency ในการตอบสนอง

การกำหนดค่า Prometheus สำหรับ Blackbox Exporter:

scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]  # ใช้ Module http_2xx ที่กำหนดไว้ใน blackbox.yml
    static_configs:
      - targets:
          - http://example.com # Target ที่ต้องการตรวจสอบ
          - https://siamlancard.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox_exporter:9115 # ที่อยู่ของ Blackbox Exporter

หมายเหตุ: ต้องรัน Blackbox Exporter แยกต่างหากบนพอร์ต 9115 ก่อน

Database Exporters: เจาะลึกประสิทธิภาพฐานข้อมูล

ฐานข้อมูลเป็นส่วนสำคัญของเกือบทุกระบบ Exporters สำหรับฐานข้อมูลช่วยให้เราสามารถ Monitoring ประสิทธิภาพของฐานข้อมูลได้อย่างละเอียดครับ

  • MySQL Exporter: mysqld_exporter สำหรับ MySQL/MariaDB
  • PostgreSQL Exporter: postgres_exporter สำหรับ PostgreSQL
  • MongoDB Exporter: mongodb_exporter สำหรับ MongoDB

Metric ที่รวบรวมได้จะรวมถึง Connection count, Query execution times, Replication status, Index usage, Cache hit rates และอื่นๆ อีกมากมายครับ

การกำหนดค่า Exporters ใน Prometheus

เมื่อ Exporter ทำงานอยู่แล้ว เราต้องบอก Prometheus Server ให้ไปดึงข้อมูลจาก Exporter เหล่านั้นครับ โดยการแก้ไขไฟล์ prometheus.yml

ตัวอย่างการเพิ่ม Node Exporter และ cAdvisor ใน prometheus.yml:

global:
  scrape_interval: 15s

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

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['your_server_ip:9100'] # IP ของ Server ที่มี Node Exporter รันอยู่

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['your_server_ip:8080'] # IP ของ Server ที่มี cAdvisor รันอยู่

หลังจากแก้ไขไฟล์ prometheus.yml แล้ว อย่าลืม Restart Prometheus Server หรือส่ง SIGHUP signal เพื่อให้ Prometheus โหลดคอนฟิกใหม่ครับ

# ถ้าใช้ Docker
docker restart prometheus

# ถ้าใช้ Binary โดยตรง
kill -HUP $(pidof prometheus)

จากนั้นไปที่ Prometheus Web UI (http://localhost:9090) ไปที่เมนู “Status” -> “Targets” คุณจะเห็น Target ของ Node Exporter และ cAdvisor ปรากฏขึ้นพร้อมสถานะ “UP” ครับ

Grafana: สร้าง Dashboard ที่สวยงามและทรงพลัง

แม้ Prometheus จะเป็นเครื่องมือที่ยอดเยี่ยมในการเก็บและ Query ข้อมูล แต่การแสดงผลข้อมูลให้อยู่ในรูปแบบที่เข้าใจง่ายและสวยงามนั้นเป็นหน้าที่ของ Grafana ครับ

Grafana คืออะไร?

Grafana คือแพลตฟอร์ม Visualization และ Monitoring แบบโอเพนซอร์สที่ช่วยให้คุณสามารถสร้าง Dashboard ที่สวยงามและโต้ตอบได้จากแหล่งข้อมูลที่หลากหลายครับ Grafana ไม่ได้เก็บข้อมูลเอง แต่ทำหน้าที่ดึงข้อมูลจาก Data Source ต่างๆ มาแสดงผลเท่านั้นครับ

ทำไมต้องใช้ Grafana คู่กับ Prometheus?

Prometheus และ Grafana เป็นคู่หูที่ลงตัวอย่างยิ่งครับ

  • Visualization ที่เหนือกว่า: Prometheus Web UI มีฟังก์ชันการแสดงกราฟพื้นฐาน แต่ Grafana มีตัวเลือก Visualization ที่หลากหลายกว่ามาก (กราฟ, ตาราง, เกจ, สถิติ, แผนที่ความร้อน ฯลฯ)
  • Dashboard ที่ปรับแต่งได้: Grafana ช่วยให้คุณสร้าง Dashboard ที่รวม Metric จากหลายๆ ระบบเข้าไว้ด้วยกันในหน้าเดียว
  • การแชร์และ Collaboration: สามารถแชร์ Dashboard กับทีมงานได้อย่างง่ายดาย
  • Templating และ Variables: สร้าง Dashboard ที่ยืดหยุ่นและสามารถเลือกดูข้อมูลของ Instance ต่างๆ ได้อย่างรวดเร็ว
  • Alerting ที่สวยงาม: Grafana มีระบบ Alerting ในตัวที่สามารถส่งการแจ้งเตือนตามเงื่อนไขที่กำหนดได้ (แม้ว่า Alertmanager จะเหมาะสมกว่าสำหรับการจัดการ Alert ที่ซับซ้อน)

สถาปัตยกรรมเบื้องต้นของ Grafana

Grafana เป็น Web Application ที่สามารถรันบน Server ทั่วไป หรือใน Container ได้ครับ

  • Frontend: ส่วนติดต่อผู้ใช้ (UI) ที่สร้างด้วย ReactJS
  • Backend: เขียนด้วย Go มีหน้าที่จัดการ Data Source, Dashboard, User, และ Alerting ครับ
  • Database: ใช้ SQLite เป็น Default แต่สามารถใช้ PostgreSQL หรือ MySQL สำหรับ Production ได้ครับ

การติดตั้ง Grafana

เราจะติดตั้ง Grafana ด้วย Docker เพื่อความง่ายครับ

docker run \
  -d \
  --name grafana \
  -p 3000:3000 \
  grafana/grafana-oss

อธิบาย Code:

  • -d: รันในโหมด Detached
  • --name grafana: กำหนดชื่อ Container
  • -p 3000:3000: Map พอร์ต 3000 ของ Container ไปยังพอร์ต 3000 บน Host
  • grafana/grafana-oss: Image ของ Grafana จาก Docker Hub

หลังจากรันแล้ว คุณสามารถเข้าถึง Grafana Web UI ได้ที่ http://localhost:3000 ครับ

Default Login:

  • Username: admin
  • Password: admin (ระบบจะให้คุณเปลี่ยน Password หลังจาก Login ครั้งแรก)

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

ขั้นตอนแรกหลังจากติดตั้ง Grafana คือการเพิ่ม Prometheus เป็น Data Source ครับ

  1. เข้าสู่ระบบ Grafana (http://localhost:3000)
  2. ที่เมนูด้านซ้าย คลิกที่ไอคอน ⚙️ Configuration แล้วเลือก Data sources
  3. คลิก Add data source
  4. เลือก Prometheus

  5. ตั้งค่า Data Source:

    • Name: ตั้งชื่อ Data Source ของคุณ (เช่น “Prometheus Local”)
    • URL: ใส่ URL ของ Prometheus Server ของคุณ (เช่น http://localhost:9090 ถ้า Prometheus รันอยู่บน Host เดียวกัน)
    • Access: เลือก Browser หรือ Server (recommended) (Server เหมาะสำหรับ Production มากกว่าครับ)
  6. คลิก Save & test หากสำเร็จ จะแสดงข้อความ “Data source is working” ครับ

การสร้าง Dashboard และ Panel พื้นฐาน

การสร้าง Dashboard ใน Grafana นั้นง่ายและยืดหยุ่นมากครับ

  1. ที่เมนูด้านซ้าย คลิกที่ไอคอน ➕ Create แล้วเลือก Dashboard
  2. คลิก Add new panel

  3. ในหน้า Panel Editor:

    • Query: เลือก Data Source เป็น Prometheus ที่เราเพิ่งเพิ่มไป
    • Metric Browser: คุณสามารถใช้ Metric Browser เพื่อค้นหา Metric ที่ Prometheus เก็บไว้ได้ครับ เช่น พิมพ์ node_cpu_seconds_total
    • PromQL Query: ใส่ PromQL Query ลงในช่อง Query. เช่น: 
      100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

      Query นี้คำนวณการใช้งาน CPU โดยรวมของแต่ละ Instance ในช่วง 5 นาทีที่ผ่านมาครับ

    • Visualization: เลือกประเภทของกราฟที่คุณต้องการ เช่น Graph, Stat, Gauge
    • Panel Title: ตั้งชื่อ Panel (เช่น “CPU Usage”)
  4. คลิก Apply เพื่อบันทึก Panel
  5. คลิก Save dashboard ที่ด้านบนขวา เพื่อบันทึก Dashboard ทั้งหมดครับ

PromQL ใน Grafana: สร้าง Visualization ที่ซับซ้อน

ความสามารถที่แท้จริงของ Grafana เมื่อใช้กับ Prometheus มาจากการใช้ PromQL ในการ Query ข้อมูลครับ คุณสามารถสร้างกราฟที่ซับซ้อนเพื่อแสดงข้อมูลเชิงลึกได้

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

  • Free Memory (เป็นเปอร์เซ็นต์): 
    100 * (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)
  • Disk Space Usage (เป็นเปอร์เซ็นต์): 
    100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100
  • Network Receive Bytes per second: 
    rate(node_network_receive_bytes_total{device="eth0"}[5m])

Templating และ Variables: Dashboard ที่ยืดหยุ่น

ฟีเจอร์ Templating ใน Grafana เป็นสิ่งสำคัญสำหรับการสร้าง Dashboard ที่ยืดหยุ่นและนำกลับมาใช้ใหม่ได้ครับ ช่วยให้คุณสามารถสร้าง Variable (ตัวแปร) จาก Metric หรือ Label ที่ Prometheus เก็บไว้ แล้วนำ Variable เหล่านั้นไปใช้ใน PromQL Query ของ Panel ได้

ตัวอย่างการสร้าง Variable สำหรับเลือก Server Instance:

  1. แก้ไข Dashboard ของคุณ
  2. คลิกที่ไอคอน ⚙️ Dashboard Settings ด้านบน
  3. เลือก Variables จากเมนูด้านซ้าย
  4. คลิก Add variable

  5. ตั้งค่า Variable:

    • Name: instance
    • Type: Query
    • Data source: เลือก Prometheus ของคุณ
    • Refresh: On Dashboard Load
    • Query: label_values(node_cpu_seconds_total, instance) (Query นี้จะดึงค่า Label ทั้งหมดของ “instance” จาก Metric node_cpu_seconds_total มาแสดงเป็นตัวเลือก)
    • Multi-value: เปิด (ถ้าต้องการเลือกหลาย Instance)
    • Include All option: เปิด (ถ้าต้องการตัวเลือก “All”)
  6. คลิก Add และ Save dashboard

เมื่อมี Variable $instance แล้ว คุณสามารถนำไปใช้ใน PromQL Query ของ Panel ได้ครับ เช่น:

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

ที่ด้านบนของ Dashboard คุณจะมี Dropdown ให้เลือก Server Instance ที่ต้องการดูข้อมูลได้ทันทีครับ นี่คือพลังของการ Monitoring แบบ Pro ที่แท้จริงครับ! เรียนรู้การสร้าง Grafana Dashboards เพิ่มเติมได้ที่นี่

PromQL: ภาษามหัศจรรย์สำหรับการ Query ข้อมูล

PromQL (Prometheus Query Language) คือภาษา Query ที่ทรงพลังและยืดหยุ่น ซึ่งเป็นหัวใจสำคัญในการดึงและวิเคราะห์ข้อมูลจาก Prometheus ครับ การเข้าใจ PromQL อย่างถ่องแท้จะช่วยให้คุณสามารถสร้าง Dashboard และ Alert Rule ที่มีประสิทธิภาพได้อย่างไม่มีขีดจำกัดครับ

ความสำคัญของ PromQL ในระบบ Monitoring

PromQL ไม่ใช่แค่ภาษา Query ธรรมดา แต่ถูกออกแบบมาโดยเฉพาะสำหรับการทำงานกับข้อมูล Time-series ที่มีมิติ (dimensional data) ครับ มันช่วยให้คุณ:

  • กรองข้อมูล: เลือก Metric และ Label ที่ต้องการ
  • รวมข้อมูล: รวมข้อมูลจากหลายๆ Instance หรือหลาย Label เข้าด้วยกัน
  • คำนวณ: ทำการคำนวณทางคณิตศาสตร์, อัตราการเปลี่ยนแปลง, ค่าเฉลี่ย, ค่าสูงสุด/ต่ำสุด
  • วิเคราะห์แนวโน้ม: ดูการเปลี่ยนแปลงของ Metric ในช่วงเวลาที่กำหนด
  • ระบุปัญหา: สร้าง Query ที่สามารถบ่งชี้ถึงปัญหาหรือความผิดปกติในระบบได้

โครงสร้างพื้นฐานของ PromQL: Metric, Labels และ Value

PromQL Query พื้นฐานประกอบด้วย 3 ส่วนหลักครับ

  1. Metric Name: ชื่อของ Metric ที่ต้องการ Query เช่น node_cpu_seconds_total, http_requests_total
  2. Label Selectors: ชุดของ Label ที่ใช้กรองข้อมูล โดยอยู่ในวงเล็บปีกกา {} ครับ
  3. Range Vector Selector (Optional): ระบุช่วงเวลาที่ต้องการดูข้อมูล ในวงเล็บเหลี่ยม [] ครับ

ตัวอย่าง:

  • node_memory_MemFree_bytes: ดึงค่า Free Memory ปัจจุบันของทุก Instance
  • node_cpu_seconds_total{instance="webserver01", mode="idle"}: ดึงค่า CPU Idle time ของ webserver01
  • node_network_receive_bytes_total[5m]: ดึงค่า Network Received bytes ในช่วง 5 นาทีที่ผ่านมาของทุก Instance (เป็น Range Vector)

Operators ใน Label Selectors:

  • =: เท่ากับ (exact match)
  • !=: ไม่เท่ากับ (not equal)
  • =~: ตรงกับ Regular Expression (regex match)
  • !~: ไม่ตรงกับ Regular Expression (regex non-match)

ตัวอย่าง Label Selectors:

node_cpu_seconds_total{job="node_exporter"}
node_cpu_seconds_total{instance=~"webserver.+", mode!="idle"}
http_requests_total{method=~"GET|POST", status="200"}

Operators และ Functions ยอดนิยม

PromQL มี Operators และ Functions มากมายที่ช่วยให้คุณประมวลผลข้อมูลได้หลากหลายครับ

Operators

  • Arithmetic Operators: +, -, *, /, %, ^
  • Comparison Operators: ==, !=, >, <, >=, <=
  • Logical Operators: and, or, unless
  • Set Operators: on(), ignoring() (สำหรับการจับคู่ Label ระหว่าง Vector)

Functions ยอดนิยม

  • rate(vector_range): คำนวณอัตราการเปลี่ยนแปลงเฉลี่ยต่อวินาทีในช่วงเวลาที่กำหนด (เหมาะสำหรับ Counter Metric)
  • increase(vector_range): คำนวณค่าที่เพิ่มขึ้นในช่วงเวลาที่กำหนด (เหมาะสำหรับ Counter Metric)
  • sum(vector) by (label): รวมค่าของ Metric ตาม Label ที่กำหนด
  • avg(vector) by (label): คำนวณค่าเฉลี่ยของ Metric ตาม Label ที่กำหนด
  • max(vector) by (label): คำนวณค่าสูงสุด
  • min(vector) by (label): คำนวณค่าต่ำสุด
  • count(vector) by (label): นับจำนวน Element
  • irate(vector_range): คล้ายกับ rate() แต่คำนวณอัตราการเปลี่ยนแปลงแบบ Instantaneous (เหมาะสำหรับ Spikes)
  • histogram_quantile(quantile, histogram_bucket_metric): คำนวณ Quantile จาก Histogram Metric (เช่น Latency Percentile)
  • topk(k, vector): คืนค่า k อันดับแรกที่มีค่าสูงสุด
  • bottomk(k, vector): คืนค่า k อันดับแรกที่มีค่าต่ำสุด

ตัวอย่าง PromQL Query สำหรับสถานการณ์จริง

มาดูตัวอย่าง PromQL Query ที่ใช้งานได้จริงกันครับ

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

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

อธิบาย: คำนวณเปอร์เซ็นต์ CPU ที่ไม่ได้อยู่ในสถานะ "idle" (ซึ่งหมายถึงกำลังใช้งาน) โดยใช้ rate() เพื่อหาอัตราการเปลี่ยนแปลงของ CPU idle time ในช่วง 5 นาทีที่ผ่านมา และใช้ avg by (instance) เพื่อรวมค่าสำหรับแต่ละ Server ครับ

2. การใช้งาน Memory (เป็นเปอร์เซ็นต์):

(node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Buffers_bytes - node_memory_Cached_bytes) / node_memory_MemTotal_bytes * 100

อธิบาย: คำนวณเปอร์เซ็นต์ของ Memory ที่ใช้งานอยู่จริง โดยหัก Buffer และ Cache ออกจาก Memory ที่ใช้งานทั้งหมดครับ

3. Disk I/O Operations per Second (IOPS):

rate(node_disk_reads_completed_total[5m]) + rate(node_disk_writes_completed_total[5m])

อธิบาย: รวมอัตราการอ่านและเขียน Disk Operations ต่อวินาทีในช่วง 5 นาที เพื่อดูภาพรวมของ Disk I/O ครับ

4. Network Traffic (bytes/sec) บน Interface eth0:

rate(node_network_receive_bytes_total{device="eth0"}[5m]) + rate(node_network_transmit_bytes_total{device="eth0"}[5m])

อธิบาย: คำนวณอัตราการรับและส่งข้อมูลบน Network Interface eth0 เป็น bytes ต่อวินาทีครับ

5. HTTP Request Rate สำหรับ Status Code 5xx:

sum by (job, instance) (rate(http_requests_total{status=~"5.."}[5m]))

อธิบาย: คำนวณอัตราการเกิด HTTP Request ที่มี Status Code เป็น 5xx (Server Error) ในช่วง 5 นาทีที่ผ่านมา โดยรวมค่าตาม job และ instance ครับ

การฝึกฝน PromQL บ่อยๆ และการทดลองใช้ผ่าน Prometheus Web UI หรือ Grafana จะช่วยให้คุณเชี่ยวชาญภาษาที่ทรงพลังนี้ได้อย่างรวดเร็วครับ

การแจ้งเตือนอัจฉริยะด้วย Alertmanager

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

ทำไมต้องมี Alertmanager?

Prometheus Server สามารถสร้าง Alert ได้ แต่ Prometheus ไม่ได้ถูกออกแบบมาเพื่อจัดการกับการแจ้งเตือนที่ซับซ้อนครับ หน้าที่ของ Alertmanager คือการแก้ปัญหานี้ครับ

  • Grouping: รวม Alert ที่คล้ายกันเป็น Alert เดียว เพื่อลดจำนวนการแจ้งเตือนที่ส่งไปถึงผู้ดูแลระบบ
  • Inhibition: ระงับการแจ้งเตือนที่มีลำดับความสำคัญต่ำกว่า หากมี Alert ที่มีลำดับความสำคัญสูงกว่าเกิดขึ้นแล้ว
  • Silences: ช่วยให้ผู้ดูแลระบบสามารถปิดการแจ้งเตือนชั่วคราวสำหรับช่วงเวลาที่กำลังแก้ไขปัญหา หรือช่วงเวลา Maintenance
  • Routing: กำหนดเส้นทางของ Alert ไปยังผู้รับที่เหมาะสมตามเงื่อนไขต่างๆ (เช่น ส่ง Critical Alert ไปยัง PagerDuty, Warning Alert ไปยัง Slack)
  • หลากหลายช่องทาง: รองรับการส่งแจ้งเตือนผ่านช่องทางต่างๆ เช่น Email, Slack, PagerDuty, Webhook, Opsgenie, VictorOps และอื่นๆ อีกมากมายครับ

สถาปัตยกรรมและหลักการทำงานของ Alertmanager

Alertmanager จะรับ Alert จาก Prometheus Server (หรือ Prometheus HA pair) ครับ เมื่อได้รับ Alert แล้ว Alertmanager จะใช้ Rule ที่กำหนดไว้ในไฟล์ alertmanager.yml เพื่อตัดสินใจว่าจะ Group, Inhibite, Silence หรือ Route Alert นั้นไปยังผู้รับคนใดบ้างครับ

Workflow โดยย่อ:

  1. Prometheus Server ประเมิน Alert Rule (ที่กำหนดใน prometheus.yml)
  2. เมื่อ Rule เป็นจริง Prometheus จะส่ง Alert ไปยัง Alertmanager
  3. Alertmanager รับ Alert และประมวลผลตาม Rule ใน alertmanager.yml
  4. Alertmanager ส่งการแจ้งเตือนไปยัง Receiver ที่กำหนดไว้

การกำหนดค่า Rule ใน Prometheus Server

ก่อนที่ Alertmanager จะทำงานได้ Prometheus Server ต้องรู้ก่อนว่าจะสร้าง Alert เมื่อใดครับ Rule เหล่านี้ถูกกำหนดไว้ในไฟล์ alert.rules.yml (หรือไฟล์ .yml อื่นๆ ที่ Prometheus Server โหลด) และถูกอ้างอิงใน prometheus.yml ครับ

ตัวอย่าง alert.rules.yml:

groups:
  - name: server_alerts
    rules:
    - alert: HighCPULoad
      expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "High CPU load on {{ $labels.instance }}"
        description: "CPU utilization on {{ $labels.instance }} has been over 80% for 5 minutes. Current value: {{ $value | humanize }}%"

    - alert: ServerDown
      expr: up == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Instance {{ $labels.instance }} is down"
        description: "{{ $labels.instance }} of job {{ $labels.job }} is down for more than 1 minute."

การเพิ่ม Rule file ใน prometheus.yml:

# ... ส่วนอื่นๆ ของ prometheus.yml
rule_files:
  - "alert.rules.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093'] # ที่อยู่ของ Alertmanager

อธิบาย Rule:

  • alert: ชื่อของ Alert
  • expr: PromQL Query ที่จะใช้ประเมินเงื่อนไข
  • for: ระยะเวลาที่เงื่อนไขต้องเป็นจริงก่อนที่จะเกิด Alert
  • labels: Label เพิ่มเติมสำหรับ Alert (เช่น Severity)
  • annotations: ข้อความอธิบาย Alert ที่จะส่งไปยัง Receiver (สามารถใช้ Go Template ได้)

การกำหนดค่า Alertmanager: Receivers และ Routes

ไฟล์คอนฟิกหลักของ Alertmanager คือ alertmanager.yml ครับ

ตัวอย่าง alertmanager.yml:

global:
  resolve_timeout: 5m # ระยะเวลาที่จะถือว่า Alert ถูกแก้ไขแล้ว หากไม่ได้รับซ้ำ

route:
  receiver: 'default-receiver' # Receiver เริ่มต้น
  group_by: ['alertname', 'severity', 'instance'] # Group Alert ตาม Label เหล่านี้
  group_wait: 30s # รอ 30 วินาทีก่อนส่ง Alert ชุดแรก
  group_interval: 5m # ส่ง Alert ซ้ำทุก 5 นาที หากยังไม่แก้ไข
  repeat_interval: 4h # ส่งซ้ำทุก 4 ชั่วโมง หาก Alert ยังคง Active

  routes:
    - match:
        severity: 'critical'
      receiver: 'slack-critical'
      group_wait: 10s
      repeat_interval: 1h

    - match:
        severity: 'warning'
      receiver: 'slack-warning'
      group_wait: 30s
      repeat_interval: 2h

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: '[email protected]'
        from: '[email protected]'
        smarthost: 'smtp.example.com:587'
        auth_username: '[email protected]'
        auth_password: 'your_email_password'
        require_tls: true

  - name: 'slack-critical'
    slack_configs:
      - channel: '#critical-alerts'
        api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
        title: '🔥 Critical Alert: {{ .CommonLabels.alertname }}'
        text: 'Summary: {{ .CommonAnnotations.summary }}\nDescription: {{ .CommonAnnotations.description }}'

  - name: 'slack-warning'
    slack_configs:
      - channel: '#warning-alerts'
        api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
        title: '⚠️ Warning Alert: {{ .CommonLabels.alertname }}'
        text: 'Summary: {{ .CommonAnnotations.summary }}\nDescription: {{ .CommonAnnotations.description }}'

การรัน Alertmanager ด้วย Docker:

docker run \
  -d \
  --name alertmanager \
  -p 9093:9093 \
  -v /path/to/your/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
  prom/alertmanager

คุณสามารถเข้าถึง Alertmanager UI ได้ที่ http://localhost:9093 ครับ

ตัวอย่างการแจ้งเตือนผ่านช่องทางต่างๆ (Slack, Email)

จากตัวอย่างคอนฟิกข้างต้น Alertmanager จะสามารถส่งการแจ้งเตือนไปยัง:

  • Email: สำหรับ Alert ทั่วไป
  • Slack Channel (Critical): สำหรับ Alert ที่มี Severity เป็น critical
  • Slack Channel (Warning): สำหรับ Alert ที่มี Severity เป็น warning

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

การขยายขนาดและการจัดการสำหรับ Production Environment

เมื่อระบบ Monitoring ของคุณเติบโตขึ้น การจัดการและปรับแต่งให้เหมาะสมกับ Production Environment จะเป็นสิ่งสำคัญอย่างยิ่งครับ โดยเฉพาะอย่างยิ่งในเรื่องของ High Availability, Long-term Storage และ Service Discovery

High Availability (HA) สำหรับ Prometheus

Prometheus Server โดย Default ไม่ได้มี HA ในตัว การล่มของ Prometheus Server เพียงตัวเดียวจะทำให้การ Monitoring หยุดชะงักได้ครับ มีหลายวิธีในการทำให้ Prometheus มี HA ครับ

  • Running Two Identical Prometheus Servers:

    เป็นวิธีที่ง่ายที่สุด คือรัน Prometheus Server สองตัวที่ Scraping Target เดียวกันครับ

    • ข้อดี: ง่ายต่อการตั้งค่า
    • ข้อเสีย: ใช้ทรัพยากรสองเท่า, Alert จะถูกส่งซ้ำ (ต้องตั้งค่า Alertmanager ให้ Deduplicate)
  • Prometheus Federation:

    Prometheus ตัวบน (Global Prometheus) ดึงข้อมูลจาก Prometheus ตัวล่าง (Local Prometheus) อีกทีครับ เหมาะสำหรับการรวมข้อมูลจากหลายๆ Data Center หรือหลายๆ Cluster เข้ามาไว้ในที่เดียว

  • Using Kubernetes Operator:

    หากใช้ Kubernetes สามารถใช้ Prometheus Operator ซึ่งจะช่วยจัดการ Deployment, Scaling และ HA ของ Prometheus และ Alertmanager ได้อย่างอัตโนมัติและมีประสิทธิภาพครับ

Long-term Storage สำหรับข้อมูลปริมาณมหาศาล

Prometheus Server ถูกออกแบบมาเพื่อเก็บข้อมูลระยะสั้นครับ (โดยทั่วไป 15 วันถึง 1 ปี) สำหรับข้อมูลระยะยาว จำเป็นต้องใช้โซลูชันภายนอกครับ

  • Thanos:

    เป็นโซลูชันยอดนิยมที่ช่วยให้ Prometheus มี Long-term Storage, HA และ Global Query View ครับ Thanos จะเก็บข้อมูล Prometheus ลงใน Object Storage (เช่น S3, GCS) และสามารถ Query ข้อมูลจาก Prometheus หลายๆ Instance ได้พร้อมกันครับ

  • Cortex:

    เป็นอีกหนึ่งโซลูชัน Long-term Storage และ HA ที่ออกแบบมาสำหรับ Multitenancy และ Scalability สูงครับ เหมาะสำหรับ Service Provider ที่ต้องการ Monitoring ลูกค้าหลายราย

  • M3DB:

    ฐานข้อมูล Time-series ที่พัฒนาโดย Uber ออกแบบมาเพื่อประสิทธิภาพสูงและ HA เหมาะสำหรับ Workload ที่มีปริมาณ Metric มหาศาล

Service Discovery: ค้นพบ Target โดยอัตโนมัติ

ในสภาพแวดล้อม Dynamic เช่น Cloud หรือ Kubernetes ที่ Server หรือ Service เกิดและดับไปอย่างรวดเร็ว การกำหนด Target ใน prometheus.yml ด้วยมือเป็นเรื่องที่ไม่สามารถทำได้จริงครับ Prometheus มีกลไก Service Discovery ที่หลากหลายเพื่อแก้ปัญหานี้ครับ

  • Kubernetes Service Discovery:

    Prometheus สามารถค้นพบ Pod, Service, Ingress หรือ Endpoint ใน Kubernetes ได้โดยตรงครับ

  • Consul Service Discovery:

    ใช้ Consul เป็นแหล่งข้อมูลสำหรับ Target ครับ เหมาะสำหรับ Microservices ที่ใช้ Consul สำหรับ Service Registry

  • AWS EC2 / GCP Compute Engine Discovery:

    ค้นพบ Instance บน Cloud Provider ต่างๆ โดยอัตโนมัติ

  • File-based Service Discovery:

    ให้ Prometheus อ่านไฟล์ JSON หรือ YAML ที่มีรายการ Target ครับ เหมาะสำหรับกรณีที่ต้องการสร้าง Script ค้นหา Target เอง

การใช้ Service Discovery ช่วยลดภาระในการบริหารจัดการคอนฟิกของ Prometheus ได้อย่างมหาศาลครับ

Security Best Practices

การรักษาความปลอดภัยของระบบ Monitoring ก็เป็นสิ่งสำคัญครับ

Related Articles
จัดส่งรวดเร็วส่งด่วนทั่วประเทศ
รับประกันสินค้าเคลมง่าย มีใบรับประกัน
ผ่อนชำระได้บัตรเครดิต 0% สูงสุด 10 เดือน
สะสมแต้ม รับส่วนลดส่วนลดและคะแนนสะสม

ติดต่อเรา | LINE: @siamlancard

Facebook | YouTube | LINE OA

เว็บในเครือ: SiamCafe.net | iCafeForex.com | Siam2R.com | XMSignal.com

© 2026 SiamLancard — จำหน่ายการ์ดแลน อุปกรณ์ Server และเครื่องพิมพ์ใบเสร็จ

SiamLancard
Logo
Free Forex EA Download — XM Signal · EA Forex ฟรี
iCafeForex.com - สอนเทรด Forex | SiamCafe.net
Shopping cart