เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

Hello!

บริษัทของเรามีส่วนร่วมในการพัฒนาซอฟต์แวร์และการสนับสนุนด้านเทคนิคในภายหลัง การสนับสนุนทางเทคนิคไม่เพียงแต่ต้องการการแก้ไขข้อผิดพลาด แต่ยังต้องติดตามประสิทธิภาพของแอปพลิเคชันของเราอีกด้วย

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

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

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

กลยุทธ์การติดตาม

การตรวจสอบฟังก์ชันการทำงานของแอปพลิเคชันไม่ใช่เรื่องง่ายงานนี้ไม่สำคัญใคร ๆ ก็บอกว่าสร้างสรรค์ด้วยซ้ำ การตรวจสอบระบบมัลติลิงค์ที่ซับซ้อนเป็นเรื่องยากเป็นพิเศษ

คุณจะกินช้างได้อย่างไร? เฉพาะบางส่วนเท่านั้น! เราใช้แนวทางนี้เพื่อตรวจสอบแอปพลิเคชัน

สาระสำคัญของกลยุทธ์การติดตามของเรา:

แบ่งแอปพลิเคชันของคุณออกเป็นส่วนประกอบต่างๆ
สร้างการตรวจสอบการควบคุมสำหรับแต่ละส่วนประกอบ

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

ดังนั้นระบบใดๆ ก็สามารถแสดงเป็นแผนผังส่วนประกอบได้ ส่วนประกอบที่ซับซ้อนจะถูกแบ่งออกเป็นองค์ประกอบที่ง่ายกว่า ส่วนประกอบง่ายๆมีการตรวจสอบ

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

ไม่มีปาฏิหาริย์ใด ๆ เช็คส่วนใหญ่จะต้องได้รับการพัฒนาอย่างอิสระ แต่อย่ากลัว เพราะในกรณีส่วนใหญ่ เช็คหนึ่งรายการจะใช้เวลาโค้ด 5-10 บรรทัด แต่คุณสามารถใช้ตรรกะใดๆ ก็ได้ และคุณจะเข้าใจวิธีการทำงานของเช็คอย่างชัดเจน

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

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

เราจะต้องมีระบบติดตาม เธอจะทำหน้าที่ดังต่อไปนี้:

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

คำอธิบายโดยย่อของระบบ ASMO

ทางที่ดีควรอธิบายด้วยตัวอย่าง มาดูกันว่ามีการจัดการติดตามประสิทธิภาพของระบบ ASMO อย่างไร

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

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

ดังนั้น องค์ประกอบของระบบจึงเป็นเรื่องปกติ: เว็บไซต์ ตัวแทน อุปกรณ์ มาเริ่มติดตามกันเลย

การแบ่งระบบออกเป็นส่วนประกอบต่างๆ

ส่วนประกอบต่อไปนี้สามารถแยกแยะได้ในระบบ ASMO:

1. บัญชีส่วนตัว
นี่คือแอปพลิเคชันเว็บ อย่างน้อยที่สุด คุณต้องตรวจสอบว่าแอปพลิเคชันนั้นพร้อมใช้งานบนอินเทอร์เน็ตหรือไม่

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

3. เซิร์ฟเวอร์
โดยเซิร์ฟเวอร์ เราหมายถึงฮาร์ดแวร์ที่แอปพลิเคชันทำงาน จำเป็นต้องตรวจสอบสถานะของ HDD, RAM, CPU

4. ตัวแทน
นี่คือบริการของ Windows ที่ทำงานต่างๆ มากมายตามกำหนดเวลา อย่างน้อยที่สุด คุณต้องตรวจสอบว่าบริการกำลังทำงานอยู่

5. งานตัวแทน
แค่รู้ว่าตัวแทนทำงานยังไม่เพียงพอ ตัวแทนอาจทำงานได้ แต่ไม่ปฏิบัติงานที่ได้รับมอบหมาย มาแบ่งส่วนประกอบตัวแทนออกเป็นงานและตรวจสอบว่างานตัวแทนแต่ละงานทำงานได้สำเร็จหรือไม่

