Lors de mon activité de consultant, et suite à un bug qui n'affiche pas correctement le nombre de CPU (OMS 10.2.0.5, agent 10.2.0.5 et linux x86_64), je me suis intéressé à la manière dont Oracle Enterprise Manager Grid Control (OEM GC) récupérait les informations de mémoire et de CPU sur les différents hôtes surveillés par ce dernier.

Tout d'abord on découvre vite que les informations de mémoire et de CPU sont stockées dans la vue MGMT$OS_HW_SUMMARY :

SQL> select host_name,mem,cpu_count

from mgmt$os_hw_summary;

vmtestoraem1.it.dbi-services.com   3034 1

vmtestora10g01.it.dbi-services.com 3034 1 

vmtestorarac1.it.dbi-services.com  3018 2 

vmtestorarac2.it.dbi-services.com  3018 2

vmtestoradg1.it.dbi-services.com   4953 2

Cette vue récupère les données de la table mgmt_os_hardware_master du schéma sysman du repository de l'OMS.

SQL> select system_config,memory_size_in_mb,cpu_count from mgmt_hc_hardware_master;

i686 3034 1 

i686 3034 1 

x86_64 3018 2 

x86_64 3018 2 

x86_64 4953 2

A cette occasion on pourra s'intéresser aux différentes tables MGMT_HC_% du schéma sysman qui contiennent toutes les informations essentielles de l'OS :

SQL> select table_name from user_tables where table_name like 'MGMT_HC%';

TABLE_NAME

------------------------------

MGMT_HC_SYSTEM_SUMMARY

MGMT_HC_HARDWARE_MASTER

MGMT_HC_CPU_DETAILS

MGMT_HC_IOCARD_DETAILS

MGMT_HC_NIC_DETAILS

MGMT_HC_OS_SUMMARY

MGMT_HC_OS_PROPERTIES

MGMT_HC_OS_COMPONENTS

MGMT_HC_FS_MOUNT_DETAILS

MGMT_HC_VENDOR_SW_SUMMARY

MGMT_HC_VENDOR_SW_COMPONENTS

Comme par exemple :

SQL> selectname,update_level,distributor_version,

     max_swap_space_in_mb,address_length_in_bits

     from mgmt_hc_os_summary;

NAME UPDATE_LEVEL DISTRIBUTOR_VERSION MAX_SWAP_SPACE_IN_MB ADDRESS_LENGTH_IN_BITS

Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) 194.el5 Oracle Enterprise Linux 4.1.2-48 2047.34 32-bit

Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) 194.el5 Oracle Enterprise Linux 4.1.2-48 2047.34 32-bit

Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) 194.el5 Oracle Enterprise Linux 4.1.2-48 6142.03 64-bit

Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) 194.el5 Oracle Enterprise Linux 4.1.2-48 6142.03 64-bit

Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) 194.el5 Oracle Enterprise Linux 4.1.2-48 6142.03 64-bit

Ou encore :

SQL> select resource_name,mount_location,type,mount_options 

     from mgmt_hc_fs_mount_details;

/dev/mapper/VolGroup00-LogVol01 / ext3 rw /dev/sda1 /boot ext3 rw 

/dev/mapper/VolGroup00-LogVol01 / ext3 rw /dev/sda1 /boot ext3 rw 

/dev/sda2 / ext3 rw 

/dev/sda1 /boot ext3 rw 

/dev/mapper/vgora-lvu00 /u00 ext3 rw 

/dev/sda2 / ext3 rw 

/dev/sda1 /boot ext3 rw 

/dev/mapper/vgora-lvu00 /u00 ext3 rw 

dbi-nas1:/share/DBI /NASDBI nfs rw,timeo=5,intr,addr=X.Y.Z. 

/dev/sda2 / ext3 rw 

/dev/sda1 /boot ext3 rw 

/dev/mapper/vgora-lvu00 /u00 ext3 rw 

/dev/mapper/vgora-lvu01 /u01 ext3 rw 

srvdbinas02:/volume1/DBI /DBINAS nfs rw,timeo=5,intr,addr=X.Y.Z.T

On s'aperçoit que toutes les informations sont stockées dans ces tables :=)

Mais comment Oracle fait-il donc pour obtenir toutes ces informations ?

En fait, toutes ces données sont collectées par les agents et envoyées dans le repository de l'OMS. Les scripts utilisés se trouvent dans le répertoire $AGENT_HOME/sysman/admin/scripts.

