การสังเกตของไมโครบริการ: คู่มือที่ครอบคลุมโดย Brajesh Kumar

ขณะที่ระบบซอฟต์แวร์ที่ซับซ้อนขึ้น microservices ได้กลายเป็นวิธีที่จําเป็นในการสร้างแอปที่สามารถปรับขนาดได้ทนทานและง่ายต่อการบํารุงรักษา แต่ด้วยความยืดหยุ่นนั้นมาถึงการชดเชย: สิ่งจะยากขึ้นในการติดตาม การทําความเข้าใจว่าส่วนเคลื่อนที่ทั้งหมดพฤติกรรมในระบบกระจายไม่ได้เป็นเรื่องง่ายและนี่คือเหตุผลที่การสังเกตไม่เพียง แต่เป็นสิ่งที่ดีที่จะมีอีกต่อไปมันเป็นสิ่งจําเป็น ความสามารถในการสังเกตได้ขยายไปกว่าการตรวจสอบแบบดั้งเดิมเพื่อให้ข้อมูลที่ลึกซึ้งเกี่ยวกับสถานะภายในของระบบที่ซับซ้อนขึ้นอยู่กับผลลัพธ์ภายนอกของระบบ ในขณะที่การสังเกตช่วยให้คุณทราบเมื่อบางสิ่งผิดพลาดความสามารถในการสังเกตช่วยให้คุณเข้าใจว่าทําไมมันผิด - บ่อยครั้งก่อนที่ผู้ใช้สังเกตปัญหา สามคอลัมน์ของการสังเกต 1. Metrics: Quantitative System Behaviour เมตริกให้การแสดงตัวเลขของระบบและประสิทธิภาพทางธุรกิจตามเวลา พวกเขาเป็นจุดข้อมูลที่มีโครงสร้างสูงและน้ําหนักเบาซึ่งช่วยให้ทีมสามารถตรวจจับแนวโน้มและผิดปกติ Key Metrics Types: เมตริกระบบ: CPU, หน่วยความจํา, การใช้ไดรฟ์และการผ่านเครือข่าย แอปพลิเคชันเมตริกซ์: อัตราคําขอ อัตราข้อผิดพลาด และเวลาตอบสนอง เมตรธุรกิจ: การมีส่วนร่วมของผู้ใช้อัตราการแปลงและปริมาณการทําธุรกรรม เมตริกที่กําหนดเอง: ตัวบ่งชี้เฉพาะโดเมนที่เกี่ยวข้องกับบริการเฉพาะของคุณ Advantages of Metrics: ด้านบนต่ําสําหรับการเก็บรวบรวมและจัดเก็บ รวมและวิเคราะห์ได้อย่างง่ายดายโดยใช้วิธีการสถิติ เหมาะสําหรับการเตือนสภาพการล้มเหลวที่รู้จัก เหมาะสําหรับ dashboard และภาพเคลื่อนไหวแบบเรียลไทม์ การประยุกต์ใช้เมตริกที่มีประสิทธิภาพเกี่ยวข้องกับการตั้งค่าขั้นตอนพื้นฐานสําหรับพฤติกรรมปกติและการตั้งค่าขอบเขตที่เหมาะสมสําหรับการแจ้งเตือน วิธีการ RED (อัตราข้อผิดพลาดระยะเวลา) และวิธีการ USE (ใช้ความ saturation ข้อผิดพลาด) ให้กรอบการให้ความสําคัญกับเมตริก 2. Logs: Detailed Event Records บันทึกเป็นเหตุการณ์ที่แตกต่างกันที่เกิดขึ้นภายในแอปพลิเคชันและส่วนประกอบโครงสร้างพื้นฐาน พวกเขาให้ข้อมูลที่อุดมไปด้วยแง่มุมเกี่ยวกับการกระทําข้อผิดพลาดหรือการเปลี่ยนแปลงสถานะเฉพาะ โลโก้ปฏิบัติการที่ดีที่สุด: นําไปใช้การบันทึกแบบโครงสร้างด้วยรูปแบบที่สอดคล้องกัน (JSON เป็นที่นิยม) รวมข้อมูลพื้นฐาน (ชื่อบริการรุ่นสภาพแวดล้อม) เพิ่ม ID การเชื่อมโยงเพื่อติดตามคําขอระหว่างบริการ ใช้ระดับบันทึกที่เหมาะสม (DEBUG, INFO, WARN, ERROR) การปฏิบัติการนโยบายการหมุนและเก็บรักษาบันทึก โลโก้การจัดการความท้าทาย: ปริมาณสูงในระบบกระจาย ค่าใช้จ่ายในการจัดเก็บและผลกระทบต่อประสิทธิภาพ ค้นหาสัญญาณที่เหมาะสมในข้อมูลเสียงรบกวน การสมดุล verbosity กับประสิทธิภาพ โซลูชั่นการจัดการบันทึกที่ทันสมัยนําบันทึกจากทุกบริการให้เป็นศูนย์กลางช่วยให้สามารถค้นหาการกรองและการวิเคราะห์ได้ทั่วทั้งระบบ บ่อยครั้งที่พวกเขาสนับสนุนคุณสมบัติเช่นการรับรู้รูปแบบและการตรวจจับความผิดปกติเพื่อระบุปัญหาได้อย่างมีประสิทธิภาพ 3. Traces: Request Journeys การติดตามแบบกระจายตามคําขอในขณะที่พวกเขาแพร่กระจายผ่านไมโครบริการสร้างมุมมองที่ครอบคลุมของวงจรชีวิตของคําขอ แต่ละแทร็คประกอบด้วยช่วง - การดําเนินงานส่วนบุคคลภายในบริการ - ซึ่งเป็นตัวแทนระดับไฮเวย์ของเส้นทางของคําขอ Tracing Components: ID Trace: ตัวระบุที่ไม่ซ้ํากันสําหรับคําขอ End-to-End Spans: การดําเนินงานส่วนบุคคลภายในเส้นทาง สเปนแง่มุม: เมตาดาต้าที่มาพร้อมกับช่วงผ่านขอบเขตบริการ หมายเหตุ / แท็ก: ข้อมูลเพิ่มเติมที่แนบมาพร้อมกับช่วง Tracing Benefits: ดูการไหลของคําขอผ่านสถาปัตยกรรมที่ซับซ้อน ปัญหาการขัดขวางประสิทธิภาพและปัญหาความล่าช้า ความเข้าใจของความเสี่ยงบริการและรูปแบบการโต้ตอบ Debug การทําธุรกรรมที่กระจายตัวที่ซับซ้อน การติดตามที่มีประสิทธิภาพต้องใช้เครื่องมือทั่วทุกบริการโดยทั่วไปผ่านห้องสมุดที่จับเวลาข้อมูลโดยอัตโนมัติและแพร่กระจายการติดตามสภาวะระหว่างบริการ กลยุทธ์และการใช้เครื่องมือ Service Mesh เครือข่ายบริการเช่น Istio, Linkerd และ Consul ให้การสังเกตข้อมูลนอกกล่องโดยการจับภาพการสื่อสารบริการต่อบริการในระดับเครือข่าย Key Features: การเก็บรวบรวมเมตริกอัตโนมัติ: ปริมาณการร้องขอความล่าช้าและอัตราความผิดพลาด การบูรณาการการติดตามแบบกระจาย: การแพร่กระจายหัวติดตาม การแสดงผลการจราจร: แผนที่การพึ่งพาบริการ การจัดการการจราจรขั้นสูง: การทําลายวงจรการทําซ้ําและการแบ่งการจราจร ตาข่ายบริการมีคุณค่าโดยเฉพาะอย่างยิ่งในสภาพแวดล้อม Kubernetes ซึ่งสามารถใช้งานได้ในฐานะพ็อกซี่ sidecar โดยไม่ต้องเปลี่ยนแปลงรหัสไปยังบริการเอง Open Telemetry: The Unified Standard Telemetry เปิดได้ปรากฏขึ้นเป็นมาตรฐานอุตสาหกรรมสําหรับเครื่องมือนําเสนอวิธีที่เป็นกลางของผู้ผลิตในการเก็บรวบรวมและส่งออกข้อมูล Telemetry Components: API: อธิบายวิธีการสร้างข้อมูล Telemetry SDK: ใช้ API ด้วยตัวเลือกการกําหนดค่า Collector: ได้รับการประมวลผลและส่งออกข้อมูล Telemetry ผู้ส่งออก: ส่งข้อมูลไปยังส่วนหลังต่างๆ โดยใช้ Open Telemetry องค์กรหลีกเลี่ยงการล็อคซัพพลายเออร์และสามารถสลับระหว่างสํารองข้อมูลการสังเกตที่แตกต่างกันตามความต้องการ Monitoring Platforms มีโซลูชั่นต่าง ๆ สําหรับการจัดเก็บการวิเคราะห์และดูข้อมูลการสังเกต: Popular Combinations: Prometheus + Grafana: การตรวจสอบและแสดงผลเมตริกส์แบบเปิดซอร์ส ELK Stack (Elasticsearch, Logstash, Kibana): การรวบรวมและวิเคราะห์บันทึก Jaeger / Zipkin: Open-source การติดตามแบบกระจาย แพลตฟอร์มการค้า: Datadog, New Relic, Dynatrace, Honeycomb องค์กรจํานวนมากใช้เครื่องมือผสมผสานแม้ว่าแพลตฟอร์มการสังเกตแบบครบวงจรจะได้รับแรงดึงสําหรับความสามารถในการสอดคล้องระหว่างเมตริกบันทึกและติดตาม ความท้าทายของการสังเกตใน Microservices Data Volume and Cardinality Microservices สร้างปริมาณข้อมูลระยะไกลขนาดใหญ่ที่มีความสําคัญสูง (หลายการรวมกันของมิติที่ไม่ซ้ํากัน) สิ่งนี้สร้างความท้าทายสําหรับ: ค่าใช้จ่ายในการจัดเก็บข้อมูล: การสมดุลการเก็บรักษาข้อมูลกับข้อ จํากัด ในงบประมาณ ประสิทธิภาพการสอบถาม: รักษาความเร็วด้วยการเพิ่มปริมาณข้อมูล อัตราสัญญาณต่อเสียงรบกวน: ค้นหาข้อมูลที่เกี่ยวข้องในชุดข้อมูลขนาดใหญ่ Context Propagation การรักษาสภาพแวดล้อมข้ามขอบเขตบริการต้องพิจารณาอย่างระมัดระวัง: หัวข้อที่สอดคล้องกัน: การจัดรูปแบบมาตรฐานสําหรับ trace IDs และ context การดําเนินงาน asynchronous: การรักษาความสัมพันธ์ระหว่างสายข้อความ บริการของบุคคลที่สาม: การจัดการกับระบบภายนอกที่ไม่สนับสนุนกลไกการติดตามของคุณ Tool Proliferation ภูมิทัศน์การสังเกตได้มีเครื่องมือพิเศษจํานวนมากนําไปสู่: ความซับซ้อนของการบูรณาการ: ให้แน่ใจว่าเครื่องมือทํางานร่วมกันได้อย่างราบรื่น การทําลายความรู้: ต้องการทีมเรียนรู้ระบบหลายระบบ การจัดการค่าใช้จ่าย: การควบคุมค่าใช้จ่ายระหว่างผู้จําหน่ายหลายราย การปฏิบัติที่ดีที่สุดสําหรับการสังเกตของ Microservices กลยุทธ์เครื่องมือ มาตรฐานสําหรับเครื่องมือ: ทําให้การสังเกตเป็นคุณสมบัติมาตรฐานไม่ใช่การคิดหลัง ใช้เครื่องมืออัตโนมัติเมื่อเป็นไปได้เพื่อลดการพัฒนา มาตรฐานเกี่ยวกับห้องสมุดที่สอดคล้องกันระหว่างบริการและทีม พิจารณาการสังเกตเห็นได้ใน API โดยการออกแบบด้วยความสามารถในการติดตาม การตรวจสอบสุขภาพและ SLIs / SLOs นําไปใช้การตรวจสอบสุขภาพบริการสําหรับการตรวจสอบความพร้อมพื้นฐาน กําหนดตัวบ่งชี้ระดับบริการ (SLIs) ซึ่งสะท้อนถึงประสบการณ์ของผู้ใช้ กําหนดเป้าหมายระดับบริการ (SLOs) เป็นเป้าหมายสําหรับความน่าเชื่อถือ สร้างงบประมาณข้อผิดพลาดเพื่อให้สมดุลความน่าเชื่อถือกับความเร็วในการพัฒนา ปริศนาปรัชญา การเตือนเกี่ยวกับอาการไม่ใช่สาเหตุ: มุ่งเน้นไปที่ผลกระทบของผู้ใช้ ลดการเตือนความเหนื่อยล้า: ลบการแจ้งเตือนที่มีเสียงรบกวนหรือเกินไป สร้างการเป็นเจ้าของที่ชัดเจน: การแจ้งเตือนเส้นทางไปยังทีมที่เหมาะสม สร้างการแจ้งเตือนที่สามารถดําเนินการได้: รวมถึงบรรทัดฐานและขั้นตอนการแก้ไขที่เป็นไปได้ การสังเกตเป็นวัฒนธรรม Shift left: รวมความสามารถในการสังเกตในกระบวนการพัฒนา ดําเนินการตรวจสอบความสามารถในการสังเกตพร้อมกับการตรวจสอบรหัส การฝึกอบรมวิศวกรรมโกลเด้นเพื่อตรวจสอบความสามารถในการสังเกตในระหว่างความล้มเหลว สร้างหนังสือเล่มสําหรับสถานการณ์ทั่วไปที่ระบุผ่านข้อมูลการสังเกต New Relic’s Comprehensive Approach to Microservice Observability สิ่งที่ทําให้ New Relic แตกต่างกันคือวิธีการแพลตฟอร์มที่สอดคล้องกันเพื่อการสังเกตได้ แทนที่จะรวมเครื่องมือเฉพาะหลายเครื่อง New Relic ให้การมองเห็นแบบ End-to-End ทั่วระบบไมโครเซิร์ฟเวอร์ทั้งหมดของคุณผ่านแผงแก้วเดียว New Relic ให้การแจ้งเตือนที่ช่วยในการล้างปัญหาการแก้ไขเสียงรบกวนก่อนที่พวกเขาจะกลายเป็นขีดข่วน มันให้เส้นทางสังเคราะห์ที่ช่วยในการกําหนดสุขภาพของบริการ มันให้ NerdGraph API เพื่ออัตโนมัติการปรับขนาด ฯลฯ ขึ้นอยู่กับการแจ้งเตือนหรือเหตุการณ์ที่เราสามารถใช้ API ที่อยู่เบื้องหลัง ด้านล่างคือสิ่งอํานวยความสะดวกขั้นสูงที่ให้โดย New Relic Service Architecture Intelligence ความสามารถในการสังเกตของไมโครเซิร์ฟเวอร์ของ New Relic คือ Service Architecture Intelligence ความสามารถนี้จะค้นพบและทําแผนที่ความสัมพันธ์ระหว่างบริการโดยอัตโนมัติเพื่อให้สามารถมองเห็นการพึ่งพาบริการของคุณได้ในเวลาจริง วิศวกรสามารถระบุข้อบกพร่องการแก้ไขปัญหาได้อย่างรวดเร็วและเข้าใจว่าการเปลี่ยนแปลงในบริการหนึ่งอาจส่งผลต่อบริการอื่น ๆ ได้อย่างไร แผนที่สถาปัตยกรรมบริการไม่ใช่แผนภูมิแบบคงที่ แต่เป็นภาพเคลื่อนไหวที่สะท้อนถึงพฤติกรรมจริงของระบบของคุณ พวกเขาอัปเดตโดยอัตโนมัติตามการพัฒนาสถาปัตยกรรมของคุณเพื่อให้มั่นใจว่าทีมงานของคุณมีความเข้าใจที่ถูกต้องเกี่ยวกับความสัมพันธ์บริการโดยไม่ต้องใช้ความพยายามในการจัดเอกสารด้วยตนเอง Queues & Streams Monitoring อาคารไมโครเซิร์ฟเวอร์สมัยใหม่ขึ้นอยู่กับสายการส่งข้อความและสตรีมเพื่อการสื่อสารแบบไม่สอดคล้องกัน การตรวจสอบสายการส่งและสตรีมของ New Relic ให้การมองเห็นแบบสองทิศทางซึ่งเชื่อมโยงหัวข้อกับทั้งผู้ผลิตและบริการผู้บริโภค วิธีการนวัตกรรมใหม่นี้ช่วยให้ทีม DevOps สามารถระบุและแก้ไขปัญหาอย่างรวดเร็วเช่นผู้ผลิตที่ช้าเกินหัวข้อหรือผู้บริโภคที่มีความขัดแย้ง ด้วยข้อมูลเชิงลึกเกี่ยวกับสุขภาพ Kafka ลงไปสู่คลัสเตอร์พาร์ทิชันโบรกเกอร์หัวข้อผู้ผลิตและระดับผู้บริโภคทีมสามารถตรวจจับขีดข่วนที่อาจเกิดขึ้นก่อนที่จะส่งผลต่อประสิทธิภาพของระบบ Fleet and Agent Control การจัดการเครื่องมือในหลายไมโครเซิร์ฟเวอร์อาจเป็นเวลานานและมีแนวโน้มที่จะเกิดข้อผิดพลาด การควบคุมกองทัพและตัวแทนของ New Relic ให้แผนการควบคุมการสังเกตที่ครอบคลุมซึ่งจะศูนย์กลางการทํางานของวงจรชีวิตของเครื่องมือทั้งหมดในสภาพแวดล้อมทั้งหมดของคุณ ด้วยเครื่องมือเหล่านี้ทีมงานสามารถ: การศูนย์กลางการดําเนินงานตัวแทนเพื่อลดแรงงานด้วยตนเอง การอัพเกรดรุ่นตัวแทนสําหรับกองทัพบริการทั้งหมดด้วยการคลิกเพียงไม่กี่ครั้ง การกําจัดจุดตาของโทรเมติกในกลุ่ม Kubernetes เครื่องมืออัตโนมัติในขนาดใหญ่ด้วย API สําหรับเครื่องมือเป็นโค้ด ความสามารถนี้เป็นสิ่งสําคัญอย่างยิ่งสําหรับสภาพแวดล้อมไมโครเซิร์ฟเวอร์ซึ่งการจัดการตัวแทนด้วยตนเองในหลายร้อยบริการจะไม่สามารถใช้ได้ Enhanced Application Performance Monitoring (eAPM) eAPM ของ New Relic ใช้เทคโนโลยี eBPF เพื่อให้ข้อมูลที่ลึกซึ้งเกี่ยวกับประสิทธิภาพของแอพพลิเคชันโดยไม่ต้องแก้ไขรหัสหรือรีสตาร์ทบริการ สิ่งนี้เป็นสิ่งสําคัญสําหรับสภาพแวดล้อมไมโครเซิร์ฟเวอร์ที่วิธีการเครื่องมือแบบดั้งเดิมอาจเป็นปัญหา ความสามารถของ eAPM มี: ความเห็นที่ขับเคลื่อนด้วย AI ที่เชื่อมโยงอัตโนมัติมาตรฐานระหว่างแอพพลิเคชันและคลัสเตอร์ Kubernetes การตรวจสอบการวัดทองคําการทําธุรกรรมและประสิทธิภาพของฐานข้อมูล การเปลี่ยนแปลงอย่างราบรื่นไปยังตัวแทน APM แบบดั้งเดิมเมื่อจําเป็นต้องมีความเข้าใจที่ลึกซึ้งขึ้น สิ่งนี้ช่วยให้ทีมงานสามารถนําไปใช้การสังเกตได้อย่างรวดเร็วในภูมิทัศน์ไมโครบริการของพวกเขาโดยไม่ต้องใช้งานเครื่องมือที่ครอบคลุม Cloud Cost Intelligence โครงสร้างไมโครเซิร์ฟเวอร์มักจะทํางานในสภาพแวดล้อมคลาวด์ซึ่งค่าใช้จ่ายสามารถหายไปได้อย่างรวดเร็ว คุณสมบัติ Cloud Cost Intelligence ของ New Relic ให้การมองเห็นค่าใช้จ่ายทรัพยากรคลาวด์ในเวลาจริงซึ่งช่วยให้ทีมงานสามารถ: ดูและจัดการค่าใช้จ่ายคลาวด์ทั่วองค์กร การประเมินผลกระทบต่อค่าใช้จ่ายของทรัพยากรการคํานวณก่อนการใช้งาน การเก็บรวบรวมและดูข้อมูลโทรเมตริกแบบเรียลไทม์โดยอัตโนมัติเพื่อให้ได้ข้อมูลค่าใช้จ่ายที่ลึกขึ้น ช่วยให้ทีมงานสามารถทํางานร่วมกันระหว่างทีมงานด้านวิศวกรรมการเงินและผลิตภัณฑ์เพื่อให้การจ่ายเงินสอดคล้องกับเป้าหมายทางธุรกิจ การรวมข้อมูลค่าใช้จ่ายกับตัวชี้วัดประสิทธิภาพช่วยให้ทีมงานตัดสินใจเกี่ยวกับการเพิ่มประสิทธิภาพการบริการและการกระจายทรั Real-Time Collaboration and Knowledge Sharing การสังเกตของไมโครเซิร์ฟเวอร์ที่มีประสิทธิภาพต้องมีการทํางานร่วมกันระหว่างทีม New Relic ช่วยให้สามารถทําเช่นนี้ได้ผ่าน Public Dashboards ซึ่งช่วยให้ทีมงานสามารถแบ่งปันข้อมูลที่สําคัญกับผู้มีส่วนร่วมภายในและภายนอกองค์กร แดชบอร์ดเหล่านี้ช่วยให้ทีมงานสามารถ สร้างและแบ่งปันความเห็นได้อย่างง่ายดายโดยใช้ภาษาฐานข้อมูลและคําถามแบบรวมของ New Relic ให้ข้อมูลวัดแบบเรียลไทม์ให้กับผู้ชมโดยไม่จําเป็นต้องใช้การเข้าสู่ระบบ New Relic ใช้การควบคุมการเข้าถึงตามบทบาทสําหรับการรักษาความปลอดภัย ความสามารถนี้ทําลาย silos ระหว่างทีมพัฒนาการดําเนินงานและผู้มีส่วนร่วมในธุรกิจเพื่อส่งเสริมการเข้าถึงที่สม่ําเสมอเกี่ยวกับความน่าเชื่อถือของบริการ ความสามารถในการสังเกตของไมโครบริการในอนาคต พื้นที่ยังคงพัฒนาด้วยการพัฒนาหลายแนวโน้มที่เกิดขึ้น: การวิเคราะห์ที่ขับเคลื่อนด้วย AI: การเรียนรู้เครื่องเพื่อตรวจจับความผิดปกติและแนะนําสาเหตุราก เทคโนโลยี eBPF: เครื่องมือระดับแกนเนลที่มีค่าใช้จ่ายต่ําสุด Open Telemetry Convergence: มาตรฐานต่อเนื่องของการเก็บรวบรวม Telemetry ความสามารถในการสังเกตเป็นรหัส: การกําหนดความต้องการในการสังเกตพร้อมกับโครงสร้างพื้นฐาน ข้อสรุป ความสามารถในการสังเกตได้อย่างมีประสิทธิภาพเปลี่ยนไมโครบริการจากกล่องดําที่มองไม่เห็นได้ไปสู่ระบบที่โปร่งใสและสามารถแก้ไขปัญหาได้ โดยการใช้กลยุทธ์ที่ครอบคลุมรวมถึงการวัดบันทึกและติดตามองค์กรสามารถสร้างความมั่นใจในสถาปัตยกรรมกระจายตัวของพวกเขาและให้ประสบการณ์ผู้ใช้ที่เชื่อถือได้มากขึ้น การลงทุนในความสามารถในการสังเกตได้ไม่เพียง แต่จะช่วยลดเวลาหยุดทํางานและแก้ไขปัญหาได้เร็วขึ้น แต่ยังช่วยให้ทีมงานสามารถนวัตกรรมใหม่ได้ด้วยความมั่นใจในความรู้ว่าพวกเขาสามารถเข้าใจระบบที่ซับซ้อนที่พวกเขาสร้างและบํารุงรักษาได้