Réduisez le bruit grâce à des alertes de qualité

Les alertes redondantes enfouissent les incidents critiques sous le bruit. L’évaluation de vos alertes existantes est un élément clé de votre stratégie de priorisation, car la qualité de vos alertes se traduit par la manière dont vos équipes réagissent aux incidents. S'il y a trop de bruit, vous risquez de fatiguer votre équipe avec des incidents de faible priorité qui ont peu ou pas d'impact sur l'entreprise. Les incidents qui ne parviennent pas à alerter peuvent cependant conduire à des pannes qui affectent l'expérience client.

Objectifs

Ce tutoriel suppose que vous disposez déjà d’alertes actives. Il offre quelques recommandations sur la gestion de la qualité de vos alertes et fournit quelques requêtes NRQL pour en créer de nouvelles. Vous serez:

• Installer le dashboard de gestion de la qualité des alertes (AQM)
• Faire la différence entre une bonne et une mauvaise alerte
• Consultez nos chaînes NRQL recommandées pour créer des alertes

Installer le dashboard AQM

AQM se concentre sur la réduction du nombre d'incidents gênants afin que votre équipe se concentre sur alertesavec un véritable impact commercial. Vous êtes un bon candidat pour AQM si :

• Vous avez trop d'alertes.
• Vous avez des alertes qui restent ouvertes pendant de longues périodes.
• Vos clients découvrent vos problèmes avant vos outils monitoring .

Pour commencer, installez le dashboard AQM via notre quickstart:

1. Accédez à la page d’observabilité instantanée Alert Quality Management .
2. Cliquez sur le bouton Install now .
3. Suivez l’invite pour choisir le compte dans lequel vous souhaitez installer le dashboard .
4. Consultez votre dashboard.

Nous vous recommandons de passer au moins deux semaines avec le dashboard AQM. Pendant ce temps, le dashboard AQM collectera des données sur la manière dont vos équipes interagissent avec toutes vos alertes.

En règle générale, nous recommandons de supprimer ces types d’alertes :

• Générer des incidents « toujours actifs » ayant une durée cumulée de plusieurs milliers de minutes ou plus.
• Lorsque 30 % ou plus des incidents sont ouverts pendant moins de 5 minutes.
• Dont le temps moyen de clôture est supérieur à 30 minutes.
• Créez plus de 350 incidents par semaine.

Créer de nouvelles alertes en cas de demande de pointe

Une fois vos politiques existantes révisées, vous souhaiterez peut-être créer de nouvelles alertes adaptées aux pics de demande. Créer une bonne alerte dépend de la spécificité de vos paramètres. Deux alertes peuvent partager la même condition de requête d'alerte, par exemple :

SELECT average(`apm.service.memory.heap.used`) FROM Metric WHERE appName = 'Inventory Service'

Bien que la requête elle-même soit une règle d'alerte puissante, la façon dont vous configurez cette alerte peut créer une redondance ou du bruit. Une mauvaise alerte peut avoir une durée de fenêtre trop petite, un seuil bas ou aucun délai ou base de référence. De plus, attacher une condition d’alerte à une source de données relativement jeune peut également créer des problèmes, car il n’y a pas suffisamment d’historique pour détecter un comportement anormal.

Si vous êtes prêt à créer de nouvelles alertes, voici quelques requêtes recommandées que vous pouvez utiliser pour votre jour de match :

SELECT average(duration) FROM Transaction WHERE account_id in (91290, 102021, 20230)

SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95) FROM Transaction

SELECT percentile(databaseDuration, 75) FROM Transaction

SELECT max(duration) FROM Transaction

SELECT average(duration) FROM Transaction

SELECT percentage(count(*), WHERE duration > 2) FROM Transaction

SELECT percentage(count(*), WHERE http.statusCode = '500') FROM Transaction

SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName like '%prod%'