การสังเกตการณ์แอปพลิเคชัน อธิบาย: วิธีการตรวจสอบระบบซอฟต์แวร์สมัยใหม่

การสังเกตการณ์แอปพลิเคชัน คือการฝึกปฏิบัติในการเก็บและวิเคราะห์ข้อมูลการตรวจสอบเพื่อทำความเข้าใจว่าแอปพลิเคชันทำอะไร, ทำไมจึงทำตัวในลักษณะเฉพาะ, และผู้ใช้งานได้รับผลกระทบอย่างไร โดยปกติจะนำเอาเมตร, บันทึก, เส้นทาง, เหตุการณ์ และบริบทของแอปพลิเคชันที่เกี่ยวข้องมารวมกัน

แอปพลิเคชันที่ทันสมัยสามารถขยายตัวไปยัง APIs,ไมโครเซอร์วิส, ฐานข้อมูล, คิว, โครงสร้างพื้นฐานของคลาวด์ และบริการของบุคคลที่สาม การตรวจสอบแบบดั้งเดิมสามารถบอกทีมว่าเกิดปัญหาขึ้น แต่การสังเกตการณ์ช่วยวิศวกรในการสอบสวนสาเหตุเบื้องหลัง

การสังเกตเห็นแอปพลิเคชันคืออะไร?

การสังเกตการณ์แอปพลิเคชันมุ่งเน้นไปที่การทำให้พฤติกรรมภายในของแอปพลิเคชันเข้าใจได้จากสัญญาณที่ระบบผลิตออกมา สัญญาณเหล่านี้สามารถช่วยทีมในการตอบคำถามเช่น ทำไมคำขอจึงช้า, การพึ่งพาใดล้มเหลว, ความผิดพลาดส่งผลกระทบต่อกระบวนการทำงานเฉพาะหรือไม่, และมีการเปลี่ยนแปลงอะไรเกิดขึ้นก่อนที่จะเกิดเหตุการณ์

การสังเกตการณ์กว้างกว่าการเก็บข้อมูล คุณค่าเกิดจากการเชื่อมโยงข้อมูลการตรวจสอบกับคำถามเชิงปฏิบัติที่มีความหมายและใช้มันในการสอบสวนและปรับปรุงซอฟต์แวร์

การสังเกตเห็น vs. การติดตาม

การติดตามยังคงเป็นส่วนสำคัญของการมองเห็น สองแนวคิดนี้เสริมกันแทนที่จะเป็นแนวทางที่ไม่สามารถทำงานร่วมกันได้

สัญญาณหลักสามประการของการสังเกตเห็น

เมตริก

เมตริกคือการวัดเชิงตัวเลขที่ถูกเก็บรวบรวมเมื่อเวลาผ่านไป ตัวอย่างการใช้งานรวมถึงอัตราการร้องขอ, ความหน่วง, อัตราความผิดพลาด, ความลึกของคิว, และการใช้งานทรัพยากร

บันทึก

ล็อกบันทึกเหตุการณ์และข้อความในแอปพลิเคชัน ล็อกที่เป็นโครงสร้างมีประโยชน์โดยเฉพาะเพราะฟิลด์เช่นชื่อบริการ, รหัสการร้องขอ, ความรุนแรง, และการดำเนินการสามารถค้นหาและสอดคล้องกันได้อย่างสม่ำเสมอ

เส้นทาง

การติดตามที่กระจายแสดงให้เห็นว่าการร้องขอเดินทางผ่านหลายส่วนประกอบของแอปพลิเคชันอย่างไร สามารถเปิดเผยได้ว่าบริการใด, คำสั่งฐานข้อมูลใด, หรือความขึ้นอยู่ภายนอกใดที่ส่งผลต่อความหน่วงหรือความล้มเหลว

สัญญาณเพิ่มเติมเช่นโปรไฟล์และเหตุการณ์ทางธุรกิจสามารถให้บริบทเพิ่มเติมในกรณีที่สถาปัตยกรรมการมองเห็นสนับสนุน

