Alertes

• Informations générales
  • Notification
  • Métrique
• Seuil
  • Tendance
• Périmètre
• Conditions d’analyse
  • Période d’analyse
  • Portée de l’analyse

Nudge APM est doté d’un moteur d’alerte qui permet de surveiller vos applications de manière proactive et d’être informé en cas de dysfonctionnement.

La gestion des alertes se fait dans le menu Alertes dans la barre de navigation à gauche de l’interface Nudge.

Une alerte se configure en spécifiant les informations suivantes :

• le périmètre du contrôle (quelle application ? quelle transaction ? …),
• la métrique à contrôler et le seuil de l’exigence (x secondes de temps de réponse, taux d’erreurs, …),
• l’action de notification (envoi de mail, webhook)
• la période et les règles d’analyse

L’assistant de saisie d’alerte va vous amener à spécifier l’ensemble des ces informations.

Informations générales

Cet écran vous permet de spécifier le type de notification et le type de métrique à observer.

Notification

Vous disposez de deux types de notifications : par mail ou par webhook.

• En cas de notifications par mail vous devez simplement paramétrer la liste des destinataires des messages d’alertes.

• Les webhooks sont des messages http que le moteur l’alertes peut envoyer à des services tiers tels que par exemple Jira, Slack, des broker SMS.

Les webhooks se configurent avec deux ou trois paramètres suivant le cas :

• le type de méthode HTTP : POST, GET ou PUT
• l’URL du service destiné à recevoir les messages d’alerte
• le format du message à émettre en cas d’alerte (ce champ n’est disponible que pour les méthodes POST ou PUT)

Au sein de l’URL et du format de message vous avez la possibilité de placer un ou plusieurs tags qui seront substitués lors des notifications par les caractéristiques relatives à l’alerte. Les paramètres qui figurent dans l’URL subissent un encodage URL.

Voici la liste des paramétres disponibles :

• ${notif_desc} : texte descriptif de la notification
• ${notif_type} : type de la notification (exemple: début d’alerte, fin d’alerte)
• ${notif_start} : date de démarrage de la notification
• ${notif_end} : date de fin de la notification
• ${alert_metric} : métrique contrôlée (temps de réponse, nombre d’erreurs …)
• ${alert_threshold} : seuil de déclenchement d’une notification
• ${transaction_name} : nom de la transaction qui est l’objet de la notification (suivant les paramétrages, cette informations est susceptible d’être non applicable)
• ${server_name} : nom du service qui est l’objet de la notification (suivant les paramétrages, cette informations est susceptible d’être non applicable)
• ${app_name} : nom de l’application qui est l’objet de la notification

Exemple :

Voici quelques exemples de paramétrages pour des outils spécifiques :

• Slack
  • Méthode http : POST
  • URL : https://hooks.slack.com/services/slack-keys
  • Message : {"channel":"#nudge","username":"webhookbot","text":"Alerte Nudge : ${notif_desc}"}
• JIRA
  • Méthode http : POST
  • URL : https://jirauser:jirapassword@yourdomain.jira.com/rest/api/latest/issue
  • Message : {"fields":{"project":{"key":"PROJECT-KEY"},"issuetype":{"Issue"},"description":"${notif_desc}","summary":"${alert_metric} not matching threshold ${alert_threshold}"}}
• Primotexto (envoi de SMS)
  • Méthode http : GET
  • URL : https://api.primotexto.com/v2/notification/messages/send?apiKey=YOUR_API_KEY&identifier=YOUR_NUMBER&sender=YOUR_SENDER&message=${notif_desc}

Métrique

Sélectionnez la métrique que vous souhaitez contrôler par cette alerte.

