การตรวจสอบและการสังเกต: กฎเกณฑ์เมตริก บันทึก การติดตาม และสัญญาณเตือน

กำไร:

• ความสามารถในการเข้าใจเสาหลักสามประการของความสามารถในการสังเกต (หน่วยเมตริก บันทึก การติดตาม) และสัญญาณทองทั้งสี่ และให้ปัญญาประดิษฐ์สร้างคำสั่ง PromQL กฎการแจ้งเตือน และแดชบอร์ด
• ความสามารถในการป้องกันความล้าของสัญญาณเตือนโดยให้ความสำคัญกับการดำเนินการของสัญญาณเตือนและตามความเร่งด่วนที่เหมาะสม และเกณฑ์การทดสอบกับข้อมูลประวัติของระบบของคุณเอง
• ความสามารถในการป้องกันความเป็นส่วนตัวและการรั่วไหลของความลับโดยการปิดบังพื้นที่ละเอียดอ่อนก่อนที่จะมอบบันทึกให้กับปัญญาประดิษฐ์

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

• ตัวชี้วัด: ค่าตัวเลขที่วัดในช่วงเวลาต่างๆ — การใช้งาน CPU, จำนวนคำขอ, เวลาตอบสนอง, อัตราข้อผิดพลาด "เท่าไร?" ตอบคำถาม
• บันทึก: บันทึกเหตุการณ์ข้อความที่ระบบสร้างขึ้น ได้แก่ "ผู้ใช้เข้าสู่ระบบ", "การเชื่อมต่อฐานข้อมูลขาดหาย" “เกิดอะไรขึ้นกันแน่?” ตอบคำถาม
• ติดตาม: เส้นทางที่คำขอตามมาขณะส่งผ่านจากบริการหนึ่งไปยังอีกบริการหนึ่งภายในระบบและระยะเวลาของแต่ละขั้นตอน “ช้าตรงไหน” ตอบคำถาม

เครื่องมือที่พบบ่อยที่สุด: Prometheus สำหรับหน่วยเมตริก, Grafana สำหรับการแสดงภาพ, Loki/ELK สำหรับบันทึก, Jaeger/OpenTelemetry สำหรับการติดตาม AI มีทักษะมากในการเขียนภาษาคิวรี (โดยเฉพาะ PromQL ของ Prometheus) กฎการแจ้งเตือน และการกำหนดค่าแดชบอร์ดสำหรับเครื่องมือเหล่านี้ นอกจากนี้ ยังเป็นจุดที่ AI แข็งแกร่งที่สุดอีกด้วย: การสรุปบันทึกและตัวชี้วัดจำนวนมาก และการรายงานความผิดปกติ

มาชี้แจงความแตกต่างระหว่างการตรวจสอบและความสามารถในการสังเกตในประโยคเดียว: การตรวจสอบเป็นการถามคำถามที่คุณรู้อยู่แล้ว (“CPU เกิน 90% หรือไม่?”); ความสามารถในการสังเกตสามารถถามคำถามที่คุณไม่รู้ได้ ("เหตุใดความล่าช้าแปลกๆ นี้จึงเกิดขึ้นกับลูกค้าบางรายในช่วงเวลาหนึ่งเท่านั้น") ระบบสมัยใหม่มีความซับซ้อนมากจนคุณไม่สามารถคาดเดารูปแบบความล้มเหลวได้ทั้งหมด ดังนั้น ความสามารถในการรวบรวมตัววัด บันทึก และการติดตามที่หลากหลาย แล้วสืบค้นในเชิงลึก ซึ่งก็คือความสามารถในการสังเกตจึงเป็นสิ่งสำคัญ นี่คือจุดที่ AI เข้ามามีบทบาทเมื่อตอบคำถาม "คำถามที่ไม่ทราบมาก่อน" โดยจะสแกนข้อมูลดิบที่คุณมีอย่างรวดเร็ว แนะนำรูปแบบและความผิดปกติ และคุณจะทราบสาเหตุที่แท้จริงโดยการตรวจสอบเบาะแสเหล่านี้