ทำไมการสังเกตเห็นแอปพลิเคชันจึงมีความสำคัญ

แอปพลิเคชันพึ่งพาส่วนประกอบที่กระจายมากขึ้น การร้องขอจากลูกค้าอาจผ่านเกตเวย์ API, บริการยืนยันตัวตน, บริการแอปพลิเคชัน, แคช, ฐานข้อมูล, ผู้ให้บริการการชำระเงิน, และระบบการส่งข้อความ

เมื่อการร้องขอล้มเหลวหรือช้า การดูเซิร์ฟเวอร์หนึ่งอาจไม่เปิดเผยสาเหตุ การติดตามที่เชื่อมโยงสามารถช่วยวิศวกรติดตามการร้องขอผ่านการขึ้นอยู่ของมันและระบุส่วนประกอบที่รับผิดชอบต่อพฤติกรรมที่สังเกตเห็นได้

การทำงานของการสังเกตเห็นแอปพลิเคชัน

1. แอปพลิเคชันและระบบที่สนับสนุนสร้างข้อมูลเชิงเทคนิค
2. การติดตั้งช่วยแนบบริบทที่มีประโยชน์กับข้อมูลเชิงเทคนิคนั้น
3. โปรแกรมรวบรวมหรือเอเย่นต์รับและประมวลผลข้อมูล
4. ข้อมูลเชิงเทคนิคถูกส่งออกไปยังระบบพื้นหลังการมองเห็น
5. แดชบอร์ด, คำถาม, การแจ้งเตือน, และการติดตามช่วยวิศวกรตรวจสอบพฤติกรรม
6. ทีมใช้ผลการค้นพบในการแก้ไขปัญหาและปรับปรุงแอปพลิเคชัน

ส่วนประกอบหลักของกลยุทธ์การสังเกตเห็น

การติดตั้ง

การติดตั้งกำหนดว่าพฤติกรรมใดของแอปพลิเคชันถูกบันทึก อาจเป็นแบบอัตโนมัติ, แบบแมนนวล, หรือการรวมกันของทั้งสอง

การเก็บรวบรวมข้อมูลเทเลเมตรี

โปรแกรมรวบรวมและเอเย่นต์สามารถรับข้อมูลเชิงเทคนิค, เสริมมัน, กรองมัน, แบ่งกลุ่มมัน, และส่งไปยังระบบจัดเก็บหรือวิเคราะห์

การสัมพันธ์

การเชื่อมโยงเชื่อมต่อข้อมูลเชิงเทคนิคที่สร้างโดยการร้องขอเดียวกัน, การทำธุรกรรม, บริการ, หรือกระบวนการทางธุรกิจ หมายเลขประจำตัวและบริบทการติดตามที่สม่ำเสมอเป็นสิ่งที่มีประโยชน์โดยเฉพาะในระบบที่กระจาย

การวิเคราะห์

วิศวกรต้องการเครื่องมือสำหรับการสอบถามข้อมูลเชิงเทคนิค, การสำรวจการติดตาม, การดูแดชบอร์ด, และการระบุรูปแบบ

การแจ้งเตือน

การแจ้งเตือนควรระบุเงื่อนไขที่ต้องการการดำเนินการ การแจ้งเตือนที่ออกแบบไม่ดีอาจสร้างเสียงรบกวนและทำให้สัญญาณสำคัญถูกมองข้าม

การสังเกตเห็นแอปพลิเคชันและระบบกระจาย

สถาปัตยกรรมที่กระจายทำให้ความจำเป็นในการมองเห็นเพิ่มขึ้นเพราะความล้มเหลวสามารถข้ามขอบเขตบริการ ความล้มเหลวในบริการหนึ่งอาจมาจากฐานข้อมูลที่ช้าหรือ API ที่ต่อเนื่องความช้า

การติดตามที่กระจายสามารถให้มุมมองระดับการร้องขอเกี่ยวกับการโต้ตอบเหล่านี้ เมตริกสามารถแสดงว่าเป็นปัญหาที่แพร่หลายหรือไม่ ในขณะที่ล็อกสามารถให้บริบทเหตุการณ์ที่ละเอียด

