Introduction
Le module d’alerting de d.side pour Oracle permet de détecter :
- une augmentation d’activité ou de consommation : CPU, physical reads, nombre de sessions…
- une baisse de l’activité : moins de requêtes exécutées, moins de transactions…
- une dérive du temps de réponse pour une requête
Chaque alerte montre quel type de seuil a été dépassé, à la hausse ou à la baisse, avec quelle valeur :
[STAT.LOW] user commits: current: 64 | limit: 100 [SESSIONS.HIGH] 843 sessions connected | limit: 800 [SQL] 2z88p343wmrj5 took 952 ms | limit: 200
Les alertes sont stockées en base dans la table AL$ALERTS du schéma de collecte Replay. Cette table peut ainsi être requêtée pour rechercher des alertes selon leur type, leur fréquence, leur date d’apparition…
On peut également produire ces alertes de manière facultative dans un fichier plat, au travers d’un DIRECTORY Oracle.
Ainsi, les outils de monitoring habituels peuvent facilement être connectés pour lire la table AL$ALERTS ou le contenu de ce fichier plat.
Architecture
Le mécanisme d’alerting s’appuie sur la collecte. Il observe à intervalles réguliers ce qui a été collecté par la procédure GATHER du package DSIDE_REPLAY. Si les statistiques qu’on surveille dépassent les seuils configurés, une alerte est levée.
Le package de collecte offre désormais la possibilité de lancer la collecte dans un mode “alerting” qui est plus léger. Il ne stocke pas, par exemple, les étapes des plans d’exécution. Cette information est destinée à du troubleshooting, pas à de l’alerting. On peut ainsi réduire facilement le volume de stockage nécessaire au fonctionnement de la collecte, et même la consommation du job de collecte.
Pour savoir sur quels seuils se baser pour décider de lever ou non une alerte, le mécanisme d’alerting doit donc, en plus des tables de collecte, connaître les statistiques que l’on souhaite surveiller, et quelles valeurs ne pas dépasser. A la hausse comme à la baisse.
Pour cela, on va créer un ou plusieurs profils.
Gestion des profils d’alerte
Lorsque l’on clique sur le bouton d’alerte dans l’interface Replay, les valeurs correspondant à l’activité observée pendant la période sélectionnée sont proposées pour la création d’un nouveau profil :
En cliquant sur une valeur, celle-ci est reportée dans la liste des seuils composant le profil.
En cliquant sur une colonne on peut reporter d’un seul coup l’intégralité des valeurs proposées.
Chaque valeur peut aussi être ajustée à la main.
A ces statistiques de consommation et d’activité on peut ajouter la surveillance de requêtes SQL. Pour cela il suffit de cliquer sur le même bouton d’alerte depuis la fenêtre “SQL Query History” de Replay :
Le SQL_ID et le temps moyen d’exécution de la requête sur la période choisie sont alors reportés directement dans le profil. On peut y associer un libellé facultatif (qui correspond par défaut aux premiers caractères de la requête), et une unité en millisecondes, en secondes ou en minutes.
Donner un nom au profil et cliquer sur le bouton SAVE permet de stocker ce profil en base. Il pourra ensuite être exploité par l’alerteur.
Bien sûr, on peut revenir quand on le souhaite sur un profil pour le mettre à jour ou le supprimer.
Gestion des plans d’alerting
En cliquant sur le bouton “Alerting plans management” on peut planifier une semaine entière de profils. Cette fonctionnalité est facultative, on peut ne travailler qu’avec des profils, mais cela permet d’ajuster facilement les profils en fonction de l’activité attendue : la nuit ne verra pas la même activité que la journée, une période de batch sera plus intense qu’un creux pendant un week-end, par exemple.
Cette planification des profils permet de contrôler heure par heure les seuils auxquels va réagir le job d’alerting.
Pour configurer les heures et les profils, un clic gauche de souris permet de démarrer une période et de choisir à quel profil cette période correspond, parmi la liste des profils existants, créés comme indiqué dans le paragraphe précédent. Puis un clic droit sur l’heure de fin de cette période permet de développer le calendrier en fonction de l’activité attendue.
Par exemple, ici on définit une plage de 08h à 19h tous les jours de la semaine pour un profil de type “horaires administratifs” [ Bleu ].
Sauf le lundi matin qui débute par une période considérée comme un pic d’activité [ Vert ].
Et le vendredi en fin de journée avec une activité attendue en baisse [ Jaune ].
Le week-end, lui, est consacré à deux périodes de batch [ Gris ].
Là encore, on peut dupliquer, supprimer et mettre à jour un plan d’alerte très facilement.
Si l’on charge un plan existant et que celui-ci s’appuie sur des profils qui n’existent plus en base, alors les périodes sont affichées, mais les profils absent sont barrés de la liste déroulante lorsque l’on clique gauche pour débuter une nouvelle période.
Dans ce cas, l’alerteur ne tiendra pas compte des profils absents. Il mentionnera juste cette situation dans les messages d’administration.
Gestion du job d’alerting
Une fois les profils et plans créés, la d.side Console permet, comme pour les jobs de collecte, de démarrer, arrêter et surveiller un job d’alerting.
Sur l’écran principal, un alerting actif est matérialisé par une cloche de couleur, alors qu’un alerting inactif (aucun job d’alerting ne tourne) est représenté à l’aide d’une cloche grisée.
Démarrer un job d’alerting
Pour configurer et lancer un job d’alerting, cliquer sur la cloche grisée pour entrer dans une fenêtre “Alerting management” qui indique que l’alerting n’est pas activé et qui propose différentes options de lancement :
Pour démarrer un nouveau job d’alerting, il est nécessaire de lui fournir soit un profil, soit un plan sur lequel il va se baser pour décider si une alerte doit être remontée ou non. Les options “Plan name” et “Profile name” sont exclusives et permettent d’indiquer sur quels seuils on souhaite que le job travaille.
Le “Directory name” est facultatif, il permet de stocker les alertes dans un fichier plat en plus de la table AL$ALERTS. Si un directory Oracle est visible par l’utilisateur avec lequel on est connecté (schéma de collecte Replay) et que cet utilisateur a les privilèges nécessaires sur ce directory, alors le directory est proposé dans la liste déroulante.
La “Fréquence” permet de définir l’intervalle entre deux contrôles par l’alerteur. Ici, toutes les 60 secondes l’alerteur ira vérifier s’il a des nouvelles données collectées à analyser.
Si une nouvelle alerte doit être levée car un seuil est dépassé dans les plus récentes données collectées, alors l’alerteur s’assurera qu’il s’est bien écoulé “Wait time” minutes (ici 5 minutes) depuis la dernière alerte. Cela permet d’éviter de surcharger les consoles d’alertes des opérateurs avec des informations redondantes, en leur laissant le temps d’analyser et traiter la première alerte remontée.
Enfin, il est possible avant de démarrer un nouveau job d’alerting, de vider la table AL$ALERTS dans laquelle de précédentes alertes ont déjà pu être stockées voire traitées.
Récupérer les alertes remontées
Pendant que le job d’alerting tourne, cliquer sur la cloche colorée de l’écran principal pour entrer dans la même fenêtre “Alerting management”, qui propose cette fois la possibilité d’interrompre le job, et d’observer l’état du job, ainsi que les alertes remontées et les messages d’administration postés par le job.
Si un directory Oracle a été précisé au lancement du job d’alerting, on peut également récupérer les alertes postées directement en lisant le fichier :
[oracle]$ tail -f d.side.alerts.B2C.log 2020.11.18-15:23:43: [STAT.LOW] execute count: current: 740 | limit: 1000 2020.11.18-15:24:14: [SESSIONS.HIGH] 914 sessions connected | limit: 900 2020.11.18-15:24:14: [STAT.HIGH] physical reads: current: 1257 | limit: 1200
Enfin, tout ce qui est réalisé et encapsulé ici au travers de la d.side Console peut être exécuté automatiquement ou par script, en s’appuyant sur le package DSIDE_ALERT et principalement sur la procédure RUN permettant de démarrer un job de collecte.
Pour plus d’informations et de détails concernant le module d’alerting d.side pour Oracle, se rendre dans le d.side Interactive Replay Alerting Guide.
