ในอดีต เมื่อเราพูดถึงแบ็กเอนด์ เรามักจะหมายถึงแอปพลิเคชันขนาดใหญ่หนึ่งตัวที่มีฐานข้อมูลขนาดใหญ่เพียงตัวเดียว และการบันทึกข้อมูลก็เพียงพอสำหรับการตรวจสอบ ปัจจุบัน ด้วยเทคโนโลยีเช่น Kubernetes ไมโครเซอร์วิส จึงกลายมาเป็นมาตรฐาน แอปพลิเคชันมีจำนวนมากขึ้นและกระจายมากขึ้น และการบันทึกข้อมูลแบบเดิมไม่เพียงพออีกต่อไปสำหรับ การดีบัก และวินิจฉัยปัญหาในแอปพลิเคชันของเรา
OpenTelemetry เป็นโซลูชันที่ยอดเยี่ยมสำหรับการจัดระเบียบการตรวจสอบ ซึ่งเป็นชุดเครื่องมือที่ทันสมัยซึ่งสามารถใช้สำหรับการดีบักและวิเคราะห์ประสิทธิภาพของระบบแบบกระจาย
บทความนี้เหมาะสำหรับผู้เชี่ยวชาญด้านไอทีที่ต้องการเพิ่มพูนความรู้เกี่ยวกับการเพิ่มประสิทธิภาพแบ็กเอนด์ ด้านล่างนี้ เราจะอธิบายรายละเอียดว่า OpenTelemetry คืออะไร แนวคิดหลัก และปัญหาที่ OpenTelemetry ช่วยแก้ไขได้ หากคุณสนใจว่า OpenTelemetry จะเปลี่ยนวิธีการตรวจสอบและแก้ไขข้อบกพร่องของระบบแบ็กเอนด์ เพื่อเพิ่มความน่าเชื่อถือและประสิทธิภาพได้อย่างไร โปรดอ่านต่อไป
บริษัทเทคโนโลยีขนาดใหญ่เผชิญกับความท้าทายในการบันทึกและติดตามแบบกระจายเป็นครั้งแรกในช่วงปลายทศวรรษปี 2000 ในปี 2010 Google ได้ตีพิมพ์เอกสาร
ในปี 2014 Kubernetes ได้ถือกำเนิดขึ้น ทำให้การพัฒนาไมโครเซอร์วิสและระบบกระจายบนคลาวด์อื่นๆ ง่ายขึ้นอย่างมาก ส่งผลให้บริษัทหลายแห่งประสบปัญหาในการบันทึกและติดตามแบบกระจายในไมโครเซอร์วิส เพื่อสร้างมาตรฐานการติดตามแบบกระจาย จึงได้มีการสร้างมาตรฐาน OpenTracing ซึ่ง CNCF นำมาใช้ และโปรเจ็กต์ OpenCensus ของ Google
ในปี 2019 โครงการ OpenTracing และ OpenCensus ได้ประกาศการควบรวมกิจการภายใต้ชื่อ OpenTelemetry แพลตฟอร์มนี้ผสมผสานแนวปฏิบัติที่ดีที่สุดที่สะสมมาหลายปีเข้าด้วยกัน ทำให้สามารถผสานการติดตาม การบันทึก และเมตริกเข้ากับระบบใดๆ ได้อย่างราบรื่น ไม่ว่าจะมีความซับซ้อนเพียงใดก็ตาม
ปัจจุบัน OpenTelemetry ไม่ใช่แค่โครงการเท่านั้น แต่ยังเป็นมาตรฐานอุตสาหกรรมสำหรับการรวบรวมและส่งข้อมูลเทเลเมทรีอีกด้วย โดยได้รับการพัฒนาและสนับสนุนโดยชุมชนผู้เชี่ยวชาญและบริษัทชั้นนำในตลาด เช่น Google และ Microsoft โครงการนี้ยังคงพัฒนาอย่างต่อเนื่องโดยได้รับความสามารถใหม่ๆ เพื่อลดความซับซ้อนของกระบวนการบูรณาการและการใช้งาน
OpenTelemetry คือชุดแนวทางปฏิบัติและเครื่องมือที่ครอบคลุมซึ่งกำหนดว่าแอปพลิเคชันสามารถสร้างสัญญาณใดเพื่อโต้ตอบกับโลกภายนอกได้ และสามารถรวบรวมและแสดงสัญญาณเหล่านี้อย่างไรเพื่อตรวจสอบสถานะของแอปพลิเคชันและระบบโดยรวม สัญญาณมีอยู่สามประเภทหลัก ได้แก่ การติดตาม การบันทึก และ การรวบรวมเมตริก
**มาดูส่วนประกอบแต่ละส่วนกันให้ละเอียดยิ่งขึ้น: \
OpenTelemetry แนะนำแนวคิดของบริบทการทำงาน บริบทประกอบด้วยแอตทริบิวต์เป็นหลัก เช่น `trace_id`
(ตัวระบุสำหรับการทำงานปัจจุบัน) และ `span_id`
(ตัวระบุสำหรับคำขอย่อย โดยคำขอย่อยแต่ละครั้งจะมี `span_id`
ที่ไม่ซ้ำกัน)
นอกจากนี้ บริบทสามารถมีข้อมูลคงที่ เช่น ชื่อโหนดที่แอปพลิเคชันถูกปรับใช้หรือชื่อสภาพแวดล้อม (prod/qa) ฟิลด์เหล่านี้ ซึ่งเรียกว่าทรัพยากรในคำศัพท์ของ OpenTelemetry จะถูกแนบไปกับบันทึก เมตริก หรือการติดตามทั้งหมดเพื่อให้ค้นหาได้ง่ายขึ้น บริบทยังสามารถรวมข้อมูลแบบไดนามิก เช่น ตัวระบุของจุดสิ้นสุดปัจจุบัน ( `http_path: "GET /user/:id/info"`
) ซึ่งสามารถแนบกับกลุ่มของบันทึก เมตริก หรือการติดตามได้อย่างเลือกสรร
บริบทของ OpenTelemetry สามารถส่งต่อระหว่างแอปพลิเคชันต่างๆ ได้โดยใช้โปรโตคอลการแพร่กระจายบริบท โปรโตคอลเหล่านี้ประกอบด้วยชุดส่วนหัวที่เพิ่มลงในคำขอ HTTP หรือ gRPC ทุกคำขอ หรือส่วนหัวของข้อความสำหรับคิว วิธีนี้ช่วยให้แอปพลิเคชันปลายทางสามารถสร้างบริบทการทำงานใหม่จากส่วนหัวเหล่านี้ได้
ต่อไปนี้เป็นตัวอย่างบางส่วนของการแพร่กระจายบริบท:
B3-Propagation เป็นชุดของส่วนหัว ( x-b3-*
) ที่พัฒนาขึ้นในตอนแรกสำหรับระบบการติดตาม Zipkin ซึ่งได้รับการดัดแปลงให้ใช้งานใน OpenTracing และใช้งานโดยเครื่องมือและไลบรารีต่างๆ มากมาย B3-Propagation มี trace_id
/ span_id
และแฟล็กที่ระบุว่าจำเป็นต้องสุ่มตัวอย่างหรือไม่
W3C Trace Context มาตรฐานนี้ได้รับการพัฒนาโดยกลุ่มงาน W3C โดยรวบรวมแนวทางการแพร่กระจายบริบทต่างๆ ให้เป็นมาตรฐานเดียวและเป็นค่าเริ่มต้นใน OpenTelemetry ตัวอย่างที่ดีของการใช้มาตรฐานเหล่านี้คือการติดตามการดำเนินการคำขอที่ส่งผ่านไมโครเซอร์วิสที่ใช้เทคโนโลยีต่างๆ โดยไม่กระทบต่อความแม่นยำในการตรวจสอบและแก้ไขข้อบกพร่อง
การติดตามคือกระบวนการบันทึกและแสดงภาพไทม์ไลน์ของเส้นทางการร้องขอผ่านไมโครเซอร์วิสต่างๆ จำนวนมาก
ในการแสดงภาพ แถบแต่ละแถบจะเรียกว่า "span" และมี "span_id" ที่ไม่ซ้ำกัน ส่วนรากของสแปนจะเรียกว่า "trace" และมี "trace_id" ซึ่งทำหน้าที่เป็นตัวระบุสำหรับคำขอทั้งหมด
การสร้างภาพประเภทนี้ช่วยให้คุณสามารถ:
trace_id
และ span_id
เพื่อใช้ในสัญญาณอื่นๆ
แม้ว่าจะดูเรียบง่าย แต่การบันทึกข้อมูลยังคงเป็นหนึ่งในเครื่องมือที่มีประสิทธิภาพมากที่สุดในการวินิจฉัยปัญหา OpenTelemetry ช่วยเพิ่มประสิทธิภาพการบันทึกข้อมูลแบบเดิมด้วยการเพิ่มข้อมูลบริบท โดยเฉพาะอย่างยิ่ง หากมีการติดตามที่ใช้งานอยู่ แอตทริบิวต์ `trace_id` และ `span_id` จะถูกเพิ่มลงในบันทึกข้อมูลโดยอัตโนมัติ โดยเชื่อมโยงแอตทริบิวต์เหล่านี้กับไทม์ไลน์การติดตาม นอกจากนี้ แอตทริบิวต์ของบันทึกข้อมูลสามารถรวมข้อมูลคงที่จากบริบทของ OpenTelemetry เช่น ตัวระบุโหนด ตลอดจนข้อมูลแบบไดนามิก เช่น ตัวระบุจุดสิ้นสุด HTTP ปัจจุบัน (`http_path: "GET /user/:id"`)
การใช้ `trace_id` ช่วยให้คุณค้นหาบันทึกจากไมโครเซอร์วิสทั้งหมดที่เกี่ยวข้องกับคำขอปัจจุบันได้ ในขณะที่ `span_id` ช่วยให้คุณแยกความแตกต่างระหว่างคำขอย่อยได้ ตัวอย่างเช่น ในกรณีของการลองใหม่ บันทึกจากความพยายามที่แตกต่างกันจะมี `span_id` ที่แตกต่างกัน การใช้ตัวระบุเหล่านี้ทำให้สามารถวิเคราะห์พฤติกรรมของระบบทั้งหมดได้อย่างรวดเร็วแบบเรียลไทม์ ช่วยเร่งการวินิจฉัยปัญหาและเพิ่มเสถียรภาพและความน่าเชื่อถือ
การรวบรวมเมตริกจะให้ข้อมูลเชิงปริมาณเกี่ยวกับประสิทธิภาพของระบบ เช่น ความหน่วง อัตราข้อผิดพลาด การใช้ทรัพยากร และอื่นๆ การตรวจสอบเมตริกแบบเรียลไทม์ช่วยให้คุณตอบสนองต่อการเปลี่ยนแปลงประสิทธิภาพได้อย่างทันท่วงที ป้องกันความล้มเหลวและการใช้ทรัพยากรจนหมด และรับรองความพร้อมใช้งานและความน่าเชื่อถือของแอปพลิเคชันสำหรับผู้ใช้
การบูรณาการกับระบบจัดเก็บและการแสดงภาพข้อมูลเมตริก เช่น Prometheus และ Grafana ทำให้การแสดงภาพข้อมูลนี้เป็นเรื่องง่ายยิ่งขึ้น ซึ่งทำให้การตรวจสอบง่ายยิ่งขึ้นอย่างมาก
ตัวรวบรวมเมตริกของ OpenTelemetry เข้ากันได้กับมาตรฐาน Prometheus และ OpenMetrics ทำให้สามารถเปลี่ยนไปใช้โซลูชัน OpenTelemetry ได้อย่างง่ายดายโดยไม่ต้องเปลี่ยนแปลงอะไรมากนัก OpenTelemetry SDK ช่วยให้สามารถส่งออกตัวอย่าง trace_id พร้อมกับเมตริกได้ ทำให้สามารถเชื่อมโยงเมตริกกับตัวอย่างบันทึกและร่องรอยได้
เมื่อนำมารวมกัน บันทึก เมตริก และการติดตามจะสร้างมุมมองที่ครอบคลุมของสถานะของระบบ:
นอกเหนือจากส่วนประกอบหลักทั้งสามส่วนแล้ว OpenTelemetry ยังรวมแนวคิดการสุ่มตัวอย่าง สัมภาระ และการจัดการบริบทการดำเนินงานอีกด้วย
ในระบบที่มีโหลดสูง ปริมาณบันทึกและการติดตามจะมหาศาล ต้องใช้ทรัพยากรจำนวนมากสำหรับโครงสร้างพื้นฐานและการจัดเก็บข้อมูล เพื่อแก้ไขปัญหานี้ มาตรฐานของ OpenTelemetry จึงรวมถึงการสุ่มสัญญาณ ซึ่งก็คือความสามารถในการส่งออกเฉพาะบางส่วนของการติดตามและบันทึก ตัวอย่างเช่น คุณสามารถส่งออกสัญญาณโดยละเอียดจากคำขอจำนวนหนึ่ง คำขอที่ดำเนินการเป็นเวลานาน หรือคำขอที่มีข้อผิดพลาด วิธีนี้ช่วยให้สามารถสุ่มตัวอย่างได้เพียงพอสำหรับการสร้างสถิติในขณะที่ประหยัดทรัพยากรจำนวนมาก
อย่างไรก็ตาม หากแต่ละระบบตัดสินใจแยกกันว่าจะตรวจสอบคำขอใดโดยละเอียด เราก็จะได้มุมมองที่กระจัดกระจายของคำขอแต่ละรายการ ระบบบางระบบอาจส่งออกข้อมูลโดยละเอียด ในขณะที่ระบบอื่นอาจส่งออกเพียงบางส่วนหรือส่งออกเลยก็ได้
เพื่อแก้ปัญหานี้ กลไกการแพร่กระจายบริบทของ OpenTelemetry จะส่งแฟล็กการสุ่มตัวอย่างพร้อมกับ `trace_id`/`span_id` วิธีนี้จะช่วยให้มั่นใจได้ว่าหากบริการเริ่มต้นที่ได้รับคำขอของผู้ใช้ตัดสินใจว่าควรตรวจสอบคำขอโดยละเอียด ระบบอื่นๆ ทั้งหมดจะทำตาม มิฉะนั้น ระบบทั้งหมดควรส่งออกสัญญาณบางส่วนหรือไม่ส่งออกเพื่อประหยัดทรัพยากร แนวทางนี้เรียกว่า "การสุ่มตัวอย่างส่วนหัว" ซึ่งเป็นการตัดสินใจที่เกิดขึ้นในช่วงเริ่มต้นของการประมวลผลคำขอ โดยอาจสุ่มหรือขึ้นอยู่กับแอตทริบิวต์อินพุตบางอย่าง
นอกจากนี้ OpenTelemetry ยังรองรับ "Tail Sampling" ซึ่งแอปพลิเคชันทั้งหมดจะส่งออกสัญญาณทั้งหมดในรายละเอียดเสมอ แต่จะมีบัฟเฟอร์ตัวกลางอยู่ หลังจากรวบรวมข้อมูลทั้งหมดแล้ว บัฟเฟอร์นี้จะตัดสินใจว่าจะเก็บข้อมูลทั้งหมดไว้หรือเก็บตัวอย่างบางส่วนเท่านั้น วิธีนี้ช่วยให้สามารถสุ่มตัวอย่างที่เป็นตัวแทนมากขึ้นสำหรับหมวดหมู่คำขอแต่ละประเภท (สำเร็จ/ยาว/ผิดพลาด) แต่ต้องมีการตั้งค่าโครงสร้างพื้นฐานเพิ่มเติม
กลไก Baggage อนุญาตให้ส่งคู่คีย์-ค่าตามอำเภอใจพร้อมกับ trace_id
/ span_id
โดยส่งผ่านระหว่างไมโครเซอร์วิสทั้งหมดโดยอัตโนมัติในระหว่างการประมวลผลคำขอ ซึ่งมีประโยชน์ในการส่งข้อมูลเพิ่มเติมที่จำเป็นตลอดเส้นทางคำขอ เช่น ข้อมูลผู้ใช้หรือการตั้งค่าสภาพแวดล้อมรันไทม์
ตัวอย่างส่วนหัวสำหรับการส่งสัมภาระตามมาตรฐาน W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5
ต่อไปนี้เป็นตัวอย่างการใช้งานกระเป๋าเดินทาง:
การส่งข้อมูลบริบททางธุรกิจ เช่น userId
, productId
หรือ deviceId
สามารถส่งผ่านไมโครเซอร์วิสทั้งหมดได้ แอปพลิเคชันสามารถบันทึกข้อมูลนี้โดยอัตโนมัติ ช่วยให้สามารถค้นหาบันทึกตามบริบทของผู้ใช้สำหรับคำขอเดิมได้
การตั้งค่า พารามิเตอร์การกำหนดค่าเฉพาะ สำหรับ SDK หรือโครงสร้างพื้นฐาน
แฟล็กการกำหนดเส้นทาง แฟล็กที่ช่วยให้ตัวปรับสมดุลการโหลดตัดสินใจกำหนดเส้นทางได้ ในระหว่างการทดสอบ คำขอบางรายการอาจต้องถูกกำหนดเส้นทางไปยังแบ็กเอนด์จำลอง เนื่องจากข้อมูลจะถูกส่งโดยอัตโนมัติผ่านบริการทั้งหมด จึงไม่จำเป็นต้องสร้างโปรโตคอลเพิ่มเติม เพียงตั้งค่ากฎบนตัวปรับสมดุลการโหลด
โปรดทราบว่าแม้ว่าผลกระทบต่อประสิทธิภาพของ Baggage จะน้อยมาก แต่การใช้งานมากเกินไปอาจเพิ่มภาระของเครือข่ายและบริการได้อย่างมาก เลือกข้อมูลที่คุณต้องการส่งผ่าน Baggage อย่างระมัดระวังเพื่อหลีกเลี่ยงปัญหาด้านประสิทธิภาพ
การนำ OpenTelemetry ไปใช้ในระดับโครงสร้างพื้นฐานเกี่ยวข้องกับการบูรณาการแบ็กเอนด์ของ OpenTelemetry เข้ากับสถาปัตยกรรมแอปพลิเคชันและการกำหนดค่าโครงสร้างพื้นฐานสำหรับการรวบรวมข้อมูล
กระบวนการนี้ประกอบด้วยสี่ขั้นตอน:
การรวมแอปพลิเคชัน ในขั้นตอนแรก SDK ของ OpenTelemetry จะถูกรวมเข้ากับแอปพลิเคชันโดยตรงเพื่อรวบรวมเมตริก บันทึก และการติดตาม เพื่อให้แน่ใจว่ามีการไหลของข้อมูลเกี่ยวกับประสิทธิภาพของส่วนประกอบระบบแต่ละส่วนอย่างต่อเนื่อง
การกำหนดค่าผู้ส่งออก ข้อมูลที่รวบรวมจะถูกส่งจากแอปพลิเคชันผ่านผู้ส่งออกไปยังระบบภายนอกเพื่อการประมวลผลเพิ่มเติม เช่น การบันทึก การตรวจสอบ การติดตาม หรือระบบวิเคราะห์ ขึ้นอยู่กับความต้องการของคุณ
การรวมและการจัดเก็บ ขั้นตอนนี้อาจเกี่ยวข้องกับการทำให้ข้อมูลเป็นมาตรฐาน เสริมด้วยข้อมูลเพิ่มเติม และผสานข้อมูลจากแหล่งต่าง ๆ เพื่อสร้างมุมมองรวมของสถานะของระบบ
การแสดงภาพข้อมูล ในที่สุด ข้อมูลที่ประมวลผลแล้วจะถูกนำเสนอในรูปแบบแดชบอร์ดในระบบ เช่น Grafana (สำหรับเมตริกและการติดตาม) หรือ Kibana (สำหรับบันทึก) ซึ่งช่วยให้ทีมงานสามารถประเมินความสมบูรณ์ของระบบ ระบุปัญหาและแนวโน้ม และตั้งค่าการแจ้งเตือนตามสัญญาณที่สร้างขึ้นได้อย่างรวดเร็ว
หากต้องการบูรณาการกับแอปพลิเคชัน คุณต้องเชื่อมต่อ OpenTelemetry SDK ที่เหมาะสมสำหรับภาษาการเขียนโปรแกรมที่ใช้งานอยู่ หรือใช้ไลบรารีและเฟรมเวิร์กที่รองรับ OpenTelemetry โดยตรง OpenTelemetry มักจะใช้อินเทอร์เฟซที่ใช้กันอย่างแพร่หลายจากไลบรารีที่รู้จัก ซึ่งช่วยให้สามารถเปลี่ยนได้เอง ตัวอย่างเช่น ไลบรารี Micrometer มักใช้สำหรับการรวบรวมเมตริกในระบบนิเวศ Java OpenTelemetry SDK นำเสนอการใช้งานอินเทอร์เฟซ Micrometer ของตนเอง ทำให้สามารถส่งออกเมตริกได้โดยไม่ต้องเปลี่ยนโค้ดแอปพลิเคชันหลัก นอกจากนี้ OpenTelemetry ยังนำเสนอการใช้งานอินเทอร์เฟซ OpenTracing และ OpenCensus รุ่นเก่า ซึ่งช่วยให้สามารถย้ายข้อมูลไปยัง OpenTelemetry ได้อย่างราบรื่น
ในระบบไอที OpenTelemetry อาจกลายมาเป็นกุญแจสำคัญสู่อนาคตของแบ็กเอนด์ที่เชื่อถือได้และมีประสิทธิภาพ เครื่องมือนี้ช่วยลดความซับซ้อนของการดีบักและการตรวจสอบ และยังเปิดโอกาสให้เข้าใจประสิทธิภาพการทำงานของแอปพลิเคชันและการเพิ่มประสิทธิภาพในระดับใหม่ เข้าร่วมชุมชน OpenTelemetry เพื่อช่วยกำหนดอนาคตที่การพัฒนาแบ็กเอนด์จะง่ายขึ้นและมีประสิทธิภาพมากขึ้น!