Prometheus รุ่นมาตรฐานถูกออกแบบให้ทำงานเป็น single node — เรียบง่าย เสถียร และดูแลง่าย แต่เมื่อระบบเริ่มใหญ่ขึ้น ทีมงานต้องการความพร้อมใช้งานระดับสูงเผื่อเซิร์ฟเวอร์ล่ม หรือมี monitoring หลาย data center ที่ต้องรวมข้อมูลขึ้นสู่ศูนย์กลาง ระบบนี้จึงมีแนวทาง High Availability (HA) และ Federation ให้เลือกใช้ตามรูปแบบองค์กร บทความนี้จะเปรียบเทียบวิธี พร้อมอธิบายการตั้ง multi-instance แบบ active-active, การใช้ Alertmanager ในโหมด clustered, และโครงสร้าง hierarchical federation ที่ใช้ได้จริง

ทำไมต้องมี HA

ปัญหาคลาสสิกของ single-instance Prometheus คือเมื่อเซิร์ฟเวอร์หยุดทำงาน หรือต้อง restart เพื่ออัพเกรด ระบบจะไม่มีข้อมูลใหม่ไหลเข้ามาและ alert จะเงียบสนิทเวลาที่ล่ม — นั่นคือเวลาที่ alert จำเป็นที่สุด HA ถูกออกแบบเพื่อแก้ปัญหานี้ด้วยการรันหลาย instance พร้อมกัน scrape จากเป้าหมายเดียวกัน ถ้าเครื่องหนึ่งล่ม อีกเครื่องยังทำงานต่อ ไม่มีช่วง blind spot

ข้อดีอีกข้อคือสามารถ rolling upgrade ได้ — ดึงเครื่องเดิมออกมา upgrade แล้วกลับเข้าระบบทีละเครื่องโดย alert ไม่หาย ส่วน Federation ตอบโจทย์ต่างกัน — ใช้เมื่อต้องรวมข้อมูลจาก server หลายชุดในหลาย site หรือ team ขึ้นมาสู่เครื่องศูนย์กลางเพื่อทำ Dashboard ภาพรวม

Multi-instance HA: รันหลายตัวคู่กัน

วิธีง่ายสุดคือรัน 2 instance ที่มี config เหมือนกัน ชี้ไปยัง target เดียวกัน เก็บข้อมูลในเครื่องของตัวเอง (ไม่ต้อง sync) ทั้งสองเครื่องจะ scrape และประมวลผล rule อิสระจากกัน

# prometheus-01.yml และ prometheus-02.yml
global:
  scrape_interval: 15s
  external_labels:
    replica: "01"   # ตัวที่สองใส่ replica: "02"
    cluster: "prod-th"

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node1:9100', 'node2:9100']

จุดสำคัญคือ external_labels ที่แยก replica ระหว่างเครื่อง — ใช้ label นี้ในการ deduplicate ข้อมูลในฝั่ง client หรือ Thanos/Mimir ภายหลัง ถ้าไม่ตั้ง external_labels จะไม่สามารถแยกได้ว่าข้อมูลมาจาก replica ไหน

Load Balancer หน้าเซิร์ฟเวอร์

เพื่อให้ Grafana ไม่ต้องรู้ว่ามี replica กี่ตัว นิยมวาง Load Balancer (HAProxy, Nginx, หรือ Kubernetes Service) ไว้หน้า cluster ทั้งชุด ถ้าตัวหนึ่ง down ตัว LB จะส่ง query ไปอีกตัวโดยอัตโนมัติ

# ตัวอย่าง config HAProxy
frontend prometheus_front
    bind *:9090
    default_backend prometheus_back

backend prometheus_back
    balance roundrobin
    option httpchk GET /-/ready
    server prom01 10.0.1.10:9090 check
    server prom02 10.0.1.11:9090 check

ข้อจำกัดของวิธีนี้คือเมื่อ query ทั้งสองเครื่อง ข้อมูลอาจต่างกันเล็กน้อย (ต่างกันแค่ scrape ไม่พร้อมกัน) — Grafana จะเห็น graph กระเพื่อมบ้างเมื่อสลับ backend ถ้าต้องการ deduplicate เต็มรูปแบบ ให้พิจารณา Thanos Query หรือ Cortex/Mimir เป็นชั้นบน

Alertmanager Cluster สำหรับ Alert

HA ฝั่ง alert สำคัญไม่แพ้ HA ของตัว scraper — ถ้า Alertmanager ตายคนเดียว alert จะไม่มีทางออก Alertmanager รองรับโหมด cluster ด้วย gossip protocol (ใช้ Memberlist) ทำให้ทั้งสอง replica ส่ง alert ไปทั้งชุด alertmanager แต่ผู้ใช้ปลายทางจะได้รับ alert เพียงครั้งเดียวต่อเหตุการณ์

# Alertmanager 1
alertmanager --cluster.listen-address=0.0.0.0:9094 \
             --cluster.peer=10.0.1.20:9094 \
             --cluster.peer=10.0.1.21:9094

# Alertmanager 2 (config เหมือนกัน เปลี่ยน IP)
alertmanager --cluster.listen-address=0.0.0.0:9094 \
             --cluster.peer=10.0.1.20:9094 \
             --cluster.peer=10.0.1.21:9094

ฝั่ง scrape ต้องใส่ Alertmanager ทั้งชุดในฟิลด์ alerting.alertmanagers เพื่อให้ส่ง alert ออกขนานกัน การ deduplicate จะเกิดใน Alertmanager cluster ผ่าน gossip

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager-01:9093'
            - 'alertmanager-02:9093'

Federation คืออะไร