ทีละขั้นตอน: อะไรและจะตรวจสอบอย่างไร?

1. เลือกตัวชี้วัดที่เหมาะสม ในอุตสาหกรรมนั้น "สัญญาณทองสี่ประการ" ถือเป็นพื้นฐาน: เวลาแฝง การรับส่งข้อมูล ข้อผิดพลาด ความอิ่มตัว — ทรัพยากรมีเพียงพอเพียงใด ข้อมูลเหล่านี้สรุปความสมบูรณ์ของบริการส่วนใหญ่
2. รวบรวมตัวชี้วัด ให้แอปพลิเคชันนำเสนอตำแหน่งข้อมูลที่ Prometheus สามารถอ่านได้
3. ตั้งค่าแดชบอร์ด แสดงภาพตัวชี้วัดเหล่านี้ใน Grafana
4. เขียนกฎการเตือน ใครจะได้รับคำเตือนเมื่อเกินเกณฑ์และอย่างไร?
5. รวมบันทึกไว้ที่ศูนย์กลาง ทำให้บันทึกการบริการทั้งหมดสามารถค้นหาได้ในที่เดียว
6. ลดเสียงรบกวน สัญญาณเตือนมากเกินไปทำให้เกิด “การแจ้งเตือนเมื่อยล้า”; สัญญาณเตือนภัยที่สำคัญจะหายไป

เคล็ดลับ: การเตือนที่ดีต้องคำนึงถึงสองสิ่ง: ดำเนินการได้และมีความเร่งด่วนที่เหมาะสม การปลุกที่ปลุกคนตื่นตอนตี 3 จะต้องเป็นสิ่งที่ต้องมีการแทรกแซงในเวลากลางคืนจริงๆ อย่าปลุกใครให้ตื่นด้วยบางสิ่งที่ไม่ต้องดำเนินการใดๆ เช่น "CPU 70%"; แสดงไว้บนกระดาน

จะเขียนกฎการเตือนได้อย่างไร?

การแจ้งเตือนประกอบด้วยองค์ประกอบ 3 ส่วน: เงื่อนไข (ตัวชี้วัดใดเกินเกณฑ์และระยะเวลา) ระยะเวลา ("เป็นเวลา 5 นาที" เพื่อหลีกเลี่ยงให้เกิดความผันผวนชั่วขณะ) และความสำคัญ/การดำเนินการ (ถึงใคร ผ่านช่องทางใด) AI สร้างสามสิ่งนี้อย่างเชี่ยวชาญด้วยบริบทที่ถูกต้อง ตัวอย่างเช่น การแปลกฎ เช่น “การแจ้งเตือนที่สำคัญหากอัตราข้อผิดพลาดเกิน 5% เป็นเวลา 5 นาที” เป็น PromQL นั้นเป็นงานเสี้ยววินาทีสำหรับ AI ​​แต่คุณจะเป็นผู้ตัดสินใจว่าเกณฑ์นั้นเหมาะสมกับระบบของคุณหรือไม่

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

บันทึกความเป็นส่วนตัว: คำเตือนที่สำคัญ

บันทึกเป็นสาเหตุของการรั่วไหลที่ถูกมองข้ามบ่อยที่สุด บรรทัดบันทึกอาจมีรหัสผ่าน หมายเลขบัตรเครดิต หรือข้อมูลส่วนบุคคล (ภายใต้ KVKK/GDPR) โดยไม่ได้ตั้งใจ เมื่อวางบันทึกลงใน AI เพื่อการวิเคราะห์:

1. มาส์กบริเวณที่บอบบาง แทนที่ค่าต่างๆ เช่น โทเค็น รหัสผ่าน อีเมล หมายเลขประจำตัวด้วย <REDACTED>
2. ยกตัวอย่าง ไม่ใช่ทั้งหมด แทนที่จะเป็นล้านบรรทัด เพียงไม่กี่ร้อยบรรทัดก็มักจะเพียงพอแล้ว
3. เลือกรถที่สถาบันรับรอง โดยเฉพาะอย่างยิ่งสำหรับบันทึกการผลิต ให้ใช้เครื่องมือที่ไม่มีข้อมูลไปฝึกอบรม

