Wie bei jeder Ausfallkommunikation möchte ein nicht-technischer Leser in erster Linie Folgendes verstehen:
- Wie lang war es?
- Wie schlimm war es
Amazon CloudWatch-Metriken bieten die folgenden Metriken für SQS-Warteschlangen , mit denen diese Fragen beantwortet werden können:
- NumberOfMessagesSent: Die Anzahl der einer Warteschlange hinzugefügten Nachrichten.
- NumberOfMessagesReceived: Die Anzahl der Nachrichten, die von Aufrufen der ReceiveMessage-API-Aktion zurückgegeben wurden.
- ApproximateNumberOfMessagesVisible: Die Anzahl der Nachrichten, die aus der Warteschlange abgerufen werden können.
Bei korrekter grafischer Darstellung können diese Metriken leistungsstarke visuelle Hilfsmittel bei der Beschreibung von Verzögerungen bei der Warteschlangenverarbeitung sein. Im Folgenden sind einige Beispiele aus einem Ausfall aufgeführt, bei dem die Kapazität des Jobs zur Verarbeitung von Warteschlangenmeldungen erheblich beeinträchtigt war:
NumberOfMessagesSent & NumberOfMessagesReceived
- Diagrammtyp: Liniendiagramm
- Statistik: Summe
- Dauer: 5 Minuten
Auf diese Weise wird der Kontrast zwischen gesendeten und empfangenen Nachrichten grafisch dargestellt. Auf diese Weise können Sie herausfinden, welche Verarbeitungskomponente für die Verzögerung verantwortlich ist. In diesem Diagramm sinkt die empfangene Metrik dramatisch, während die gesendete Metrik ihren normalen Trend beibehält. Daraus lässt sich schließen, dass das Problem in der Warteschlangenlesekomponente und nicht in der Warteschlangenschreibkomponente liegt.
Beantwortet dies, wie lange / wie schlecht das Ereignis war? Ja; beschreibt Prozesse, die im Laufe der Zeit beeinflusst werden.
Anzahl der empfangenen und ungefähren Anzahl der sichtbaren Nachrichten
- Diagrammtyp: Gestapeltes Flächendiagramm
- Statistik: Summe
- Dauer: 5 Minuten
Auf diese Weise wird die Warteschlangentiefe über den empfangenen Nachrichten grafisch dargestellt, um zu zeigen, wie weit die Warteschlange gesichert und wie sie wiederhergestellt wurde. In diesem Diagramm sehen wir, dass die Warteschlangentiefe dramatisch gesichert wurde, während die Warteschlangenlesekomponente Probleme hatte, und dass die Wiederherstellung begann, als die Warteschlangenlesekomponente erneut mit dem Lesen von Nachrichten begann.
Beantwortet dies, wie lange / wie schlecht das Ereignis war? Ja; beschreibt Nachrichten, die im Laufe der Zeit betroffen sind.
Grafik Diskussion
In beiden Diagrammen kann die Warteschlangenverarbeitung im Allgemeinen als fehlerfrei angesehen werden, wenn sich die Zeilen überlappen, und als fehlerhaft, wenn sich die Zeilen unterscheiden. Dies ist ein einfaches Muster, das Sie einem nicht-technischen Teammitglied beibringen können, um schnell zu ermitteln, wo und wie Probleme mit diesen Diagrammen auftreten.
Um bestimmte Punkte in Diagrammen besser zu kommunizieren, können Sie sie einfach mit Anmerkungen versehen:
Grafiktipps:
- Beschriften Sie Einheiten und Achsen.
- Verwenden Sie konsistente Farben, um Kennzahlen in allen Diagrammen abzugleichen. Beachten Sie, dass NumberOfMessagesReceived in beiden Diagrammen orange ist. Auf diese Weise können Sie dieselbe Metrik in verschiedenen Diagrammen darstellen.
- Richten Sie Diagramme, die ähnliche Metriken beschreiben, vertikal aus, damit sie über die Zeit hinweg leichter verglichen werden können.
Hinweis: Ich habe diese Diagramme für die Präsentation in StackExchange formatiert, sodass dies nicht unbedingt der Fall ist, wenn ich sie nach einem Ausfall post mortem präsentiere. Ich habe hier ausdrücklich Werte von der linken Achse entfernt, um sie von StackExchange zu verbergen. du wirst sie in deinen Obduktionen behalten wollen.
Zusätzliche Tipps
- Befähigen Sie Ihr Team: Nachdem Sie Ihre Teammitglieder zum Lesen dieser Grafiken geschult haben, gibt es keinen Grund, sie versteckt zu halten. Erwägen Sie, ein CloudWatch-Dashboard einzurichten und Ihren nicht-technischen Teammitgliedern schreibgeschützten IAM-Zugriff auf CloudWatch zu gewähren , damit sie diese Diagramme jederzeit anzeigen können.
- Einrichten von Benachrichtigungen: Erwägen Sie, Cloudwatch-Alarme basierend auf der Metrik ApproximateNumberOfMessagesVisible einzurichten, wenn sie einen vereinbarten hohen Wert überschreiten, und abonnieren Sie Teammitglieder, um sie über potenzielle Probleme zu informieren. Cloudwatch-Alarme haben Beschreibungsfelder, die zusammen mit den Benachrichtigungs-E-Mails gesendet werden. Stellen Sie sicher, dass Sie eine lesbare Beschreibung enthalten, damit Ihre nicht-technischen Mitglieder den Alarm verbreiten können.
- Versuchen Sie andere Daten: Per Evgeny Kommentar , erkunden andere Daten über das, was Cloudwatch bietet und darüber nachdenken , wie Sie feststellen , dass Daten zu Ihrem Team vermitteln können. Sein Beispiel für die Verwendung der Nachrichtenlebensdauer in der Warteschlange zum Erstellen eines Histogramms ist ein gutes Beispiel für dieses kreative Denken und kann durch Protokollieren der Sende- und Empfangszeiten von Nachrichten in Ihrer Anwendung erreicht werden. Sie können den gesendeten Zeitstempel der Nachricht über das SentTimeStamp-Attribut in jeder Warteschlangennachricht der ReceiveMessage-API-Antwort abrufen. Weitere Details hier .