Bagaimana cara mengkomunikasikan penundaan pemrosesan berbasis antrian kepada anggota tim non-teknis?


13

Saya bertanggung jawab atas serangkaian pekerjaan pemrosesan antrian SQS dengan kebijakan penskalaan pada ApproximateNumberOfMessagesVisiblemetrik CloudWatch. Pekerjaan-pekerjaan ini dapat gagal mengikuti jumlah pesan yang dikirim karena sejumlah alasan:

  • Degradasi layanan mengurangi kapasitas pesan yang dapat diproses.
  • AutoScaling batas maksimal tercapai sementara kedalaman antrian terus meningkat.
  • S3 Outage memengaruhi layanan AWS lain yang bergantung ( AutoScalinglayanan) yang digunakan pekerjaan pemrosesan antrian untuk memenuhi permintaan.

Ketika mendiskusikan pemadaman dengan anggota tim non-teknis, saya ingin mengkomunikasikan penundaan khusus pemrosesan antrian yang dapat diterjemahkan ke dalam degradasi yang terlihat oleh pelanggan. Bagaimana saya bisa melakukan ini dengan antrian SQS?

Jawaban:


15

Seperti halnya komunikasi pemadaman, pembaca non-teknis akan berusaha memahami:

  • Berapa lama?
  • Seberapa buruk itu?

Metrik Amazon CloudWatch menyediakan metrik berikut untuk antrian SQS yang dapat membantu menjawab pertanyaan ini:

  • NumberOfMessagesSent: Jumlah pesan yang ditambahkan ke antrian.
  • NumberOfMessagesReceived: Jumlah pesan yang dikembalikan oleh panggilan ke tindakan API ReceiveMessage.
  • ApproximateNumberOfMessagesVisible: Jumlah pesan yang tersedia untuk diambil dari antrian.

Ketika dibuat grafik dengan benar, metrik ini bisa menjadi alat bantu visual yang kuat dalam menggambarkan penundaan pemrosesan antrian. Berikut adalah beberapa contoh dari pemadaman yang saya alami di mana kapasitas pekerjaan untuk memproses pesan antrian sangat menurun:

NumberOfMessagesSent & NumberOfMessagesDiterima

  • Tipe Grafik: Grafik Garis
  • Statistik: Jumlah
  • Periode: 5 menit

NumberOfMessagesSent & NumberOfMessagesDiterima

Ini grafik kontras antara pesan yang dikirim dan diterima, yang membantu mengisolasi komponen pemrosesan mana yang bertanggung jawab atas keterlambatan. Dalam grafik ini, metrik yang diterima turun secara dramatis sementara metrik yang dikirim melanjutkan tren normalnya, sehingga kami dapat menyimpulkan bahwa masalahnya terletak pada komponen pembacaan antrian alih-alih komponen penulisan antrian.

Apakah ini menjawab berapa lama / seberapa buruk kejadiannya? Iya; menjelaskan proses yang berdampak dari waktu ke waktu.

NumberOfPesan diterima & PerkiraanNomorPesanPenerimaan

  • Tipe Grafik: Grafik Area Tertumpuk
  • Statistik: Jumlah
  • Periode: 5 menit

NumberOfPesan diterima & PerkiraanNomorPesanPenerimaan

Ini grafik kedalaman antrian di atas pesan yang diterima, yang membantu menunjukkan seberapa jauh antrian didukung dan bagaimana itu pulih. Dalam grafik ini, kita dapat melihat bahwa kedalaman antrian didukung secara dramatis ketika komponen pembacaan antrian mengalami masalah, dan mulai pulih ketika komponen pembacaan antrian mulai membaca pesan lagi.

Apakah ini menjawab berapa lama / seberapa buruk kejadiannya? Iya; menjelaskan pesan yang terpengaruh dari waktu ke waktu.


Diskusi Grafik

Dalam kedua grafik, pemrosesan antrian secara umum dapat dianggap sehat ketika garis tumpang tindih, dan tidak sehat ketika garis berbeda. Ini adalah pola yang mudah untuk diajarkan kepada anggota tim non-teknis, dan dapat membantu mereka dengan cepat membahas di mana dan bagaimana ada masalah ketika disajikan dengan grafik ini.

Untuk lebih jauh mengomunikasikan titik-titik tertentu dalam grafik, Anda dapat membuat anotasi mereka:

Kedua grafik sebelumnya dengan anotasi.

Tips Grafik:

  • Beri label satuan dan sumbu.
  • Gunakan warna yang konsisten untuk mencocokkan metrik di seluruh grafik. Perhatikan bahwa NumberOfMessagesReceived berwarna oranye di kedua grafik; ini akan membantu memvisualisasikan metrik yang sama di berbagai grafik.
  • Luruskan grafik yang menggambarkan metrik yang serupa secara vertikal sehingga lebih mudah untuk dibandingkan antar waktu.

Catatan: Saya telah memformat grafik ini untuk presentasi di StackExchange, jadi ini belum tentu bagaimana saya akan mempresentasikannya dalam pematian post-mortem. Saya telah secara eksplisit menghapus nilai dari sumbu kiri di sini untuk mengaburkannya dari StackExchange; Anda ingin menyimpannya di post-mortem Anda.


Kiat tambahan

  • Berdayakan Tim Anda: Setelah melatih anggota tim Anda untuk membaca grafik ini, tidak ada alasan untuk menyembunyikannya. Pertimbangkan untuk menyiapkan Dasbor CloudWatch dan memberikan akses IAM hanya-baca anggota tim non-teknis Anda ke CloudWatch , sehingga mereka dapat melihat grafik ini kapan saja.
  • Mengatur Notifikasi: Pertimbangkan untuk mengatur Alarm Cloudwatch berdasarkan metrik ApproximateNumberOfMessagesVisible jika melebihi beberapa nilai tinggi yang disepakati, dan berlangganan anggota tim untuk memberi tahu mereka tentang masalah potensial. Cloudwatch Alarms memiliki bidang deskripsi yang dikirim bersama dengan email notifikasi - pastikan untuk menyertakan deskripsi yang dapat dibaca manusia untuk membantu anggota non-teknis Anda menyebarkan alarm.
  • Jelajahi Data Lain: Per komentar Evgeny , jelajahi data lain di luar apa yang CloudWatch sediakan dan pikirkan tentang bagaimana Anda bisa menyampaikan data itu ke tim Anda. Contohnya menggunakan masa pakai pesan dalam antrian untuk membuat histogram adalah contoh yang bagus dari pemikiran kreatif ini, dan dapat dicapai dengan mencatat waktu pengiriman pesan dan waktu pesan dalam aplikasi Anda. Anda bisa mendapatkan pesan Timestamp Terkirim melalui Atribut SentTimeStamp pada setiap pesan antrian dari respons API ReceiveMessage. Lebih detail di sini .

1
Juga sangat berguna untuk melihat data dari berbagai sudut pandang, bukan hanya yang disediakan oleh CloudWatch. Misalnya jika Anda dapat menampilkan histogram berapa lama setiap pesan tetap dalam antrian, menunjukkan bahwa beberapa pesan tetap untuk waktu X sementara yang lain tetap untuk waktu X * 2. Dan selama pemadaman histogram, memindahkan titik tinggi menuju X * 4 atau sesuatu ... sangat kuat untuk dilihat.
Evgeny

4
Juga, hanya ingin mengatakan: ini adalah jawaban yang benar-benar luar biasa.
Evgeny

Terima kasih @ Evgeny! Itu adalah ide bagus dan saya telah menambahkan tip lain untuk jawaban berdasarkan itu, dengan pujian untuk komentar Anda.
Anthony Neace
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.