OpenTelemetry คืออะไร และสามารถปรับปรุงคุณภาพแบ็กเอนด์ของคุณได้อย่างไร

ในอดีต เมื่อเราพูดถึงแบ็กเอนด์ เรามักจะหมายถึงแอปพลิเคชันขนาดใหญ่หนึ่งตัวที่มีฐานข้อมูลขนาดใหญ่เพียงตัวเดียว และการบันทึกข้อมูลก็เพียงพอสำหรับการตรวจสอบ ปัจจุบัน ด้วยเทคโนโลยีเช่น จึงกลายมาเป็นมาตรฐาน แอปพลิเคชันมีจำนวนมากขึ้นและกระจายมากขึ้น และการบันทึกข้อมูลแบบเดิมไม่เพียงพออีกต่อไปสำหรับ และวินิจฉัยปัญหาในแอปพลิเคชันของเรา Kubernetes ไมโครเซอร์วิส การดีบัก OpenTelemetry เป็นโซลูชันที่ยอดเยี่ยมสำหรับการจัดระเบียบการตรวจสอบ ซึ่งเป็นชุดเครื่องมือที่ทันสมัยซึ่งสามารถใช้สำหรับการดีบักและวิเคราะห์ประสิทธิภาพของระบบแบบกระจาย บทความนี้เหมาะสำหรับผู้เชี่ยวชาญด้านไอทีที่ต้องการเพิ่มพูนความรู้เกี่ยวกับการเพิ่มประสิทธิภาพแบ็กเอนด์ ด้านล่างนี้ เราจะอธิบายรายละเอียดว่า OpenTelemetry คืออะไร แนวคิดหลัก และปัญหาที่ OpenTelemetry ช่วยแก้ไขได้ หากคุณสนใจว่า OpenTelemetry จะเปลี่ยนวิธีการตรวจสอบและแก้ไขข้อบกพร่องของระบบแบ็กเอนด์ เพื่อเพิ่มความน่าเชื่อถือและประสิทธิภาพได้อย่างไร โปรดอ่านต่อไป ประวัติโดยย่อของ OpenTelemetry บริษัทเทคโนโลยีขนาดใหญ่เผชิญกับความท้าทายในการบันทึกและติดตามแบบกระจายเป็นครั้งแรกในช่วงปลายทศวรรษปี 2000 ในปี 2010 Google ได้ตีพิมพ์เอกสาร ซึ่งวางรากฐานให้กับเครื่องมือติดตามของ Twitter ที่ชื่อว่า Zipkin ซึ่งเปิดตัวในปี 2012 Dapper โครงสร้างพื้นฐานการติดตามระบบแบบกระจายขนาดใหญ่ ในปี 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 ทุกคำขอ หรือส่วนหัวของข้อความสำหรับคิว วิธีนี้ช่วยให้แอปพลิเคชันปลายทางสามารถสร้างบริบทการทำงานใหม่จากส่วนหัวเหล่านี้ได้ ต่อไปนี้เป็นตัวอย่างบางส่วนของการแพร่กระจายบริบท: เป็นชุดของส่วนหัว ( ) ที่พัฒนาขึ้นในตอนแรกสำหรับระบบการติดตาม Zipkin ซึ่งได้รับการดัดแปลงให้ใช้งานใน OpenTracing และใช้งานโดยเครื่องมือและไลบรารีต่างๆ มากมาย B3-Propagation มี / และแฟล็กที่ระบุว่าจำเป็นต้องสุ่มตัวอย่างหรือไม่ B3-Propagation x-b3-* trace_id span_id มาตรฐานนี้ได้รับการพัฒนาโดยกลุ่มงาน W3C โดยรวบรวมแนวทางการแพร่กระจายบริบทต่างๆ ให้เป็นมาตรฐานเดียวและเป็นค่าเริ่มต้นใน OpenTelemetry ตัวอย่างที่ดีของการใช้มาตรฐานเหล่านี้คือการติดตามการดำเนินการคำขอที่ส่งผ่านไมโครเซอร์วิสที่ใช้เทคโนโลยีต่างๆ โดยไม่กระทบต่อความแม่นยำในการตรวจสอบและแก้ไขข้อบกพร่อง W3C Trace Context การติดตาม การติดตามคือกระบวนการบันทึกและแสดงภาพไทม์ไลน์ของเส้นทางการร้องขอผ่านไมโครเซอร์วิสต่างๆ จำนวนมาก ในการแสดงภาพ แถบแต่ละแถบจะเรียกว่า "span" และมี ที่ไม่ซ้ำกัน ส่วนรากของสแปนจะเรียกว่า และมี ซึ่งทำหน้าที่เป็นตัวระบุสำหรับคำขอทั้งหมด "span_id" "trace" "trace_id" การสร้างภาพประเภทนี้ช่วยให้คุณสามารถ: วิเคราะห์เวลาการดำเนินการคำขอในระบบและฐานข้อมูลที่แตกต่างกันเพื่อระบุคอขวดที่ต้องมีการปรับให้เหมาะสม ตรวจจับการอ้างอิงแบบวนซ้ำระหว่างบริการ ค้นหาคำขอที่ซ้ำกัน โดยใช้ข้อมูลการติดตาม คุณยังสามารถสร้างการวิเคราะห์เพิ่มเติมได้ เช่น การสร้างแผนที่ไมโครเซอร์วิสหรือการกระจายเวลาในระบบต่างๆ ในระหว่างการประมวลผลการทำงาน แม้ว่าคุณจะไม่ได้ใช้ข้อมูลการติดตามเพื่อแสดงไทม์ไลน์ OpenTelemetry ก็ยังสร้าง และ เพื่อใช้ในสัญญาณอื่นๆ 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 ตัวอย่างเช่น Grafana ช่วยให้ผู้ใช้ดูการติดตามและเมตริกคำขอที่เกี่ยวข้องเมื่อดูบันทึก ซึ่งช่วยเพิ่มประสิทธิภาพและการใช้งานแพลตฟอร์มได้อย่างมาก นอกเหนือจากส่วนประกอบหลักทั้งสามส่วนแล้ว 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 เพื่อช่วยกำหนดอนาคตที่การพัฒนาแบ็กเอนด์จะง่ายขึ้นและมีประสิทธิภาพมากขึ้น!