Regardez notre webinaire sur les diagnostics automatisés sur demande pour en savoir plus sur les diagnostics courants des composants courants et sur la manière dont nous fournissons des modèles de tâches prêts à l'emploi pour vous permettre de démarrer immédiatement.

Il s'agit du deuxième article d'une série sur les diagnostics automatisés, un cas d'utilisation courant pour le Automatisation des processus PagerDuty portefeuille.

Dans le dernier morceau , nous avons parlé des bases du diagnostic automatisé et de la façon dont les équipes peuvent utiliser la solution pour réduire les escalades vers les spécialistes et permettre aux intervenants d'agir plus rapidement. Dans ce blog, nous allons parler de quelques exemples de diagnostics de base pour les composants les plus pertinents pour nos utilisateurs.

Mais avant de nous lancer, clarifions ce qu'est le diagnostic automatisé. n'est pas , basé sur certains commentaires du public sur Twitter de la part de dernier article :

1. Le diagnostic automatisé est différent de la corrélation des alertes . La corrélation des alertes dépend d'une profondeur de signaux spécifiée, ainsi que d'un moteur qui peut identifier correctement les signaux corrélés. Les diagnostics automatisés sont destinés à aider le premier intervenant à trianguler la source du problème pour soit résoudre le problème plus rapidement lui-même, soit l'escalader avec plus de précision.
2. Le diagnostic automatisé est différent de la surveillance . La surveillance est spécialement conçue pour identifier les états indésirables dans les performances ou les activités. Cela signifie que la plupart La surveillance n'est pas conçue pour imiter les activités d'un premier intervenant afin de valider un vrai positif ou d'identifier les premières mesures à prendre. La surveillance est axée sur le déclenchement de l'alerte. Les diagnostics automatisés visent à déterminer comment résoudre un problème une fois l'alerte créée.

Cela dit, les diagnostics automatisés peuvent certainement utiliser les données collectées par les outils de surveillance. La plupart des gens n'appliquent pas de seuils à chaque point de données qu'ils collectent. En fait, l'une de nos intégrations de diagnostic les plus couramment utilisées consiste à interroger les journaux CloudWatch. Bien que nous puissions considérer un agrégateur de journaux comme un outil de surveillance, les premières étapes de l'investigation consistent parfois à examiner les données de l'outil de surveillance qui existent uniquement pour diagnostiquer les problèmes.

Fournir aux intervenants des capacités de diagnostic à la demande ou pré-exécutées pour leurs propres environnements peut aider un premier intervenant à déterminer rapidement la cause probable, attirant ainsi moins des personnes pour aider à résoudre l'incident. En fournissant aux premiers intervenants des données de « diagnostic » qui ne sont généralement récupérables que par des experts du domaine, la nécessité de faire appel à davantage de personnes pour résoudre les incidents est considérablement réduite . Cela réduit à son tour le coût des incidents et le temps moyen de réponse (MTTR) en automatisant les étapes d’enquête qui sont généralement de nature manuelle.

Le statu quo : l'automatisation de la réponse aux incidents

Les responsables des opérations sont souvent enthousiasmés par l’idée de permettre l’auto-réparation ou la correction automatique. Il est naturel de penser qu’accélérer la résolution grâce à l’automatisation signifie « appliquer un remède ». Mais le plus souvent, la théorie du secteur selon laquelle « aucun incident n’est vraiment identique » fait son apparition. Lorsque le degré de variabilité est élevé, cela réduit la valeur de cette automatisation potentielle, car elle est moins susceptible d’être exécutée. Par exemple, le redémarrage d’un service principal peut être la bonne façon de résoudre le problème d’aujourd’hui, mais cela peut conduire à une défaillance en cascade et à un incident encore plus grave demain.

*Le lecteur passe maintenant à la vitesse cognitive et passe aux étapes initiales d’une réponse.*

Mais savez-vous ce qui a tendance à être très répétitif ? Les mêmes étapes d'investigation qu'un intervenant entreprend pour commencer à diagnostiquer ce qui s'est passé et déterminer ce qui s'est passé. Une action plus répétitive signifie plus de valeur à tirer de l'application de l'automatisation. Par exemple, disons qu'un incident se produit dans votre distribution Kubernetes. Quelle que soit la nature de l'incident, qu'il s'agisse d'un incident dans votre référentiel d'images ou dans votre équilibreur de charge, vous allez probablement toujours suivre la même étape de diagnostic consistant à extraire vos journaux Kubernetes.

Ces étapes de diagnostic restent souvent statiques, pour la plupart, en fonction du composant avec lequel vous travaillez, quelle que soit la priorité de l'incident qui se produit. Les diagnostics automatisés peuvent être applicables à des incidents hétérogènes. Ils ne doivent pas nécessairement être conçus spécifiquement pour le même incident récurrent. Ils peuvent être appliqués et personnalisés autour de toutes sortes de types et de gravités d'incidents courants, spécifiques à votre environnement, pour presque tous les composants courants. Pensez-y comme si vous alliez chez le médecin. Que vous vous rendiez aux urgences pour une plainte spécifique ou simplement pour un contrôle annuel, ils prennent toujours votre température, votre tension artérielle et votre poids à votre arrivée.

Exemples courants

Chaque environnement de développement est différent, mais de nombreux environnements sont également assez similaires une fois que vous avez vraiment ouvert le capot. Au début d'une réponse, la plupart des diagnostics proviendront de trois sources de données principales :

