Collecter les données de surveillance appropriées
L’observation de l’intégrité et de la disponibilité de votre solution cloud vous permet de mieux comprendre les signaux que vous attendez dans vos systèmes afin de déterminer les données à collecter.
Cet article fait partie d’une série du guide de supervision du cloud.
Considérations relatives à la collecte de données
Posez-vous ces questions pour établir les critères d’une configuration de surveillance :
Composition des services : Quelle est la composition des services ? Ces dépendances sont-elles supervisées aujourd’hui ? Si c’est le cas, plusieurs outils sont-ils impliqués et y a-t-il une possibilité de consolider sans introduire de risque supplémentaire ?
Définir les états d’échecs prévisibles : Ces signaux sont les symptômes d’une défaillance, mais n’en sont pas la cause. Les outils de monitoring s’appuient sur des métriques et des journaux pour établir des diagnostics avancés et une analyse de la cause racine.
SLA de service : quel est le contrat de niveau du service (SLA) et comment allez-vous le mesurer et le signaler ?
Conception du tableau de bord de services : À quoi doit ressembler le tableau de bord de service lors de l’examen des incidents ? À quoi doit ressembler le tableau de bord pour le propriétaire du service et pour l’équipe qui assure le support du service ?
Métriques de ressources : Quelles métriques de ressources sont produites par la solution que vous devez surveiller ?
Recherche des journaux : Comment le propriétaire du service, les équipes de support et les autres membres du personnel feront-ils des recherches dans les journaux ?
Participation des parties prenantes : Incluez le propriétaire du service de supervision, le responsable des opérations informatiques et d’autres parties prenantes pendant la phase de planification. Continuez à les impliquer tout au long des cycles de développement et de mise en production de vos solutions de supervision.
Données sensibles : Quelles données sensibles dois-je éviter de collecter pour les applications que je ne souhaite pas exposer à mes opérateurs ?
La façon dont vous répondez à ces questions ainsi que les critères d’alerte déterminent la façon dont vous allez utiliser la plateforme de supervision.
Évaluer les signaux de surveillance requis
Que vous déployiez de nouvelles charges de travail avec une nouvelle solution de supervision ou que vous procédiez à une migration à partir d’une plateforme de supervision existante ou d’un ensemble d’outils de supervision, l’évaluation des signaux de supervision requis est essentielle. La conception minutieuse des signaux requis permet d’obtenir les résultats attendus et de réduire le bruit.
Tenez compte des éléments suivants :
- Actionnable : N’oubliez pas que les données de surveillance doivent être actionnables pour réduire le bruit et les faux positifs.
- Optimisé : Optimisez les données collectées pour vous donner une vue holistique de l’intégrité globale du service.
- Instrumentation des incidents : L’instrumentation définie pour identifier les incidents réels doit être aussi simple, prévisible et fiable que possible.
Développer une configuration de supervision
En règle générale, le propriétaire d’un service de supervision et son équipe adhèrent à un ensemble standard d’activités pour créer une configuration de supervision. Ces activités englobent les premières étapes de planification, les tests et la validation dans un environnement hors production, ainsi que le déploiement en production.
Pour développer des configurations de surveillance, l’équipe s’appuie sur les modes d’échecs connus, les résultats des tests de défaillances simulées et l’expérience de diverses personnes au sein de l’organisation, telles que le service d’assistance, le personnel des opérations, les ingénieurs et les développeurs.
Ces configurations sont conçues en supposant que le service existe déjà, qu’il est en cours de migration vers le cloud et qu’il n’a pas été restructuré. Pour garantir des résultats de qualité au niveau du service, il est essentiel de surveiller l’intégrité et la disponibilité de ces services au début du processus de développement. Si la surveillance de la conception du service ou de l’application n’est considérée qu’après coup, les résultats risquent d’être limités.
Pour accélérer la résolution de l’incident, tenez compte des recommandations suivantes :
Tableaux de bord de composants individuels : Définissez un tableau de bord pour chaque composant de service afin d’identifier rapidement les problèmes connus dans un domaine donné de vos applications et de votre infrastructure.
Utiliser des métriques : Utilisez les signaux de métriques intégrés aux différents composants pour vous aider à diagnostiquer et à identifier les résolutions ou les solutions de contournement si vous ne pouvez pas identifier une cause racine.
Activer les personnalisations de tableau de bord : Concevez vos tableaux de bord pour pouvoir facilement explorer les données des tableaux de bord de surveillance. Veillez à prendre en charge la personnalisation dynamique des vues, ce qui facilite le filtrage et la résolution des problèmes.
L’adoption de cet ensemble de principes directeurs peut vous offrir des insights en quasi-temps réel et une meilleure gestion de votre service.