Comment surveiller mes systèmes SAP ?

La mise en œuvre d'un monitoring SAP nécessite avant tout une chose : du temps. Pour les administrateurs de base et les responsables de modules, la mise en place des conditions nécessaires à la surveillance de SAP dans le back-end représente un énorme effort.

Mais seul celui qui surveille ses systèmes SAP de manière exhaustive peut assurer la stabilité de ses processus commerciaux.

Pourquoi surveiller SAP ?

Étape 1 : Aussi banal que cela puisse paraître, avant de commencer à mettre en place un monitoring SAP, vous devez vous demander ce que vous voulez en faire.

Réduire les coûts ? Démontrer des services stables ? Réduire les activités manuelles ? Bien entendu, la plupart des utilisateurs auront à cœur de garantir la stabilité de leurs systèmes SAP et de limiter au maximum les pannes et les goulots d'étranglement.

Mais les économies de coûts et la création de services informatiques transparents peuvent également jouer un rôle.

D'autres raisons peuvent être l'automatisation d'activités de routine, comme la vérification continue des fichiers log ou le contrôle d'instances individuelles. La surveillance allège la charge de travail des administrateurs et leur permet de se consacrer davantage à leurs tâches principales.

De plus, comme la surveillance est automatisée et s'effectue toujours selon les mêmes critères, les erreurs humaines sont minimisées. La disponibilité de données de performance fiables rend le système transparent et inspire confiance.

De nombreux services informatiques souhaitent utiliser ces valeurs comme base pour un reporting, afin de pouvoir les utiliser comme preuve de disponibilité ou comme base de données pour l'analyse des performances et la gestion des capacités.

Une surveillance SAP peut donc faire beaucoup plus et il y a de nombreuses bonnes raisons de le faire.

Mesurer quoi ?

Étape 2 : Quiconque s'est déjà penché sur le thème du monitoring SAP sait qu'il existe un nombre presque incalculable d'indicateurs de performance et de métriques qui peuvent être surveillés.

Dans un deuxième temps, il convient donc de se consacrer à la sélection des paramètres critiques pour le fonctionnement. Cette étape est élémentaire, car une bonne surveillance ne se caractérise pas par la quantité de métriques surveillées, mais par un rapport sain entre les métriques importantes et le fait de "ne pas mesurer" délibérément.

En matière de monitoring SAP notamment, il est facile de collecter d'innombrables données dont on ne peut cependant pas faire grand-chose.

Avec quoi mesurer ?

Étape 3 : Au cours de sa longue histoire, SAP a développé un grand nombre d'outils de surveillance. Ceux-ci sont très utiles, mais ne contribuent pas forcément à une meilleure vue d'ensemble. La troisième étape consiste donc à se pencher sur les différents outils de surveillance de SAP.

Alors que les outils de surveillance propres à SAP, tels que SAP Computer Center Management System (CCMS), CEN, GRMG, SAP-Performance-Monitor (ST03n) ou eCATT, permettent d'avoir un aperçu différencié de la vie interne d'un système SAP, un logiciel open source tel que Nagios permet de garder un œil sur toute l'infrastructure réseau.

C'est un avantage inestimable, notamment en cas de panne de système dont la cause n'est pas immédiatement identifiable. Et avec Solution Manager 7.2, SAP a livré une autre nouvelle architecture (dont je parle ci-après en tant que SolMan).

Les administrateurs SAP ont ainsi devant eux une série de nouveaux thèmes. Ainsi, l'intégration de Wily Introscope a permis à SAP de se développer considérablement, notamment dans l'environnement Java.

De même, SAP ne s'appuie plus uniquement sur les informations du CCMS, mais utilise également d'autres sources, comme par exemple les connexions aux bases de données et l'agent de diagnostic SAP.

La complexité du paysage de la surveillance a donc considérablement augmenté. De plus, le SolMan présente un autre inconvénient : Les systèmes non-SAP ne peuvent être surveillés que de manière rudimentaire ou pas du tout.

Le SolMan constitue donc un îlot de surveillance au sein du cosmos SAP. Il ne faut pas sous-estimer les liens entre SAP et d'autres composants du système et applications :

Souvent, ce que l'on croit être un problème SAP est en fait un problème d'infrastructure de base ou d'applications tierces. Les administrateurs devraient donc se demander s'ils ne devraient pas intégrer SAP dans le monitoring général.

Intégration dans le monitoring de l'infrastructure ?

Étape 4 : Outre la complexité de SAP et les exigences très élevées en matière de connaissances des collaborateurs qui y sont liées, le plus grand défi lors de la mise en place d'une surveillance SAP consiste en fait à mettre en place une surveillance complète qui tienne compte de toutes les interdépendances entre SAP et les systèmes tiers.

L'étape suivante consiste donc à se demander comment combler l'écart entre SAP et les systèmes tiers. D'après mon expérience, une approche ouverte est la plus prometteuse.

C'est pourquoi je recommande l'utilisation de technologies ouvertes ou de solutions open source. Pour la solution de monitoring open source Nagios, il existe quelques plug-ins qui tirent leurs informations du CCMS de SAP.

