Comment nous buvons notre propre champagne (et effectuons une surveillance chez PagerDuty)

Nous envoyons plus de 4 millions d'alertes chaque mois et les entreprises comptent sur nous pour les avertir en cas de panne. Alors, qui surveille les gardiens ? Arup Chakrabarti, responsable technique de PagerDuty, a parlé de la façon dont nous surveillons nos propres systèmes aux DevOps Days Chicago plus tôt ce mois-ci. Voici quelques points saillants de son discours sur les outils de surveillance et les philosophies que nous utilisons ici chez PagerDuty.

Utilisez le bon outil

En ce qui concerne les outils, New Relic est l'un de ceux que nous utilisons, car il peut fournir de nombreux graphiques et rapports. Les outils de gestion des performances des applications vous fournissent de nombreuses informations, ce qui est utile lorsque vous ne savez pas vraiment quelles sont vos mesures critiques. Mais ils peuvent être difficiles à personnaliser, et toutes ces informations peuvent entraîner une « paralysie de l'analyse ».

PagerDuty utilise également les métriques clés du moniteur StatsD et DataDog, car elles sont faciles à utiliser et très personnalisables, même si cela peut prendre un peu de temps (nous avons organisé une session d'une demi-journée avec nos ingénieurs) pour que les équipes soient au courant des métriques. SumoLogic analyse les journaux d'applications critiques et les ingénieurs de PagerDuty configurent des alertes sur les modèles dans les journaux. Wormly et Monitis assurent une surveillance externe, même si l'équipe a dû créer une page de contrôle de santé plus intelligente qui alerte sur des valeurs inattendues. Et enfin, PagerDuty utilise PagerDuty pour consolider les alertes de tous ces systèmes de surveillance et nous avertir en cas de problème.

Évitez la surveillance d'un seul hôte pour les systèmes distribués

« Supposons que tout ce qui fonctionne sur une seule boîte est fragile et se brisera au moment le plus inopportun », explique Chakrabarti. PagerDuty configure plutôt des alertes sur les métriques au niveau du cluster, telles que le nombre total de 500 erreurs, et non le nombre dans un seul fichier journal, et la latence globale, et non la latence d'une boîte. Pour cette raison, PagerDuty essaie de canaliser tous ses systèmes via le système de surveillance plutôt que de transmettre les données directement des serveurs ou des services vers PagerDuty.

Nous canalisons les alertes de serveur et de service via un système de surveillance hautement disponible afin de signaler l'impact global plutôt que les problèmes de boîtier individuels.

Chakrabarti aborde également la surveillance des dépendances, ou comment surveiller les performances des systèmes SaaS que vous ne contrôlez pas. Il n’existe pas encore de réponse miracle à ce problème. Nous effectuons une combinaison de vérifications manuelles et de pings automatisés. À titre d’exemple, il raconte l’histoire d’un client qui ne recevait pas ses SMS à l’appel. Après enquête, il s’est avéré que notre fournisseur de SMS envoyait les messages, mais que pour une raison quelconque, l’opérateur sans fil les bloquait. En conséquence, nous avons élaboré un cadre de test, « autrement dit, comment abuser des forfaits de messagerie illimitée ». Chaque minute, nous envoyons une alerte SMS à tous les principaux opérateurs et mesurons les temps de réponse.

Nous envoyons des SMS aux principaux opérateurs mobiles chaque minute et mesurons les temps de réponse pour nous assurer de savoir si les opérateurs rencontrent des problèmes susceptibles d'affecter la délivrabilité de nos alertes SMS.

Soyez alerté sur ce qui intéresse les clients

Beaucoup de gens font l’erreur d’alerter sur chaque élément erroné dans le journal, explique Chakrabarti. « Si le client ne le remarque pas, il n’est peut-être pas nécessaire de l’alerter. » Mais, prévient-il, le mot « client » peut avoir différentes significations au sein d’une même organisation. « Si vous travaillez sur des éléments destinés aux utilisateurs finaux, vous souhaiterez surveiller la latence. Si vous vous souciez davantage des opérations internes, vous vous soucierez peut-être du processeur de votre cluster Cassandra, car vous savez que cela affectera vos autres équipes d’ingénierie. » Nous avons une excellente article de blog sur ce sur quoi être alerté si vous souhaitez en savoir plus.

Valider que les alertes fonctionnent

Le meilleur exemple de surveillance des observateurs est peut-être le fait que « de temps en temps, vous devrez peut-être entrer manuellement et vérifier que vos alertes fonctionnent toujours », explique Chakrabarti. « Nous avons quelque chose chez PagerDuty que nous appelons Vendredi d'échec , alors que nous allons attaquer nos propres services. » L'équipe laisse toutes les alertes en marche et procède à la destruction des processus, du réseau et des centres de données, dans le but de valider les alertes.

Qu'a appris l'équipe de Failure Friday ? « La surveillance des processus était mêlée à l'exécution des processus », explique Chakrabarti. « Si le service tombe en panne, la surveillance du service tombe également en panne, et vous ne le saurez jamais jusqu'à ce qu'il tombe en panne sur chaque machine. » Et c'est là, en bref, la raison d'être de la surveillance externe.