• Application Data
• Données système
• Données environnementales

Il existe plusieurs exemples de diagnostics et de composants courants qui peuvent être automatiquement extraits au début d'une intervention. Cela aiderait non seulement l'intervenant à mieux comprendre la gravité de l'incident, mais permettrait également de s'assurer qu'il ne fasse pas appel à trop de spécialistes et ne les interrompe pas dans leur journée de travail normale. Par exemple, examinons Kubernetes (k8s) en tant que composant d'un intervenant lors d'un incident. Lorsqu'un incident se produit dans un environnement k8s, l'ingénieur d'infrastructure qui assure la maintenance de la technologie effectue généralement des actions telles que :

• Journaux de bord du pod k8s
• Récupérer les journaux de k8s par étiquette de sélecteur
• Vérifier le dépôt d'images
• Décrire le déploiement
• Exécuter la commande dans le pod

Toutes ces actions ont un point commun : un intervenant L1 typique qui accuse réception d'un incident ne sait pas comment orchestrer ces actions, ce n'est tout simplement pas son domaine d'expertise. Mais avec les tâches prêtes à l'emploi des diagnostics automatisés de PagerDury, l'intervenant L1 peut exécuter automatiquement ces diagnostics et ces tâches, ce qui accélère la réponse et réduit l'escalade vers l'ingénieur d'infrastructure responsable de l'environnement k8s.

Voici quelques exemples courants de diagnostics et d’alertes :

• Services consommant du CPU/de la mémoire
  • Alerte commune : CPU/mémoire élevés
  • Question commune: Quels services consomment du CPU/de la mémoire ?
• Taille du fichier / Consommation du disque
  • Alerte commune : CPU/mémoire élevés
  • Question commune: Quels fichiers/répertoires consomment le plus d’espace ?
• Journaux système : commandes Linux/Windows
  • Alerte commune : Problèmes de serveur/service
  • Question commune: S'agit-il d'un problème de système d'exploitation ou d'application ?
• Commandes de base de données SQL
  • Alerte commune : Blocages/blocages de base de données
  • Question commune: Existe-t-il une requête de longue durée bloquant d’autres requêtes de base de données ?
• Disponibilité de l'hôte
  • Alerte commune : Hôte en panne
  • Question commune: Est-ce que c'est réellement en panne ou s'agit-il d'un problème d'accessibilité faussement positif ?
• Erreur d'application : Journaux ou traces d'application
  • Alerte commune : Codes d'erreur 400/500
  • Question commune: Qu'est-ce que la stack-trace ?

Quelques exemples de diagnostics courants pour des composants connus :

• Surveillance des nuages Journaux: Application spécifique à la surface et journaux VPC.
• ECS: Afficher les erreurs des tâches ECS arrêtées.
• ELB: Déboguer les instances de groupe cible non disponibles.
• Kubernetes Récupérer les journaux des pods par étiquette de sélecteur.
• Linux. Récupérer l'état du service.
• Nginx . Récupérer les journaux d'erreurs.
• Redis Entrées de journal lentes.

Et ce ne sont là que quelques-uns des plus de 30 modèles d'emplois prêts à l'emploi que nous avons créés pour nos utilisateurs et que vous pouvez trouver dans le Guide de solution de diagnostic automatisé. Pour utiliser la solution de diagnostic automatisé, vous devez disposer d'une licence PagerDuty Runbook Automation ou d'une licence Process Automation (anciennement Rundeck Enterprise). Voir le FAQ pour plus de détails sur la façon de les utiliser. Si vous ne possédez pas de licence pour l'un de ces produits, Contactez-nous pour apprendre plus.

Automatisation des diagnostics dans PagerDuty

Les incidents qui avertissent les intervenants sont remplis d’informations fournies par des outils de surveillance qui ont une vue « myope » sur la ou les alertes. Un exemple courant est qu’une utilisation élevée du processeur déclenche une alerte, ce qui avertit un intervenant. Mais les informations contenues dans l’alerte sont superficielles dans la mesure où elles ne précisent pas quelle pourrait être la cause de l’augmentation du processeur.

Données de diagnostic est l'information de niveau plus profond qui permet de répondre aux questions « pourquoi » et « où » des incidents. Même si certains outils de surveillance et de corrélation fournissent quelques Bien que les outils d'analyse des causes profondes soient utiles aux utilisateurs, la plupart d'entre eux ne parviennent pas à imiter les étapes d'investigation/dépannage d'un intervenant consistant à rassembler des sources de données disparates dans une vue unifiée. En fournissant aux intervenants des capacités de diagnostic à la demande ou avant exécution, les chances que le premier intervenant résolve le problème par lui-même augmentent, ainsi que la probabilité d'intervenir. moins des personnes pour aider à résoudre l'incident. Entrez dans les diagnostics automatisés.

Vous souhaitez en savoir plus sur les diagnostics courants des composants que vous utilisez ? Registre pour notre événement webinaire du 14 septembre du même nom, animé par Justyn Roberts, consultant principal en solutions, PagerDuty. Vous débutez dans l'automatisation des processus ? Demander un démo . Vous utilisez déjà PageDuty Process Automation ? Découvrez diagnostic automatisé guide de solutions pour voir le processus de bout en bout pour parvenir à la solution complète. Des questions ? Contactez-moi directement sur Twitter @sordnam un Et discutons !