Comme pour toute communication en cas de panne, un lecteur non technique cherchera principalement à comprendre:
- Cela durait combien de temps?
- À quel point était-ce mauvais?
Les métriques Amazon CloudWatch fournissent les métriques suivantes pour les files d'attente SQS qui peuvent aider à répondre à ces questions:
- NumberOfMessagesSent: nombre de messages ajoutés à une file d'attente.
- NumberOfMessagesReceived: nombre de messages renvoyés par les appels à l'action d'API ReceiveMessage.
- ApproximateNumberOfMessagesVisible: nombre de messages disponibles pour la récupération dans la file d'attente.
Lorsqu'elles sont représentées graphiquement correctement, ces mesures peuvent être de puissants assistants visuels pour décrire les délais de traitement des files d'attente. Voici quelques exemples d'une panne que j'ai connue où la capacité du travail à traiter les messages de file d'attente a été gravement dégradée:
NumberOfMessagesSent & NumberOfMessagesReceived
- Type de graphique: Graphique linéaire
- Statistique: somme
- Durée: 5 minutes
Ce graphique illustre le contraste entre les messages envoyés et reçus, ce qui permet d'isoler le composant de traitement responsable du retard. Dans ce graphique, la métrique reçue chute considérablement tandis que la métrique envoyée poursuit sa tendance normale, nous pouvons donc en déduire que le problème réside dans le composant de lecture de file d'attente au lieu du composant d'écriture de file d'attente.
Est-ce que cela répond à la durée / à la gravité de l'événement? Oui; décrit les processus impactés au fil du temps.
NumberOfMessagesReceived & ApproximateNumberOfMessagesVisible
- Type de graphique: Graphique de zone empilée
- Statistique: somme
- Durée: 5 minutes
Cela représente la profondeur de la file d'attente au-dessus des messages reçus, ce qui permet de voir dans quelle mesure la file d'attente a été sauvegardée et comment elle a été récupérée. Dans ce graphique, nous pouvons voir que la profondeur de la file d'attente a été sauvegardée de façon spectaculaire pendant que le composant de lecture de la file d'attente rencontrait des problèmes et a commencé à récupérer lorsque le composant de lecture de la file d'attente a recommencé à lire les messages.
Est-ce que cela répond à la durée / à la gravité de l'événement? Oui; décrit les messages impactés au fil du temps.
Discussion graphique
Dans les deux graphiques, le traitement de la file d'attente peut généralement être considéré comme sain lorsque les lignes se chevauchent et malsain lorsque les lignes divergent. Il s'agit d'un modèle facile à enseigner à un membre de l'équipe non technique et qui peut l'aider à disséminer rapidement où et comment il y a des problèmes lorsqu'il est présenté avec ces graphiques.
Pour communiquer davantage des points spécifiques dans les graphiques, vous pouvez simplement les annoter:
Conseils graphiques:
- Étiquetez les unités et les axes.
- Utilisez des couleurs cohérentes pour faire correspondre les mesures entre les graphiques. Notez que NumberOfMessagesReceived est orange dans les deux graphiques; cela aidera à visualiser la même métrique sur différents graphiques.
- Alignez verticalement des graphiques qui décrivent des mesures similaires afin de les comparer plus facilement dans le temps.
Remarque: J'ai formaté ces graphiques pour une présentation sur StackExchange, donc ce n'est pas nécessairement la façon dont je les présenterais dans une panne post-mortem. J'ai explicitement supprimé les valeurs de l'axe gauche ici pour les masquer de StackExchange; vous voudrez les garder dans vos autopsies.
Conseils supplémentaires
- Habilitez votre équipe: après avoir formé les membres de votre équipe à lire ces graphiques, il n'y a aucune raison de les cacher. Envisagez de configurer un tableau de bord CloudWatch et de donner à vos membres non techniques un accès IAM en lecture seule à CloudWatch , afin qu'ils puissent afficher ces graphiques à tout moment.
- Configurer les notifications: envisagez de configurer des alarmes Cloudwatch basées sur la métrique ApproximateNumberOfMessagesVisible si elle dépasse une valeur élevée convenue, et abonnez les membres de l'équipe pour les informer des problèmes potentiels. Les alarmes Cloudwatch ont des champs de description qui sont envoyés avec les e-mails de notification - assurez-vous d'inclure une description lisible par l'homme pour aider vos membres non techniques à diffuser l'alarme.
- Explorez d'autres données: selon le commentaire d'Evgeny , explorez d'autres données au-delà de ce que CloudWatch fournit et réfléchissez à la façon dont vous pouvez transmettre ces données à votre équipe. Son exemple d'utilisation de la durée de vie des messages dans la file d'attente pour créer un histogramme est un excellent exemple de cette pensée créative et peut être accompli en enregistrant les heures d'envoi et de réception des messages dans votre application. Vous pouvez obtenir le message Horodatage envoyé via l'attribut SentTimeStamp sur chaque message de file d'attente de la réponse de l'API ReceiveMessage. Plus de détails ici .