Surveillance de l'OMS

Voici une façon de mettre en place un processus de surveillance de l'installation d'Oracle 10g Grid Control. À l'aide de scripts « perl », l'agent résidant sur le même serveur qu'Oracle Management Server peut envoyer un courriel lorsque l'OMS ne répond plus.

Cette méthode de surveillance est aussi nommée « Notification OOB (Out-of-Bound) ».

La configuration de ce processus a été effectuée sur un Oracle Management Server (OMS), un référentiel de base de données et un agent tous de la version 10.2.0.4 et sur un environnement Sun Solaris.

Avant de débuter, sachez que cette configuration peut être effectuée seulement sur l'agent où réside l'OMS et que vous devez aoir une configuration existante et fonctionnelle d'envoi de courriel.

Voici comment j'ai procédé pour activer la surveillance.

VÉRIFIER LA PRÉSENCE DE LA CIBLE OMS

Initialiser les variables d'environnement pour qu'elles soient sur l'ORACLE_HOME correspondant à l'agent puis exécuter la commande suivante :

AGENT_HOME/bin/emctl config agent listtargets grep oracle_emrep

Le résultat de cette commande doit être :

[Management Services and Repository, oracle_emrep]

Autrement, cela signifie que la cible correspondante à l'OMS n'est pas présente. Dans ce cas, il doit être ajouté dans le fichier « targets.xml » qui est sous le répertoire « AGENT_HOME/sysman/emd ».

Tout changement à la configuration de l'agent nécessite un redémarrage de l'agent pour la prise en compte des nouvelles valeurs.

CONFIGURATION DE L'AGENT

Le fichier de paramètres de l'agent (emd.properties) doit être modifié pour y fournir les informations relatives à l'envoi de courriel.

Ouvrir le fichier « emd.properties » qui est sous le répertoire « $AGENT_HOME/sysman/config » et indiquer des valeurs aux paramètres ci-dessous :

#
# The email address for out-of-band notifications
#
emd_email_address=prenom.nom@domaine.com
emd_email_gateway=localhost
#
# The return email address for out-of-band notifications
#
emd_from_email_address=oms_agent@domaine.com

REDÉMARRER L'AGENT

Pour que les nouvelles valeurs des paramètres soient actives, il faut redémarrer l'agent :

emctl reload agent

VÉRIFIER LE FONCTIONNEMENT

Pour vérifier le bon fonctionnement de la notification, Oracle Management Server doit être arrêté :

$ORACLE_HOME/opmn/bin/opmnctl stopall

Si tout est configuré adéquatement, vous devriez recevoir un message semblable à ceci :

Expéditeur : oms_agent@domaine.com
Objet : Severe Enterprise Manager problem
Texte du courriel :
Fri Sep 18 14:20:07 2009
Severe Enterprise Manager problem
Error message: No active Management Services were found

RÉFÉRENCES

Oracle Metalink, Note 429257.1

L'agent a perdu la tête !

Salut,

Dernièrement, j’ai migré l’OMS (Oracle Management Service) ainsi que tous les agents à la version 10.2.0.4.0. Et, actuellement, nous sommes entrain de migrer les bases de données à la version 10.2.0.4.0.

Depuis que certaines bases de données sont passées à la nouvelle version (10.2.0.4.0), les agents sur les hôtes réagissent d’une façon très étrange. En l’espace de 2 à 3 minutes, le mécanisme de notification m’informe que l’agent ne peut pas être contacté puis, par la suite, je reçois un autre message m’indiquant que le problème est résolu.
Voici des exemples de messages de notification reçus :

Agent is Unreachable (REASON = Connection refused) but the host is UP.
Agent is Unreachable (REASON = Received unexpected response text : EMDClient request Error:nmemdisp_main Internal Error)

Ce message provenant de la notification n’indique absolument rien de précis. Je me suis pencher sur le problème et en fouillant davantage dans le fichier de trace de l’agent, j’ai trouvé une erreur qui se répétait à plusieurs reprises :

2009-03-30 16:08:37,105 Thread-1931 ERROR upload: nmehursf_logError:lfiflu failed -2 rawdata.dat 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: rawdata.dat rename failed 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: rawdata.dat deleted, it will not be merged 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: ERROR: nmehursf_Rowset_write - lfiopn failed -2 rawdata.dat 2009-03-30 16:08:37,106 Thread-1931 ERROR upload: Error happened in nmehursf_Rowset_write:lfiopn, error = 24: Too many open files for rawdata.dat

Comme toute bonne chose à une fin, ce problème est connu chez Oracle et, un patch est disponible.

L’agent nécessite qu’un correctif soit installé sur les cibles de type base de données de la version 10.2.0.3.0. Ce correctif porte le numéro #5872000. Le correctif s’intitule :

