Maison / Technologie / PagerDuty Analytics avec Python et Periscope

PagerDuty Analytics avec Python et Periscope

Comment nous avons remplacé la vérification manuelle des alertes PagerDuty par un tableau de bord récapitulatif automatique.

Je suis un ingénieur en logiciel à Plaid dans l'équipe Data Science & Infrastructure. Nous soutenons une multitude de services pour les clients externes et les employés internes: nous mettons à la disposition des équipes produit, croissance et ingénierie des outils tels que Redshift pour les requêtes analytiques volumineuses et la Pile ELK pour une enquête en temps réel sur les nombreux services alimentant Plaid.

La prise en charge de ces services d’analyse et de surveillance est une mission essentielle: s’ils interrompent des dizaines de flux de travail au sein de la société; il est important de détecter toute dégradation du service avant que cela ne devienne un problème. En 2018, nous avons ajouté des dizaines de nouvelles fonctionnalités aux services que nous prenons en charge: nouveaux jeux de données, fonctionnalités d'analyse plus rapides et davantage de portails de données en libre-service. Nous devons rechercher tous les problèmes avant qu'ils ne soient réalisés par nos utilisateurs:

Le mode de défaillance: nos utilisateurs internes se plaignent avant que nous remarquions que quelque chose ne va pas.

Nous utilisons PagerDuty envoyer des alertes en temps réel en cas de dégradation des performances du service. Notre équipe dispose d'une rotation sur appel: nous intervenons entre quatre ingénieurs en tant que personne directement responsable du traitement des alertes de performance de service générées par PagerDuty. La semaine de votre appel, vous utilisez l’application PagerDuty pour alerter les alertes DSI-Urgent en temps réel, et l’intégration de PagerDuty en attente pour envoyer d’autres messages au canal de relâchement DSI-Notify.

PagerDuty slackbot – l'ami de tous.

Vers la fin de l’année, nous avons réalisé que même si nous avions bien fait d’ajouter de nouvelles alertes PagerDuty pour prendre en charge les accords de niveau de service pour nos services, nous n’avions pas été aussi disciplinés en triant et en résolvant les problèmes à long terme sous-jacents. Afin de prendre du recul par rapport au traitement des symptômes et de rechercher une qualité de service globale, nous avons décidé d’ajouter un résumé «sur appel» aux réunions hebdomadaires de notre équipe. Cela a contribué à faciliter la discussion sur les raisons pour lesquelles nous étions paginés, à effectuer une itération sur un service pour améliorer la fiabilité et à modifier la structure des alertes afin de réduire les fausses alarmes.

Test d'un document de transfert formalisé, avec des catégories d'alertes pour faciliter l'analyse des tendances et des commentaires sur des alertes spécifiques pour des détails spécifiques.

En tant que projet pilote, cela a bien fonctionné: nous avons pu mieux cerner les problèmes communs, identifier plus facilement les modèles et découpler la cadence de garde liée à la résolution des problèmes en temps réel avec la nécessité d’apporter des modifications de fond à plus long terme.

Toutefois, notre vision à long terme n’a pas été d’ajouter du travail manuel à la rotation sur appel. PagerDuty offre quelques vues sur l'analyse, mais nous souhaitions un contrôle plus précis du grain de nos données et pouvoir les associer à d'autres sources de données d'analyse. Nous nous sommes mis à utiliser le API PagerDuty V2 extraire les données qui permettraient d’informer les tendances en matière d’incidents et de supplanter le suivi manuel de notre document de transfert.

Nous utilisons Apache Airflow pour un large éventail d'ETL récurrents de données et a écrit un DAG Airflow unique qui télécharge un historique des données de PagerDuty, l'écrit dans S3, puis les copie de S3 vers Redshift. Vous pouvez voir une version assainie du script python dans cette essence.

DAG Airflow pour l'acquisition de données PagerDuty

