Note préliminaire
Ce qui suit s’applique à Enterprise Manager Grid Control 10.2.0.4 et est susceptible d’évoluer dans les prochaines versions.

Il n’est pas toujours aisé de s’assurer du bon fonctionnement de la supervision de vos composants et applications avec Oracle Enterprise Manager GridControl. C’est surtout le cas pour les notifications relatives aux évènements sur les travaux (*, i.e. job) . Non que vous puissiez pas mettre en place un fonctionnel qui réponde à la plupart des besoins, y compris si vos configurations sont étendues et critiques; il faudra toutefois faire un bon effort de compréhension et/ou être bien accompagné lors de l’implémentation; mais quand vous y serez arrivé, dites-vous n’étiez pas le premier.

Dans ce qui suit, vous trouverez une synthèse des paramètres impliqués dans les notifications relatives aux évènements sur les travaux. En effet, celles-ci, bien que différentes des notifications relatives aux alertes, elles sont tout aussi importantes: imaginez que vous ne soyez pas informé qu’une sauvegarde a échouée! Pendant 1 mois!

Avant tout, que vous ayez déjà les licences Oracle Diagnostic Pack ou que vous envisagiez simplement d’utiliser OEM pour superviser vos environnements, lisez « 285093.1 How to Troubleshoot Notifications That Are Hung / Stuck and Not Being Sent from EM 10g » et tous les liens associés. Ensuite, validez toujours vos changements, même très simple, par des tests. Enfin, même si vous utilisez les notifications avec succès, organisez de manière régulière, quasi quotidienne, un screening du Grid Control ET des travaux. Ça prendra 5 à 10 minutes par jour et vous permettra d’anticiper de nombreux problèmes, y compris en traitant par ce moyen les avertissements non-critiques.

Notifications sur les travaux

Quelles sont les conditions nécessaires pour qu’une notification soit envoyée à un utilisateurs? C’est en substance la question qu’il faut se poser pour expliquer pourquoi une notification n’a pas été reçue. La réponse dans le cas des travaux tient dans la liste qui suit:

1. Il faut qu’OEM soit configuré pour envoyer des notifications et que la configuration fonctionne; Autrement dit, si vous voulez être notifié par email, celui-ci étant re-routé sur un pager par exemple, il faut que le serveur email ainsi que les droits soient correctement enregistrés. Il faut aussi que le serveur email envoie le message à la passerelle SMS et que celle-ci la re-route correctement. Il faut que ces messages n’entre dans aucune liste de SPAM qui les détourneraient.
2. Il faut que l’utilisateur qui doit recevoir les notifications ait des préférences correctes. Autrement dit, dans le cas d’une notification sur une adresse email, il faut que cette adresse soit valide, enregistrée dans ses adresses emails préférées et que son calendrier de notifications soit mis à jour avec les bonnes périodes/adresse email.
3. Il faut que l’utilisateur ait accès au travail ou job! Je reviendrai sur les conséquences de ce point dans la partie qui suit mais, le fait qu’un utilisateur ait accès à une cible ne signifie pas qu’il voit les travaux sur cette cible, et vice-versa. Pour vérifier ce point, éditez le travail et sélectionnez l’onglet « Access » (Accès?); Vous trouverez la liste des utilisateurs qui voient (View) ou peuvent modifier le travail (Full).
4. Il faut une règle de notifications qui inclut le travail, nomimativement ou au travers d’une expression de correspondance, ET les évènements dont vous voulez être notifié. Vous noterez qu’une règle de notification ne s’applique qu’à un seul type de cible; le travail doit donc s’appliquer sur le même type de cible que la règle. C’est vrai, même si les cibles d’une règles contiennent un groupe constitué de plusieurs types de cibles; A ce propos, notez qu’une sauvegarde peut-être exécutée sur une instance de base de données ou une base de données en cluster qui sont 2 types de cible différentes.
5. Enfin il faut que l’utilisateur souscrive à la règle qui inclut le travail et l’évènement dont il voudra être notifié

Nota Bene:
Si vous êtes le propriétaire du travail vous pouvez souscrire aux évènements associés directement dans sa définition et donc sans vérifier les contraintes 3, 4 et 5.

Conséquences sur la gestion des utilisateurs et de leurs droits

L’une des difficultés que vous rencontrerez sans doute avec le Grid Control, si vous supervisez les environnements au travers de notifications, c’est : « Comment faire la transition entre les personnes d’astreinte ? ». Jusqu’en 10.2.0.3, une notification n’était envoyée qu’une seule fois; et c’est toujours le comportement par défaut en 10.2.0.4. Imaginons que vous ayiez un volume disque qui dépasse un seuil critique à 17:59: si vous utilisez des comptes nominatif pour gérer les notifications, il y a de grandes chances que la prochaine personne qui appelle le DBA/SA d’astreinte soit… un responsable projet ou un utilisateur.

Vous me direz, il ne faut être c… et c’est pour cela que les procédures de transition sont si importantes! Je répondrai que ca milite également en faveur de quelques minutes de screening et de l’utilisation d’un ou plusieurs comptes génériques pour les notifications. Le système d’astreinte ou de ticketing faisant quant à lui le dispatching et le lien avec la base de connaissance et des incidents.

Un autre élément en faveur de l’utilisation d’un ou plusieurs comptes génériques pour les notifications est la difficulté de s’assurer un paramètrage homogène entre les utilisateurs; le premier exemple qui vient à l’esprit est relatif au calendrier; le Grid Control n’offre pas de moyen simple pour valider que les calendriers de plusieurs utilisateurs sont paramétrés en fonction des astreintes. Biensur vous pouvez toujours développer un rapport mais idéalement il faudrait pouvoir déléguer les droits pour planifier les calendriers ce qui dans le contexte de la version 10.2.0.4 nécessite de faire une intégration.

Mais la vrai raison qui milite pour l’utilisation du compte générique pour les notifications est l’absence d’un niveau de regroupement des administrateurs et la complexité induite sur la gestion des comptes nominatifs. Illustration!

Dans la section précédente, vous voyez que pour être notifié d’un évènement sur un travail il faut avoir accès à ce travail. Or si un nouveau membre rejoint une équipe, le seul moyen réaliste(**) de lui donner cet accès consiste à modifier chacun des travaux planifiés et stockés dans la bibliothèque. S’il existait un niveau de regroupement, on pourrait simplement ajouter l’administrateur à la liste des administrateurs du domaine X mais ce n’est pas le cas Même si vous pouvez définir des travaux multi-cibles ou que emcli vous permet de modifier des configurations à la chaine, ajouter un utilisateur nomminatif n’est pas si simple, si vous voulez que celui-ci puisse accéder à la liste des travaux de son domaine.

Le problème est identique si un administrateur change de domaine d’intervention.

Conclusion

Lorsque vous ajoutez un utilisateur au GridControl, n’oubliez pas de lui donner les droits adéquats sur les travaux qui le concerne.

(*) C’est d’autant plus vrai que cette partie est sujette à plusieurs problèmes de fonctionnement jusqu’en 10.2.0.4.
(**) Un moyen irréaliste consisterait à mettre tout le monde Super Utilisateur