สัญญาณทองคำสี่สัญญาณและตารางสัญญาณเตือน

สัญญาณ

วัดโดย

ตัวอย่างเกณฑ์การเตือน

ความเร่งด่วน

เวลาแฝง

เวลาตอบสนอง

p95 > 800 มิลลิวินาที 5 นาที

สูง

การจราจร

คำขอ/วินาที

เพิ่ม/ลดทันที 300%

ปานกลาง

เกิดข้อผิดพลาด

อัตราคำขอล้มเหลว

> 5%, 5 นาที

สำคัญ

ความอิ่มตัว

การครอบครองทรัพยากร

ดิสก์ > 85%

สูง

มินิเคสสามอัน

กรณีที่ 1 — สรุปบันทึก 400 บรรทัดใน 30 วินาที การบริการชะลอตัวลง วิศวกรมอบบันทึก 400 บรรทัดที่ปกปิดไว้ให้กับ AI และกล่าวว่า "สรุปรูปแบบข้อผิดพลาดที่เกิดซ้ำและความเข้มข้นของเวลา" AI แสดงให้เห็นว่าการเรียก API ภายนอกโดยเฉพาะหมดเวลาทุกๆ 30 วินาที พบสาเหตุที่แท้จริงใน 30 วินาที การสแกนบันทึกด้วยตนเองจะใช้เวลาครึ่งชั่วโมง

กรณีที่ 2 — แก้ไขความล้าของสัญญาณเตือนแล้ว ทีมหนึ่งได้รับสัญญาณเตือน 200 ครั้งต่อวันและเพิกเฉยต่อการแจ้งเตือนทั้งหมด จนกระทั่งสัญญาณเตือนไฟดับจริงๆ ก็ถูกมองข้ามไป มอบกฎการแจ้งเตือนทั้งหมดให้กับ AI แล้วถามว่า "อันไหนที่ดำเนินการไม่ได้และอันไหนที่สามารถรวมกันได้" พวกเขาถาม จำนวนการปลุกลดลงเหลือ 12 ครั้งต่อวัน ตอนนี้ทุกสัญญาณเตือนภัยได้รับการดำเนินการอย่างจริงจังแล้ว

กรณีที่ 3 — จับเกณฑ์ผิดตั้งแต่เนิ่นๆ YZ แนะนำ "เตือนเมื่อเต็ม 95%" สำหรับดิสก์ วิศวกรดูข้อมูลประวัติ: เมื่อดิสก์ถึง 95% ก็มีเวลาเพียงเล็กน้อยสำหรับการแทรกแซง ลดเกณฑ์ลงเหลือ 80% และเพิ่มการแจ้งเตือนครั้งที่สองตาม "อัตราการเติบโต" การยืนยันป้องกันการหยุดทำงานตอนเที่ยงคืนจริง ๆ

เทมเพลตที่สามารถคัดลอกได้สี่แบบ

1) การสรุปบันทึก (สวมหน้ากาก):

วิเคราะห์ตัวอย่างบันทึกด้านล่าง (ฉันปกปิดค่าที่ละเอียดอ่อนด้วย <REDACTED>) ให้ฉัน: (1) รูปแบบข้อผิดพลาดที่เกิดซ้ำ (2) สมาธิเมื่อเวลาผ่านไป (3) สาเหตุที่เป็นไปได้มากที่สุด และ (4) ตัวชี้วัด 3 ตัวที่ฉันจะดูเพื่อตรวจสอบ บันทึก: [LINES]

2) การสร้างกฎการเตือน:

เขียนกฎการเตือนสำหรับ Prometheus/Alertmanager: สร้างการเตือน [SEVERITY] หาก [THRESHOLD] เกิน [METRIC][DURATION] กฎควรเน้นการดำเนินการและรวมช่องคำอธิบายประกอบและลิงก์ Runbook อธิบาย PromQL และเขียนว่าเหตุใดเกณฑ์นี้จึงสมเหตุสมผล

