La couverture des alertes de prestation de services garantit que vos applications et services destinés aux clients disposent d'alertes monitoring pour détecter les problèmes susceptibles d'avoir un impact sur l'expérience utilisateur et les opérations commerciales.
À propos de cette règle de dashboard
Cette règle de couverture d'alerte de prestation de services fait partie du niveau 1 (réactif) du modèle de maturité des temps de disponibilité de l'entreprise. Il vérifie que vos applications et services disposent d'alertes de base configurées pour vous avertir lorsque des problèmes rencontrés par les clients surviennent.
Pourquoi cela est important : les problèmes de prestation de services ont un impact direct sur l’expérience client et les revenus de l’entreprise. Sans alerte d'application appropriée, vous risquez de ne découvrir des problèmes que lorsque les clients les signalent, ce qui peut entraîner des pannes plus longues et des relations clients endommagées.
Comment fonctionne cette règle
Cette règle examine votre entité de prestation de services et vérifie si elle a défini une condition d'alerte. Plus précisément, il recherche des alertes sur :
- Entités APM-APPLICATION : monitoring des applications et services backend par les agents APM
- Entités BROWSER-APPLICATION : Moniteur d'applications Web frontend en monitoring les navigateurs
- Entités MOBILE-APPLICATION : Moniteur d'applications mobiles par monitoring des applications mobiles
- Entités SYNTH-MONITOR : Moniteur synthétique qui simule l'interaction utilisateur
La règle échoue si une entité de prestation de services de monitoring manque d'au moins une condition d'alerte.
Comprendre votre score
- Pass (Vert) : Toutes les entités de prestation de services ont au moins une condition d'alerte définie
- Échec (rouge) : une ou plusieurs entités de prestation de services manquent de couverture d'alerte
- Cible : couverture d'alerte à 100 % sur toutes les applications et tous les services destinés aux clients
Ce que cela signifie :
- Score de réussite : Votre base de monitoring des applications est en place pour détecter les problèmes ayant un impact sur les clients
- Score d'échec : certaines applications ou certains services pourraient échouer sans alerter votre équipe, ce qui pourrait avoir un impact sur les clients.
Comment améliorer la couverture des alertes de prestation de services
Si votre score indique des alertes de prestation de services manquantes, suivez ces étapes pour établir une couverture complète :
1. Identifier les services non couverts
- Examiner l'entité défaillante : identifier les applications ou services spécifiques qui manquent de couverture d'alerte
- Prioriser en fonction de l'impact sur les clients : se concentrer d'abord sur les applications destinées aux clients et les services critiques pour les revenus
- Évaluer la criticité du service : déterminer quels services nécessitent une alerte immédiate ou différée
2. Configurer des alertes de livraison de services essentiels
Configurez des alertes pour ces mesures critiques en fonction de votre type d'entité :
Alertes d'application APM :
- Taux d'erreur : Alerte lorsque le pourcentage d'erreur dépasse 5 % pendant 5 minutes
- Temps de réponse : Alerte lorsque le temps de réponse moyen dépasse le seuil acceptable (par exemple > 2 secondes)
- Débit : alerte lorsque le volume de requêtes diminue considérablement, indiquant des pannes potentielles
- Score Apdex : alerte lorsque les scores de satisfaction des utilisateurs tombent en dessous des niveaux acceptables (par exemple, moins de 0,8)
Alertes d'application Browser :
- Erreurs JavaScript : alerte en cas de pic du taux d'erreur du frontend
- Temps de chargement de page : Alerte lorsque les temps de chargement de page dépassent le seuil d'expérience utilisateur
- Core Web Vitals: alerte lorsque des métriques telles que Largest Contentful Paint ou Cumulative Layout Shift se dégradent
- Sessions utilisateur : Alerte lorsque les sessions des utilisateurs actifs s'arrêtent de manière inattendue
Alertes d'applications mobiles :
- Taux de plantage : Alerte lorsque les taux de plantage des applications dépassent 1 à 2 %
- Erreurs réseau : alerte en cas de pic d'échecs de requêtes réseau
- Heure de lancement de l'application : alerte lorsque les temps de démarrage de l'application deviennent inacceptables
- Interaction utilisateur : alerte lorsque les actions clés de l'utilisateur (connexion, achat) échouent fréquemment
Alertes du moniteur Synthétique :
- Moniteur des pannes : alerte immédiate en cas de défaillance des contrôles synthétiques
- Dégradation des performances : alerte lorsque transaction Synthétique augmentent considérablement
- Disponibilité : Alerte lorsque le temps de disponibilité tombe en dessous des exigences SLA (par exemple, moins de 99,9 %)
- Pannes multi-sites : alerte lorsque le même problème apparaît sur plusieurs sites
3. Configurer efficacement les alertes
Définir un seuil approprié :
- Seuil de base sur les données de performance historiques et les exigences commerciales
- Utiliser un seuil différent pour différents environnements (la production devrait être plus sensible)
- Tenir compte de l'impact de l'expérience utilisateur lors de la définition du temps de réponse et du taux d'erreur seuil
Choisissez des fenêtres d’évaluation appropriées :
- Utilisez des fenêtres plus courtes (2 à 5 minutes) pour les problèmes critiques rencontrés par les utilisateurs
- Utilisez des fenêtres plus longues (10 à 15 minutes) pour les tendances de performance qui nécessitent du temps pour s'établir
- Évitez les fenêtres si courtes qu’elles se déclenchent sur des fluctuations temporaires
4. Établir des procédures de réponse aux incidents
- Définir le canal de notification: configurer l'intégration avec Slack, PagerDuty ou e-mail
- Désigner des équipes responsables : s'assurer que les alertes parviennent aux équipes capables de diagnostiquer et de résoudre les problèmes
- Créer des chemins d'escalade : définir ce qui se passe si les alertes ne sont pas reconnues dans les délais SLA
- Procédures de réponse aux tests : vérifier que les équipes peuvent réellement répondre aux problèmes signalés et les résoudre
Mesurer l'amélioration
Suivez ces mesures pour vérifier les améliorations de votre couverture d’alerte de prestation de services :
- Pourcentage de couverture : monitoring de l'IA pour une couverture d'alerte de 100 % sur les applications et services de production
- Temps moyen de détection (MTTD) : mesurez la rapidité avec laquelle les alertes identifient les problèmes ayant un impact sur les clients
- Précision des alertes : monitorez le pourcentage d'alertes qui représentent de véritables problèmes nécessitant une action
- Réduction de l'impact sur les clients : déterminez si une détection plus rapide conduit à des pannes plus courtes pour les clients
Scénarios et solutions courants
Applications héritées ou inutilisées :
- Problème : les anciennes applications apparaissent toujours dans monitoring , mais ne servent plus les clients
- Solution : supprimez les applications inutilisées de monitoring ou tag les comme obsolètes pour les exclure des exigences de couverture.
Environnements de développement et de test :
- Problème : les applications hors production encombrent les mesures de couverture des alertes
- Solution : utiliser des conventions de balises ou de dénomination pour séparer les environnements et concentrer les règles de couverture sur les services de production
Architectures de microservices :
- Problème : De nombreux petits services rendent difficile l'obtention et le maintien d'une couverture à 100 %.
- Solution : Prioriser les services destinés aux clients et les dépendances critiques, utiliser des cartes de services pour identifier les composants clés
Dépendance à un tiers :
- Problème : les services externes ne sont pas sous votre contrôle mais ont un impact sur vos applications
- Solution : Créer un moniteur Synthétique pour tester les intégrations et API tierces critiques
Considérations avancées
Personnalisation des règles de couverture
Vous devrez peut-être ajuster la règle du dashboard si :
- Différents types de services : Votre architecture comprend d'autres types d'entités (fonction Lambda, base de données, fichier d'attente des messages)
- Niveaux de criticité de l'entreprise : certains services sont plus critiques que d'autres et nécessitent des stratégies d'alerte différentes
- Modèles déployés : le déploiement Canary ou le déploiement bleu-vert peuvent affecter temporairement la couverture.
Coordination des alertes et dépendance
Pour les architectures de services complexes :
- Dépendance de service : configurer des alertes pour tenir compte des défaillances de service en amont
- Corrélation des alertes : regroupez les alertes liées pour éviter les tempêtes notification en cas d'incident
- Alerte intelligente : utilisez la fonctionnalité d'apprentissage automatique pour réduire les faux positifs et améliorer la qualité du signal
Considérations importantes
- Impact sur les clients : prioriser les alertes pour les problèmes qui affectent directement l'expérience client
- Équilibrez la couverture avec la qualité : assurez-vous qu'une couverture complète ne crée pas de fatigue due aux alertes auxiliaires
- Maintenance régulière : examinez et mettez à jour les conditions d'alerte à mesure que vos applications évoluent
- Coordination inter-équipes : s'assurer que les équipes de développement et d'exploitation collaborent sur la stratégie d'alerte
Prochaines étapes
- Action immédiate : Configurer des alertes de base pour tous les services actuellement dépourvus de couverture
- Monitoring continue : Révisez cette règle du dashboard chaque semaine pour maintenir la couverture à mesure que les services changent.
- Amélioration de la qualité : se concentrer sur l'efficacité des alertes et réduire les faux positifs
- Passer au niveau 2 : une fois l’alerte de prestation de services établie, concentrez-vous sur les pratiques monitoring proactive
Pour des conseils détaillés sur monitoring de la configuration des applications, consultez notre documentation pour APM, monitoring des navigateurs, monitoring des applications mobiles et monitoring synthétique.