ในฐานะ SRE ผมมีหน้าที่ดูแลให้ระบบ Monitoring ที่เราใช้งานสามารถทำงานได้อย่างแม่นยำและเชื่อถือได้ แต่ระหว่างที่ผมกำลังออกแบบระบบ Monitoring สำหรับ MySQL บน Azure ผมพบกับปัญหา Azure API Rate Limits ซึ่งเป็นข้อจำกัดในการเรียก API ของ Azure ส่งผลให้บางครั้งการดึงข้อมูล Metrics ไม่สม่ำเสมอ วันนี้ผมอยากมาแชร์ประสบการณ์และแนวทางที่ผมใช้ Grafana Alloy ร่วมกับ Azure Exporter เพื่อออกแบบระบบ Monitoring ที่สามารถใช้งานได้จริง มีประสิทธิภาพ และลดผลกระทบจากข้อจำกัดของ Azure API ครับ
Azure API Rate Limits
Project ที่ผมดูแลมี MySQL Instances บน Azure มากกว่า 20 ตัว และแต่ละตัวต้องการ Monitoring ในหลายๆ Metric เช่น
- CPU Utilization
- Memory Usage
- Disk Space
- Query Performance
- Connection Count
ตอนแรกผมเลือกใช้ Grafana Azure Monitor เป็น datasource สำหรับทำ Alerting เพราะดูสะดวก ตรงไปตรงมา และสามารถใช้งานได้เลย แต่พอใช้งานจริงกลับเจอปัญหาที่สำคัญคือ ไม่สามารถใช้ Regex ในการ query instance ใน Alert Rules ได้ พูดง่ายๆ ก็คือ ผมไม่สามารถสร้าง Alert rules ที่ query ทุก Instance ใน alert rule อันเดียวได้ ทำให้ต้องสร้าง Alert Rules ทีละตัว เช่น
- 1 Alert Rule สำหรับ mysql-a memory utilization warning
- 1 Alert Rule สำหรับ mysql-a memory utilization critical
- 1 Alert Rule สำหรับ mysql-a cpu utilization warning
- 1 Alert Rule สำหรับ mysql-a cpu utilization critical
- 1 Alert Rule สำหรับ mysql-b memory utilization warning
เมื่อเอาจำนวน MySQL Instances ที่มีมากกว่า 20 ตัวมาคูณกับ Metrics ที่ต้องดูมากกว่า 10 metrics ต่อ 1 Instance ผมก็ต้องสร้าง Alert Rules กว่า 100 ตัว ซึ่งส่งผลให้เกิดปัญหาหลักๆ ดังนี้
- API Calls ไป Azure Monitor เยอะมาก จนไปชน Rate Limit ของ Azure
- Alerts ใช้งานไม่ได้ เพราะ Grafana ไม่สามารถดึงข้อมูลจาก Azure Monitor ได้เนื่องจากติด Rate Limit
- ภาระงานเพิ่มขึ้นมหาศาล เพราะต้องมานั่งสร้างและจัดการ Alert Rules กว่าร้อยตัว แก้ไขทีก็ต้องไล่แก้ทุกตัว
ปัญหาเหล่านี้บังคับให้ผมต้องมองหาวิธีที่ ชาญฉลาดและมีประสิทธิภาพกว่าเดิม เพื่อให้ระบบ Monitoring ทำงานได้อย่างราบรื่นโดยไม่ต้องเจอปัญหา Rate Limits ซ้ำๆ ครับ
Grafana Alloy คืออะไร
Grafana Alloy เป็นเครื่องมือ opensource ที่ออกแบบมาเพื่อช่วยให้การทำ observability ง่ายขึ้น โดยสามารถรวบรวมข้อมูลจากหลายแหล่ง เช่น metrics, logs, traces และ profiles ให้อยู่ในแพลตฟอร์มเดียว รองรับทั้ง OpenTelemetry และ Prometheus ซึ่งทำให้มันเป็นตัวเลือกที่เหมาะกับระบบที่มีความซับซ้อนสูง เช่น ระบบคลาวด์ยุคใหม่ครับ
พูดง่ายๆ ก็คือ Grafana Alloy ทำหน้าที่เป็น ศูนย์กลางจัดการข้อมูล monitoring ที่ช่วยให้ผมสามารถดึงและจัดการข้อมูลจากหลายที่ได้อย่างยืดหยุ่น โดยไม่ต้องเรียก API ตรงๆ จากระบบปลายทางบ่อยๆ ครับ
วิธีแก้: ใช้ Grafana Alloy กับ Azure Exporter
หลังจากลองหาทางออกหลายแบบ ผมพบว่าการเปลี่ยนมาใช้ Architecture ที่สามารถจัดการกับ Azure API Rate Limits ได้ดีกว่าเป็นทางออกที่เหมาะสม โดยใช้เครื่องมือหลัก 3 ตัวดังนี้
- Azure Exporter – เป็น Exporter ขนาดเล็กที่ดึง Metrics จาก Azure Monitor API
- Grafana Alloy – ทำหน้าที่เป็น Metrics Gateway คอย Transform และ Route ข้อมูลจาก Exporter ไปยังระบบปลายทาง
- Grafana Mimir – ใช้เป็น Scalable Metrics Storage Backend สำหรับเก็บข้อมูลระยะยาว
ขั้นตอนการ Implement
ในการเปลี่ยนมาใช้ Grafana Alloy + Azure Exporter ผมได้ทำตามขั้นตอนหลักๆ ดังนี้ครับ
- ติดตั้ง Grafana Alloy กับ Azure Exporterติดตั้งผ่าน Helm (แนะนำสำหรับ Kubernetes Users)
หากรันบน Kubernetes สามารถติดตั้งผ่าน Helm ได้ง่ายๆ แบบนี้
จากนั้นให้ Config Grafana Alloy ด้วย Module Azure Exporter ให้ดึง Metrics จาก Azure API
- เชื่อมต่อ Grafana Alloy กับ Mimir
ให้เพิ่ม Config ใน Grafana Alloy เพื่อส่ง Metrics ไปยัง Mimir
เมื่อเชื่อมต่อสำเร็จ Metrics ทั้งหมดจะถูกเก็บไว้ใน Mimir ทำให้ผมสามารถ Query ผ่าน Grafana ได้โดยไม่ต้องกังวลเรื่อง Rate Limits ครับ - สร้าง Alert Rules ใหม่ให้ยืดหยุ่นขึ้น
ตอนแรกที่ต้องสร้าง Alert Rule ทีละตัวสำหรับแต่ละ Instance แต่เมื่อเปลี่ยนมาใช้ Alloy + Mimir + Regex-Based Rules ผมก็สามารถลดจำนวน Rules ลงได้เยอะ
ตัวอย่างเดิม (Alert Rule แบบเก่า)
ต้องสร้างหลาย Rule เช่นmysql-a memory utilization warningmysql-a memory utilization criticalmysql-b memory utilization warning
ตอนนี้ผมสามารถใช้ Regex Pattern แทน เช่นcpu_usage{resource=~"mysql-.+"} > 80Rule นี้สามารถ Monitor CPU Usage ของ MySQL ทุกตัว ได้ในคราวเดียว ไม่ต้องสร้าง Alert ทีละตัวอีกต่อไป
ผลลัพธ์: ระบบ Monitoring ที่มีประสิทธิภาพมากขึ้น
หลังจากเปลี่ยนไปใช้แนวทางใหม่นี้ ผมได้เห็นผลลัพธ์ที่ดีขึ้นอย่างชัดเจน
- ลดจำนวน API Calls ไปที่ Azure Monitor ได้มากกว่า ~85% Azure Exporter จะเป็นตัวกลางที่ดึงข้อมูลจาก Azure Monitor แค่ครั้งเดียว แล้วส่งให้ Grafana Alloy ทำการกระจายข้อมูลไปยังระบบต่างๆ แทน
- เพิ่มความยืดหยุ่นในการจัดการ Alerting จากเดิมที่มี หลายร้อย Alert Rules ตอนนี้เหลือแค่ ไม่กี่ตัว ตัวอย่างเช่น
- 1 Rule สำหรับ Memory Alerts ของทุก Instance
- 1 Rule สำหรับ CPU Alerts ของทุก Instance
- รองรับการขยายตัวของระบบในอนาคต เพิ่ม MySQL Instances ใหม่โดย ไม่ต้องแก้ไข Alert Configuration เลย
- ลดปัญหา API Rate Limit ทำให้ Monitoring มี ความเสถียร และแม่นยำมากขึ้น
- Performance ดีขึ้น ลด Latency ของระบบ Alerting ทำให้แจ้งเตือนได้เร็วขึ้น
บทเรียนที่เราได้เรียนรู้
ต้องคำนึงถึง API Rate Limits ตั้งแต่แรก
- Azure มีข้อจำกัดเรื่อง API Calls ดังนั้นต้องออกแบบระบบ Monitoring ให้รองรับข้อจำกัดนี้
Grafana Alloy คือพระเอกของงานนี้
- ทำหน้าที่เป็น Transformation Layer ระหว่าง Azure กับ Alerting System
- ลดการเรียก API ซ้ำๆ โดยใช้ข้อมูลที่ Export มาแล้ว
Regex Patterns ช่วยลดจำนวน Alert Rules ได้มาก
- การใช้
cpu_usage{resource=~"mysql-.+"}ช่วยให้ตั้ง Alert Rule เดียวสำหรับ MySQL ทุกตัวแทนการสร้างเป็นร้อยๆ Rules
สรุป
หลังจากเปลี่ยนแนวทางไปใช้ Grafana Alloy กับ Azure Exporter ผมไม่เจอปัญหา API Rate Limit อีกต่อไป และยังมี Headroom เหลือเฟือ แม้ว่าเราจะเพิ่ม MySQL Instances ขึ้นเรื่อยๆ
หวังว่าบทความนี้จะช่วยให้คุณออกแบบระบบ Monitoring ได้มีประสิทธิภาพขึ้น และหลีกเลี่ยงปัญหา Rate Limit ได้ตั้งแต่เนิ่นๆ
ท้ายนี้หากองค์กรท่านกำลังมองหาโซลูชันด้าน DevOps ช่วยปรับรูปแบบการทำงานให้เป็นอัตโนมัติ ลดต้นทุนการทำธุรกิจ SCB TechX พร้อมเป็นโซลูชันที่ช่วยพัฒนา และ Deliver ผลิตภัณฑ์และบริการออกสู่ตลาด ต่อยอดองค์กรของท่านให้เติบโตอย่างยั่งยืน
สนใจบริการโปรดติดต่อเราที่ https://forms.office.com/r/P14E9tNGFD
