Visionnez notre webinaire sur les diagnostics automatisés. sur demande pour en savoir plus sur les diagnostics courants pour les composants courants et sur la façon 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 consacrée aux diagnostics automatisés, un cas d'utilisation courant pour le Automatisation des processus PagerDuty portefeuille.

Dans le dernière pièce Nous avons abordé les principes fondamentaux du diagnostic automatisé et expliqué comment les équipes peuvent utiliser cette solution pour réduire les interventions de spécialistes et permettre aux équipes d'intervention de réagir plus rapidement. Dans cet article, nous allons présenter quelques exemples de diagnostics simples pour les composants les plus pertinents pour nos utilisateurs.

Mais avant de nous lancer, clarifions ce que sont les diagnostics automatisés. n'est-ce pas , d'après certains commentaires du public sur Twitter de la part de dernier article :

1. Le diagnostic automatisé diffère 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 permet d'identifier correctement ces signaux corrélés. Le diagnostic automatisé vise à aider le premier intervenant à localiser la source du problème afin de le résoudre plus rapidement lui-même ou de le signaler plus précisément.
2. Le diagnostic automatisé est différent de la surveillance La surveillance est spécifiquement conçue pour identifier les états indésirables de performance ou d'activité. Cela signifie que la plupart La surveillance n'est pas conçue pour reproduire les interventions des premiers secours afin de confirmer un incident avéré ou d'identifier les premières actions à entreprendre. Elle vise à déclencher l'alerte. Le diagnostic automatisé, quant à lui, vise à déterminer comment résoudre un problème une fois l'alerte créée.

Cela dit, les diagnostics automatisés peuvent tout à fait exploiter les données collectées par les outils de surveillance ; la plupart des utilisateurs n'appliquent pas de seuils à chaque point de données collecté. D'ailleurs, l'une de nos intégrations de diagnostic les plus courantes consiste à interroger les journaux CloudWatch. Bien qu'un agrégateur de journaux puisse être considéré comme un outil de surveillance, les premières étapes d'une investigation consistent parfois à analyser les données de l'outil de surveillance dédié au diagnostic des problèmes.

Offrir aux intervenants des capacités de diagnostic à la demande ou pré-exécution pour leurs propres environnements peut aider un premier intervenant à déterminer rapidement la cause probable, et ainsi faciliter l'intervention. moins En fournissant aux premiers intervenants des données de diagnostic généralement accessibles uniquement aux experts du domaine, on réduit considérablement le besoin de mobiliser davantage de personnes pour le dépannage. . Cela permet à son tour de réduire 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 manuelles.

État des lieux : automatisation de la réponse aux incidents

Les responsables des opérations sont souvent enthousiastes à l'idée de permettre l'autoréparation ou la remédiation automatique. On a naturellement tendance à penser qu'accélérer la résolution des problèmes grâce à l'automatisation revient à « appliquer une solution miracle ». Mais bien souvent, le principe selon lequel « deux incidents ne sont jamais parfaitement identiques » se vérifie. Face à une forte variabilité, l'intérêt de cette automatisation potentielle diminue, car elle a moins de chances d'être mise en œuvre. Par exemple, redémarrer un service essentiel peut être la solution au problème du jour, mais cela pourrait entraîner une panne en cascade – et un incident encore plus grave – le lendemain.

*Le lecteur passe maintenant à la phase initiale de sa réponse.*

Mais savez-vous ce qui est souvent très répétitif ? Les mêmes étapes d'investigation qu'un intervenant suit pour diagnostiquer le problème et déterminer ce qui s'est passé. Plus une action est répétitive, plus l'automatisation est profitable. Par exemple, imaginons qu'un incident se produise dans votre distribution Kubernetes. Quelle que soit la nature de l'incident, qu'il provienne de votre dépôt d'images ou de votre équilibreur de charge, vous effectuerez probablement la même étape de diagnostic : la récupération des journaux Kubernetes.

Ces étapes de diagnostic restent souvent statiques, en grande partie, en fonction du composant concerné et quelle que soit la priorité de l'incident. Les diagnostics automatisés, quant à eux, s'appliquent à des incidents hétérogènes ; ils ne sont pas nécessairement conçus spécifiquement pour un même incident récurrent. Ils peuvent être appliqués et personnalisés pour s'adapter à tous types d'incidents courants, de gravité variable, propres à votre environnement, et ce, pour presque tous les composants. C'est un peu comme aller chez le médecin. Que ce soit pour une consultation d'urgence ou un simple bilan de santé annuel, on prend systématiquement 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 présentent aussi des similitudes lorsqu’on les examine de plus près. Lors des premières étapes d’une intervention, la plupart des diagnostics proviennent de trois sources de données principales :