Malheureusement, la simple connexion au CCMS ne suffit pas. Si l'on veut être équipé à long terme, il faut envisager l'intégration de plusieurs interfaces et la connexion de nouvelles technologies.

Par exemple, les systèmes SAP basés sur Java ne peuvent être surveillés que de manière très limitée par le CCMS. Il faut donc trouver une alternative. Le nouveau point de départ s'appelle SAP Control Webservice et offre les fonctions suivantes :

• AbapReadSyslog : Informations dans le style de la transaction SM21 ;
• AbapGetWPTable : Informations dans le style de la transaction SM50 ;
• GetAlertTree : informations dans le style de la transaction RZ20 ;
• GetAlerts : informations sur toutes les alertes ;
• GetProcessList : surveillance du serveur de messages et du répartiteur ;
• J2EE : informations sur diverses métriques et statistiques Java ;
• EnqGetStatistic : Statistiques de file d'attente (Enqueue-Errors, Dequeue-Errors) ;
• EnqGetLockTable : Informations sur les entrées de verrouillage

Ce que le service Web de contrôle SAP peut mettre à disposition dépend de la version et du type de système.

Créer l'architecture de surveillance

Étape 5 : Passons maintenant au concret : créez l'architecture de votre monitoring SAP. Avec SolMan 7.2, SAP propose un monitoring centralisé qui ne puise plus seulement ses informations dans le CCMS, mais qui se connecte également à d'autres sources de données et met toutes les informations à disposition dans une interface centrale.

Lors de la mise en place du monitoring, je recommande de décomposer la surveillance en sous-domaines. Cela vous permet de mesurer SAP et les différents composants tels que la base de données, le système d'exploitation, le matériel, etc. indépendamment les uns des autres.

• Matériel informatique : Un composant souvent négligé mais élémentaire dans la surveillance de SAP est un matériel qui fonctionne. Les informations sur le matériel peuvent être mises à disposition par les agents matériels des différents fabricants (Dell, Fujitsu, HP, IBM) via le protocole SNMP (Simple Network Management Protocol) et peuvent ainsi être intégrées dans la surveillance centrale.Ceci est important car même les meilleures redondances comme RAID (Redundant Array of Independent Disks) ne servent à rien à long terme si leur état n'est pas également surveillé.
• Système d'exploitation : Outre le matériel, le système d'exploitation est un autre composant important. Il constitue la base des applications à surveiller et doit donc naturellement aussi être saisi.Pour éviter les dépendances avec le CCMS, il est recommandé d'effectuer la surveillance au moyen d'agents du système d'exploitation. En particulier, l'utilisation et le degré de remplissage des disques durs sont des facteurs importants dans le domaine SAP, car l'expérience montre que c'est souvent une partition pleine qui est à l'origine de l'arrêt de SAP.Les statistiques CPU et mémoire donnent en outre un bon aperçu pour savoir si le système d'exploitation a atteint ses limites de performance.
• Base de données : La base de données est nécessaire à SAP et devrait donc également être surveillée. Ici aussi, outre le critère de la connexion réussie à la base de données, le paramètre "utilisation de l'espace mémoire" joue un rôle central.Les messages d'erreur des bases de données sont généralement écrits dans des fichiers journaux qui doivent être analysés. Une bonne méthode se distingue par le fait qu'elle permet d'indiquer des modèles critiques, d'avertissement et d'ok, des rotations de logs ainsi que l'observation exclusive de lignes nouvellement ajoutées.

Mettre en place une surveillance de la base SAP

Étape 6 : La sixième étape concerne la surveillance proprement dite du système SAP de base. Les métriques suivantes font partie d'une surveillance de base :

SM04 Nombre d'utilisateurs, SM12 Entrées de blocage : Enqueue Errors/Dequeue Errors, SMQ1 Status qRFC Out, SMQ2 Status qRFC Input, SM13, Aborted Jobs/Longrunners, SM 50 Error in Dialog, Batch, Update Prozesse, SM 51 Status SAP Server SM21 Syslogfrequency, SM 56 Tranches de numéros encore libres, SM58 Statut TRFC, SPAD Spoolerstatus/Spool Used Numbers, ST03N Temps de réponse du dialogue, ST22 Shortdumps/Shortdumpfrequency, SM21 Syslogfrequency, SCC4 Modification du système (table T000), WE02 IDOCs erronés.

Les métriques sélectionnées à partir du CCMS et du SAP Control Webservice sont choisies en fonction des transactions les plus importantes. Veillez à ce que le monitoring choisi puisse toujours être facilement adapté à vos besoins.

Si votre surveillance SAP comprend les points décrits jusqu'ici, vous pouvez vous taper sur l'épaule : vous disposez maintenant d'une surveillance complète de la base SAP. Vous avez ainsi jeté les bases d'un système SAP qui fonctionne.

Intégrer des applications dans la surveillance

Étape 7 : La surveillance de SAP ne s'arrête pas au suivi des indicateurs de performance. Il est tout aussi important de considérer l'application du point de vue de l'utilisateur, afin de garder un œil sur le fonctionnement du système SAP dans son ensemble.

