Il existe une catégorie de problèmes de performance SAP qui n’apparaît pas dans les métriques HANA. La mémoire HANA reste dans les seuils attendus. Les temps de réponse de la base de données sont normaux. Le CPU de l’hôte de base de données ne montre rien d’inquiétant. Pourtant, les utilisateurs d’une instance serveur applicatif signalent des lenteurs intermittentes, qui apparaissent et disparaissent sans corrélation évidente avec la charge système.
La cause se situe généralement dans la couche NetWeaver, plus précisément dans l’architecture de gestion mémoire ABAP qui se trouve entre les utilisateurs et la base de données. Épuisement de la mémoire étendue, zones de roll saturées, dégradation des taux de réussite des buffers ou appels RFC synchrones qui maintiennent des work processes dialogue en état d’attente pendant que la réponse traverse un saut réseau : aucun de ces éléments ne déclenche d’alerte HANA. En revanche, ils provoquent des pics de temps de réponse dialogue difficiles à attribuer sans une supervision couvrant spécifiquement la couche applicative.
Cet article présente les métriques NetWeaver et ABAP qui définissent la stabilité des performances dans un environnement SAP de production. Il se concentre sur les signaux distincts de la supervision base de données, ceux qui expliquent les problèmes de performance que les métriques database ne peuvent pas expliquer.
La couche de performance NetWeaver que la plupart des outils de monitoring oublient
La gestion mémoire ABAP n’est pas la couche base de données
SAP NetWeaver ABAP possède sa propre architecture de gestion mémoire, indépendante de la base de données sous-jacente. La comprendre est indispensable pour interpréter les métriques de performance qui la surveillent.
Chaque session utilisateur dans un système ABAP conserve une zone de roll : un segment mémoire qui stocke le contexte de session entre les étapes de dialogue. Lorsqu’un utilisateur appuie sur Entrée, le work process qui traite cette étape enregistre l’état de la session dans la zone de roll à la fin de l’étape, puis le restaure depuis cette même zone au début de l’étape suivante. La zone de roll est elle-même allouée depuis la mémoire étendue, ou Extended Memory, un segment de mémoire partagée sur chaque instance serveur applicatif. La taille de cette mémoire étendue est définie par un paramètre de profil, abap/em_global_area_MB, configuré au niveau de l’instance.
Lorsque la mémoire étendue est entièrement allouée entre les sessions actives, les nouvelles sessions ou les nouvelles étapes de dialogue ne peuvent plus réclamer d’espace EM. Elles basculent alors vers le heap local au processus, limité par ce que le profil autorise, puis finalement vers le fichier de roll sur disque, ce qui revient en pratique à du paging. Une étape de dialogue nécessitant un stockage roll sur disque prend des ordres de grandeur plus longtemps qu’une étape servie depuis la mémoire partagée. Cela se produit de manière transparente, sans erreur visible, et l’impact apparaît sous forme de pic intermittent du temps de réponse dialogue, affectant des utilisateurs précis plutôt que tout le système.
La métrique qui révèle cette condition est l’utilisation de la mémoire étendue en pourcentage de la limite configurée. Elle est disponible dans le moniteur mémoire ABAP, transaction ST02, et dans les statistiques de charge. Elle est rarement intégrée aux configurations de monitoring standard, qui se concentrent généralement sur les métriques de base de données et d’infrastructure plutôt que sur la mémoire de la couche ABAP.
Pourquoi les lenteurs intermittentes sont souvent un problème NetWeaver, pas un problème HANA
Le schéma qui doit déclencher une investigation au niveau NetWeaver plutôt qu’au niveau base de données présente des caractéristiques précises. Une lenteur spécifique à une session, non généralisée à tout le système, et qui disparaît lorsqu’un utilisateur se déconnecte puis se reconnecte, pointe vers un état mémoire lié à la session. Une lenteur qui apparaît à partir d’un certain nombre d’utilisateurs concurrents et qui diminue lorsque des sessions se terminent pointe vers une pression sur la mémoire étendue. Une lenteur constante sur une instance serveur applicatif et absente sur les autres instances du même paysage pointe vers une configuration au niveau instance ou un problème de répartition de charge.
Aucun de ces schémas ne produit de signaux évidents dans la supervision base de données. HANA traite les requêtes avec une latence normale. L’hôte de base de données dispose de CPU disponible. Le tableau de bord de monitoring est au vert. L’utilisateur subit pourtant des étapes de dialogue de 8 secondes. L’explication se trouve dans la couche ABAP, pas dans la base de données.
Cet écart entre ce que montre la supervision database et ce que vivent les utilisateurs explique pourquoi les métriques spécifiques à NetWeaver méritent d’être maintenues comme un axe de monitoring séparé. Elles répondent à des questions auxquelles les métriques base de données ne peuvent structurellement pas répondre.
Les métriques qui définissent la santé des performances NetWeaver
Décomposition du temps de réponse dialogue : la vraie image derrière le total
Le temps de réponse dialogue total est une métrique utile pour suivre une tendance, mais elle reste faible pour le diagnostic. Un temps de réponse total de 3 secondes peut signifier 2,8 secondes de temps base de données et 0,2 seconde de traitement ABAP, ou 2,8 secondes d’attente RFC pendant qu’un appel synchrone vers un système externe se termine, ou encore 2,8 secondes de temps en file d’attente avant qu’un work process soit disponible. Chacun de ces cas a une cause racine totalement différente et nécessite une remédiation différente.
Le moniteur de charge, transaction SWNC ou /SDF/MON sur les anciens systèmes, accessible via SM66 dans la vue d’analyse des performances, décompose le temps de réponse total en plusieurs composants : temps de traitement, c’est-à-dire CPU ABAP pur, temps de requête base de données, temps de roll et dequeue, correspondant à la sauvegarde et à la restauration du contexte aux limites des étapes, temps d’attente, soit le temps passé dans la file d’attente du work process avant le début du traitement, et temps RFC, soit le temps passé à attendre des appels de fonction distants synchrones vers d’autres systèmes.
Surveiller chaque composant séparément, et déclencher des alertes sur des anomalies propres à ces composants plutôt que sur le total uniquement, rend le monitoring du temps de réponse réellement actionnable. Une hausse du temps RFC qui coïncide avec l’introduction d’une nouvelle interface pointe vers un problème de performance d’intégration. Une hausse du temps d’attente corrélée à un nombre d’utilisateurs concurrents plus élevé pointe vers un problème de capacité des work processes. Une hausse du temps de requête base de données sans changement correspondant dans les métriques HANA pointe vers des statistiques de tables manquantes ou une régression du plan de requête. Le temps total masque ces trois scénarios. Les composants les révèlent.
En pratique : la vue des enregistrements statistiques dans STAD fournit les décompositions de temps de réponse au niveau de chaque transaction. Lorsqu’un utilisateur signale une transaction lente, STAD montre si le temps a été passé dans ABAP, dans la base de données, dans un appel RFC ou en attente d’un work process. Il fournit les preuves nécessaires pour orienter l’investigation au lieu de partir d’hypothèses.
Utilisation de la mémoire étendue : la métrique qui explique les lenteurs intermittentes
La mémoire étendue est configurée une fois au niveau du profil d’instance et ne se redimensionne pas automatiquement pendant l’exploitation. La mémoire EM totale disponible est partagée entre toutes les sessions actives d’une instance. Chaque session en réclame une partie à la connexion et la libère à la déconnexion. Les sessions qui exécutent des tâches gourmandes en mémoire, comme de grands rapports ou des traitements maintenant de grandes tables internes dans le contexte de session, consomment plus que la moyenne.
Le seuil pratique pour l’utilisation de la mémoire étendue est de 80 % de la limite configurée. En dessous, la marge est suffisante pour que des pics occasionnels de consommation mémoire par session ne forcent aucune session à basculer vers le roll. Au-dessus de 80 %, une seule session consommant plus de mémoire EM que d’habitude en raison d’un jeu de résultats plus volumineux peut pousser l’utilisation totale au-delà de la limite et forcer d’autres sessions à utiliser le fichier de roll.
Deux valeurs doivent être surveillées : l’utilisation EM actuelle en pourcentage de la limite et l’utilisation EM maximale observée sur les dernières 24 heures. Le maximum capture les périodes de charge de pointe que l’utilisation actuelle peut manquer. Une instance dont l’utilisation EM actuelle est à 55 %, mais dont le maximum quotidien atteint 88 %, présente un risque réel à traiter, même si elle semble saine au moment de la mesure.
Lorsque l’utilisation EM est constamment élevée, les options de remédiation consistent à augmenter la limite EM configurée dans le profil d’instance, ce qui nécessite un redémarrage, à réduire le nombre de sessions concurrentes sur l’instance via des ajustements de répartition de charge, ou à identifier et corriger les programmes qui conservent une quantité excessive de mémoire de session. Ce diagnostic se fait généralement avec les outils d’analyse mémoire de l’ABAP Workbench.
Qualité des buffers : taux de réussite du table buffer et du program buffer
SAP NetWeaver maintient plusieurs couches de buffers en mémoire sur chaque instance serveur applicatif, séparées de la mémoire HANA. Deux d’entre elles ont un impact direct sur les performances dans la plupart des environnements de production : le table buffer et le program buffer.
Le table buffer stocke en mémoire partagée, sur le serveur applicatif, le contenu des tables de base de données fréquemment lues. Les tables configurées pour le buffering, via SE13, sont lues depuis ce cache local plutôt que depuis la base de données. Pour les tables de customizing, les tables de configuration et certaines tables de données de base fréquemment consultées, cela élimine des lectures base de données qui se produiraient autrement des milliers de fois par heure. Un taux de réussite du table buffer inférieur à 98 % signifie qu’au moins 2 % des lectures de tables bufferisées partent vers la base de données parce que le buffer est trop petit pour contenir tout le working set. Dans un système avec une forte activité de lecture de customizing, cela génère une charge database mesurable et inutile.
Le program buffer stocke les programmes ABAP compilés en mémoire partagée afin qu’ils n’aient pas besoin d’être rechargés depuis la base de données à chaque exécution. Un program buffer trop petit ou trop fragmenté provoque des rechargements fréquents de programmes, des opérations coûteuses qui se sérialisent via le chargeur de programmes et créent des pauses brèves mais mesurables. Les taux de réussite inférieurs à 95 % méritent une investigation dans les systèmes de production.
Les deux taux de réussite sont visibles dans ST02, le monitoring des buffers ABAP. Le diagnostic important ne porte pas seulement sur le taux de réussite actuel, mais aussi sur le nombre de swaps : combien de fois des objets du buffer ont été évincés pour libérer de la place à de nouveaux objets. Un buffer avec un nombre élevé de swaps est sous-dimensionné par rapport à la variété des objets chargés, même si le taux de réussite paraît acceptable à un instant donné.
Point de vigilance : la synchronisation du table buffer entre plusieurs instances serveur applicatif utilise un mécanisme appelé messages de synchronisation de buffer. Lorsqu’une table de customizing est modifiée sur une instance, un message de synchronisation invalide la version mise en cache sur les autres instances afin qu’elles la rechargent depuis la base de données. Dans les systèmes soumis à une forte activité de changement, par exemple du customizing actif pendant les heures ouvrées, le trafic de synchronisation des buffers peut lui-même créer de brefs impacts de performance. Surveiller le taux de messages de synchronisation buffer par instance permet d’identifier cette condition.
Short dumps, entrées de verrouillage et journal système comme signaux de performance
Le taux de short dumps comme indicateur de stabilité
Un short dump, ou erreur d’exécution ABAP enregistrée dans la transaction ST22, représente une étape de dialogue ou un job d’arrière-plan qui s’est terminé anormalement à cause d’une exception non gérée. L’exception peut être une erreur de programme, un échec d’autorisation, un dépassement de limite de ressources, comme un overflow mémoire ou un timeout, ou encore une incohérence de données que le programme ABAP n’a pas pu traiter.
Dans un système ABAP de production, le taux de short dumps doit être proche de zéro. Non pas parce que les erreurs n’arrivent jamais, mais parce qu’un système de production doit avoir bénéficié de suffisamment de tests et de gestion d’exceptions pour que les erreurs d’exécution dans les transactions utilisateurs restent exceptionnelles plutôt que routinières. Un système qui génère en moyenne 15 short dumps par jour a un problème de stabilité : une partie des transactions utilisateurs échoue, certains jobs d’arrière-plan se terminent, et la cause est absorbée dans une liste ST22 qui s’allonge au lieu d’être suivie et résolue.
Le monitoring des short dumps comporte deux signaux distincts à suivre séparément. Le nombre absolu par jour, qui indique la stabilité globale, et la distribution par classe de dump, qui indique le type de problèmes rencontrés. MEMORY_NO_MORE_PAGING et TSV_TNEW_PAGE_ALLOC_FAILED sont des classes de dumps liées à la mémoire, indiquant que certaines sessions dépassent leurs limites mémoire configurées. TIME_OUT indique des programmes qui dépassent la limite maximale de durée d’une étape de dialogue. DBIF_REPO_SQL_ERROR signale des problèmes de connectivité base de données ou de requêtes. Chaque classe pointe vers une couche différente du problème.
Accumulation des entrées de verrouillage et conséquences sur les performances
Les verrous de niveau SAP ABAP sont gérés par le work process d’enqueue et visibles dans SM12. Dans un système de production sain, la liste SM12 change en permanence à mesure que les transactions acquièrent et libèrent des verrous pendant les opérations métier normales. Les entrées apparaissent brièvement puis disparaissent lorsque les transactions effectuent leur commit.
La condition de performance à surveiller est l’accumulation des entrées de verrouillage : un nombre croissant d’entrées sur des objets spécifiques qui ne se libèrent pas. Cela se produit lorsqu’une transaction acquiert un verrou et ne se termine pas, soit parce que l’utilisateur a lancé une transaction puis laissé l’écran ouvert sans finaliser, soit parce qu’un job d’arrière-plan conserve un verrou pendant une longue séquence de traitement sans commits intermédiaires.
Les verrous accumulés créent un goulot d’étranglement caché. Chaque transaction suivante qui doit accéder au même objet métier attend jusqu’à ce que le verrou soit libéré. Les utilisateurs perçoivent cela comme une absence de réponse sur certaines transactions, sans lien évident avec la session verrouillée ailleurs dans le système. Surveiller le nombre et l’âge des entrées SM12, et déclencher une alerte sur les entrées maintenues au-delà d’une durée configurée pendant les heures ouvrées, permet de détecter cette situation avant qu’elle ne devienne un incident visible.
Une métrique associée est l’utilisation de la table de verrouillage : le work process d’enqueue maintient une table de verrous de taille fixe. Si cette table approche sa limite de capacité, les nouvelles demandes de verrouillage sont refusées et les transactions échouent avec une erreur d’enqueue. Dans les environnements comptant de nombreux utilisateurs concurrents ou des verrous maintenus longtemps, cette limite peut parfois être atteinte. C’est une condition rare, mais elle produit des symptômes très nets lorsqu’elle survient, et le monitoring doit la détecter avant les utilisateurs.
SM21 et le journal système comme source de données de performance
Le journal système SAP, transaction SM21, enregistre les événements de niveau système : redémarrages de work processes, pénuries mémoire, overflows de fichiers de roll, événements de synchronisation de buffers, erreurs ICM et épuisement des pools de connexions. Ces événements ne sont pas des métriques de performance au sens traditionnel. Ce sont des signaux ponctuels indiquant qu’un événement anormal s’est produit au niveau de l’infrastructure système.
Utilisé comme source de monitoring plutôt que comme outil de revue manuelle, SM21 fournit un contexte qu’aucune autre couche de métriques ne fournit. Un événement de dépassement de fichier de roll dans SM21 à 10 h 47 se corrèle avec le pic de temps de réponse dialogue observé dans le moniteur de charge à 10 h 47. Un redémarrage de work process enregistré dans SM21 explique la brève interruption de disponibilité dialogue apparue dans le monitoring de disponibilité. Sans données SM21 intégrées au monitoring, la corrélation entre événements d’infrastructure et signaux de performance nécessite une investigation manuelle à chaque fois.
Les classes d’événements SM21 à surveiller en continu sont les terminaisons et redémarrages de work processes, les événements d’overflow de zone de roll, les événements d’overflow de mémoire étendue et les échecs de synchronisation de buffers. Une fréquence supérieure à un ou deux événements par heure en production indique une condition systémique qui mérite une investigation, et pas seulement une réponse incident par incident.
Temps d’attente RFC : lorsque la performance est empruntée à un autre système
Les appels RFC synchrones dans les étapes de dialogue et leur coût caché
Un appel RFC synchrone dans une étape de dialogue maintient le work process dialogue occupé pendant toute la durée de l’appel, y compris le temps de transit réseau vers le système cible, le temps de traitement sur le système cible et le temps de transit réseau pour la réponse. Le work process appelant ne peut servir aucun autre utilisateur pendant ce temps. Si le système cible est lent, le work process dialogue SAP appelant devient lent par héritage.
Ce goulot d’étranglement est fréquemment sous-estimé, car la cause et le symptôme se trouvent dans des systèmes différents. Un utilisateur signale une transaction lente sur le système A. L’investigation montre que HANA est sain, que les work processes sont disponibles et que le programme ABAP est efficace. Ce que l’investigation peut manquer, c’est que le programme effectue un appel RFC synchrone vers le système B pour récupérer des données, et que le système B est fortement chargé avec des temps de réponse RFC de 4 secondes. Le temps de réponse dialogue du système A inclut ces 4 secondes d’attente de la réponse du système B, alors que le système B n’apparaît dans aucun monitoring centré sur le système A.
Le composant temps RFC dans les statistiques de charge ABAP est la métrique qui révèle cette situation. Lorsque le temps RFC représente une part importante du temps de réponse dialogue total, le problème de performance se trouve dans le système appelé ou dans le réseau entre les deux, pas dans la couche applicative SAP observée. Cette distinction réoriente immédiatement l’investigation et évite de perdre du temps à optimiser le mauvais système.
Chaînes d’appels RFC et multiplication des temps d’attente
La situation est encore plus problématique lorsque les appels RFC sont chaînés. La transaction X sur le système A appelle le module fonction Y via RFC sur le système B, qui appelle ensuite le module fonction Z via RFC sur le système C pour récupérer des données supplémentaires avant de répondre. L’étape de dialogue de l’utilisateur sur le système A attend l’aller-retour A vers B, plus le temps de traitement de B, plus l’aller-retour B vers C, plus le temps de traitement de C, plus le retour C vers B, puis le retour B vers A. Trois sauts réseau et trois temps de traitement sont sérialisés dans un seul temps de réponse dialogue.
Dans les paysages SAP complexes avec plusieurs systèmes connectés, ces chaînes sont fréquentes et souvent invisibles depuis le monitoring d’un seul système. Le monitoring qui les détecte est soit une corrélation de performance RFC intersystèmes, où le temps d’attente RFC sur le système A est corrélé aux temps de réponse réels sur les systèmes B et C, soit un tracing transactionnel de bout en bout qui suit la chaîne d’appels à travers les frontières système.
Le point de départ pratique sans monitoring intersystèmes consiste à identifier les destinations RFC qui représentent la plus grande part du temps d’attente RFC dans les statistiques de charge. Une seule destination RFC représentant 40 % du temps d’attente RFC total du système constitue une cible à investiguer côté réception, quel que soit l’endroit où les symptômes de temps de réponse dialogue sont signalés.
Modes d’opération et répartition de charge entre les instances
SM63 et le ratio dialogue/background dans le temps
Les modes d’opération SAP, transaction SM63, permettent d’ajuster automatiquement le ratio entre work processes dialogue et background selon l’heure de la journée. Une configuration typique utilise un mode riche en dialogue pendant les heures ouvrées, puis bascule vers un mode plus orienté background pendant la nuit, lorsque les jobs batch s’exécutent et que les utilisateurs interactifs sont absents.
Surveiller les transitions de modes d’opération comme des événements, plutôt que surveiller uniquement l’utilisation des work processes, fournit un contexte utile pour interpréter les métriques d’utilisation. Un pic d’utilisation des work processes qui se produit précisément au moment d’un changement de mode d’opération n’est pas un incident de performance. C’est un comportement attendu pendant une courte période de rééquilibrage. Un pic d’utilisation survenant pendant une période planifiée de changement de mode, mais qui se prolonge bien au-delà de la fin attendue de la transition, peut indiquer que le changement de mode ne s’est pas correctement terminé.
Le risque de configuration dans les modes d’opération apparaît lorsque la fenêtre batch nécessite plus de work processes background que le mode actuel n’en fournit, mais que le changement de mode n’a pas été mis à jour pour refléter l’évolution du planning batch. La charge batch a augmenté. Le mode d’opération alloue toujours le même nombre de work processes background qu’il y a deux ans. Résultat : le pool de work processes background sature pendant la fenêtre nocturne, alors que le système semble correctement configuré.
Répartition de charge entre instances : là où SM66 devient essentiel
Dans un paysage avec plusieurs instances serveur applicatif, les problèmes de performance peuvent être locaux à une instance tandis que les autres restent saines. Les groupes de connexion, les modes d’opération et les affectations de groupes de serveurs pour les jobs background influencent l’instance sur laquelle arrivent les utilisateurs et les jobs. Lorsque cette répartition est déséquilibrée, une instance porte une charge disproportionnée pendant que les autres sont sous-utilisées.
SM66 fournit la vue interinstances de l’occupation des work processes. Les outils de monitoring qui ne remontent que des métriques par instance de manière isolée peuvent manquer le schéma où l’instance A est constamment à 90 % d’utilisation des work processes dialogue tandis que les instances B et C tournent à 40 %. La moyenne agrégée des trois instances paraît modérée. Les utilisateurs de l’instance A vivent pourtant une expérience bien moins bonne que cette moyenne ne le suggère.
La dimension de monitoring requise est donc l’utilisation des work processes par instance, suivie séparément et non agrégée à l’échelle du paysage. Une alerte déclenchée lorsqu’une instance dépasse 85 % d’utilisation soutenue des WP dialogue, indépendamment de l’état des autres instances, détecte le déséquilibre. Une alerte basée sur l’utilisation moyenne du système le manque.
Construire une baseline de performance NetWeaver réellement utile
Une baseline de performance NetWeaver n’a pas le même objectif qu’une baseline de performance HANA. Les métriques HANA disposent de plages normales relativement stables, applicables à des environnements aux profils de charge similaires. Les métriques NetWeaver sont fortement propres à la configuration de l’instance et au comportement des programmes ABAP exécutés sur cette instance.
La plage normale d’utilisation de la mémoire étendue dépend du nombre de sessions concurrentes que l’instance exécute habituellement et de l’intensité mémoire de ces sessions. Les taux de réussite des buffers dépendent des tables bufferisées et de la capacité du buffer à contenir le working set. Le temps d’attente RFC dépend des systèmes externes appelés et de leurs temps de réponse habituels. Aucun de ces éléments ne possède de valeur normale universelle.
Une baseline NetWeaver utile se construit en collectant quatre à six semaines de métriques sur des jours ouvrés, en capturant les variations entre le pic de charge du lundi et le jeudi après-midi, entre le début d’une clôture mensuelle et un mardi classique en milieu de mois. À partir de ces données, des plages normales émergent pour chaque métrique : non pas comme des valeurs uniques, mais comme des distributions par heure de journée et par jour de semaine, reflétant les vrais schémas d’exploitation.
Le résultat pratique de cette baseline est une configuration de seuils suffisamment spécifique pour être actionnable. Une alerte d’utilisation de la mémoire étendue à 80 % de la limite d’instance, définie sur la base d’une baseline montrant que le pic normal est à 65 %, est un signal pertinent. Une alerte à 80 % appliquée à une instance dont le pic normal est à 78 % se déclenchera chaque jour ouvré et sera ignorée en moins d’une semaine.
Une métrique mérite d’être intégrée spécifiquement à la baseline parce que sa dégradation est lente et cumulative : le taux de swaps des buffers. En conditions normales, les taux de swaps du table buffer et du program buffer sont faibles. Si la tendance du taux de swaps augmente progressivement sur plusieurs mois, le working set du buffer grandit et la taille configurée finira par devenir insuffisante. Détecter cette tendance dans les données de baseline et ajuster la configuration des buffers avant que la performance ne se dégrade correspond exactement au rôle attendu d’un monitoring proactif.
La couche applicative entre les utilisateurs et la base de données
Les métriques NetWeaver et ABAP occupent un angle mort dans de nombreux environnements SAP, car elles se situent entre deux couches bien connues. Le monitoring infrastructure et OS couvre le serveur. Le monitoring database couvre HANA. La couche NetWeaver, avec sa propre gestion mémoire, sa propre infrastructure de buffers, sa propre planification de work processes et sa propre gestion des verrous, se trouve entre les deux et est souvent supervisée avec moins de rigueur que chacune d’elles.
Les écarts qui en résultent sont prévisibles : dégradation intermittente des performances que les métriques base de données n’expliquent pas, dégradation des taux de réussite des buffers créant une charge database inutile, chaînes RFC synchrones qui sérialisent des problèmes de performance à travers plusieurs systèmes, et accumulation de short dumps signalant des problèmes de stabilité que personne n’a investigués parce que le total ne semblait jamais assez alarmant.
Aucun de ces signaux ne nécessite un outillage sophistiqué pour être détecté. Ils exigent de collecter les bonnes métriques au bon niveau et de maintenir des baselines qui rendent les écarts reconnaissables. Le moniteur de charge ABAP, ST02, ST22, SM12 et SM21 contiennent les données. La question est de savoir si elles sont lues par l’infrastructure de monitoring à une fréquence qui les rend utiles pour la détection précoce, plutôt que seulement pour les investigations après incident.
Redpeaks supervise les environnements SAP NetWeaver ABAP depuis la couche applicative jusqu’aux couches inférieures, en couvrant l’utilisation de la mémoire étendue, les taux de réussite des buffers, la décomposition du temps de réponse par composant, le temps d’attente RFC par destination et les tendances de short dumps. Sans agents, sans transports. Découvrez la couverture de monitoring NetWeaver.
