แนวคิดของ Observability และกระบวนการพัฒนาของเครื่องมือ

• แนวคิดของ Observability:

  • ตัวชี้วัดที่บอกว่าสามารถอนุมานสถานะภายในของระบบได้ดีเพียงใดจากผลลัพธ์ที่ระบบส่งออกภายนอก (ความรู้)
  • ระบบแบบไดนามิกที่ออกแบบมาให้ประเมินสถานะของระบบจากการวัดค่าผลลัพธ์
  • เมื่อสภาพแวดล้อมคลาวด์แพร่หลาย และแอปที่ทำงานแบบ Dockerized กับสถาปัตยกรรมไมโครเซอร์วิสกลายเป็นเรื่องทั่วไป จึงยิ่งจำเป็นต้องมี Observability

• ความแตกต่างระหว่าง Observability กับ Monitoring:

  • Monitoring: สิ่งที่ผู้ใช้ทำ แสดงให้เห็นว่าอะไรผิดปกติ
  • Observability: แนวคิดที่ครอบคลุม Monitoring ไว้ด้วย ให้ข้อมูลบริบทของการทำงานภายในอย่างครบถ้วน และช่วยแก้ปัญหาระบบเชิงลึก แสดงได้ถึงขั้นว่าอะไรผิด และ ‘ทำไม’ จึงผิด

• สถานการณ์ที่องค์กรต้องการ Observability:

  • เมื่อเกิดปัญหาในโปรดักชันแล้วมีคำถามว่า ‘ข้อมูลที่ใช้หาสาเหตุของปัญหาคืออะไร อยู่ที่ไหน และควรดูข้อมูลนั้นอย่างไร?’
  • เมื่อบริการที่ยังปกติดีเมื่อ 1 นาทีก่อนเกิดปัญหาขึ้น และต้องเผชิญกับคำถามว่า ‘ควรเริ่มหาต้นตอของปัญหาจากตรงไหน?’
  • เมื่อองค์กรกำลังคิดว่า ‘จะทำอย่างไรให้ทีมพัฒนารู้ถึงอาการผิดปกติของบริการได้ก่อนลูกค้าหรือทีมซัพพอร์ต/ปฏิบัติการ?’
  • เมื่อต้องการวิธีติดตามข้อผิดพลาดของบริการหรือปัญหาด้านประสิทธิภาพในไมโครเซอร์วิสอย่างมีประสิทธิภาพ หรือสงสัยว่า ‘จะตรวจสอบสิ่งเหล่านี้ในรูปแบบของล็อกหรือ Application Performance Monitoring (APM) ได้หรือไม่’

• กระบวนการพัฒนาของเครื่องมือ Observability:

  • ตั้งแต่ช่วงทศวรรษ 2010 เป็นต้นมา มีเครื่องมือ Observability หลากหลายออกมาในอุตสาหกรรม IT
  • ในปี 2010 Google เปิดตัวโครงสร้างพื้นฐานการติดตามระบบแบบกระจายขนาดใหญ่ชื่อ ‘Dapper’
  • หลังจากนั้น Uber และ Twitter ได้สร้างระบบ distributed tracing ของตนเองคือ ‘Jaeger’ (Uber) และ ‘Zipkin’ (Twitter) ตามลำดับ
  • ต่อมามี ‘Open Tracing’ ซึ่งเป็นชุด API มาตรฐานสำหรับทำโมเดลและอธิบายการทำงานของระบบแบบกระจายอย่างต่อเนื่อง
  • มีการเปิดเผย ‘Open Census’: ชุดไลบรารีสำหรับหลายภาษา ที่เก็บรวบรวม application metrics และ distributed tracing แล้วส่งข้อมูลไปยังแบ็กเอนด์แบบเรียลไทม์
  • จากนั้น ‘Prometheus’ ก็ปรากฏขึ้น
  • ในปี 2019 มีการเปิดตัวชุดเครื่องมือ, API และ SDK ชื่อ ‘Open Telemetry (OTel)’ ซึ่งรวม Open Tracing และ Open Census เข้าด้วยกัน