6. จุดควบคุมถนน (ตู้คอนเทนเนอร์ของ กนง. ทั้งหมด)
มีจุดควบคุมถนนหลายจุด ดังนั้นเรามารวม MPC ทั้งหมดไว้ในองค์ประกอบเดียวกันดีกว่า ซึ่งจะทำให้สะดวกยิ่งขึ้นในการอ่านข้อมูลการตรวจสอบ เมื่อดูสถานะของส่วนประกอบ “ระบบ ASMO” จะชัดเจนทันทีว่าปัญหาอยู่ที่ใด: ในแอปพลิเคชัน ฮาร์ดแวร์ หรือในระบบควบคุมสูงสุด

7. จุดควบคุมถนน (ขีดจำกัดสูงสุดหนึ่งจุด)
เราจะถือว่าส่วนประกอบนี้สามารถใช้งานได้หากอุปกรณ์ทั้งหมดใน MPC นี้สามารถใช้งานได้

8. อุปกรณ์
นี่คือกล้องวิดีโอหรือสถานีตรวจอากาศที่ติดตั้งที่ขีดจำกัดความเข้มข้นสูงสุด จำเป็นต้องตรวจสอบว่าอุปกรณ์ทำงานอย่างถูกต้องหรือไม่

ในระบบการตรวจสอบ แผนผังส่วนประกอบจะมีลักษณะดังนี้:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

การตรวจสอบแอปพลิเคชันเว็บ

ดังนั้นเราจึงได้แบ่งระบบออกเป็นส่วนประกอบต่างๆ ตอนนี้เราจำเป็นต้องตรวจสอบส่วนประกอบแต่ละส่วน

ในการตรวจสอบเว็บแอปพลิเคชัน เราใช้การตรวจสอบต่อไปนี้:

1. ตรวจสอบการเปิดหน้าหลัก
การตรวจสอบนี้ดำเนินการโดยระบบการตรวจสอบ ในการดำเนินการ เราจะระบุที่อยู่หน้า ส่วนการตอบสนองที่คาดหวัง และเวลาดำเนินการคำขอสูงสุด

2. ตรวจสอบกำหนดเวลาการชำระเงินโดเมน
การตรวจสอบที่สำคัญมาก เมื่อโดเมนยังคงค้างชำระ ผู้ใช้จะไม่สามารถเปิดไซต์ได้ การแก้ปัญหาอาจใช้เวลาหลายวัน เนื่องจาก... การเปลี่ยนแปลง DNS จะไม่ถูกนำไปใช้ทันที

3. การตรวจสอบใบรับรอง SSL
ในปัจจุบัน เว็บไซต์เกือบทั้งหมดใช้โปรโตคอล https ในการเข้าถึง เพื่อให้โปรโตคอลทำงานได้อย่างถูกต้อง คุณต้องมีใบรับรอง SSL ที่ถูกต้อง

ด้านล่างนี้คือองค์ประกอบ “บัญชีส่วนบุคคล” ในระบบการตรวจสอบ:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

คุณสามารถตรวจสอบอะไรได้อีก?

หากต้องการตรวจสอบเว็บแอปพลิเคชันของคุณอย่างสมบูรณ์ยิ่งขึ้น คุณสามารถดำเนินการตรวจสอบต่อไปนี้:

  • จำนวนข้อผิดพลาด JavaScript ต่อช่วงเวลา
  • จำนวนข้อผิดพลาดในฝั่งแอปพลิเคชันเว็บ (แบ็คเอนด์) ในช่วงเวลาดังกล่าว
  • จำนวนการตอบกลับเว็บแอปพลิเคชันที่ไม่สำเร็จ (รหัสตอบกลับ 404, 500 ฯลฯ)
  • เวลาดำเนินการแบบสอบถามโดยเฉลี่ย

การมอนิเตอร์บริการ windows (ตัวแทน)

ในระบบ ASMO เอเจนต์จะมีบทบาทเป็นผู้กำหนดเวลางาน ซึ่งจะดำเนินการงานที่กำหนดเวลาไว้ในเบื้องหลัง

หากงานตัวแทนทั้งหมดเสร็จสมบูรณ์ แสดงว่าตัวแทนทำงานได้อย่างถูกต้อง ปรากฎว่าในการตรวจสอบตัวแทน คุณต้องตรวจสอบงานของตัวแทน ดังนั้นเราจึงแบ่งองค์ประกอบ “ตัวแทน” ออกเป็นงาน สำหรับแต่ละงาน เราจะสร้างส่วนประกอบแยกต่างหากในระบบการตรวจสอบ โดยที่ส่วนประกอบ "ตัวแทน" จะเป็น "หลัก"

