Plus le système est complexe, plus il est envahi par toutes sortes d’alertes. Et il faut réagir à ces mêmes alertes, les agréger et les visualiser. Je pense que c’est une situation familière à beaucoup au point de devenir nerveuse.
La solution qui sera discutée n'est pas la plus inattendue, mais la recherche ne renvoie pas d'article à part entière sur ce sujet.
C’est pourquoi j’ai décidé de partager l’expérience de FunCorp et de parler de la façon dont le processus de service est structuré, qui appelle, pourquoi et comment tout cela peut être examiné.
Qu’est-ce que PagerDuty ?
Ainsi, pour résoudre tous ces problèmes, nous avons commencé à chercher un outil pratique. Après quelques recherches, nous avons choisi PagerDuty. PD nous a semblé être une solution assez complète et concise avec un grand nombre d'intégrations et de paramétrages. À quoi ressemble-t-elle?
En bref, PagerDuty est une plateforme de traitement des incidents capable de traiter les incidents entrants grâce à diverses intégrations, de mettre en place des ordres de service puis d'alerter l'ingénieur de service en fonction du niveau de l'incident (à un niveau élevé - un appel, à un niveau bas - un push depuis l'application / SMS) .
Qui est l'officier de service ?
C'est probablement le premier endroit pour commencer à configurer PD.
Chez FunCorp, comme dans d'autres sociétés, il existe un poste honorifique d'officier de service. Il est transmis d'ingénieur à ingénieur une fois par jour. Il existe ce qu'on appelle une première et une deuxième ligne de réponse à une alerte de PagerDuty. Supposons qu'une alerte de haute priorité arrive et que si 10 minutes après l'appel à l'ingénieur de service depuis la première ligne, il n'y a aucune réaction (c'est-à-dire qu'il n'est pas transféré à l'état d'accusé de réception ou résolu), l'appel est transmis à la seconde. ingénieur de service. Ceci est configuré dans PagerDuty lui-même via les politiques d'escalade.
Si le deuxième agent de service ne répond pas, la notification revient à le principal à l'officier de service.
Ainsi, toute alerte entrante de haute priorité ne peut rester sans traitement.
Voyons maintenant d'où peuvent provenir les incidents.
Quelles intégrations utilisons-nous ?
PD reçoit de nombreux incidents différents provenant de divers services. Nous disposons actuellement d'environ 25 services de ce type et pour les traiter, nous utilisons des intégrations prêtes à l'emploi.
- Prométhée
Le principal système de collecte de métriques est Prometheus. On a déjà beaucoup écrit à ce sujet sur Habré, je dirai juste que nous en avons plusieurs pour différents environnements : l'un collecte des métriques à partir de machines virtuelles et de dockers, un autre à partir des services Amazon, le troisième à partir de machines matérielles. Telegraf est principalement utilisé comme exportateur de métriques.
Ici aussi, je pense, tout ressort clairement du titre. Cette intégration est utilisée pour envoyer des notifications de certains scripts exécutés par cron. PD vous donne une certaine adresse à laquelle vous envoyez des lettres. Lors de la création d'un service avec une telle intégration, vous pouvez définir des priorités, dans quel ordre les incidents entrants seront traités, comment créer exactement une alerte (pour chaque lettre entrante, pour une lettre entrante + une certaine règle, etc.).
- Slack
À mon avis, une intégration très intéressante. Il y a des moments où quelque chose se produit mais n’est pas couvert par des incidents. Par conséquent, nous avons ajouté l'intégration de Slack pour créer un incident. Autrement dit, vous pouvez écrire sur Slack d'entreprise /callofduty tout est lent et va bientôt tomber en panne et le PD le traitera et enverra l'incident à l'ingénieur de service.
Nous faisons:
Nous voyons:
- API
Intégration HTTP. En fait, il n’y a rien de particulièrement intéressant ici, juste une requête POST avec un corps au format JSON. Par exemple, quelque chose d'intéressant : nous l'utilisons pour la surveillance externe en utilisant . Ce service vérifie l'accessibilité de nos sites depuis différentes parties du monde. Dans le cas où nous recevons un code de réponse inacceptable (par exemple 502), un incident est créé et tout suit alors la chaîne décrite ci-dessus. StatusCake lui-même a la capacité de surveiller les URL internes, les certificats SSL ou l'expiration du domaine.
- LibreNMS
Il s'agit d'un autre système de surveillance, vous pouvez en savoir plus sur leur site Web. . Avec son aide, nous surveillons les interfaces réseau et l'iDRAC des serveurs.
Il y avait aussi des intégrations telles que Datadog, CloudWatch. Vous pouvez en savoir plus sur ce qui leur est arrivé .
Visualisation
Le principal système de reporting d’incidents est Slack. Tous les incidents arrivant sur PD sont écrits dans un chat spécial, et si leur statut change, cela est également affiché dans le chat.
Lorsque l'occasion s'est présentée d'afficher des données utiles sur les écrans des moniteurs suspendus au plafond, nous avons soudain réalisé que nous (au département devops) n'avions rien à afficher dessus. Il existe un merveilleux Grafana, mais il ne couvre pas tout et les employés réagissent aux alertes, pas aux graphiques.
Après une recherche approfondie mais infructueuse sur GitHub pour un « tableau » concis et informatif pour PD, nous avons décidé d'écrire le nôtre - uniquement avec ce dont nous avions besoin. Bien qu'au début il y ait eu l'idée d'afficher l'interface PD elle-même, cela semblait encore plus gênant.
Pour l'écrire, il suffit d'obtenir une clé auprès d'un PD avec des droits en lecture seule.
Et voici ce que nous avons obtenu :
L'écran affiche les incidents ouverts actuellement, le nom de l'ingénieur actuellement en service dans le planning sélectionné et le temps sans incident de haute priorité (le panneau avec un incident de haute priorité sera surligné en rouge).
.
En conséquence, nous avons reçu un tableau de bord pratique pour visualiser tous nos incidents. Je serai heureux si certains d’entre vous trouvent notre expérience utile.
Source: habr.com