Federation คือการให้ monitoring server เครื่องหนึ่ง scrape “เมตริกที่สรุปแล้ว” จาก server อีกเครื่องผ่าน endpoint /federate ส่วนใหญ่ใช้เพื่อรวมข้อมูลจากหลาย instance ระดับล่าง (per-data-center หรือ per-team) ขึ้นสู่ Prometheus ระดับบน (global) เพื่อให้ Dashboard ภาพรวมเข้าถึงข้อมูลได้จากจุดเดียว

สิ่งสำคัญที่ต้องเข้าใจคือ Federation ไม่ได้ออกแบบให้ดึงทุก metric จากเครื่องล่าง แต่ดึงเฉพาะเมตริกที่ pre-compute ด้วย recording rule แล้วให้ชั้นบนอ่าน — ช่วยลด cardinality และ bandwidth

Hierarchical Federation: รูปแบบที่นิยม

• ระดับล่าง (edge): instance ใน data center แต่ละแห่ง scrape infrastructure ในพื้นที่
• ระดับกลาง: instance ต่อ cluster หรือ service group รวมข้อมูลจาก edge มา aggregate
• ระดับบน (global): server ส่วนกลางที่ดึงเฉพาะเมตริกสรุประดับ cluster/service ขึ้นมา

โครงสร้างสามชั้นแบบนี้ช่วยให้ข้อมูลรายละเอียดอยู่ใกล้แหล่งกำเนิด ไม่ต้อง sync ทั้งหมด — Dashboard ผู้บริหารอ่านจาก global, ทีมเทคนิคใน data center อ่านจาก edge โดยตรง

ตัวอย่าง Config Federation

scrape_configs:
  - job_name: 'federate'
    scrape_interval: 30s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="node"}'
        - '{__name__=~"job:.*"}'   # recording rule อย่างเดียว
    static_configs:
      - targets:
          - 'prometheus-dc1:9090'
          - 'prometheus-dc2:9090'
          - 'prometheus-dc3:9090'

ประเด็นสำคัญคือ honor_labels: true เพื่อให้เซิร์ฟเวอร์ชั้นบนเคารพ label ที่มาพร้อมเมตริก (เช่น replica, cluster, dc) ไม่ใช่ถูก overwrite และ match[] ควรกรองเฉพาะเมตริกที่จำเป็นจริง ๆ เพื่อไม่ให้ bandwidth และ TSDB พองเกินจำเป็น

ข้อจำกัดและสิ่งที่ Federation ไม่ใช่

• ไม่ใช่ long-term storage — หาก server เครื่องล่างลบข้อมูลเก่า เครื่องบนจะไม่มีทาง backfill
• ไม่ใช่การสำรองข้อมูล — ข้อมูลเดิมยังอยู่เฉพาะที่เครื่องล่าง
• ไม่เหมาะกับการดึงเมตริก raw ทุกตัว — จะเจอ cardinality ระเบิดและ bandwidth เกิน
• ไม่แทนที่ Thanos/Mimir — โครงการเหล่านี้ออกแบบมาเพื่อ global view เต็มรูปแบบ

เปรียบเทียบ HA vs Federation vs Thanos/Mimir

ความต้องการ	วิธีที่เหมาะ
Monitoring server ตัวเดียวไม่ล่ม	Multi-instance HA + LB
Alert ไม่เงียบ	Alertmanager Cluster
Dashboard ภาพรวมจากหลาย site	Hierarchical Federation
Global deduplication เต็มรูปแบบ + long-term	Thanos หรือ Mimir
Multi-tenancy พร้อม isolation	Mimir (Cortex)

แนวทางที่ใช้จริงในองค์กรไทย

องค์กรที่มี monitoring stack เพียง cluster เดียวและเริ่มต้นสนใจ HA ให้เริ่มจากรัน 2 instance ใน zone คนละ zone พร้อม LB หน้า และ Alertmanager Cluster 3 ตัว (เลขคี่เพื่อหลีกเลี่ยง split-brain) — ครอบคลุมเคสเครื่อง crash, network partition, หรือ rolling upgrade ได้โดยไม่ต้องใช้ component เพิ่ม

องค์กรที่มี data center หลายแห่งหรือต้อง serve dashboard ทั่วองค์กรควรผูก Federation เฉพาะกับ recording rule สรุปแทน raw metric — จำกัด cardinality ที่ชั้นบนและให้ทีมใน site ใช้เครื่อง monitoring ของตัวเองสำหรับ troubleshoot เชิงลึก

เมื่อทีมขยายใหญ่จนต้องการ multi-tenancy, retention นาน, และ global query ที่ deduplicate ได้ทันที จึงขยับไปใช้ Thanos (เสริมบนระบบเดิม) หรือ Mimir (replace ด้วย cluster ใหม่) — เป็นขั้นต่อไปของเส้นทาง scaling

สรุป

HA กับ Federation เป็นสองเครื่องมือที่ตอบโจทย์ต่างกัน HA ทำให้ระบบไม่เงียบเวลาเครื่องตัวเดียวล่ม ส่วน Federation รวมข้อมูลจากหลายเครื่องขึ้นมาให้ Dashboard กลางใช้ — องค์กรส่วนใหญ่จะเริ่มด้วย HA ก่อน แล้วค่อยเพิ่ม Federation เมื่อต้องการมุมมองข้ามทีม สิ่งที่ไม่ควรลืมคือ Alertmanager ก็ต้องทำ cluster ไปพร้อมกัน ไม่เช่นนั้น alert ยังมี single point of failure แม้ monitoring server จะ redundant แล้ว

เมื่อโต enough จนมีหลาย region และต้อง store metric เป็นปี ให้พิจารณา Thanos หรือ Mimir — ทั้งสองช่วยให้ระบบกลายเป็น long-term, globally queryable store ในระดับ enterprise