ระบบนิเวศ OpenTelemetry ยังคงก่อให้เกิดการอภิปรายอย่างดุเดือดในหมู่นักพัฒนา โดยหลายคนตั้งคำถามว่าความซับซ้อนที่เพิ่มขึ้นนั้นคุ้มค่ากับประโยชน์ที่ได้รับสำหรับโปรเจกต์ขนาดเล็กหรือไม่ แม้ว่า OpenTelemetry Collector จะสัญญาว่าจะให้การจัดการ telemetry แบบรวมศูนย์และการปรับปรุงต้นทุน แต่ข้อเสนอแนะจากชุมชนเผยให้เห็นความแตกแยกที่เพิ่มขึ้นระหว่างการนำไปใช้ในองค์กรและความหงุดหงิดของนักพัฒนา
ประสิทธิภาพและความมีประสิทธิภาพของทรัพยากรทำให้ผู้ใช้ประหลาดใจ
แม้จะมีความกังวลเบื้องต้นเกี่ยวกับการเพิ่มคอมโพเนนต์อีกตัวหนึ่งเข้าไปใน stack แต่ข้อมูลการใช้งานจริงแสดงให้เห็นว่า OpenTelemetry Collector มีน้ำหนักเบาอย่างน่าประหลาดใจ นักพัฒนาหลายคนรายงานว่าการใช้หน่วยความจำอยู่ต่ำกว่า 50MB แม้ในขณะที่ประมวลผล trace ปริมาณมาก ประสิทธิภาพนี้ทำให้ทีมบางทีมนำมาใช้เป็นค่าเริ่มต้น โดยเฉพาะเมื่อใช้บริการ metrics บนคลาวด์ที่ collector ช่วยปรับปรุงการกระจายข้อมูลที่อาจดูผิดปกติ
ความง่ายในการ deploy ผ่าน sidecars ในสภาพแวดล้อม container สมัยใหม่ยังช่วยลดความกังวลเรื่องค่าใช้จ่ายในการดำเนินงาน อย่างไรก็ตาม คุณภาพของเอกสารยังคงเป็นจุดเจ็บปวดที่ต่อเนื่อง โดยนักพัฒนามักต้องพึ่งพาการกำหนดค่าที่ชุมชนแบ่งปันมากกว่าคำแนะนำอย่างเป็นทางการ
การใช้ทรัพยากรของ OpenTelemetry Collector
- การใช้หน่วยความจำ: ต่ำกว่า 50MB สำหรับงานทั่วไป
- ความสามารถด้านประสิทธิภาพ: มากกว่า 1 ล้านเหตุการณ์ต่อวินาที (เมตริกและการติดตาม)
- วิธีการติดตั้ง: คอนเทนเนอร์ Sidecar ในแพลตฟอร์มการจัดการสมัยใหม่
เครื่องมือทางเลือกท้าทาย OpenTelemetry ในการครองตลาด
การถกเถียงเรื่องความซับซ้อนได้เปิดประตูสำหรับแนวทางและเครื่องมือทางเลือก นักพัฒนาบางคนกำลังสำรวจการเก็บรวบรวม metrics แบบ log-based สำหรับโปรเจกต์ขนาดเล็ก แม้จะมีคำเตือนจากอุตสาหกรรมเกี่ยวกับแนวทางนี้ คนอื่นๆ กำลังประเมิน Vector เป็นทางเลือกแทน OpenTelemetry agent โดยเฉพาะสำหรับการประมวลผล log ที่ประสิทธิภาพที่ผ่านการทดสอบมาแล้วของ Vector ให้ความได้เปรียบเหนือความสามารถ log ที่ใหม่กว่าของ OpenTelemetry
สำหรับการรับข้อมูล metric และ trace ขนาดใหญ่ OpenTelemetry collector แสดงประสิทธิภาพที่แข็งแกร่ง สามารถจัดการเหตุการณ์หลายล้านครั้งต่อวินาที อย่างไรก็ตาม การเลือกเครื่องมือขึ้นอยู่กับประเภทข้อมูลและกรณีการใช้งานเฉพาะมากขึ้น มากกว่าแนวทางแบบครอบคลุมทุกอย่าง
การเปรียบเทียบ Direct Export กับ Collector
| ด้าน | Direct Export | Collector-Based |
|---|---|---|
| ความเร็วในการติดตั้ง | เร็ว | ปานกลาง |
| การควบคุม Policy | แยกตามแต่ละ service | รวมศูนย์ |
| การปรับ Cost ให้เหมาะสม | ยาก | ง่าย |
| การย้าย Vendor | เจ็บปวด | เปลี่ยน config ง่ายๆ |
| แนะนำสำหรับ | แอปเล็กๆ/POCs | Production/หลาย service |
โซลูชัน Observability แบบ Self-Hosted ได้รับแรงผลักดัน
การอภิปรายนี้เน้นย้ำถึงความสนใจที่เพิ่มขึ้นในแพลตฟอร์ม observability แบบ self-hosted ที่เสนอการ query ข้อมูล telemetry แบบ SQL โซลูชันอย่าง HyperDX, SigNoz และ OpenObserve กำลังดึงดูดนักพัฒนาที่ต้องการการเข้าถึงฐานข้อมูลโดยตรงโดยไม่ติดกับผู้ให้บริการ HyperDX ดูเหมือนจะได้รับความนิยมมากกว่า SigNoz โดยผู้ใช้อ้างถึงคุณภาพการสร้างที่ดีกว่าและเครื่องมือแปลง log ที่เชื่อถือได้มากกว่า
ผมลองทั้งสองแล้ว Signoz สร้างมาอย่างหละหลวมมาก... HyperDX ดีกว่ามาก แน่นอนว่ามีข้อบกพร่องเล็กน้อยบ้าง แต่พวกเขาทำทุกสิ่งที่สำคัญได้ถูกต้อง
แพลตฟอร์มเหล่านี้ดึงดูดทีมที่แสวงหาความเรียบง่ายของการเขียน SQL queries กับข้อมูล telemetry ในขณะที่ยังคงการควบคุมโครงสร้างพื้นฐาน observability ของตนเอง
แพลตฟอร์ม Observability แบบ Self-Hosted ยอดนิยม
- HyperDX: การ query แบบ SQL, backend ใช้ ClickHouse, คุณภาพการ build ดี
- SigNoz: โอเพนซอร์ส แต่มีรายงานปัญหาเรื่องคุณภาพการ build
- OpenObserve: รวม logs/metrics/traces ไว้ในที่เดียว ไม่ต้องพึ่งพา dependencies
- GreptimeDB: ฐานข้มูล time-series ที่มีการรวมเข้ากับ OTEL collector
การตัดสินใจด้านสถาปัตยกรรมสะท้อนขนาดของโปรเจกต์
ฉันทามติของชุมชนแนะนำว่าการตัดสินใจด้านสถาปัตยกรรมควรสอดคล้องกับขนาดและความต้องการของโปรเจกต์ สำหรับบริการเดียวที่มีการเข้าชมต่ำ การส่งออกโดยตรงไปยัง backends ยังคงเป็นไปได้ อย่างไรก็ตาม สภาพแวดล้อมหลายบริการในการผลิตได้ประโยชน์อย่างมากจากการสุ่มตัวอย่างแบบรวมศูนย์ การควบคุมต้นทุน และขอบเขตความปลอดภัยของ collector
ข้อมูลเชิงลึกสำคัญที่เกิดขึ้นจากการอภิปรายเหล่านี้คือความสำคัญของการออกแบบแอปพลิเคชันโดยคำนึงถึงความยืดหยุ่น ทีมที่จัดโครงสร้างการส่งออก telemetry ผ่านตัวแปรสภาพแวดล้อมสามารถเปลี่ยนจากการส่งออกโดยตรงไปยังสถาปัตยกรรมแบบ collector ได้อย่างง่ายดายเมื่อความต้องการของพวกเขาพัฒนา หลีกเลี่ยงการปรับปรุงโค้ดที่เจ็บปวดซึ่งมาพร้อมกับการนำไปใช้แบบเชื่อมโยงแน่น
อ้างอิง: OpenTelemetry Collector: What It Is, When You Need It, and When You Don't