|
Dans une grande entreprise,
déterrer la racine d'un problème informatique
peut être un véritable calvaire. A moins
de disposer d'un système de contrôle surveillant
toutes les ressources de l'entreprise, éclatées
au quatre coins du système d'information. Pour
celà, il faut préalablement placer des agents
à tous les points stratégiques de l'infrastructure,
vérifiant en permanence la santé des applications
et du matériel. Le travail de ces "agents" -
sur le terrain - est la base même de tout système
de gestion des performances, et bien sûr un socle
que l'on aura tout intérêt à soigner.
Un agent
pour chaque enjeu
Mais à quoi au juste ressemblent ces mystérieux
agents ? "Il s'agit souvent d'un petit logiciel
que l'on installe sur un serveur important - ou
sur une machine située à proximité
immédiate du matériel à surveiller.
Chaque agent embarque dans sa machine virtuelle une
série de règles, qui sont autant de sondes
capables de réunir des informations sur un point
particulier du système. Il existe une règle
pour contrôler un OS beta, une règle pour
contrôler une base de donnée gamma, etc ...."
explique Christophe Richard, responsable avant-vente
de Patrol (BMC), l'un des leaders du marché.
On place donc un agent
sur chaque machine que l'on souhaite surveiller, et
on l'équipe des règles nécessaires -
OS, applicatifs, etc - facturées à
l'unité ... Le tout n'alourdit pas de façon
exagérée la charge du serveur : un
agent consomme rarement plus de 4 % des ressources
système.
Les agents sont le plus
souvent installés directement sur les machines -
ce qui permet de recuillir les données très
rapidement. Mais ce n'est pas toujours vrai : certains
fabriquants proposent en effet des produits qui fonctionnent
à distance, ce qui se révèle très
utile dans la cas des ASP. Mais ces agents sont moins
réactifs, et ils mobilisent beaucoup plus de
bande passante sur le réseau. On leur préfère
souvent des agents locaux.
Agents
pour les logiciels ou agents pour le matériel ?
Mais comment ces petits logiciels recueillent-t-ils
des informations pertinentes ? Entrons plus avant
dans la technique : "les règles exécutées
par les agents peuvent être classées en
deux familles : celles qui surveillent le software,
et celles qui contrôlent le hardware" explique
Christophe Richard. Quant un agent veut recueillir des
informations sur un matériel - un routeur,
un switch, une baie de stockage -, il va fouiller
dans une MIB (Management Interface Base), qui
est une sorte de fichier "log" que chaque
produit hardware communique vers l'extérieur,
via le protocole SNMP.
Lorsqu'il s'agit de récupérer
des informations en provenance d'un logiciel -
un ERP, un OS, une base de données -, les
méthodes sont plus variées. "Nous
faisons souvent appel à une API spécifique
à l'application, mais aussi aux fichiers 'log'
ou aux fichiers d'alertes que l'on peut trouver. On
peut attaquer directement le process du soft en analysant
ce qu'il y a en mémoire vive, ou faire appel
aux informations stockées en mémoire morte".
Ces méthodes sont valables pour la plupart des
applicatifs, mais on dispose d'autres astuces pour quelques
familles de logiciels : le fichier "trace"
HTTP pour les applications web, ou encore les requêtes
SQL - ou moteur - pour les bases de données.
Le développement
d'un agent requiert une connaissance très fine
de chaque produit, environnement ou applicatif surveillé.
"Il faut être capable d'extraire des informations
le plus près possible du noyau du logiciel. Heureusement,
les fabriquants et les éditeurs nous facilitent
la tâche en nous communicant des informations
très précises sur la façon d'y
accéder. Ce qui est très important, à
tel point que BMC a placé un ingénieur
en faction au siège de Microsoft pour surveiller
les développements du géant".
Vers
la console
Une fois récupérées,
ces informations subiront un sort bien précis :
elles seront d'abord triées selon des règles
élaborées, afin de ne retenir que celles
qui sont vraiment pertinentes. "Un agent retiendra
par exemple que le processeur est utilisé à
plus de 98 % depuis plus de 10 minutes, ou qu'une
application n'a pas été utilisée
depuis plus d'une heure". Une fois le tri effectué,
des alertes sont mises en forme et remontées
vers la console d'administration - le petit logiciel
qui permet à l'administrateur de surveiller la
santé de l'infrastructure. Chaque problème
détecté est signalé.
Les informations non communiquées
sont gardées en mémoire durant quelques
semaines, ce qui permet à un administrateur d'enquêter
depuis sa console et d'obtenir un complément
d'information. La console est prévue pour gérer
la requête d'un administrateur distant et pour
lui délivrer des informations complémentaires,
bien souvent indispensables.
Implémentation
sans douleurs
Reste à intégrer
chaque agent dans le système d'information. Une
manoeuvre qui devrait se passer sans trop de peine :
Christophe Richard (BMC) explique pourquoi : "L'idée
de base est d'avoir un impact minimal sur le système
d'information. Ce n'est pas à nous de dicter
au client ce que doit être son infrastructure.
C'est à nous de nous y fondre".
On intègrera donc
facilement une batterie d'agents à un système
d'information hétérogène, à
condition toutefois de faire appel aux produits d'un
leader : seuls les plus grosses firmes sont capables
de fournir suffisamment de règles pour couvrir
tous les produits, tous les OS et tous les applicatifs
du marché. Si toutefois vous ne trouviez pas
votre bonheur chez IBM, BMC, HP ou CA, il est encore
possible de faire fabriquer votre agent sur mesure,
ou de le développer en interne gràce aux
kits de développement proposés par certains
éditeurs et aux formations qu'ils proposent.
Ou placer
ses agents ?
Reste cependant un point délicat, qui justifie
le recours à un spécialiste : le
choix du placement des agents - et par extension
des logiciels et matériels que l'on
va contrôler. Christophe Richard assure qu'"il
faut beaucoup d'expérience pour mener cette opération
à bien intelligemment. Il ne faut par exemple
pas être tenté de poser immédiatement
des agents à tous les endroits du SI. Nous conseillons
de commencer par les points les plus stratégiques,
et - à la lumière de cette expérience -
de parfaire le maillage petit à petit".
En clair : il n'est pas
nécessaire de surveiller chaque machine, et de
recueillir des informations sur chaque parcelle du système
d'information. "Mieux vaut se concentrer sur les
points stratégiques, dont l'interruption de service
paralyserait l'entreprise". A moins de céder
aux sirènes de l'approche en vogue sur le marché
de la gestion des performances - qui répond
au nom de "end user" ou "business process".
Les éditeurs se sont en effet rendu compte que
ce qui importait le plus était de savoir si chaque
utilisateur, ou chaque processus métier pouvait
travailler sans entrave. A tout seigneur tout honneur :
nous avons traité cette approche dans un article
séparé.
|
[