Intéressons-nous plus particulièrement aux aspects de CPU et de mémoire. Un premier script intéressant est le programme perl ecmSysData1.pl. En le lançant en mode debug, on obtient les résultats suivants :

oracle:> perl -i $perl_lib /u00/app/oracle/agent10g/sysman/admin/scripts/ecmSysData1.pl -debug ALL > hw_all.txt

Mais la valeur de NumCpu est incorrecte dans le fichier hw_all.txt xml généré, le host posséde 16 CPU et le programme perl n'en affiche qu'une seule :

TOTAL_LOCAL_DISK_SPACE_IN_GB 634.76 TOTAL_LOCAL_DISK_SPACE_IN_GB

NUMBER_OF_CPUS 1 NUMBER_OF_CPUS

NUMBER_OF_CPU_BOARDS 1 NUMBER_OF_CPU_BOARDS

La console OEM Grid Control nous affiche un nombre incorrect de CPU :

Si nous lançons le script nmupm manuellement, le nombre de CPU est pourtant correct :

oracle:/oracle/sys01/agent10g/bin/ :> ./nmupm cpudata

GenuineIntel|16|1|16|1|16

En consultant le code perl du fichier Ptdpm1.pl, nous pouvons trouver le code suivant :

if(!isXenServer()) {

my $cpucmd = "$Ptdpm1::NMUPM cpudata";

my $cpustring = execCmd($cpucmd);

my @cpudata = split ('\|',$cpustring );

$NoOfCPU = $cpudata[2]; # Number of physical cpu(s)

}

Nous modifions ce code de la manière suivante :

if(!isXenServer()) {

my $cpucmd = "$Ptdpm1::NMUPM cpudata";

my $cpustring = execCmd($cpucmd);

my @cpudata = split ('\|',$cpustring );

$NoOfCPU = $cpudata[1]; # Number of physical cpu(s)

}

Si nous relançons le programme perl ecmSysData1.pl, le fichier hw_all.txt affiche le nombre correct de CPU :

TOTAL_LOCAL_DISK_SPACE_IN_GB 634.76 TOTAL_LOCAL_DISK_SPACE_IN_GB

NUMBER_OF_CPUS 16 NUMBER_OF_CPUS

NUMBER_OF_CPU_BOARDS 1 NUMBER_OF_CPU_BOARDS

Et la console OEM Grid Control également :

De la même manière, pour trouver la mémoire du serveur, on découvre que c'est le programme Ptdpm1.pm qui effectue le travail :

chomp($memory = `$Ptdpm0::EGREP "^MemTotal:" /proc/meminfo`);

$memory = left("kB", right("MemTotal:", $memory), 1); 

# convert MEMORY_SIZE_IN_MB to MB

$memory = int($memory / 1024);

Le processus de rafraichissement du host est lancé automatiquement une fois par jour par OEM Grid Control, mais il est possible de le lancer manuellement par la commande suivante :

emctl control runcollection

Exemple :

oracle@vmtestora10g01:/u00/app/oracle/product/10.2.0.5/agent11g/bin/ [agent11g] ./emctl control agent runcollection vmtestora10g01.it.dbi-services.com:host

Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0

Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.

Ou alors directement depuis la console Grid Control en utilisant "Régénérer la configuration d'hôte" depuis le menu "Déploiements" :

Lorsqu'on lance le rafraichissement manuellement ou via le Grid Control, l'agent exécute sur le host les commandes suivantes :

ecmSysData1.pl HARDWARE

ecmSysData1.pl OS_SOFTWARE

ecmSysData1.pl VENDOR_SOFTWARE

Celles-ci génèrent des fichiers xml dans le répertoire $AGENT_HOME/sysman/emd/upload.

Ces fichiers xml sont alors transmis à l'OMS dans le répertoire $OMS_HOME/sysman/recv et sont ensuite chargés dans le repository. Une fois chargés dans le repository, ces fichiers sont détruits du répertoire.

Au final, OEMGC utilise des moyens classiques pour récupérer les différentes informations des hôtes qu'il gère.

Ainsi, on peut voir les immenses possibilités des informations que l'on peut collecter par l'intermédiaire des tables mgmt_hc% du schéma sysman du repository. Il est alors possible de créer facilement des reports pour visualiser tous les composants d'une infrastructure de production.