3) การเขียน/ประกาศแบบสอบถาม PromQL:

เขียนแบบสอบถาม PromQL ที่วัด: [EX. เปอร์เซ็นต์อัตราข้อผิดพลาด 5xx ในช่วง 5 นาทีที่ผ่านมา] อธิบายคำถามทีละขั้นตอน แล้วบอกฉันว่าช่วงที่ดีต่อสุขภาพของค่านี้ควรเป็นเท่าใด

4) การออกแบบแดชบอร์ด:

ออกแบบแดชบอร์ด Grafana สำหรับ [บริการ]: ฉันควรแสดงสัญญาณสีทองสี่สัญญาณด้วยแผงใด (เวลาแฝง การรับส่งข้อมูล ข้อผิดพลาด ความอิ่มตัว) แนะนำตัวชี้วัด ประเภทการแสดงภาพ และเกณฑ์ที่เหมาะสมสำหรับแต่ละแผง วัตถุประสงค์: เพื่อดูสถานะสุขภาพของยามใน 10 วินาที

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

อ่อนแอ: "มีอะไรอยู่ในบันทึกนั้น?" (ตามด้วยบันทึกดิบ 5,000 บรรทัด มีโทเค็นอยู่ในนั้น)

ผลลัพธ์: คุณเปิดเผยความลับ และ AI ให้ข้อมูลสรุปแบบผิวเผินที่ไม่ตรงเป้าหมาย

แข็งแกร่ง: "ค้นหารูปแบบข้อผิดพลาดที่เกิดซ้ำและความเข้มข้นของเวลาในตัวอย่างบันทึกที่ปกปิด 300 บรรทัดด้านล่าง บอกสาเหตุที่แท้จริงที่เป็นไปได้มากที่สุดและตัวชี้วัดที่ฉันจะดูเพื่อตรวจสอบ ฉันทำโทเค็น <ข้อมูลปกปิด>"

ความแตกต่าง: พรอมต์ที่สองให้ตัวอย่างที่ปกปิดและมุ่งเน้น โดยขอผลลัพธ์การวิเคราะห์ที่ชัดเจน ทั้งปลอดภัยและมีประโยชน์

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

สำหรับบริการ (หรือบริการตัวอย่าง): (1) มีการสร้างกฎการแจ้งเตือนสำหรับอัตราข้อผิดพลาดด้วยเทมเพลต "การสร้างกฎการแจ้งเตือน" และตั้งค่าเกณฑ์ที่แนะนำเป็น "มีการทริกเกอร์กี่ครั้งในอดีต" ทดสอบด้วยคำถาม (2) ปิดบังตัวอย่างบันทึกที่คุณมี และนำไปวิเคราะห์ด้วยเทมเพลต "การสรุปบันทึก" (3) จดบันทึกว่าคุณจะพิจารณาเมตริกใดเพื่อยืนยันสาเหตุที่แท้จริงที่เป็นไปได้มากที่สุด

รายการตรวจสอบ

• [ ] ฉันเลือกหน่วยเมตริกที่จะติดตามโดยอิงตามสัญญาณทองสี่สัญญาณ
• [ ] ฉันปกปิดบันทึกทั้งหมดที่ฉันให้กับ AI ในแง่ของพื้นที่ละเอียดอ่อน
• [ ] ฉันตรวจสอบแล้วว่าสัญญาณเตือนแต่ละรายการเน้นไปที่การดำเนินการและมีความเร่งด่วนที่ถูกต้อง
• [ ] ฉันทดสอบเกณฑ์การแจ้งเตือนกับข้อมูลประวัติของระบบ
• [ ] ฉันกรองความผันผวนที่เกิดขึ้นทันทีโดยการเพิ่ม (ระยะเวลา) ให้กับเสียงปลุก
• [ ] ฉันใช้เมตริก + บันทึก + ติดตามร่วมกันเพื่อหาสาเหตุที่แท้จริง