HEALTHCHECK ERROR OCCURS FOR 32BIT DATABASE ON 64BIT OS DUE TO BUG4526916 FIX

Ce problème est perceptible seulement si l’agent doit surveiller des bases de données 10.2.0.3.0 et 10.2.0.4.0 sur un même hôte.

Probleme de notification : Tablespace Space Used % sur instance RAC

Depuis quelque temps, je soupçonnais des problèmes de notification avec les instances RAC définies dans Oracle EM Grid Control.

Je me suis alors bâtit un cas d'essai. J'ai créé un tablespace contenant une seule table. Celle-ci a été remplie jusqu'au bouchon en m'aidant de la vue DBA_OBJECTS. (Insert into ... Select * from dba_objects)

La requête ci-dessous permet d'afficher les alertes que la base de données a rencontrées :

SELECT REASON
, METRIC_VALUE
, MESSAGE_TYPE
, TO_CHAR(CREATION_TIME,'DD-MON-YYYY HH24:MI:SS')
, HOST_ID
FROM SYS.DBA_OUTSTANDING_ALERTS;

J'y ai alors trouvé une alerte à propos du tablespace créé pour mon cas d'essai :

REASON
-------------------------------------------------------
METRIC_VALUE MESSAGE_TYPE TO_CHAR(CREATION_TIM HOST_ID
------------ ------------ -------------------- --------
Tablespace [TEST_OEM_EC] is [90 percent] full
90 Warning 28-FEB-2009 20:48:04 MOMSVR


Étrange! l'alerte est inscrite dans la base de données mais elle n'est pas envoyé vers Enterprise Manager ?!?

J'ai décidé de vérifier si l'agent était ble et bien enregistrer à la base de données ORCL :

select agent_name from SYSTEM.AQ$_INTERNET_AGENTS order by agent_name;

Cette requête doit retourner au minimum un enregistrement qui contient un nom d'agent dont le nom est constitué du nom de l'hôte, du port et du SID de la base de données.

Ex : MOMSRV_1830_ORCL1

Ce n'était pas mon cas... La requête m'a affiché un autre agent avec un port différent. En fait, c'était un ancien agent qui fut déjà installé auparavant.

J'ai finalement trouvé de l'information à propos d'un bug à ce sujet et Oracle recommande de faire ce qui suit et ce, même si la configuration est déjà présente dans Oracle EM Grid Control.

Dans la console EM :

1. Cliquer sur le "cluster" en question
2. Au bas de la page, cliquer sur le lien intitulé "Monitoring Configuration"
3. Parcourir les étapes de configuration même si elles ont déjà été faites

Sur chacun des noeuds :

$ emctl stop agent
$ emctl start agent
$ emctl clearstate agent

J'ai refait mon test de notification et tout à fonctionné correctement.

Pour terminer en beauté, j'ai décidé de supprimer l'ancien agent inscrit. Pour ce faire, j'ai exécuté la commande suivante :

exec dbms_aqadm.DROP_AQ_AGENT('MOMSRV_3872_ORCL1');

Reconfiguration d'un Management Agent pour OMS (Grid)

Pour que l'Agent communique correctement avec Oracle Management Service, j'ai dû reconfigurer complètement l'agent et toutes les composantes du Grid propre à cet hôte.

1. Arrêter l'agent

cd $ORACLE_HOME
emctl stop agent

2. Supprimer toutes les composantes liés à l'hôte dont l'agent y est installé.

Sous SQL*Plus, se connecter avec SYSMAN au référentiel de l'OMS pour supprimer complètement l'agent

exec mgmt_admin.cleanup_agent('NomAgent:NoPort');

3. Nettoyer les répertoires de l'agent

cd $ORACLE_HOME/sysman/emd
/usr/bin/rm -rf agntstmp.txt lastupld.xml recv/* collection/* upload/* state/*

cd $ORACLE_HOME/hôte/sysman/emd
/usr/bin/rm -rf agntstmp.txt lastupld.xml recv/* collection/* upload/* state/*

La commande "emctl clearstate agent" peut aussi être utilisé pour faire le ménage cependant, je ne crois pas qu'elle soit aussi efficace que la commande "rm -rf".

4. Configurer l'agent sur l'hôte

Dans mon cas, c'est un agent installé sur un cluster RAC à 3 noeuds

agentca -f -n nom_cluster -c "hôte1,hôte2,hôte3"

4. Sécuriser la communication entre l'Agent et OMS

emctl secure agent

5. Charger les informations dans OMS

emctl upload

Et, pour terminer. il suffit de naviguer dans la console Oracle EM Grid Control et de configurer les cibles découvertes :

- Se connecter à la console
- Cliquer sur "Setup", "Agents"
- Choisir un agent en particulier puis cliquer sur le bouton configurer