Installer un logiciel de monitoring sur un système SAP de production crée une dépendance qui se révèle souvent au pire moment. Le kernel SAP est patché. L’agent de monitoring, installé sur le serveur applicatif pour lire les données de bas niveau des processus, n’est pas compatible avec la nouvelle version du kernel. Le monitoring de ce système devient aveugle pendant que l’éditeur prépare un correctif. Impossible alors de savoir si le système fonctionne correctement. Quatre jours plus tard, le correctif arrive, nécessite un redémarrage et déclenche un nouveau ticket de gestion du changement.
Ce scénario n’est pas théorique. Il se produit dans les environnements qui ont choisi un monitoring avec agents sans mesurer pleinement la maintenance qu’il implique. Sur un seul système, le coût paraît maîtrisable. Sur dix systèmes, avec des cycles de patch, des versions SAP et des configurations d’agents différents, cette maintenance devient un chantier opérationnel à part entière que personne n’avait réellement budgété.
Le monitoring sans agent supprime cette dépendance en retirant entièrement l’agent du système SAP. Aucun logiciel de monitoring n’est installé sur le système supervisé. Aucune demande de transport. Aucun programme ABAP déployé. Aucun processus exécuté sur le serveur applicatif. La connexion s’effectue entièrement depuis l’extérieur, via les interfaces standard déjà présentes dans SAP. Cet article explique précisément comment cette architecture fonctionne, ce qu’elle change au quotidien et quelles sont ses limites réelles.
Que signifie réellement le monitoring sans agent dans un environnement SAP ?
L’agent, une dépendance à maintenir
Dans le monitoring traditionnel, un agent est un processus logiciel exécuté sur le système supervisé ou directement à l’intérieur de celui-ci. Dans SAP, il peut prendre plusieurs formes. Un agent au niveau de l’OS, installé sur l’hôte Linux ou Windows, lit les métriques des processus, les données du système de fichiers et les statistiques réseau. Un agent ABAP déployé par transport exécute des programmes, lit des tables et appelle des modules fonction directement dans la pile ABAP. Un agent Java s’intègre à la JVM pour lire l’état des threads, la mémoire heap et le chargement des classes. Chacun de ces logiciels doit être présent, fonctionner de manière fiable et rester compatible avec l’environnement SAP au fil de ses évolutions.
La dépendance de maintenance varie selon le type d’agent. Un agent OS doit être mis à jour lorsque le système d’exploitation évolue, testé après un changement matériel et redémarré s’il tombe en panne. Un agent ABAP déployé par transport doit suivre tout le parcours de transport SAP : installation en développement, tests en QA, passage en production, puis nouveaux tests après chaque mise à niveau SAP susceptible de modifier le comportement des fonctions appelées. Un agent Java doit rester compatible avec la SAP Java VM, qui évolue avec les enhancement packages et les feature packs.
Lorsqu’une entreprise n’exploite qu’un seul système SAP, ces tâches restent gérables. Lorsqu’un MSP administre 40 systèmes SAP pour différents clients, chacun avec son propre cycle de patch et ses propres validations d’agents, le volume de maintenance devient un coût opérationnel qui n’avait pas été prévu dans le modèle tarifaire initial.
À quoi ressemble une connexion sans agent ?
Le monitoring sans agent se connecte au système SAP depuis l’extérieur, à l’aide des interfaces déjà fournies par le système. Le mode de connexion dépend de la couche de la pile SAP à superviser.
Pour la couche applicative ABAP, la connexion utilise une RFC de type 3 : une connexion RFC externe qui pointe vers le serveur de messages ou la gateway du système SAP. Le collecteur de monitoring envoie des appels RFC au système SAP. Celui-ci exécute des modules fonction standard ou lit des tables standard, puis renvoie le résultat. Aucun code spécifique ne s’exécute côté SAP. Aucun transport n’est nécessaire. Le système SAP reçoit et traite ces appels via l’infrastructure RFC existante, comme il le fait pour toute autre connexion externe.
Pour la couche base de données SAP HANA, la connexion s’effectue en JDBC ou ODBC vers la base HANA, avec un utilisateur de monitoring dédié au niveau de la base de données. Le collecteur envoie des requêtes SQL aux vues système des schémas SYS et _SYS_STATISTICS : M_MEMORY_OVERVIEW, M_SERVICE_REPLICATION, M_DISK_USAGE, M_EXPENSIVE_STATEMENTS, entre autres. La base HANA exécute ces requêtes et renvoie les résultats. Aucun logiciel supplémentaire n’est nécessaire côté HANA, en dehors de l’utilisateur de base de données et de ses autorisations.
Le collecteur de monitoring, c’est-à-dire le logiciel qui initie ces connexions et stocke les données reçues, s’exécute sur une infrastructure distincte des systèmes SAP. Il reste extérieur à tous les composants supervisés. Du point de vue de SAP, ce collecteur ressemble à n’importe quel client RFC ou application de base de données : il se connecte, s’authentifie, interroge le système, puis se déconnecte.
Comment fonctionne techniquement la collecte de données sans agent ?
Collecte via RFC : lire la couche ABAP
Le protocole RFC est le mécanisme standard de SAP pour les communications entre systèmes. Lorsqu’une application externe souhaite appeler un module fonction dans un système SAP distant, elle établit une connexion RFC, envoie une requête avec le nom du module et ses paramètres, puis reçoit les paramètres de retour. C’est exactement ainsi que les systèmes SAP communiquent entre eux dans les architectures distribuées. Le collecteur de monitoring utilise le même mécanisme.
Les modules fonction et les lectures de tables accessibles via RFC couvrent l’ensemble des données de monitoring de la couche ABAP. L’équivalent des données de SM50 est disponible via des modules fonction standard qui renvoient l’état et les statistiques des work processes. Les données des jobs SM37 sont accessibles par les interfaces RFC des traitements batch. L’état des files IDoc et qRFC peut être lu via les modules fonction standard des API ALE et RFC. Les données du journal système SM21 sont disponibles par les interfaces de lecture des logs système. Aucun code spécifique n’est nécessaire. Ces interfaces accessibles par RFC sont les mêmes que celles utilisées depuis des années par CCMS, Solution Manager et différents outils standard SAP.
L’intervalle de collecte dépend de la planification configurée dans le collecteur. Avec une interrogation toutes les 60 secondes, le collecteur envoie un appel RFC chaque minute, récupère l’état actuel du système et l’enregistre. Un intervalle de 30 secondes double la fréquence de collecte. SAP traite ces appels comme toute autre requête RFC, en utilisant les work processes background ou dialog disponibles selon la configuration de la connexion. La charge dépend de la fréquence de collecte et du volume de données par appel. Elle reste généralement faible par rapport à la charge transactionnelle de production.
Collecte SQL HANA : lire la couche base de données
Les vues système HANA, préfixées par M_ dans le schéma SYS, constituent la principale source de données pour le monitoring HANA. Elles fournissent en temps réel des informations sur l’allocation mémoire, l’état des services, les requêtes actives, la réplication, l’utilisation des disques et des dizaines d’autres métriques. Il s’agit d’objets HANA standard, documentés par SAP et interrogeables par toute application disposant des privilèges de base de données appropriés.
Le collecteur se connecte à HANA en JDBC avec un utilisateur de base de données disposant des privilèges système MONITORING et CATALOG READ. Ces deux privilèges lui permettent d’interroger toutes les vues M_* du schéma SYS. Aucune autre configuration n’est requise côté HANA. Aucun script n’est déployé. Aucune procédure stockée n’est installée. L’utilisateur de monitoring existe comme un utilisateur de base de données classique. Ses privilèges sont documentés, auditables et peuvent être contrôlés ou révoqués à tout moment via la gestion standard des utilisateurs HANA.
La séparation entre la connexion RFC ABAP et la connexion SQL HANA reflète l’architecture même du système SAP. Les métriques ABAP et HANA proviennent de couches différentes, avec des mécanismes d’accès distincts. Le collecteur maintient donc les deux connexions indépendamment. Une modification de la configuration HANA n’affecte pas la connexion RFC. Une évolution du profil d’autorisations ABAP n’a aucun effet sur l’utilisateur de la base HANA.
Le collecteur : où s’exécute le composant externe
Dire qu’une approche de monitoring est sans agent ne signifie pas qu’aucun logiciel n’est utilisé. Le collecteur de monitoring est bien un logiciel. La différence tient à l’endroit où il s’exécute. Le collecteur fonctionne sur une infrastructure contrôlée par l’équipe SAP, mais séparée des systèmes supervisés. Il peut s’agir d’un serveur dédié, d’une machine virtuelle, d’un conteneur dans un réseau d’administration ou d’un service hébergé dans le cloud. L’essentiel est qu’il ne soit ni installé sur le serveur applicatif SAP, ni déployé dans la base HANA, ni intégré au système de transport SAP.
Cette séparation donne au collecteur son propre cycle de vie, indépendant de celui des systèmes SAP qu’il supervise. Lorsqu’un kernel SAP est patché, le collecteur n’a pas besoin d’être mis à jour. Si SAP modifie l’interface d’un module fonction standard, l’adaptation est intégrée à la prochaine version planifiée du collecteur, sans aucun changement sur le système supervisé. Le système SAP ne connaît pas la version de l’outil de monitoring utilisée par le collecteur. Il sait uniquement qu’un client RFC s’est authentifié, a envoyé un appel et a reçu une réponse.
La disponibilité du collecteur reste essentielle à la continuité du monitoring. S’il tombe en panne, la collecte s’arrête et crée une interruption dans les données. La haute disponibilité du collecteur, via des instances redondantes ou un basculement automatique, relève de l’architecture de monitoring, pas des systèmes SAP. Ce n’est pas l’équipe SAP qui gère cette disponibilité, mais l’équipe monitoring ou le MSP.
Le coût opérationnel des agents se révèle à grande échelle
Un système, un agent : un coût encore maîtrisable
Installer un agent sur un seul système SAP représente quelques heures de travail. Il faut créer le transport, tester en DEV, passer en QA, tester à nouveau, puis déployer en production. Un redémarrage peut être nécessaire. Le changement doit aussi être documenté. La charge existe, mais elle reste contenue. Après la prochaine mise à niveau SAP, le test de compatibilité demande encore une demi-journée. Sur un an, la maintenance de l’agent pour un système peut représenter 5 à 10 heures de travail.
À cette échelle, les arguments contre les agents sont peu convaincants. L’agent fonctionne, les données remontent et la maintenance reste occasionnelle. Les équipes acceptent cette charge, car elle se fond dans le volume global des opérations.
Vingt systèmes, vingt agents : le calcul change
Avec 20 systèmes SAP, la maintenance des agents augmente de façon linéaire. Vingt jeux de transports à gérer. Vingt tests de compatibilité à chaque cycle de mise à niveau SAP. Vingt fenêtres de redémarrage à coordonner. Vingt dossiers de gestion du changement à ouvrir et à clôturer. Si l’entreprise effectue quatre mises à niveau SAP par an, cela représente 80 tests de compatibilité annuels. Et si l’éditeur de l’agent publie deux mises à jour par an, il faut réaliser 40 déploiements sur les 20 systèmes.
Le calcul se complexifie encore lorsque ces 20 systèmes utilisent des versions SAP, des systèmes d’exploitation ou des calendriers de patch différents. Un agent validé pour S/4HANA 2023 FPS02 peut se comporter autrement sur S/4HANA 2022 FPS04. L’équipe monitoring doit maintenir une matrice de compatibilité et tester chaque version de l’agent avec chaque version SAP avant tout déploiement. Dans un paysage hétérogène, cette matrice devient rapidement conséquente.
Le coût invisible de ce calcul réside dans la charge projet. Chaque projet de mise à niveau SAP qui inclut des tests de compatibilité des agents est plus lourd qu’il ne le serait sans agents. Cet effort de test n’est pas toujours attribué à l’outil de monitoring dans le budget du projet. Il apparaît simplement comme un dépassement du projet de mise à niveau, sans cause clairement identifiée.
Mises à niveau : pourquoi la maintenance des agents s’alourdit à chaque cycle de patch SAP
SAP publie des correctifs de kernel, des enhancement packages, des feature packs et des versions majeures selon un rythme qui s’est accéléré depuis l’arrivée de S/4HANA. Chaque nouvelle version peut créer un problème de compatibilité pour tout logiciel exécuté sur le système SAP ou à l’intérieur de celui-ci. L’éditeur du monitoring doit tester son agent avec la nouvelle version, publier une mise à jour, puis les clients doivent la déployer avant de mettre à niveau leurs systèmes SAP.
Dans la pratique, l’enchaînement est rarement aussi simple. La mise à jour SAP est disponible avant celle de l’agent. Le client dispose d’une fenêtre de maintenance pour le patch SAP, mais d’aucune version compatible de l’agent. Il peut alors reporter le patch SAP, ce qui est inacceptable pour un correctif de sécurité, appliquer le patch et accepter une interruption du monitoring jusqu’à la sortie de l’agent compatible, ce qui contredit l’objectif même du monitoring, ou désinstaller l’agent avant le patch puis le réinstaller, ce qui génère trois dossiers de gestion du changement au lieu d’un.
Avec un monitoring sans agent, ce problème disparaît. Un correctif du kernel SAP ne modifie ni l’interface RFC ni les vues système HANA. Le collecteur continue donc à récupérer les données sans adaptation. Le périmètre du projet de mise à niveau est plus léger, car la compatibilité du monitoring ne fait plus partie des éléments à tester. L’équipe SAP peut appliquer les patchs selon son calendrier, sans coordination avec l’éditeur du monitoring.
| En pratique : Dans les environnements réglementés, comme les systèmes pharmaceutiques conformes aux GxP ou les systèmes financiers soumis aux contrôles SOX, toute installation logicielle en production exige une procédure de gestion du changement documentée. Installer un agent revient à installer un logiciel : il entre donc dans ce processus, nécessite des tests de validation et peut demander une documentation réglementaire selon le statut de validation du système. Le monitoring sans agent évite entièrement cette charge. Aucun logiciel n’est installé sur le système validé, donc aucune procédure de changement n’est déclenchée. |
Autorisations et sécurité du monitoring sans agent
Ce dont l’utilisateur de monitoring a réellement besoin
Une connexion de monitoring via RFC s’authentifie avec un utilisateur SAP. Cet utilisateur doit disposer des autorisations nécessaires pour exécuter les appels RFC et lire les données dont l’outil a besoin. Le principe du moindre privilège s’applique exactement comme ailleurs : l’utilisateur de monitoring doit accéder uniquement aux éléments nécessaires à la supervision, sans aucun droit supplémentaire.
Les principaux objets d’autorisation pour le monitoring de la couche ABAP sont S_RFC, qui définit les groupes de fonctions et modules fonction accessibles depuis une connexion externe, S_TCODE, qui contrôle l’accès aux codes de transaction dont l’outil lit les données, et, dans certains cas, S_ADMI_FCD pour des fonctions de lecture liées à l’administration du système. Les valeurs exactes dépendent des métriques collectées. Un outil de monitoring correctement documenté fournit la liste des objets requis et de leurs valeurs précises.
Créer un rôle spécifique à partir de ces autorisations permet d’obtenir un compte dont l’accès est clairement défini, documenté et auditable. L’équipe sécurité peut examiner ce rôle et confirmer que l’utilisateur de monitoring ne peut modifier aucune donnée SAP, exécuter aucune transaction métier ni accéder à des données applicatives au-delà de ce qui est nécessaire aux métriques de santé du système. Cette traçabilité n’existe pas avec un agent doté d’un accès étendu aux processus au niveau de l’OS ou installé, par facilité, avec un compte très privilégié.
Pourquoi des autorisations minimales sont-elles plus faciles à auditer qu’un agent ?
Un agent exécuté au niveau de l’OS avec des privilèges root ou Administrator pour accéder aux informations des processus dispose d’un périmètre d’autorisations très large, difficile à délimiter lors d’une revue des accès. Le modèle de contrôle d’accès des processus OS est binaire : le processus peut lire tout ce qui est accessible à son compte utilisateur. Limiter cet accès aux seules données utiles au monitoring exige des règles de sécurité au niveau de l’OS, indépendantes de l’outil lui-même.
Une connexion RFC de monitoring associée à un rôle d’autorisations précisément configuré possède un périmètre explicite, défini dans le système de contrôle d’accès de SAP. La revue de cet utilisateur s’effectue dans SU01 et dans l’éditeur de rôles, avec les mêmes outils que ceux utilisés par l’équipe sécurité pour tous les autres contrôles d’accès. La nature de cet accès ne diffère pas de celle d’un autre utilisateur fonctionnel SAP. Son périmètre est simplement beaucoup plus restreint.
L’intérêt concret de cette auditabilité apparaît surtout lors des audits de sécurité et des tests d’intrusion. À la question « À quoi le système de monitoring a-t-il accès ? », il existe une réponse claire et précise, directement issue de la documentation des autorisations SAP, et non de fichiers de configuration propres à un agent externe. Cette précision est particulièrement appréciée des auditeurs et des équipes responsables de la sécurité des systèmes de production.
Ce que le monitoring sans agent ne peut pas faire, et comment combler ces limites
Métriques OS et approche hybride
Le monitoring SAP sans agent via RFC et SQL HANA couvre la couche applicative SAP ABAP et la couche base de données HANA. Il ne couvre pas toute la couche système d’exploitation : utilisation des systèmes de fichiers sur les volumes non-HANA, trafic des interfaces réseau, température et état des ventilateurs au niveau matériel, ou encore indicateurs de pression mémoire au niveau du kernel qui ne sont pas exposés par les API SAP.
C’est la limite réelle de cette architecture. Les interfaces RFC et SQL donnent accès à ce que SAP expose. Certaines métriques OS sont disponibles via les API SAP, car SAP les lit en interne et les publie dans CCMS ou dans les vues système HANA. Mais la couverture n’est pas exhaustive.
Dans la plupart des environnements, la solution la plus pragmatique consiste à adopter une approche hybride. Les métriques OS sont collectées par les outils standard de monitoring de l’infrastructure : agent léger de la plateforme, interrogation SNMP ou monitoring natif du fournisseur cloud dans les environnements hyperscaler. Les métriques applicatives SAP et celles de la base de données sont collectées sans agent par la plateforme de monitoring. Les deux sources sont ensuite réunies dans des dashboards intégrés, afin de corréler les événements OS et SAP sans obliger chaque outil à sortir de son domaine.
Cette approche hybride est généralement préférable à l’extension d’un outil de monitoring SAP vers la couche OS. Le monitoring des systèmes d’exploitation est un problème bien maîtrisé, avec des outils matures. Le monitoring applicatif SAP est un domaine spécialisé qui répond à des exigences particulières. Réunir les deux dans un outil SAP qui installe aussi des agents OS recrée précisément la dépendance de maintenance que l’architecture sans agent cherche à éviter.
Quand un agent reste la bonne réponse
Dans certains cas, un agent reste pertinent, même dans un environnement qui privilégie par ailleurs le monitoring sans agent. La collecte de métriques spécifiques à partir de données non exposées par les API standard SAP peut nécessiter un rapport ABAP sur mesure ou un agent léger chargé de récupérer et transmettre l’information. Certains scénarios de monitoring matériel exigent l’accès à des données disponibles uniquement via l’OS ou le BMC. Des exigences réglementaires particulières peuvent aussi imposer une architecture dans laquelle le code de monitoring s’exécute sur le système supervisé pour garantir la chaîne de traçabilité.
Le monitoring sans agent n’est pas une règle absolue. Il constitue la meilleure architecture par défaut pour le monitoring SAP, car les interfaces standard couvrent les métriques les plus importantes, la maintenance devient le principal coût opérationnel à grande échelle et le modèle d’autorisations est plus clair. Lorsqu’un besoin spécifique ne peut pas être couvert par les interfaces standard, l’agent est une exception justifiée, pas un renoncement au principe.
L’essentiel consiste à traiter les agents comme des exceptions documentées et régulièrement réévaluées, plutôt que comme des composants par défaut qui s’accumulent sans contrôle. Un paysage SAP dans lequel six équipes ont installé six agents différents sur chaque système en cinq ans, sans documentation complète et avec des versions parfois incompatibles avec la version actuelle de SAP, est précisément ce qu’une architecture sans agent permet d’éviter.
Déploiement rapide et intégration à grande échelle
Le temps de connexion pour chaque système
La connexion d’un système SAP à une plateforme de monitoring sans agent suit un calendrier prévisible. Créer dans SU01 l’utilisateur RFC de monitoring avec le rôle requis : 20 minutes. Créer dans SM59 la destination RFC qui pointe vers le collecteur : 10 minutes. Vérifier le test de connexion RFC et le test des autorisations : 5 minutes. Configurer l’utilisateur de monitoring HANA avec les privilèges système requis : 15 minutes. Vérifier la connectivité HANA depuis le collecteur : 5 minutes. Lancer la collecte et confirmer l’apparition des métriques dans le dashboard : 10 minutes.
Temps total pour ajouter un nouveau système SAP au monitoring : environ une heure, hors éventuel délai d’approbation interne pour la création de l’utilisateur. Aucun transport. Aucun redémarrage SAP. Aucun ticket de gestion du changement lié à l’installation d’un logiciel. Aucun test de compatibilité avec la version SAP concernée. Aucune intervention de SAP ou de l’éditeur du monitoring au-delà de la configuration initiale de la plateforme.
Avec une architecture basée sur des agents, le même processus comprend la création et le test d’un transport en développement, la planification du passage en QA, les tests en QA, la planification du passage en production, le déploiement pendant une fenêtre de changement et la vérification du bon fonctionnement de l’agent. Selon le rythme de gestion du changement de l’entreprise, cette séquence prend une à trois semaines. Pour un MSP qui intègre le système d’un nouveau client, l’écart entre une heure et trois semaines a un impact commercial direct.
Des usages différents pour les MSP et les grandes équipes IT
Pour un MSP qui gère les environnements SAP de plusieurs clients, l’architecture sans agent change l’équation économique de chaque nouveau système intégré. Le coût d’onboarding reste faible et prévisible. Le coût de maintenance récurrent n’augmente pas avec le nombre de systèmes. Une équipe qui gère 50 systèmes SAP sans agent supporte la même charge de maintenance par système qu’une équipe qui en gère 5. Avec des agents, l’équipe qui administre 50 systèmes doit absorber dix fois plus de maintenance.
Cette différence ne concerne pas seulement l’efficacité. Elle détermine aussi les services que le MSP peut proposer de manière crédible. Avec un monitoring peu coûteux à maintenir, il peut intégrer la supervision à une offre standard de services managés, sans gonfler le prix par système. Avec un monitoring lourd à maintenir, il doit soit absorber le coût au détriment de sa marge, soit le répercuter sous la forme d’un supplément qui rend son offre moins compétitive.
Pour les grandes équipes IT qui gèrent leur paysage SAP en interne, le bénéfice est différent. La contrainte principale n’est généralement pas le coût par système, mais le temps des ingénieurs. Une architecture qui n’exige pas leur intervention à chaque cycle de mise à niveau SAP, ni de coordination entre les équipes SAP et monitoring pour tester la compatibilité, libère du temps pour des tâches à plus forte valeur. L’équipe SAP gère les mises à niveau. L’équipe monitoring gère la plateforme. Aucune des deux ne dépend de l’autre pour la maintenance courante.
Une architecture qui reste simple, même à grande échelle
La plupart des infrastructures se complexifient à mesure que le nombre de systèmes gérés augmente. Plus de systèmes signifie plus d’agents, plus de configurations, plus d’entrées dans les matrices de compatibilité et plus de chantiers de maintenance menés en parallèle. La charge opérationnelle progresse avec l’échelle et finit, à un certain stade, par devenir la principale contrainte au lieu de rester un coût de fond.
Le monitoring sans agent inverse cette relation. Ajouter un nouveau système SAP au paysage de monitoring demande la même opération, qu’il s’agisse du cinquième ou du cinquantième système : un utilisateur RFC, un rôle d’autorisations, un utilisateur de base de données et une entrée de configuration dans le collecteur. La complexité de l’infrastructure de monitoring n’augmente pas avec le nombre de systèmes couverts. Elle se concentre sur le collecteur lui-même, un point d’investissement unique partagé par l’ensemble du paysage supervisé.
Cette charge opérationnelle stable lorsque le paysage s’agrandit fait du monitoring sans agent l’architecture par défaut la plus adaptée aux organisations qui gèrent plus que quelques systèmes SAP. Non pas parce que les agents sont toujours une mauvaise solution, mais parce que leur coût de maintenance s’additionne jusqu’à devenir dominant, tandis qu’une architecture sans agent retire entièrement cette variable de l’équation. Redpeaks se connecte à SAP via RFC et SQL HANA, sans agent, transport ni logiciel côté SAP. Après la création de l’utilisateur RFC, un nouveau système est généralement supervisé en moins d’une heure. Découvrez l’architecture de connexion.