เราแบ่งส่วนประกอบ Agent ออกเป็นส่วนประกอบย่อย (งาน):

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

มีงานมากกว่าร้อยงานในระบบ ASMO จำเป็นหรือไม่ที่จะต้องตรวจสอบเฉพาะสำหรับแต่ละงาน? แน่นอนว่า การควบคุมจะดีกว่าถ้าเราคิดและใช้การตรวจสอบพิเศษของเราเองสำหรับงานตัวแทนแต่ละงาน แต่ในกรณีส่วนใหญ่ การใช้การตรวจสอบสากลก็เพียงพอแล้ว

ระบบ ASMO ใช้การตรวจสอบงานแบบสากลเท่านั้น และเพียงพอสำหรับการตรวจสอบประสิทธิภาพของระบบ

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

อัลกอริทึมการตรวจสอบ

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

การตรวจสอบนี้สามารถตรวจพบปัญหาต่อไปนี้:

  1. งานรันแต่ล้มเหลวโดยมีข้อผิดพลาด
  2. งานหยุดทำงานแล้ว เช่น หยุดทำงาน

มาดูวิธีการแก้ไขปัญหาเหล่านี้อย่างละเอียดกันดีกว่า

ปัญหาที่ 1 – งานรันแต่ล้มเหลวโดยมีข้อผิดพลาด
ด้านล่างนี้เป็นกรณีที่งานดำเนินไปแต่ล้มเหลวระหว่างเวลา 14:00 น. ถึง 16:00 น.

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

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

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

ปัญหาที่ 2 - งานหยุดดำเนินการ (ค้าง)
ระบบติดตามจะเข้าใจได้อย่างไรว่างานค้าง?

ผลการตรวจสอบมีอายุการใช้งาน เช่น 1 ชั่วโมง หากผ่านไปหนึ่งชั่วโมงและไม่มีผลการทดสอบใหม่ ระบบตรวจสอบจะตั้งค่าสถานะการทดสอบเป็นสัญญาณเตือน

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

ในภาพด้านบนไฟดับเมื่อเวลา 14 น. เวลา 00 น. ระบบติดตามจะตรวจพบว่าผลการทดสอบ (ตั้งแต่เวลา 15 น.) เน่าเสีย เนื่องจาก เวลาที่เกี่ยวข้องหมดอายุแล้ว (หนึ่งชั่วโมง) แต่ไม่มีผลลัพธ์ใหม่ และจะเปลี่ยนการตรวจสอบเป็นสถานะการเตือน

เวลา 16 น. ไฟเปิดอีกครั้ง โปรแกรมจะทำงานให้เสร็จสิ้นและส่งผลการดำเนินการไปยังระบบตรวจสอบ สถานะการทดสอบจะสำเร็จอีกครั้ง

ฉันควรใช้เวลาใดในการตรวจสอบความเกี่ยวข้อง

เวลาที่เกี่ยวข้องจะต้องมากกว่าระยะเวลาการดำเนินงาน ฉันแนะนำให้ตั้งเวลาที่เกี่ยวข้องให้นานกว่าระยะเวลาดำเนินการ 2-3 เท่า นี่เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงการรับการแจ้งเตือนที่ผิดพลาด เช่น เมื่องานใช้เวลานานกว่าปกติหรือมีคนโหลดโปรแกรมซ้ำ

กำลังตรวจสอบความคืบหน้า

ระบบ ASMO มีงาน “พยากรณ์โหลด” ซึ่งพยายามดาวน์โหลดการคาดการณ์ใหม่จากแหล่งภายนอกชั่วโมงละครั้ง ไม่ทราบเวลาที่แน่นอนที่การคาดการณ์ใหม่ปรากฏในระบบภายนอก แต่เป็นที่รู้กันว่าสิ่งนี้เกิดขึ้น 2 ครั้งต่อวัน ปรากฎว่าหากไม่มีพยากรณ์อากาศใหม่เป็นเวลาหลายชั่วโมงก็ถือเป็นเรื่องปกติ แต่หากไม่มีพยากรณ์อากาศใหม่นานกว่าหนึ่งวัน แสดงว่ามีบางอย่างผิดปกติ ตัวอย่างเช่น รูปแบบข้อมูลในระบบการคาดการณ์ภายนอกอาจมีการเปลี่ยนแปลง ซึ่งเป็นสาเหตุที่ ASMO จะไม่เห็นการเผยแพร่การคาดการณ์ใหม่