• Données de l'application
• Données système
• Données environnementales

Il existe plusieurs exemples de diagnostics et de composants courants qui peuvent être extraits automatiquement au début d'une intervention. Cela permettrait non seulement à l'intervenant de mieux comprendre la gravité de l'incident, mais aussi d'éviter de mobiliser trop de spécialistes et de perturber leur travail quotidien. Prenons par exemple… Kubernetes (k8s) en tant que composant pour un intervenant lors d'un incident. Lorsqu'un incident survient dans un environnement k8s, l'ingénieur infrastructure qui gère la technologie effectue généralement des actions telles que :

• Journaux de queue du pod k8s
• Récupérer les journaux de Kubernetes 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

Tous ces actes ont un point commun ? Un technicien de niveau 1 qui accuse réception d'un incident ne sait pas comment les orchestrer : ce n'est tout simplement pas son domaine d'expertise. Mais grâce aux tâches prêtes à l'emploi des diagnostics automatisés de PagerDury, le technicien de niveau 1 peut exécuter automatiquement ces diagnostics et ces tâches, ce qui accélère la réponse et réduit le recours à l'ingénieur infrastructure responsable de l'environnement Kubernetes.

Voici quelques exemples courants de diagnostics et d'alertes :

• Services consommateurs de processeur/mémoire
  • Alerte générale : Processeur/mémoire élevés
  • Question fréquente : Quels services consomment du processeur/de la mémoire ?
• Taille du fichier / Consommation d'espace disque
  • Alerte générale : Processeur/mémoire élevés
  • Question fréquente : Quels fichiers/répertoires consomment le plus d'espace ?
• Journaux système : Commandes Linux/Windows
  • Alerte commune Problèmes de serveur/service
  • Question fréquente : S'agit-il d'un problème lié au système d'exploitation ou à l'application ?
• Commandes de base de données SQL
  • Alerte générale : Blocages/interblocages de bases de données
  • Question fréquente : Une requête de longue durée bloque-t-elle les autres requêtes de base de données ?
• Disponibilité de l'hôte
  • Alerte générale : L'hôte est hors service.
  • Question fréquente : Le service est-il réellement en panne ou s'agit-il d'un faux positif lié à un problème d'accessibilité ?
• Erreur d'application : Journaux ou traces de l'application
  • Alerte générale : Codes d'erreur 400/500
  • Question fréquente : Quelle est la trace de la pile ?

Voici quelques exemples de diagnostics courants pour des composants connus :

• Cloudwatch Journaux : Journaux d'applications et de VPC spécifiques à la surface.
• ECS : Afficher les erreurs de la tâche ECS arrêtée.
• ELB : Déboguer les instances de groupe cible indisponibles.
• 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 exemples parmi plus de 30 modèles de tâches prêts à l'emploi que nous avons créés pour nos utilisateurs et que vous pouvez trouver dans… Guide des solutions 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 la FAQ pour plus de détails sur l'utilisation. Si vous ne possédez pas de licence pour l'un ou l'autre de ces produits, Contactez-nous Pour en savoir plus.

Automatisation des diagnostics dans PagerDuty

Les incidents qui alertent les intervenants sont souvent accompagnés d'informations fournies par des outils de surveillance qui offrent une vision partielle des alertes. Par exemple, une utilisation élevée du processeur déclenche une alerte, qui notifie un intervenant. Cependant, les informations contenues dans l'alerte sont superficielles car elles ne précisent pas la cause de cette hausse soudaine.

Données diagnostiques Il s'agit des informations plus approfondies qui permettent 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 la plupart des outils d'aide à l'analyse des causes profondes soient insuffisants pour reproduire les étapes d'investigation et de dépannage d'un intervenant, notamment la collecte de données provenant de sources disparates en une vue unifiée, leur mise à disposition offre aux intervenants des capacités de diagnostic à la demande ou pré-exécution. On augmente ainsi leurs chances de résoudre le problème par eux-mêmes et la probabilité de solliciter des renforts. moins Des personnes sont mobilisées pour intervenir en cas d'incident. Lancez le diagnostic automatisé.

Vous souhaitez en savoir plus sur les diagnostics courants des composants que vous utilisez ? Registre pour notre webinaire du 14 septembre Du même nom, animé par Justyn Roberts, consultant senior en solutions PagerDuty. Vous débutez dans l'automatisation des processus ? Demander une démo . Vous utilisez déjà PageDuty Process Automation ? Découvrez la diagnostics automatisés guide de solutions Pour découvrir le processus complet menant à la solution finale. Des questions ? Contactez-moi directement sur Twitter. @sordnam un Et discutons-en !