Nous nous sommes concentrés sur deux tables: incidents et log_entries, ce qui nous donne un historique des équipes informées de quelle alerte à quelle date. PagerDuty offre un mois d’historique d’incidents via l’API. Étant donné qu'un utilisateur peut modifier un incident bien après la date d'origine de l'alerte, nous récupérons l'historique complet des incidents sur 30 jours et mettons à jour les données modifiées. En revanche, log_entries est un journal contenant uniquement des ajouts. Nous prenons donc plus simplement les nouvelles données à une cadence normale et les copions dans redshift.

Enfin, avec les données de Redshift, nous pouvons créer une version automatisée de notre document de transfert! Voici un exemple de requête sur le schéma final pour extraire des informations de l'historique des incidents et des notifications:

- catégoriser les alertes et compter par catégorie + date
- prend une histoire de roulement de cinq jours
sélectionner
date_trunc (& # 039; jour & # 039 ;, (created_at) :: horodatage) :: date
, Cas
lorsque incidents.summary, comme% pulsations de la circulation d'air% & # 039;
puis "Airflow Heartbeat" & # 039;
lorsque incidents.summary ressemble à & # 039;% mysql_dump% & # 039;
alors & # 039; MysqlDump & # 039;
lorsque incidents.summary ressemble à & # 039;% TaskInstance: dump _% & # 039;
alors & # 039; MongoDump & # 039;
lorsque incidents.summary, comme% ES% pas vert% & # 039;
alors & # 039; ES pas vert & # 039;
lorsque incidents.summary, comme la file d’attente%, est en train de créer% & # 039;
Ensuite, la & # 039; file d'attente Logstash & # 039;
lorsque incidents.summary ressemble à% kinesis% derrière% & # 039;
alors & # 039; Kinesis Behind & # 039;
when incidents.summary, comme & # 039;% TaskInstance% & # 039;
puis & # 039; Airflow - Other & # 039;
autre
- supprimer les numéros pour regrouper plus facilement les alertes
regexp_replace (incidents.summary, & # 039;[0-9]& # 039 ;, & # 039; & # 039;)
fin comme résumé
, compte (1)
de
pagerduty.incidents

abs (datiff (& # 039; jour & # 039 ;, getdate (), created_at)) <5
et (escalation_policy_summary = & # 039; DW-DSI & # 039;)
par groupe
1
, 2
commandé par
3 desc

Ce qui nous amène à la grande conclusion: un tableau de bord Periscope où nous pouvons examiner le nombre d'alertes, la ventilation par catégorie et par service et suivre les tendances au fil du temps.

Le tableau de bord final dans Periscope, résumant les alertes des 7 derniers jours.

Notre documentation de transfert est maintenant un peu plus propre: plutôt que de devoir taper manuellement des rapports sur des alertes individuelles, nous pouvons résumer la semaine à partir de notre tableau de bord et passer directement aux actions collectives et individuelles que nous souhaitons entreprendre pour construire une infrastructure de données résiliente et fiable.

Nouveau document de transfert, qui se concentre sur des actions concrètes

Ce nouveau processus nous a aidés à hiérarchiser et à résoudre les alertes bruyantes et les incidents persistants. En prime, il aide nos utilisateurs à faire surface et à résoudre les problèmes en suspens qui ont été masqués par la cadence des alertes sur appel, en se concentrant sur d'autres problèmes importants:

La bonne affaire: nos utilisateurs internes attaquent les vrais problèmes.


PagerDuty Analytics avec Python et Periscope a été publié à l'origine dans Hacker midi sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.

Source

A propos newstrotteur-fr

Découvrez également

Loin de la maison offre quelques nouvelles images – Newstrotteur

Voici le synopsis: Peter Parker revient dans Spider-Man: Far From Home, le prochain chapitre de …

Un commentaire

  1. lenewstrotteur, thank you for this post. Its very inspiring.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Do NOT follow this link or you will be banned from the site!