L'expérience montre que la meilleure façon de surveiller les applications est de mettre en place un monitoring de bout en bout. C'est la seule façon de s'assurer que l'application fonctionne réellement.

Un bon monitoring de bout en bout se caractérise par le fait qu'il n'est pas seulement enregistré avec un enregistreur, mais qu'il peut également réagir aux actions. C'est pourquoi il convient de décrire le plus précisément possible les processus ainsi que les particularités et problèmes qui surviennent.

Je recommande d'utiliser des robots spéciaux de bout en bout qui exécutent de manière cyclique des actions utilisateur définies via l'interface utilisateur graphique SAP. Il peut s'agir d'actions allant de la connexion à SAP au remplissage de masques de recherche.

Le temps écoulé entre les points de mesure librement définis est évalué, analysé et transmis au système de surveillance. Dans l'idéal, ces sondes se trouvent à différents points de la topologie du réseau par respect pour les conditions générales les plus réelles possibles.

Optimisez votre monitoring SAP

Étape 8 : La plupart des utilisateurs SAP sont sceptiques à l'égard de l'open source. Le système semble trop puissant pour être "maîtrisé" par des technologies ouvertes.

Dans ce contexte, les solutions open source permettent d'aborder le CCMS, le SAP Control Webservice, les fonctions RFC et BAPI et de les intégrer ainsi dans une surveillance centralisée.

Outre la surveillance globale, une telle intégration offre d'autres possibilités : Il est par exemple possible de mettre en relation des métriques issues de la surveillance SAP avec des métriques de l'infrastructure.

En mettant en relation tous les systèmes informatiques impliqués dans un service d'entreprise, on obtient un monitoring complet et adapté à l'entreprise, qui permet de surveiller sans faille même les grands paysages SAP et informatiques.

Je recommande donc de tenir compte des technologies ouvertes lors de la mise en place du suivi SAP. Deux systèmes sont à mon avis les plus appropriés à cet égard.

Plug-ins Nagios pour CCMS

Quand on pense à un logiciel open source de surveillance de réseau, on pense à Nagios. Cette solution, placée sous GPLv2, est depuis des années le standard de facto dans ce domaine.

Grâce à sa structure modulaire et à son architecture extensible, cet outil est adapté à la surveillance d'environnements système complexes avec SAP et d'autres applications propriétaires. Des plug-ins se chargent chez Nagios de la surveillance des différents composants.

Les plug-ins Nagios pour CCMS sont probablement les plus connus pour le CCMS et sont considérés comme un modèle pour l'intégration des métriques CCMS dans Nagios. Avec les plug-ins, il est possible d'obtenir et d'afficher des paramètres du CCMS.

Le nombre de connexions à SAP et l'exécution de nombreux contrôles actifs dans Nagios posent toutefois problème. C'est pourquoi on crée souvent un set de monitoring spécial qui est récupéré. La sortie est enregistrée dans un fichier texte.

En général, c'est une bonne approche, car cela permet d'alléger la charge du système SAP. La configuration s'effectue via les fichiers de configuration. Il faut impérativement avoir accès à SAP pour pouvoir obtenir les informations sur les métriques et les sets de surveillance.

Le module de suivi SAP d'OpenITCockpit

Les solutions de monitoring disponibles ont un point commun : les allègements ont un effet positif soit sur la performance de SAP, soit sur celle du système de monitoring - mais pas sur les deux en même temps.

La solution OpenITCockpit basée sur Nagios est une approche qui soulage les deux systèmes de la même manière. Le module de surveillance SAP poursuit deux objectifs : L'intégration du SAP Control Webservice garantit une surveillance pérenne des systèmes SAP.

L'architecture des plug-ins et leur interaction avec un contrôle actif et de multiples contrôles passifs permettent de réduire la charge des systèmes SAP et du système de surveillance. Le monitoring SAP OpenITCockpit ne nécessite pas SolMan comme source de données.

Grâce à la possibilité de surveillance distribuée (Distributed Monitoring), l'évolutivité est en outre nettement accrue, ce qui permet à OpenITCockpit de surveiller également de grands paysages SAP et des environnements d'infrastructure étendus.

Pour un monitoring indépendant et étendu, d'autres sources de données peuvent être connectées en plus du CCMS. Il s'agit entre autres de : Bases de données, agents du système d'exploitation, services web de contrôle SAP et appel de fonctions RFC ainsi que de modules BAPI.

Conclusion : gardez une vue d'ensemble

De nombreux chemins mènent au but et une surveillance de base de SAP est possible avec de nombreux outils différents. Les outils embarqués de SAP donnent accès à toutes les données pertinentes et permettent également de surveiller des composants au-delà du seul environnement SAP.

Malheureusement, l'installation et la configuration des différents outils sont très complexes et ne sont parfois pas automatiques.

Afin de poser les bases d'un monitoring complet de SAP à long terme, il est important de miser sur des technologies telles que le SAP Control Webservice.

Un logiciel open source comme Open-ITCockpit offre une vue unifiée de l'ensemble de l'informatique, y compris le réseau, les serveurs et SAP. La configuration et l'exploitation sont plus simples qu'avec Solution Manager.