การติดตามประสิทธิภาพแอปพลิเคชันและการสังเกตเห็น

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

ขอบเขตที่แน่นอนระหว่าง APM และการมองเห็นแตกต่างกันไปตามผลิตภัณฑ์และองค์กร สิ่งที่สำคัญทางปฏิบัติคือวิศวกรสามารถได้รับบริบทเพียงพอในการตรวจจับ, สืบสวน, และแก้ไขปัญหาในแอปพลิเคชันหรือไม่

บริบททางธุรกิจในด้านการสังเกตเห็น

ข้อมูลเชิงเทคนิคจะเป็นประโยชน์มากขึ้นเมื่อสามารถเชื่อมต่อกับกระบวนการทางธุรกิจ ตัวอย่างเช่น การเพิ่มขึ้นของความหน่วงใน API อาจมีความสำคัญมากขึ้นเมื่อส่งผลต่อการทำรายการเสร็จสิ้นหรืองานลงทะเบียนบัญชี

ทีมสามารถเพิ่มคุณลักษณะทางธุรกิจหรือเหตุการณ์ที่เลือกอย่างระมัดระวังเข้าสู่อุปกรณ์ข้อมูลเชิงเทคนิคในขณะที่เคารพความเป็นส่วนตัวและความต้องการลดข้อมูล สิ่งนี้ช่วยเชื่อมโยงเหตุการณ์ทางเทคนิคกับผลกระทบที่มุ่งหน้าไปยังผู้ใช้.

การสังเกตเห็นแอปพลิเคชันและ OpenTelemetry

OpenTelemetry ให้ API, SDK, การติดตั้ง, ข้อตกลงทางอาคตและส่วนประกอบการเก็บข้อมูลที่ไม่ขึ้นกับผู้ขายสำหรับ telemetry เช่น traces, metrics และ logs ดังนั้นจึงสามารถเป็นส่วนสำคัญของสถาปัตยกรรมการสังเกตเห็นแอปพลิเคชัน

OpenTelemetry ไม่ได้แทนที่ระบบหลังบ้านสำหรับการสังเกตเห็น Telemetry โดยปกติต้องส่งออกไปยังระบบที่ให้การจัดเก็บ, การค้นหา, การแสดงผล, และการแจ้งเตือน

การพิจารณาด้านความปลอดภัยและความเป็นส่วนตัว

ข้อมูลการสังเกตเห็นอาจมีข้อมูลที่ละเอียดอ่อน URL, พารามิเตอร์การร้องขอ, ตัวระบุผู้ใช้, คำสั่งฐานข้อมูล, ข้อความข้อยกเว้น และ logs อาจเปิดเผยข้อมูลที่เป็นความลับหากการติดตั้งไม่ถูกออกแบบมาอย่างดี

• อย่าวางรหัสผ่าน, API keys หรือโทเคนใน telemetry
• ตรวจสอบข้อมูลที่สามารถระบุตัวตนออกเท่าก่อนการเก็บข้อมูล
• ใช้การควบคุมการเข้าถึงกับแพลตฟอร์มการสังเกตเห็น
• เข้ารหัส telemetry ระหว่างการส่งข้อมูลเมื่อเหมาะสม
• กำหนดนโยบายการเก็บรักษาและการลบข้อมูล
• ใช้การกรองหรือการแก้ไขสำหรับฟิลด์ที่ละเอียดอ่อน

การพิจารณาด้านต้นทุนและประสิทธิภาพ

Telemetry ใช้ทรัพยากรการคอมพิวเตอร์, แบนด์วิดธ์เครือข่าย และการจัดเก็บ ข้อมูลที่มีความหลากหลายสูงและ logs ที่มีรายละเอียดมากเกินไปอาจมีค่าใช้จ่ายสูงและค้นหาได้ยาก

