Dans nos précédents articles de blog sur Capture de l'état de l'application et en utilisant Conteneurs éphémères pour le débogage de Kubernetes Nous avons discuté de l'intérêt de pouvoir déployer des outils spécifiques pour recueillir des diagnostics en vue d'une analyse ultérieure, tout en fournissant à l'intervenant sur l'incident les moyens de résoudre les problèmes d'infrastructure ou d'application.

Cela permet de trouver un équilibre entre la nécessité de rétablir un service le plus rapidement possible et celle de garantir la disponibilité de suffisamment de données de débogage pour une résolution permanente ultérieure, tout en permettant à une équipe de développement de maintenir un conteneur fonctionnant de manière légère et performante.

En capturant à la fois l'état de l'application et de l'environnement lors de l'incident, tout intervenant ou responsable de service passe moins de temps à changer de contexte entre les outils, les identifiants et les environnements, ce qui permet des réponses et une résolution des problèmes plus précises et plus rapides.

Les techniques abordées dans les précédents articles de cette série étaient axées sur les plateformes modernes natives du cloud comme Kubernetes, et sur les approches spécifiques nécessaires aux conteneurs, en particulier ceux qui ne sont pas livrés nativement avec des outils de débogage.

Tout le monde n'est pas en mesure ou disposé à migrer toutes ses applications vers le cloud natif, et beaucoup d'entre nous travaillent encore dans un scénario hybride combinant applications conteneurisées et applications traditionnelles.

Même sans la nature éphémère des conteneurs et les politiques strictes relatives aux images de conteneurs, il reste nécessaire de recueillir des preuves sur le champ pour faciliter l'analyse des causes profondes et éviter que de tels incidents ne se reproduisent.

Examinons des cas d'utilisation décrivant la capacité à capturer automatiquement l'état en cas de panne ou de baisse de performance, et choisissons quelques scénarios intéressants à explorer plus en détail.

Cette liste n'est pas exhaustive, mais voici quelques exemples de la manière dont la capture d'état de débogage est utilisée dans les environnements d'application traditionnels :

Infrastructure et réseau

• Processus les plus gourmands en ressources sur un ou plusieurs composants d'infrastructure
• Vidage TCP ; vidage des threads/de la mémoire/des fichiers mémoire

Base de données

• Requêtes consommatrices de ressources
• État actuel de la requête
• Exécution de requêtes spécifiques à l'application

Spécifique à l'application

• Java – Effectuer un vidage de thread/de tas avec des outils comme jstack
• Windows – Vidage du processeur
• Python – Exécution d'un thread dump
• Tous – Fichiers journaux spécifiques à l'application

Fichiers journaux supplémentaires

La capture d'état de débogage peut récupérer des journaux complets ou partiels de n'importe quel fichier qui ne peut pas être capturé par un agrégateur de journaux.

PagerDuty Process Automation propose de nombreux modèles de flux de travail prédéfinis pour la capture de l'état des applications et de l'environnement. projet de diagnostic automatisé Ces flux de travail sont flexibles et extensibles, ce qui permet de les personnaliser pour les adapter à vos cas d'utilisation spécifiques.

Approfondir

Examinons de plus près quelques exemples précis de capture de l'état de l'environnement qui pourraient s'avérer utiles pour identifier la solution à long terme à un incident.

Cas d'utilisation 1 – Collecte des données de débogage de la base de données

Nous pouvons utiliser l'étape SQL RUN dans Process Automation pour ajouter une instruction en ligne ou exécuter un script existant. Mon application étant basée sur MariaDB (une version dérivée de MySQL), je peux utiliser les paramètres suivants pour exécuter la requête MySQL :

AFFICHER LA LISTE COMPLÈTE DES PROCESSUS ;

( Note : les informations d'identification proviennent de mon système de stockage externe existant et sont transmises de manière sécurisée lors de l'exécution de l'étape dans le cadre d'un flux de travail, ce qui me permet de déléguer en toute sécurité sans exposer d'informations.

Je transmets le résultat à ma plateforme de gestion des incidents (dans mon cas, PagerDuty, bien sûr), et je configure la tâche pour qu'elle collecte automatiquement les données si un incident survient au sein du service de base de données.

Ces informations sont désormais automatiquement accessibles à mon interlocuteur via son application, son outil de chatops ou lors de toute analyse post-mortem. Dans ce cas précis, je peux constater qu'un test de performance est en cours au moment de l'incident ! Comme pour les précédents articles de blog, il serait également facile de publier des versions plus complexes de ces données dans un environnement de stockage tel qu'un compartiment AWS S3 pour une analyse ultérieure.

Cas d'utilisation 2 – Collecte des informations de débogage de l'application

Mon outil d'observabilité m'informe très rapidement QUAND une application a échoué, mais pas toujours de la raison de cet échec. Ce second cas d'utilisation exécutera une commande ad hoc pour mon application Python afin d'utiliser py-spy, un profileur d'échantillonnage, conjointement avec l'un de nos plugins d'automatisation pour déplacer des fichiers de manière sécurisée vers S3 en vue de leur récupération ultérieure.

Envoie les données directement vers mon stockage S3 :

Cet exemple met en évidence les états des nœuds de calcul de mon application Python au niveau des threads, directement entre les mains de mon développeur, et stockés aussi longtemps qu'il pourrait en avoir besoin pour s'y référer.
Bien sûr, ces commandes ne sont pas exclusives, et je pourrais facilement enchaîner plusieurs vérifications pour obtenir une vue d'ensemble plus large.

Cas d'utilisation 3 – Capture d'état de débogage d'infrastructure traditionnelle

Pour le troisième cas d'utilisation, je dois déployer un ensemble de commandes bash sur une machine distante et les exécuter à nouveau lors de l'événement déclencheur. Cela permet principalement d'afficher des diagnostics tels que les fichiers ouverts et les connexions réseau, mais aussi d'exécuter d'autres tâches. bpftrace , un outil qui peut être utilisé pour tracer des appels spécifiques :

L'automatisation des processus me permet de définir et de déployer un script complet et de stocker le résultat afin de recueillir un instantané de l'état de mon environnement :

Conclusion

Même dans les environnements traditionnels, les signaux provenant des outils de surveillance gagnent en visibilité, permettant ainsi à tout intervenant, ingénieur DevOps ou SRE de prendre des décisions rapides et sûres. Les développeurs ont également souvent besoin d'informations supplémentaires et de la possibilité de capturer l'état du système en cas de problème, car ils ne sont pas toujours disponibles immédiatement.

La capture d'état de débogage permet cela, en fournissant un contexte supplémentaire à l'utilisateur, en réduisant le temps passé à explorer différents outils et en offrant la possibilité de collecter des ensembles de données plus approfondis pour une analyse ultérieure.

Envie d'en savoir plus ? Commencez dès aujourd'hui avec un essai gratuit. Automatisation des manuels d'exploitation .