• Open Telemetry:

  • เฟรมเวิร์ก Observability แบบโอเพนซอร์สที่เป็นกลางทางผู้ให้บริการ
  • ข้อมูล telemetry ที่ช่วยวิเคราะห์ประสิทธิภาพและการทำงานของซอฟต์แวร์ประกอบด้วย logs, metrics และ traces โดย Open Telemetry ใช้สำหรับ instrument, สร้าง, เก็บรวบรวม และส่งออกข้อมูลเหล่านี้
    • logs: ข้อมูลเมตาพร้อม timestamp ใช้ในการตัดสินหาสาเหตุรากของปัญหา
    • metrics: ข้อมูลเชิงสถิติหรือข้อมูลสรุปที่มีแท็กคีย์/ค่า ซึ่งวัดได้จากบริการ เป็นค่าที่จับได้ขณะรันไทม์ของบริการ
    • traces: บันทึกเหตุการณ์ที่เกิดขึ้นกับผู้ใช้และแอปพลิเคชัน บันทึกเส้นทางการแพร่กระจายของแต่ละ request
  • วิธีใช้งาน: เครื่องมือ Observability ส่งการแจ้งเตือน -> ตรวจสอบรายละเอียดการแจ้งเตือน แล้วไปที่แดชบอร์ดเพื่อดูจุดที่มีปัญหา -> query รายละเอียดเฉพาะส่วนจากจุดปัญหานั้น -> ค้นหาและตรวจสอบ logs -> หา trace data ที่เกี่ยวข้องกับ logs นี้แล้วจัดรูปแบบเป็นแพตเทิร์น -> ตรวจพบปัญหาที่จุดนี้ แล้วแก้ไข พร้อมนำ Observability ไปใช้งาน
  • ปัจจุบันเครื่องมือ Observability ส่วนใหญ่ที่สร้างขึ้นใหม่รองรับ Open Telemetry เป็นพื้นฐาน

• เหตุผลที่ Open Telemetry ถือกำเนิดขึ้น:

  • ในอดีตแต่ละ Observability backend มีไลบรารีและเอเจนต์สำหรับ instrument ของตนเองเพื่อส่งข้อมูลจากเครื่องมือเข้าไป และมีหลายวิธีในการ instrument โค้ด
  • ไม่มีรูปแบบข้อมูลมาตรฐานสำหรับส่งข้อมูลไปยัง Observability backend
  • ต่อมาจึงมีการรวม Open Tracing และ Open Census เข้าด้วยกันเพื่อสร้างมาตรฐานเดียว กลายเป็น Open Telemetry

• SigNoz: เครื่องมือ APM แบบโอเพนซอร์ส

  • ช่วยมอนิเตอร์แอปพลิเคชันและแก้ปัญหา
  • ใช้เทคโนโลยี distributed tracing เพื่อทำความเข้าใจซอฟต์แวร์สแตกของผู้ใช้
    • มอนิเตอร์ application metrics เช่น latency, requests per second, error rates
    • สังเกต infrastructure metrics เช่น การใช้ CPU หรือการใช้หน่วยความจำ
    • ติดตาม user requests ตลอดทั้งบริการ
    • ตั้งค่าการแจ้งเตือนบน metrics ได้
    • สามารถเจาะไปยัง trace ที่เป็นต้นเหตุของปัญหาเพื่อหาสาเหตุรากได้
    • สามารถดู flame graph แบบละเอียดของการติดตามแต่ละ request ได้

[ninebow]

ขอบคุณสำหรับบทความดีๆ ครับ!

[ironlung]

ขอบคุณสำหรับคอมเมนต์นะครับ! :)

[kaistj]

ขอบคุณสำหรับบทความดี ๆ ครับ~

[ironlung]

ขอบคุณสำหรับความคิดเห็น! :)

[jujumilk3]

จะมอนิเตอร์ได้อย่างไรว่าระบบมอนิเตอร์ทำงานได้ดีจริง?

ผมเคยมีความกังวลคล้ายกับในหนังสือการ์ตูนเรื่อง Watchmen แต่เพิ่งรู้ว่ามีคำว่า observability นี่เอง ขอบคุณครับ

[ironlung]

ขอบคุณครับ! ช่วงนี้ก็เริ่มเห็นหลายที่พัฒนาเครื่องมือที่ทำให้ Observability เรียบง่ายขึ้นด้วย AI เช่นกัน เป็นสาขาที่อยากรู้ให้มากขึ้นอีกครับ! :)

[inthelife]

ขอบคุณสำหรับบทความดี ๆ :)

[ironlung]

ขอบคุณครับ! :D