Entité	Métrique	Description
Application	TRM	Temps de réponse moyen
Application	Erreurs	Nombre ou taux d’erreurs
Application	APDEX	Indice de satisfaction
Service	Panne	Interruption du monitoring
Service	JMX	Attribut de MBean JMX (Java uniquement

La notion d’apdex peut intervenir dans deux contextes :

• soit pour analyser la valeur de l’indice sur une application ou une transaction, il s’agit alors de la métrique APDEX
• soit pour définir le seuil de référence d’un contrôle, c’est à dire qu’on utilisera le paramètre de satisfaction ou de tolérance affecté à une transaction donnée comme seuil de référence du contrôle, il s’agit dans ce cas de figure d’un contrôle sur la métrique TRM

Seuil

Suivant la métrique choisie, cet écran de paramétrage sera sensiblement différent. Les éléments de comparaison ou les unités des valeurs changent en fonction de la nature de la métrique à contrôler.

Tendance

Suivant la nature des mesures, vous disposez parfois de la possibilité de choisir un seuil en fonction de la tendance.
Ce type de contrôle permet de détecter la dégradation d’une mesure par rapport à ce qui a pu être observé précédemment.
L’efficacité d’un contrôle sur tendance dépendent de la saisonnalité des mesures : si les mesures historiques sont très volatiles, un tel contrôle risque de provoquer de nombreuses alertes.

Pour contrôler une mesure par rapport à une tendance, le moteur d’alertes doit d’abord évaluer la tendance. Pour ce faire, il va récupérer les mesures observées à un moment donné qui est fonction de la saisonnalité de la mesure et qui est défini par les paramètres de décalage dans le temps et de taille de la fenêtre de la tendance.
À cette tendance est appliqué un coefficient de tolérance pour obtenir le seuil de référence auquel sera comparé la mesure qui est l’objet de cette analyse.

Exemple : Prenons une transaction dont la saisonnalité de l’utilisation est hebdomadaire. on est alors sensé observer à tout moment à peu près la même chose que ce qu’on a observé une semaine auparavant, c’est ce qu’on va tenter de contrôler.

Nous positionnons les paramètres suivants :

• décalage d’une semaine,
• fenêtre de 30 minutes,
• tolérance de dégradation de 1.5.

Le seuil de référence pour le contrôle d’un évènement qui a été observée à 11h52 le 13/01/2017, sera évaluer à partir des mesures observées le 06/01/2017 entre 11h37 et 12h07 multipliée par 1,5.

Périmètre

Cet écran permet de sélectionner la ou les entités sur lesquelles le contrôle doit avoir lieu.
À titre d’exemple, voici quelques combinaisons pour le contrôle du temps de réponse :

• une application sans distinction de transaction : dans ce cas de figure le temps de réponse contrôlé sera celui de l’application globalement en moyennant l’ensemble des transactions observées sur l’application
• une transaction ou un ensemble de transactions : dans ce cas la ou les transactions seront analysées individuellement
• …

Conditions d’analyse

Période d’analyse

Définissez ici la période pendant laquelle le contrôle doit avoir lieu. Sélections les heures d’analyse, incluez ou non les week-end …

Portée de l’analyse

La portée de l’analyse permet de définir un laps de temps sur lequel le contrôle doit agir lors d’une analyse. Le moteur d’analyse s’assurera alors que, sur ce laps de temps, le seuils défini a été ou non dépassé pendant plus d’un certain pourcentage de la durée.
Cette option permet d’éviter de déclencher des alertes très fréquentes pour des phénomènes ponctuels.
Par défaut le contrôle se fait avec les valeurs 5 minutes et 80%, cela signifie que lors de l’analyse d’un évènement, on observe ce qui s’est passé relativement à la même entité pendant les 5 minutes précédent l’évènement puis on déclenche l’alerte si on a dépassé le seuil du contrôle pendant au moins 4 de ces 5 dernières minutes.

Exemples plus précis pour un seuil maximum de 2 sur une métrique donnée, sur plusieurs séquences de valeurs minute par minute précédent une mesure en cours d’analyse :

• 1.5,2.1, 2.2, 3.0, 2.5 => l’exigence du seuil d’alerte n’est pas respectée (seuil franchi au moins 80% du temps sur 5 minutes), Il est en état d’alerte
• 2.1, 2.2, 1.0, 3.0, 3.0 => l’exigence du seuil d’alerte n’est pas respectée (seuil franchi au moins 80% du temps sur 5 minutes), Il est en état d’alerte
• 1.5, 2.1, 2.2, 3.0, 1.5 => l’exigence du seuil d’alerte est respectée (seuil franchi moins de 80% du temps sur 5 minutes), Il n’est pas en état d’alerte