Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Étape 2 : Mettre en œuvre l'observabilité
À ce stade, vous lancez le processus permettant à vos équipes de se frayer un chemin progressivement vers l'étoile polaire.
Choisissez votre plateforme d'observabilité
La première étape consiste à identifier les bons outils pour ingérer, visualiser et analyser les signaux, ainsi que pour envoyer des alertes. Lorsque vous sélectionnez un outil, tenez compte de ses fonctionnalités, de son modèle de licence, de son prix, de ses compétences requises et de sa maintenance.
Ensemble de fonctionnalités
Voici certaines des questions à prendre en compte :
-
Configurabilité et personnalisation. Quelles fonctionnalités l'outil offre-t-il pour simplifier l'expérience d'enquête et contribuer à réduire le MTTR ? L'outil offre-t-il une corrélation des alarmes, des calculs métriques, une flexibilité dans la gestion de la télémétrie manquante ou la détection d'anomalies ?
-
Granularité. Quelle est la granularité prise en charge pour l'ingestion et la visualisation des signaux de télémétrie ?
-
Personnages. L'outil prend-il en charge les expériences que vous souhaitez offrir à vos développeurs, à vos ingénieurs de plateforme et à d'autres personnes ? Cela fonctionne-t-il à la fois pour les techniciens et les professionnels ?
-
Widgets. Quels types de widgets sont compatibles avec les tableaux de bord ? L'outil permet-il de créer des widgets personnalisés ?
-
Solutions prédéfinies. Quels types de solutions d'observabilité prédéfinies l'outil propose-t-il pour réduire le délai de rentabilisation ?
-
Automatisation et IA générative. Quelles sont les fonctionnalités de l'outil qui peuvent aider à automatiser ou à réduire le travail pour vous et votre équipe ? Par exemple, la détection automatique des anomalies, l'analyse prédictive et d'autres fonctionnalités d'IA générative peuvent aider à réduire le stress lié aux hypothèses et aux inconnues (c'est-à-dire des choses dont vous n'êtes pas conscient ou que vous ne comprenez pas parfaitement). L'outil prend-il en charge l'utilisation de AI/ML modèles génératifs pour améliorer l'analyse des données à grande échelle ? Vous offre-t-il la possibilité d'automatiser et de mettre en œuvre AIOps ?
-
Sûreté.Quels types d'intégrations d'authentification et d'autorisation l'outil prend-il en charge ? Les expériences utilisateur et de connexion répondent-elles aux besoins de votre organisation ?
-
OpenTelemetry soutien. L'outil et l'agent OpenTelemetry sont-ils compatibles ? La plupart des plateformes d'observabilité prennent en charge l'ingestion de signaux OpenTelemetry compatibles, mais tous les agents ne proposent pas d'options de configuration pour transférer ces signaux vers une plateforme d'observabilité.
-
Intégrations. Quelles sont les intégrations proposées par l'outil ? Déterminez si vous devez envoyer des alertes à Slack, aux membres de l'équipe de page ou automatiser la résolution.
-
Scalabilité. Dans quelle mesure l'outil est-il évolutif et performant ? La solution d'observabilité doit évoluer à mesure que vos demandes et votre utilisation augmentent, afin de pouvoir fournir des diagnostics même si votre application n'est pas disponible.
-
Support. Quel est le modèle de support proposé ? Votre outil d'observabilité doit être disponible même en cas de défaillance de votre application afin que vous puissiez atteindre vos objectifs de MTTR et de disponibilité des applications ou vos accords de niveau de service (). SLAs Les solutions open source peuvent offrir un support formel limité.
Modèle de licence et de déploiement
Tenez compte du modèle de licence (open source ou commercial) et du modèle de déploiement (auto-hébergé ou basé sur le cloud) de la solution. Les options open source ont souvent des coûts initiaux moins élevés, mais peuvent nécessiter plus de temps pour le déploiement, l'installation et la configuration, la maintenance et le renforcement des compétences des équipes avant d'apporter de la valeur. Si vous envisagez des options open source, vous pourriez avoir besoin d'une équipe dédiée d'experts en observabilité. Les logiciels commerciaux offrent généralement un délai de rentabilisation plus rapide avec un coût initial plus élevé, et le besoin d'une équipe dédiée à l'observabilité évolue au fil du temps à mesure que l'adoption, la complexité et la maturité augmentent. Les solutions auto-hébergées nécessitent plus de temps pour le déploiement, l'installation et la configuration, la maintenance et les frais opérationnels par rapport aux solutions basées sur le cloud.
Grille tarifaire
Quel sera l'impact du modèle de tarification de l'outil sur votre coût total de possession (TCO) à mesure que votre application gagnera de nouveaux utilisateurs, augmentera l'encombrement de l'architecture ou créera de nouvelles fonctionnalités et applications ? Par exemple, certains modèles de licence classiques sont perpétuels ou basés sur les abonnements, le nombre d'utilisateurs nommés, la consommation ou le volume. Réfléchissez à l'évolution de l'utilisation de votre application et de l'outil d'observabilité et à l'impact du modèle de licence sur le coût de l'outil.
Compétences d'équipe
En fonction des compétences actuelles et de la maturité de votre équipe, vous devrez déterminer le niveau de renforcement des compétences requis. Réfléchissez au type de support fourni par le fournisseur pour former votre équipe. Déterminez également si votre structure organisationnelle prend en charge la configuration et la gestion de l'outil que vous choisissez. Par exemple, si vous le souhaitez OpenTelemetry, vous devriez envisager de créer une équipe distincte spécialisée dans l'observabilité.
Exploitation et maintenance
Évaluez les questions suivantes :
-
Quelles sont les options de déploiement proposées par l'agent ou le collecteur d'observabilité ? Ces options répondent-elles aux exigences de votre architecture ? Par exemple, si vous utilisez un déploiement conteneurisé pour l'outil d'observabilité, celui-ci prend-il en charge un daemonset ou un sidecar ? Quelles mesures ou quels outils supplémentaires l'équipe des opérations devrait-elle prendre ou utiliser pour garantir l'alignement avec la sécurité et tous les autres processus ?
-
Quels sont les efforts nécessaires pour maintenir la solution ? Dans quelle mesure le processus de mise à jour de l'agent ou du collecteur est-il simple ou automatisé ? Les interfaces d'observabilité entièrement gérées et basées sur le cloud ont généralement une charge opérationnelle moindre par rapport aux applications auto-déployées et hébergées, bien que la gestion de l'agent ou du collecteur reste la même. Tenez compte de la structure de votre équipe et prenez en compte le coût humain du maintien de l'option que vous choisissez.
Instrumentez votre application
Les réponses aux questions de la section précédente vous fournissent les informations dont vous avez besoin pour instrumenter votre application, c'est-à-dire pour ajouter du code afin de capturer les signaux de télémétrie envoyés à votre application et de mesurer, observer et valider les comportements. Vous pouvez SDKs notamment utiliser le OpenTelemetry SDK pour la langue de votre application afin d'instrumenter automatiquement votre application. Il se peut que vous deviez tout de même ajouter un code d'instrumentation manuel pour combler les éventuelles lacunes et garantir end-to-end la visibilité. Soyez attentif à la télémétrie que vous ajoutez et assurez-vous de pouvoir la reconnecter à une ou plusieurs SLIs télémétrie SLOs que vous avez établies à l'étape précédente.
Collectez la télémétrie
Implémenter les composants d'observabilité
Lorsque la télémétrie circule et est ingérée dans une plateforme d'observabilité, créez des tableaux de bord, des alertes, des playbooks et des runbooks.
-
Tableaux de bord : créez des tableaux de bord contenant des informations pertinentes, notamment une représentation visuelle des tendances actuelles et historiques associées à vos résultats prioritaires. Mettez ces tableaux de bord à la disposition des parties prenantes que vous avez définies à l'étape 1. Pour plus d'informations, consultez Création de tableaux de bord pour une visibilité opérationnelle
sur le site Web Amazon Builders' Library. -
Alertes : définissez des alertes pour avertir votre équipe lorsque les résultats sont menacés ou ne sont pas respectés. Envisagez d'ajouter des alertes en cas de problèmes de sécurité et de performance. Optimisez les alertes afin de réduire la fatigue liée aux alertes et les coûts en adoptant les mesures suivantes :
-
Utilisez la détection des anomalies pour éviter de définir des seuils stricts, qui nécessitent des ajustements fréquents, et pour réduire l'occurrence d'inconnues.
-
Utilisez des combinaisons d'alertes intelligentes qui examinent plusieurs indicateurs connexes ensemble au lieu de configurer des alertes individuelles pour chaque indicateur. Par exemple, au lieu de configurer des alertes distinctes pour le processeur, la mémoire et le temps de réponse, créez une alerte significative qui ne se déclenche que lorsque ces indicateurs indiquent collectivement un problème réel. Cette approche réduit considérablement le bruit des alertes et permet à vos équipes de se concentrer sur les problèmes réels ayant un impact sur le service au lieu d'avoir à répondre à des pics métriques isolés.
-
Générez des alertes uniquement lorsque l'expérience utilisateur ou les résultats sont menacés. Par exemple, évitez de recevoir des alertes concernant un pic de processeur provoqué par une mise à niveau automatique lorsque votre application ne compte aucun utilisateur actif.
-
-
Playbooks : Un playbook fournit un modèle mental et un contexte à la personne qui répond à un incident ou à une alerte, et l'aide à identifier plus rapidement la cause première. Envisagez de créer des playbooks pour les applications complexes et hautement couplées et pour les applications dépourvues d'instrumentation mais ayant un impact direct sur les résultats que vous avez identifiés et priorisés à l'étape 1.
-
Runbooks : utilisez des runbooks pour définir les étapes nécessaires à la résolution d'un incident ou d'une alerte.
Valider le système d'observabilité
Tout au long de votre cycle de développement logiciel (SDLC), vérifiez que les tableaux de bord fournissent les comportements attendus et les mises à jour lors des tests du système. Mettez en œuvre l'ingénierie du chaos et validez les étapes décrites dans les playbooks et les runbooks, afin de vous assurer qu'elles sont précises et répondent à leurs objectifs. Vous devez également valider la propriété des alertes et les chemins d'escalade.