อัลกอริทึมการตรวจสอบ

งานจะส่งผลลัพธ์ของการตรวจสอบความสำเร็จไปยังระบบตรวจสอบเมื่อดำเนินการได้สำเร็จ (ดาวน์โหลดพยากรณ์อากาศใหม่) หากไม่มีความคืบหน้าหรือข้อผิดพลาดเกิดขึ้น จะไม่มีการส่งสิ่งใดไปยังระบบการตรวจสอบ

การตรวจสอบจะต้องมีช่วงเวลาที่เกี่ยวข้องเพื่อรับประกันว่าจะได้รับความคืบหน้าใหม่ในช่วงเวลานี้

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

การตรวจสอบฐานข้อมูล

ในการควบคุมฐานข้อมูลในระบบ ASMO เราทำการตรวจสอบดังต่อไปนี้:

  1. กำลังตรวจสอบการสร้างข้อมูลสำรอง
  2. กำลังตรวจสอบพื้นที่ว่างในดิสก์

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

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

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

สะดวกในการใช้หน่วยเมตริกเพื่อตรวจสอบพารามิเตอร์ตัวเลข

ตัวชี้วัด เป็นตัวแปรตัวเลขซึ่งค่าจะถูกส่งไปยังระบบตรวจสอบ ระบบตรวจสอบจะตรวจสอบค่าเกณฑ์และคำนวณสถานะเมตริก

ด้านล่างนี้เป็นภาพของส่วนประกอบ "ฐานข้อมูล" ในระบบการตรวจสอบ:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

การตรวจสอบเซิร์ฟเวอร์

ในการตรวจสอบเซิร์ฟเวอร์ เราใช้การตรวจสอบและตัวชี้วัดต่อไปนี้:

1. พื้นที่ว่างในดิสก์
หากพื้นที่ดิสก์หมด แอปพลิเคชันจะไม่สามารถทำงานได้ เราใช้ค่าเกณฑ์ 2 ค่า: ระดับแรกคือคำเตือน ระดับที่สองคือสัญญาณเตือน

2. ค่า RAM เฉลี่ยเป็นเปอร์เซ็นต์ต่อชั่วโมง
เราใช้ค่าเฉลี่ยรายชั่วโมงเพราะว่า... เราไม่สนใจเผ่าพันธุ์หายาก

3. เปอร์เซ็นต์ CPU เฉลี่ยต่อชั่วโมง
เราใช้ค่าเฉลี่ยรายชั่วโมงเพราะว่า... เราไม่สนใจเผ่าพันธุ์หายาก

4. เช็คปิง
ตรวจสอบว่าเซิร์ฟเวอร์ออนไลน์อยู่ ระบบการตรวจสอบสามารถตรวจสอบได้โดยไม่จำเป็นต้องเขียนโค้ด

ด้านล่างนี้เป็นภาพของส่วนประกอบ "เซิร์ฟเวอร์" ในระบบการตรวจสอบ:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

การตรวจสอบอุปกรณ์

ฉันจะบอกคุณว่าข้อมูลได้มาอย่างไร สำหรับแต่ละจุดควบคุมถนน (MPC) จะมีงานอยู่ในผู้วางแผนงาน เช่น “สำรวจ MPC M2 กม. 200” งานได้รับข้อมูลจากอุปกรณ์ MPC ทั้งหมดทุกๆ 30 นาที

ปัญหาช่องทางการสื่อสาร
อุปกรณ์ส่วนใหญ่ตั้งอยู่นอกเมือง เครือข่าย GSM ใช้สำหรับการส่งข้อมูลซึ่งทำงานไม่เสถียร (มีเครือข่ายหรือไม่มีเครือข่าย)