การสุ่มตัวอย่าง, การกรอง, การรวม, นโยบายการเก็บรักษา และระดับ log ที่เหมาะสมสามารถช่วยควบคุมค่าใช้จ่าย ทีมงานควรวัดคุณภาพ telemetry แทนที่จะเก็บปริมาณสูงสุดที่เป็นไปได้

วิธีการสร้างกลยุทธ์การสังเกตเห็นแอปพลิเคชัน

1. ระบุเส้นทางผู้ใช้ที่สำคัญที่สุดของแอปพลิเคชัน
2. กำหนดตัวชี้วัดระดับการบริการและเมตริกปฏิบัติการที่มีประโยชน์
3. ติดตั้งเส้นทางที่สำคัญของแอปพลิเคชันและการพึ่งพา
4. มาตรฐานการบันทึกโครงสร้างและตัวระบุการเชื่อมโยง
5. ใช้การติดตามแบบกระจายเมื่อเหมาะสม
6. สร้างแดชบอร์ดโดยรอบคำถามปฏิบัติการที่มีความหมาย
7. สร้างการแจ้งเตือนที่สามารถดำเนินการได้โดยมีความรับผิดชอบที่ชัดเจน
8. ตรวจสอบคุณภาพ, ความปลอดภัย, การเก็บรักษา, และค่าใช้จ่ายของ telemetry อย่างสม่ำเสมอ

เคล็ดลับจากผู้เชี่ยวชาญ

• เริ่มต้นด้วยเส้นทางผู้ใช้ที่สำคัญแทนที่จะติดตั้งทุกอย่างอย่างเท่าเทียมกัน
• ใช้ชื่อบริการและข้อมูลเมตาดาทาที่สอดคล้องกันทั่วทุกสภาพแวดล้อม
• เชื่อมต่อ traces, logs และ metrics ผ่านบริบทที่แชร์กัน
• คงรักษาการแจ้งเตือนให้มุ่งเน้นไปที่สถานการณ์ที่ต้องการการดำเนินการจากมนุษย์
• บันทึกบริบทพอเพียงเพื่อวินิจฉัยความล้มเหลวโดยไม่เก็บข้อมูลที่ละเอียดอ่อนที่ไม่จำเป็น
• ทดสอบการเฝ้าสังเกตการณ์ในช่วงที่เกิดความล้มเหลวที่ควบคุมได้ ไม่เพียงแต่ในช่วงการทำงานปกติเท่านั้น

ข้อผิดพลาดทั่วไปในการสังเกตเห็นแอปพลิเคชัน

• การเก็บข้อมูลเทเลเมตรีจำนวนมากโดยไม่มีวัตถุประสงค์ที่ชัดเจน
• การสร้างแดชบอร์ดที่แสดงข้อมูลแต่ไม่สามารถตอบคำถามการดำเนินงานได้
• การใช้ตัวระบุที่ไม่สอดคล้องกันระหว่างบริการต่างๆ
• การมองข้ามความปลอดภัยและความเป็นส่วนตัวของเทเลเมตรี
• การแจ้งเตือนในทุกข้อผิดพลาดแทนที่จะจัดลำดับความสำคัญของสภาพที่มีผลกระทบต่อผู้ใช้
• ล้มเหลวในการเฝ้าติดตามท่อการเฝ้าสังเกตการณ์เอง

คำถามที่พบบ่อย

การสังเกตการณ์แอปพลิเคชันในแง่ที่ง่ายคืออะไร?

มันคือการใช้เทเลเมตรีเพื่อเข้าใจพฤติกรรมภายในของแอปพลิเคชันและตรวจสอบว่าทำไมมันถึงผลิตผลลัพธ์เฉพาะอย่าง

สัญญาณการสังเกตการณ์หลักมีอะไรบ้าง?

เมตริก, บันทึก, และการติดตามเป็นสัญญาณหลักที่มักใช้ในการเฝ้าสังเกตการณ์แอปพลิเคชัน โปรไฟล์และเหตุการณ์ทางธุรกิจสามารถเพิ่มบริบทเพิ่มเติมได้

