เช่นเดียวกับการสื่อสารดับใด ๆ ผู้อ่านที่ไม่ใช่ด้านเทคนิคจะต้องทำความเข้าใจเป็นหลัก:
- นานแค่ไหน
- มันเลวร้ายแค่ไหน?
ตัวชี้วัด Amazon CloudWatch จัดเตรียมเมทริกต่อไปนี้สำหรับคิว SQSที่สามารถช่วยตอบคำถามเหล่านี้:
- NumberOfMessagesSent:จำนวนข้อความที่เพิ่มในคิว
- NumberOfMessagesReceived:จำนวนข้อความที่ส่งคืนโดยการเรียกไปยังการดำเนินการรับของ API
- ApproximateNumberOfMessagesVisible:จำนวนข้อความที่สามารถเรียกค้นได้จากคิว
เมื่อกราฟถูกต้องตัวชี้วัดเหล่านี้สามารถเป็นภาพช่วยที่มีประสิทธิภาพในการอธิบายการประมวลผลคิวล่าช้า ต่อไปนี้เป็นตัวอย่างบางส่วนจากไฟดับที่ฉันพบซึ่งความสามารถของงานในการประมวลผลข้อความคิวลดลงอย่างรุนแรง:
NumberOfMessagesSent & NumberOfMessages ได้รับแล้ว
- ประเภทกราฟ:กราฟเส้น
- สถิติ:ผลรวม
- ระยะเวลา: 5 นาที
กราฟนี้แสดงความแตกต่างระหว่างข้อความที่ส่งและรับซึ่งช่วยแยกส่วนประกอบการประมวลผลที่รับผิดชอบต่อความล่าช้า ในกราฟนี้ตัวชี้วัดที่ได้รับจะลดลงอย่างมากในขณะที่ตัวชี้วัดที่ส่งยังคงอยู่ในแนวโน้มปกติดังนั้นเราสามารถสรุปได้ว่าปัญหานั้นอยู่ในองค์ประกอบการอ่านคิวแทนที่จะเป็นองค์ประกอบการเขียนคิว
นี่เป็นคำตอบว่านานแค่ไหน / เหตุการณ์ไม่ดีเป็นอย่างไร ใช่; อธิบายกระบวนการที่ได้รับผลกระทบเมื่อเวลาผ่านไป
NumberOfMessages ที่ได้รับ & ApproximateNumberOfMessagesVisible
- ประเภทกราฟ:กราฟพื้นที่ซ้อนกัน
- สถิติ:ผลรวม
- ระยะเวลา: 5 นาที
กราฟนี้จะแสดงความลึกของคิวที่ด้านบนของข้อความที่ได้รับซึ่งจะช่วยแสดงให้เห็นว่าคิวสำรองข้อมูลนานแค่ไหนและกู้คืนได้อย่างไร ในกราฟนี้เราจะเห็นว่าความลึกของคิวสำรองในขณะที่องค์ประกอบการอ่านคิวมีปัญหาและเริ่มกู้คืนเมื่อองค์ประกอบการอ่านคิวเริ่มอ่านข้อความอีกครั้ง
นี่เป็นคำตอบว่านานแค่ไหน / เหตุการณ์ไม่ดีเป็นอย่างไร ใช่; อธิบายข้อความที่ได้รับผลกระทบเมื่อเวลาผ่านไป
การอภิปรายกราฟ
ในกราฟทั้งสองการประมวลผลคิวโดยทั่วไปถือว่ามีประโยชน์เมื่อเส้นทับกันและไม่แข็งแรงเมื่อเส้นแตกต่างกัน นี่เป็นรูปแบบที่ง่ายต่อการสอนให้กับสมาชิกในทีมที่ไม่ใช่ด้านเทคนิคและสามารถช่วยพวกเขาแยกแยะได้อย่างรวดเร็วว่ามีที่ไหนและอย่างไรมีปัญหาเมื่อนำเสนอด้วยกราฟเหล่านี้
หากต้องการสื่อสารจุดเฉพาะในกราฟเพิ่มเติมคุณสามารถใส่คำอธิบายประกอบ:
เคล็ดลับการสร้างกราฟ:
- หน่วยฉลากและแกน
- ใช้สีที่สอดคล้องกันสำหรับการจับคู่การวัดข้ามกราฟ โปรดทราบว่า NumberOfMessagesReceived เป็นสีส้มในกราฟทั้งสอง สิ่งนี้จะช่วยให้เห็นภาพตัวชี้วัดเดียวกันในกราฟที่แตกต่างกัน
- จัดเรียงกราฟแนวตั้งที่อธิบายตัวชี้วัดที่คล้ายกันเพื่อให้สามารถเปรียบเทียบได้ง่ายขึ้นตลอดเวลา
หมายเหตุ:ฉันได้จัดรูปแบบกราฟเหล่านี้เพื่อนำเสนอใน StackExchange ดังนั้นสิ่งเหล่านี้ไม่จำเป็นต้องเป็นวิธีที่ฉันจะนำเสนอพวกเขาในการโพสต์ชันชันดับ ฉันได้ลบค่าอย่างชัดเจนจากแกนด้านซ้ายที่นี่เพื่อบดบังพวกเขาจาก StackExchange คุณจะต้องการเก็บไว้ในโพสต์ชันสูตรของคุณ
เคล็ดลับเพิ่มเติม
- เสริมพลังทีมของคุณ:หลังจากฝึกฝนสมาชิกในทีมของคุณให้อ่านกราฟเหล่านี้ไม่มีเหตุผลที่จะซ่อนพวกเขาไว้ พิจารณาตั้งค่าแผงควบคุม CloudWatchและให้สมาชิกในทีมที่ไม่ใช่ด้านเทคนิคของคุณเข้าถึง IAM แบบอ่านอย่างเดียวกับ CloudWatchเพื่อให้พวกเขาสามารถดูกราฟเหล่านี้ได้ตลอดเวลา
- ตั้งค่าการแจ้งเตือน:พิจารณาตั้งค่าการเตือน Cloudwatchตาม ApproximateNumberOfMessagesVisible ตัวชี้วัดหากเกินกว่าค่าที่ตกลงกันไว้สูงและสมัครสมาชิกทีมเพื่อแจ้งปัญหาที่อาจเกิดขึ้น Cloudwatch Alarms มีช่องคำอธิบายที่ส่งไปพร้อมกับอีเมลแจ้งเตือน - ตรวจสอบให้แน่ใจว่าได้ใส่คำอธิบายที่มนุษย์สามารถอ่านได้เพื่อช่วยให้สมาชิกที่ไม่ใช่ด้านเทคนิคเผยแพร่สัญญาณเตือน
- สำรวจข้อมูลอื่น ๆ :ตามความเห็นของ Evgenyสำรวจข้อมูลอื่น ๆ นอกเหนือจากที่ CloudWatch ให้ไว้และคิดว่าคุณจะถ่ายทอดข้อมูลนั้นให้ทีมของคุณได้อย่างไร ตัวอย่างของการใช้อายุการใช้งานข้อความในคิวเพื่อสร้างฮิสโตแกรมเป็นตัวอย่างที่ดีของการคิดสร้างสรรค์นี้และสามารถทำได้โดยการบันทึกทั้งการส่งข้อความและรับข้อความเวลาในใบสมัครของคุณ คุณสามารถรับข้อความ Sent Timestamp ผ่านทาง SentTimeStamp Attribute ในแต่ละข้อความคิวของการตอบสนอง ReceiveMessage API รายละเอียดเพิ่มเติมที่นี่