เนื่องจากเครือข่ายขัดข้องบ่อยครั้ง ในตอนแรก การตรวจสอบแบบสำรวจ MPC ในการตรวจสอบมีลักษณะดังนี้:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

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

ด้านล่างนี้เป็นภาพลักษณะของอุปกรณ์ในระบบการตรวจสอบ:

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

ที่สำคัญ!
เมื่อเครือข่าย GSM หยุดทำงาน อุปกรณ์ MDC ทั้งหมดจะไม่ถูกสำรวจ เพื่อลดจำนวนอีเมลจากระบบการตรวจสอบ วิศวกรของเราสมัครรับการแจ้งเตือนเกี่ยวกับปัญหาส่วนประกอบประเภท "MPC" แทนที่จะเป็น "อุปกรณ์" ซึ่งจะทำให้คุณได้รับการแจ้งเตือนหนึ่งรายการสำหรับแต่ละ MPC แทนที่จะได้รับการแจ้งเตือนแยกต่างหากสำหรับอุปกรณ์แต่ละเครื่อง

รูปแบบการตรวจสอบ ASMO ขั้นสุดท้าย

ลองรวบรวมทุกอย่างเข้าด้วยกันแล้วดูว่าเรามีรูปแบบการติดตามแบบใด

เรากินช้างเป็นชิ้น ๆ กลยุทธ์การติดตามสุขภาพของแอปพลิเคชันพร้อมตัวอย่าง

ข้อสรุป

มาสรุปกัน
การติดตามประสิทธิภาพของ ASMO ให้อะไรแก่เรา

1. ระยะเวลาในการกำจัดข้อบกพร่องลดลง
ก่อนหน้านี้เราเคยได้ยินเกี่ยวกับข้อบกพร่องจากผู้ใช้ แต่ไม่ใช่ผู้ใช้ทุกคนที่จะรายงานข้อบกพร่อง บังเอิญเราได้เรียนรู้เกี่ยวกับความผิดปกติของส่วนประกอบของระบบหนึ่งสัปดาห์หลังจากที่มันปรากฏขึ้น ตอนนี้ระบบตรวจสอบจะแจ้งให้เราทราบถึงปัญหาทันทีที่ตรวจพบปัญหา

2. ความเสถียรของระบบเพิ่มขึ้น
เนื่องจากข้อบกพร่องเริ่มถูกกำจัดไปก่อนหน้านี้ ระบบโดยรวมจึงเริ่มทำงานมีเสถียรภาพมากขึ้น

3. การลดจำนวนการโทรติดต่อฝ่ายสนับสนุนด้านเทคนิค
ปัญหาหลายอย่างได้รับการแก้ไขแล้วก่อนที่ผู้ใช้จะรู้ด้วยซ้ำ ผู้ใช้เริ่มติดต่อฝ่ายสนับสนุนด้านเทคนิคน้อยลง ทั้งหมดนี้ส่งผลดีต่อชื่อเสียงของเรา

4. การเพิ่มความภักดีของลูกค้าและผู้ใช้
ลูกค้าสังเกตเห็นการเปลี่ยนแปลงเชิงบวกในความเสถียรของระบบ ผู้ใช้พบปัญหาในการใช้ระบบน้อยลง

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

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

ระบบตรวจสอบจะต้องทำงานบนเซิร์ฟเวอร์แยกต่างหากในศูนย์ข้อมูลอื่น

หากคุณไม่ต้องการใช้เซิร์ฟเวอร์เฉพาะในศูนย์ข้อมูลใหม่ คุณสามารถใช้ระบบตรวจสอบคลาวด์ได้ บริษัทของเราใช้ระบบตรวจสอบคลาวด์ Zidium แต่คุณสามารถใช้ระบบตรวจสอบอื่นๆ ได้ ค่าใช้จ่ายของระบบตรวจสอบคลาวด์ต่ำกว่าการเช่าเซิร์ฟเวอร์ใหม่

คำแนะนำ:

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

หากคุณยังไม่ได้ใช้ระบบ Monitoring เริ่มได้เลย! มันไม่ยากอย่างที่คิด ลองมองดูต้นไม้ส่วนผสมสีเขียวที่คุณปลูกเอง

โชคดี

ที่มา: will.com

เพิ่มความคิดเห็น