- ชุดผลิตภัณฑ์ Grafana มีแนวโน้ม ยกเลิกหรือเปลี่ยนองค์ประกอบหลักบ่อยในรอบเวลาสั้น ๆ ทำให้โครงสร้างไม่เอื้อต่อการใช้งานระยะยาว
- ทุกครั้งที่นำโซลูชันใหม่มาใช้ วิธีคอนฟิก, DSL, Helm chart, Operator ฯลฯ จะเปลี่ยนซ้ำไปมา จนกลายเป็นสภาพแวดล้อมที่ดูแลรักษาอย่างเสถียรได้ยาก
- เมื่อเทียบกับระบบนิเวศของ Prometheus Operator ยังมี ความเข้ากันได้ของ CRD ที่ไม่สมบูรณ์ โดย
ServiceMonitor และ PodMonitor ใช้ได้ แต่ฟีเจอร์สำคัญอย่าง AlertmanagerConfig ยังมีช่องว่างด้านการรองรับ
- Mimir 3.0 บังคับเพิ่มการพึ่งพา Apache Kafka ทำให้ความซับซ้อนของคลัสเตอร์และภาระในการดูแลระบบสูงขึ้นมาก
- ทั้ง Grafana Cloud และชุดผลิตภัณฑ์ Mimir·Loki·Grafana โดยรวม ตำแหน่งคอนฟิกและเอนด์พอยต์เปลี่ยนได้ง่าย ทำให้รูปแบบที่สร้างครั้งเดียวแล้วใช้งานยาว ๆ เป็นเรื่องยากซ้ำแล้วซ้ำเล่า
การเปลี่ยนโครงสร้างบ่อยของชุดผลิตภัณฑ์ Grafana
- ฟังก์ชันหลักอย่าง Grafana Agent, Flow Mode, OnCall ถูก ยกเลิกหรือแทนที่ภายใน 1–3 ปี ซ้ำแล้วซ้ำอีก
- Grafana UI ที่อิง Angular ถูกเปลี่ยนเป็น React ทำให้แดชบอร์ดเดิมจำนวนมากใช้งานไม่ได้
- Helm chart บางส่วนไม่ได้รับการบำรุงรักษาอีกต่อไป
ความซับซ้อนที่เพิ่มขึ้นจากการนำ Alloy มาใช้
- Grafana Alloy ที่ชูจุดขายแบบ all-in-one เข้ามาแทน Agent เดิม แต่ในช่วงแรกมีปัญหาด้านเสถียรภาพ
- ใช้ DSL ของตัวเอง (คล้าย HCL) ทำให้ขาดความต่อเนื่องจากกระบวนการเดิมที่อิง YAML
- เมื่อมี Alloy Operator เพิ่มเข้ามา องค์ประกอบของระบบก็ยิ่งซับซ้อนขึ้น
ความสอดคล้องที่ไม่สมบูรณ์กับระบบนิเวศของ Prometheus Operator
- รองรับมาตรฐานมอนิเตอร์ของ K8s อย่าง
ServiceMonitor, PodMonitor แต่
PrometheusRules ต้องมีการตั้งค่าเพิ่มเติมAlertmanagerConfig ยังไม่รองรับ- Mimir ใช้ Alertmanager ของตัวเอง จึงเกิด ความต่างของเวอร์ชันและความไม่เข้ากันในรายละเอียด
การเพิ่มการพึ่งพา Kafka ใน Mimir 3.0
- แม้มุ่งเป้าไปที่การขยายระบบได้ดีกว่าเดิม แต่
- มีการ เพิ่ม Kafka เป็นองค์ประกอบบังคับในส่วนสำคัญ ทำให้ความยากในการปฏิบัติการสูงขึ้นมาก
- จากการติดตั้งด้วย Helm เพียงชุดเดียว → กลายเป็นความซับซ้อนที่เพิ่มแบบทวีคูณจากการประสานหลายคอมโพเนนต์
ระบบนิเวศที่ใช้งานอย่างเสถียรได้ยาก
- ingestion endpoint ของ Grafana Cloud หายากขึ้นเพราะมีการนำระบบจัดการใหม่มาใช้
- รอบการอัปเกรดและยกเลิกขององค์ประกอบหลักเกิดเร็ว จึงไม่เหมาะกับองค์กรที่ต้องการ “ระบบมอนิเตอร์ที่น่าเบื่อแต่เสถียร”
- มากกว่าปัญหาของเทคโนโลยีเอง วิธีบริหารผลิตภัณฑ์และความเร็วในการเปลี่ยนแปลง คือปัจจัยหลักที่บั่นทอนความน่าเชื่อถือ
5 ความคิดเห็น
แดชบอร์ดที่มีมาให้ใน influxdb เองก็พอใช้งานแบบง่าย ๆ ได้เหมือนกัน
ผมเห็นด้วยว่า Grafana ไม่ค่อยดีเท่าไร แต่มีตัวไหนที่พอจะแนะนำได้บ้างไหมที่รองรับหลาย datasource ได้มากพอๆ กับ Grafana?
ก็ไม่ได้มีทางเลือกอื่นที่ชัดเจนเท่าไร
ดูเหมือนว่าแม้แต่ใน Grafana ก็มีคนจำนวนไม่น้อยที่อยากได้เลื่อนตำแหน่งหรือแต่งเรซูเม่ให้ดูดีขึ้นนะ
ความคิดเห็นจาก Hacker News
ฉันเองก็กำลังคิดอย่างจริงจังว่าจะ เลิกใช้ Grafana ไปเลยดีไหม ด้วยเหตุผลเดียวกับผู้เขียน
การต้องมาสร้างแดชบอร์ดใหม่ทุกปี รีเซ็ตการแจ้งเตือน และตามฟีเจอร์ใหม่ให้ทันนั้นทำให้เหนื่อยมาก
ที่จริงอยากให้มันแค่แจ้งตอนที่บริการล่มก็พอ และตราบใดที่ data source หรือ metric ไม่เปลี่ยน ก็อยากคงนิยามแดชบอร์ดเดิมไว้ได้ยาว 10 ปี
เมื่อก่อนในแถบด้านข้างมีลิงก์หลักแค่ 4~5 อัน แต่ตอนนี้มีเมนูย่อยซ้อนในเมนูเยอะเกินไป จนหาฟังก์ชันพื้นฐานอย่างแดชบอร์ดหรือการแจ้งเตือนได้ยาก
การต้องเรียนรู้ UI ใหม่ทุกครั้งสำหรับสิ่งที่เปิดดูแค่เดือนละครั้งนั้นไม่มีประสิทธิภาพเอามาก ๆ
ในสถานการณ์ที่อายุการใช้งานของบริการมีแค่ 2~3 ปี การซ้อนผลิตภัณฑ์หลายตัวเข้าไปให้ความรู้สึกว่า สุดท้ายก็มีแต่ ภูเขาหนี้ทางเทคนิค ที่โตขึ้นเรื่อย ๆ
ความจริงที่ว่าทุกไตรมาสต้องเปลี่ยนอะไรชิ้นใหญ่สักอย่างนั้นช่างทรมาน
Mimir เป็นระบบที่ออกแบบมาเพื่อจัดการ metric ในระดับสเกลที่ต่างออกไปโดยสิ้นเชิง
ในระดับนั้น Kafka จำเป็นจริง
แต่ผู้ใช้ส่วนใหญ่ไม่ได้ต้องการ ความสามารถในการขยายระบบ ระดับนั้น
ถ้าไม่ได้รัน Mimir บน Kubernetes cluster เฉพาะทาง ก็ถือว่าออกแบบเกินความจำเป็น
ใช้ Prometheus ไปตรง ๆ จะสมจริงกว่า
แม้จะรันในโหมด single instance ก็ทำงานได้ดีอย่างน่าทึ่ง และ ขยายระบบได้ง่ายมาก
เคยใช้ทั้งในหลายองค์กรและโปรเจกต์ส่วนตัว และก็พอใจเสมอ
แต่ Amazon Managed Prometheus ของ AWS นั้นสร้างบน Cortex และ OpenObserve เองก็ใช้งานในระดับเพตะไบต์อยู่แล้ว
แบบที่เหมาะที่สุดคือดีพลอยง่ายด้วย single binary รองรับ OpenTelemetry และภายหลังก็ย้ายไปผู้ให้บริการ OTEL รายอื่นได้
ถ้าจะสร้างโซลูชันใหม่บน OTEL อยากรู้ว่าตัวไหนดูมีอนาคตที่สุดในฐานะทางเลือกแทน Prometheus/Grafana
ถ้าจะจัดการ log และ trace ก็ต้องมีคอมโพเนนต์ซับซ้อนเพิ่มอีก
เลยไปเจอ GreptimeDB ซึ่งรองรับ การจัดการ metric·log·trace แบบรวมศูนย์
เก็บข้อมูลด้วย OpenTelemetry และแสดงผลด้วย Grafana
สามารถสร้างแดชบอร์ดด้วย SQL ได้ จึงเข้ากับทักษะของทีมได้ดี
ด้วยโครงสร้างที่เรียบง่ายจึงทำให้พอใจมากในฐานะ platform engineer
มันถูกสร้างมาเพื่อแก้ความซับซ้อนของ Grafana และ Elastic และสามารถจัดการ log·metric·trace·dashboard·alert ได้ทั้งหมดใน single container
(ผู้เขียนความเห็นเป็น maintainer ของ OpenObserve)
เป็นโอเพนซอร์ส กำลังพัฒนาอย่างคึกคัก และการสื่อสารของทีมก็ดี
มีผู้ใช้จำนวนมากย้ายมาเพื่อหลีกเลี่ยงความซับซ้อนของ Grafana ที่ต้องจัดการหลายแบ็กเอนด์ด้วยตัวเอง
(ผู้เขียนความเห็นเป็น maintainer ของ SigNoz)
ไม่เข้าใจว่าทำไมนักพัฒนาต้องเปลี่ยนการตั้งค่าทุกสัปดาห์เพื่อ ไล่ตามเทคโนโลยีใหม่ล่าสุด
ฉันใช้ชุด Grafana + Prometheus มาตั้งแต่ปี 2017 และตอนนี้ก็ยังทำงานได้ดี
อัปเดตเฉพาะเวอร์ชัน LTS ทุก 1~2 ปี
แดชบอร์ดยังสมบูรณ์แบบเหมือนเดิม และไม่มีปัญหาอะไรเลย
สำหรับคนส่วนใหญ่ ชุดนี้ที่ น่าเบื่อแต่เสถียร น่าจะดีที่สุด
อยากถามว่าหรือว่ายังใช้เวอร์ชันเก่าอยู่แบบเดิม
มี ตัวสร้างแดชบอร์ด แบบโอเพนซอร์สที่ใช้แทน Grafana ได้ไหม? ที่บริษัทเราก็ใช้ Grafana กันอย่างกว้างขวาง
หรือจะใช้ Prometheus console template หรือแดชบอร์ดในตัวของ VictoriaMetrics ก็ได้ แต่ความสามารถจะจำกัดกว่ามาก
ตัว Grafana dashboard เองยังใช้งานได้ค่อนข้างสบายเมื่อจับคู่กับ VictoriaMetrics + ClickHouse
จำได้ลาง ๆ แค่ชื่ออย่าง RRD หรือ Nagios
การเปลี่ยนแปลงไม่หยุด ของ Grafana กลับทำให้ชินไปเอง
ทุกครั้งที่มี major release แดชบอร์ดจะพังหรือ UI เปลี่ยน แต่ก็ได้แต่คิดว่าเอาเถอะ
ปัญหาจริงคือ PromQL lock-in ของ Prometheus
ถ้าเปลี่ยนชื่อ metric ก็ต้องแก้กฎ การแจ้งเตือน และแดชบอร์ดทั้งหมด
PromQL แทบไม่แจ้ง error นอกจาก syntax error ดังนั้นจึงต้องใช้เครื่องมืออย่าง pint มาช่วยตรวจสอบ
เวลาดีพลอยบนเซิร์ฟเวอร์เดี่ยว มักใช้ Prometheus Pushgateway + Grafana เป็น docker-compose template
มันง่ายและทำงานได้ดี แต่พอปริมาณ metric โตขึ้น ความซับซ้อนก็ระเบิดตามไปด้วย
ถ้า Prometheus ยังคงมี รูปแบบการส่งข้อมูล ที่มีประสิทธิภาพกว่านี้ ปัญหาแบบนี้คงน้อยลง
ถ้ามี binary metric format ที่ compact แทน text format ก็น่าจะรองรับ label ระดับหลายล้านได้สบายกว่านี้
SigNoz เป็นตัวเลือกที่ดีและกำลังพัฒนาอย่างคึกคัก
เมื่อก่อนเคยจ่ายแพงมากให้กับแพลตฟอร์ม observability บนคลาวด์ แต่ตอนนี้รัน self-hosted SigNoz บนกล่อง Hetzner แล้วจบที่เดือนละ $10
Prometheus และ Grafana ต่างก็พยายามมุ่งไปสู่ full-stack solution และเมื่อ OTEL เข้ามา ภาพรวมก็ยิ่งซับซ้อนขึ้น
OTEL เป็นโปรโตคอลสำหรับ metric·trace·log แต่ไม่มี DB เดียวที่รองรับทั้งหมดนี้
ส่วนใหญ่ยังคงใช้การจับคู่ Prometheus (metric) + OpenSearch (log)
สุดท้ายแล้ว OTEL ก็เหมือนบังคับให้ต้อง เปลี่ยน collector และจัดโครงสร้างใหม่