สังเกตบริการและผู้ใช้

เริ่มจากคำถาม

Monitoring ตรวจเงื่อนไขที่ทราบ ส่วน observability ช่วยสืบหาพฤติกรรมระบบ รวมถึงความขัดข้องที่ไม่ได้คาดการณ์ Dashboard ที่มากขึ้นไม่ได้ให้คำตอบที่ดีขึ้นโดยอัตโนมัติ

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

OpenTelemetry ให้เครื่องมือ instrumentation และมาตรฐาน telemetry สามารถส่งสัญญาณไปยัง backend ที่เข้ากันได้ คุณยังต้องมีที่เก็บข้อมูล query การควบคุมสิทธิ์ ระยะเวลาเก็บรักษา และคนที่ดำเนินการจากหลักฐาน ความรู้เบื้องต้นเรื่อง observability

เชื่อมหลักฐานต่างรูปแบบ

Metric วัดปริมาณตามเวลา Log บันทึกเหตุการณ์ Trace เชื่อมการทำงานที่เกี่ยวข้องขณะคำขอผ่านระบบ Span แทนการทำงานหนึ่งอย่างภายใน trace

สำหรับงาน asynchronous ให้รักษาความเชื่อมโยงที่ปลอดภัยระหว่างงานที่ส่งกับการทำงานของ worker HTTP 202 อาจหมายถึงรับงานแล้ว ไม่ได้พิสูจน์ว่าการส่งออกเสร็จ

แจ้งเตือนเมื่อต้องดำเนินการ

กำหนด SLI และตัวหารก่อนตั้ง SLO ในตัวอย่างให้นับการส่งออกที่เข้าเกณฑ์และเสร็จถูกต้องภายในเวลาที่ตกลง กำหนดวิธีนับงานที่ทำงานนานและงานที่ถูกละทิ้งในการวัด

Error budget อธิบายความล้มเหลวที่ยอมให้เกิดได้ในช่วง SLO ส่วน burn rate อธิบายว่าความล้มเหลวใช้ budget นั้นเร็วเพียงใด แนวทางของ Google ใช้หลายช่วงเวลาเพื่อสมดุลระหว่างการตรวจพบทันเวลากับ alert ที่รบกวน การแจ้งเตือนตาม SLO

เรียกผู้รับผิดชอบเมื่อเงื่อนไขนั้นต้องได้รับการดำเนินการทันเวลา ส่งงานเร่งด่วนน้อยกว่าเข้าคิว Alert ทุกอันต้องมีผู้รับผิดชอบ คำอธิบายผลกระทบ ลิงก์สำหรับสืบหาสาเหตุ และคำแนะนำตอบสนอง ทบทวน alert ที่เกิดซ้ำแต่ไม่ได้นำไปสู่การดำเนินการ

อย่าใช้ threshold ทั่วไปค่าเดียวกับทุกบริการ ผลกระทบต่อผู้ใช้ traffic เวลาทำการ และกำลังคนตอบสนองล้วนมีผลต่อการตัดสินใจ

ป้องกัน telemetry pipeline

Telemetry อาจมีข้อมูลส่วนบุคคล token, request parameter และเอกสารลับ กำหนด field ที่อนุญาตก่อนเก็บ จำกัดการเข้าถึงและระยะเวลาเก็บรักษา นำ secret ออกก่อนส่งไปยัง backend ภายนอก Telemetry ที่มีข้อมูลอ่อนไหว

อย่าใช้อีเมลลูกค้าหรือ job ID ที่ไม่ซ้ำเป็น metric label Label ที่ไม่มีขอบเขตจำกัดเพิ่มจำนวน time series และอาจเปิดเผยรหัส ใช้มิติที่ควบคุมได้สำหรับ metrics ใส่รหัสเชื่อมโยงที่ได้รับอนุมัติไว้ใน log หรือ trace ที่ควบคุมการเข้าถึง

วัด pipeline เองด้วย ตรวจสอบการรับข้อมูลที่ล้มเหลว ข้อมูลที่ถูกทิ้ง และอายุของข้อสังเกตล่าสุด กราฟ error ที่ราบอาจหมายถึงไม่มี error หรือไม่มี telemetry เข้ามา แสดงความต่างนี้

สืบหาความขัดข้องที่เป็นรูปธรรม

บริการในสถานการณ์สมมติรายงาน HTTP 202 สำหรับทุกคำขอ อายุของงานในคิวเพิ่มจากระดับวินาทีเป็น 15 นาที Log ของ worker แสดง database timeout ซ้ำ Trace ที่สุ่มเก็บแสดงว่าเวลาส่วนใหญ่ของ worker อยู่ที่การเรียกฐานข้อมูล

หลักฐานนี้สนับสนุนการสืบหาสาเหตุที่เจาะจง แต่ยังไม่ยืนยันว่าสาเหตุคือการเปลี่ยน query การใช้ connection จนหมด หรือความจุฐานข้อมูล เปรียบเทียบสมมติฐานเหล่านี้ด้วยวิธี debug

Taiga Monitoring ให้มุมมองสถานะผลิตภัณฑ์ด้วยสัญญาณความพร้อมใช้งานและประสบการณ์ผ่าน browser ช่วยเสริม observability ของโครงสร้างพื้นฐานและแอปพลิเคชัน ไม่ได้แทนระบบเหล่านั้น Monitoring