ความแตกต่างระหว่างการสังเกตการณ์และการตรวจสอบคืออะไร?

การเฝ้าติดตามมักมุ่งเน้นไปที่การติดตามสภาวะที่รู้จัก ขณะที่การเฝ้าสังเกตการณ์เน้นการใช้ข้อมูลจากระบบเพื่อตรวจสอบพฤติกรรมและปัญหาอย่างกว้างขวาง

OpenTelemetry เป็นแพลตฟอร์มการสังเกตการณ์หรือไม่?

OpenTelemetry เป็นกรอบการเฝ้าสังเกตการณ์ที่เปิดกว้างและระบบนิเวศของเทเลเมตรี โดยทั่วไปทำงานร่วมกับแบ็คเอนด์ที่แยกจากกันสำหรับการจัดเก็บ, การวิเคราะห์, แดชบอร์ด, และการแจ้งเตือน

การสังเกตการณ์ช่วยปรับปรุงประสิทธิภาพแอปพลิเคชันหรือไม่?

การเฝ้าสังเกตการณ์สามารถช่วยทีมในการระบุจุดคอขวดด้านประสิทธิภาพและการเสื่อมถอย มันไม่ได้ปรับปรุงประสิทธิภาพโดยอัตโนมัติ วิศวกรใช้ข้อมูลที่ได้เพื่อทำการเปลี่ยนแปลง

การสังเกตการณ์แอปพลิเคชันมีไว้สำหรับไมโครเซอร์วิสเท่านั้นหรือ?

ไม่ มันสามารถเป็นประโยชน์สำหรับแอปพลิเคชันโมโนลิธ, งานที่ไม่มีเซิร์ฟเวอร์, แบ็คเอนด์มือถือและเว็บไซต์, และระบบที่กระจาย

แอปพลิเคชันควรเก็บข้อมูลการตรวจสอบเท่าไหร่?

เพียงพอที่จะตอบคำถามการดำเนินงานที่สำคัญในขณะที่ควบคุมค่าใช้จ่าย, ประสิทธิภาพ, ความเป็นส่วนตัว, และการเก็บรักษา ระดับที่เหมาะสมขึ้นอยู่กับแอปพลิเคชันและโปรไฟล์ความเสี่ยงของมัน

สิ่งที่ผู้เริ่มต้นควรตรวจสอบก่อนคืออะไร?

เริ่มต้นด้วยความพร้อมใช้งาน, อัตราขอ, ความล่าช้า, ข้อผิดพลาด, ขึ้นอยู่กับที่สำคัญ, เส้นทางผู้ใช้ที่สำคัญ, และบันทึกและการติดตามที่เพียงพอสำหรับการตรวจสอบความล้มเหลว

บทสรุป

การสังเกตการณ์แอปพลิเคชัน ให้ทีมวิศวกรรมมีวิธีการที่เป็นระบบในการเข้าใจพฤติกรรมของซอฟต์แวร์ผ่านเมตริก, บันทึก, การติดตาม, และบริบทที่เกี่ยวข้อง โดยเฉพาะมีค่ามากเมื่อแอปพลิเคชันครอบคลุมหลายบริการและชั้นโครงสร้างพื้นฐาน

กลยุทธ์การเฝ้าสังเกตการณ์ที่มีประโยชน์ไม่ได้ถูกกำหนดโดยปริมาณของข้อมูลที่เก็บรวบรวม แต่มันถูกกำหนดโดยว่าวิศวกรสามารถตอบคำถามสำคัญเกี่ยวกับสุขภาพของแอปพลิเคชัน, ผลกระทบของผู้ใช้, ความขึ้นอยู่, และความล้มเหลวอย่างรวดเร็วในขณะที่รักษาความปลอดภัยและการควบคุมค่าใช้จ่ายที่เหมาะสม

ดำเนินการต่อเนื่องจากซีรีส์เทคโนโลยี: ถัดไปคือ เทคโนโลยี eBPF, which explores how the Linux kernel can provide powerful visibility and programmability for modern systems.