Surveillance des performances des applications SAP (APM) : au-delà des indicateurs génériques

Votre outil APM d'entreprise indique que SAP utilise 90 % des ressources du processeur. Le tableau de bord passe au rouge. Une alerte se déclenche.

Et maintenant ?

Vous ouvrez Dynatrace. Vous voyez les indicateurs de la machine virtuelle Java pour votre pile NetWeaver. Vous voyez les temps de réponse HTTP de vos applications Fiori. Vous constatez un pic dans les appels à la base de données.

Rien de tout cela ne vous explique pourquoi VA01 met 45 secondes à créer une commande client. Rien de tout cela ne vous indique quel état ABAP personnalisé consomme de la mémoire. Rien de tout cela n'explique le vidage mémoire partiel qui a provoqué le plantage de votre routine de tarification.

C'est là que réside la différence entre un outil APM générique et un véritable surveillance des performances des applications SAP. Vos outils d'entreprise détectent les symptômes, mais ne peuvent pas en diagnostiquer la cause.

Le défi particulier lié aux performances SAP

SAP fonctionne différemment des applications que vos outils APM ont été conçus pour surveiller. Son architecture, ses protocoles et son modèle d'exécution remettent en cause les principes sur lesquels reposent les approches de surveillance génériques.

Protocoles propriétaires

Les outils APM modernes excellent dans le traçage HTTP/REST. Ils instrumentent le bytecode Java et les assemblages .NET. Ils suivent les requêtes à travers les architectures de microservices.

SAP utilise des protocoles propriétaires que ces outils ne peuvent pas analyser :

Lorsqu'un utilisateur clique sur « Enregistrer » dans SAP GUI, la requête est transmise au serveur d'applications via le protocole DIAG. Les outils APM génériques ne peuvent pas suivre cette interaction. Ils détectent le trafic réseau, mais ne peuvent pas voir la transaction.

Avec état vs sans état

L'APM générique fonctionne avec des appels HTTP sans état. Chaque requête est indépendante. Chaque réponse clôt une transaction. Le traçage permet de relier les différents éléments entre les services.

SAP fonctionne différemment. Une session utilisateur dans SAP GUI conserve son état au fil de multiples interactions. Les changements d'écran, la saisie de données et les appels de fonction s'effectuent dans le cadre d'un dialogue continu. La « transaction », selon la terminologie SAP, couvre plusieurs minutes d'activité utilisateur, et non quelques millisecondes d'échange HTTP.

Les outils génériques perdent le contexte au cours de cette interaction prolongée. Ils traitent les requêtes individuellement sans saisir le contexte de la session qui les relie.

La boîte noire ABAP

Les agents APM génériques s'installent au niveau du système d'exploitation ou de la JVM. Ils instrumentent le conteneur. Ils ne peuvent pas instrumenter le runtime ABAP.

Résultat : votre tableau de bord APM indique « Le serveur d'applications SAP utilise 90 % du CPU », sans préciser quel programme, quel utilisateur ou quelle instruction SQL est à l'origine de cette charge.

Voici la « boîte noire » ABAP. Les outils génériques ne voient que l'extérieur de la boîte. La surveillance native SAP permet d'en voir l'intérieur.

Indicateurs clés pour un véritable SAP APM

Une véritable surveillance des performances des applications SAP permet de suivre des indicateurs auxquels les outils génériques n'ont pas accès. Ces indicateurs se trouvent au sein de la pile ABAP, de la base de données HANA et de l'environnement d'exécution propriétaire de SAP.

Indicateur n° 1 : temps de réponse du dialogue

Le temps de réponse des boîtes de dialogue mesure le temps que les utilisateurs doivent attendre avant que SAP ne réponde. C'est le Saint Graal de l'expérience utilisateur SAP. Tout administrateur Basis connaît les causes de ce problème :

Temps de réponse total = temps de traitement + temps de consultation de la base de données + temps d'attente + temps de réseau

Optimisation des performances SAP nécessite une visibilité sur chaque composant :

• Temps d'exécution (CPU) : Temps passé à exécuter le code ABAP
• Temps passé sur la base de données : Temps passé à attendre les requêtes HANA ou AnyDB
• Temps d'attente : Temps passé à attendre des processus de travail disponibles
• Temps de communication réseau : Temps passé en communication entre le client et le serveur

Les outils APM génériques mesurent le temps de réponse total depuis l'extérieur. La surveillance native SAP mesure chaque composant depuis l'intérieur. C'est cette différence qui détermine si vous pouvez résoudre le problème ou si vous pouvez seulement l'observer.

Un temps de réponse de 10 secondes, dont 9 secondes passées dans la base de données, indique un problème d'optimisation SQL. Le même temps de réponse de 10 secondes, dont 9 secondes de temps d'attente, indique un problème de capacité des processus de travail. Les outils génériques détectent une « réponse lente ». Les outils natifs détectent un « problème de base de données » ou un « problème de capacité ».

Indicateur n° 2 : Utilisation des processus de travail

Chaque serveur d'applications SAP exécute un nombre fixe de processus de travail. Les processus de dialogue (DIA) gèrent les interactions avec les utilisateurs. Les processus d'arrière-plan (BGD) gèrent les tâches batch. Les processus de mise à jour (UPD) gèrent les validations de la base de données.

Le taux d'utilisation des processus de travail sert d'indicateur de congestion. Lorsque tous les processus DIA sont occupés, les nouvelles requêtes sont mises en file d'attente. Les utilisateurs subissent des retards avant même que leurs transactions ne commencent à s'exécuter.

Les outils APM génériques ne suivent pas l'état des processus de travail. Ils mesurent l'utilisation du processeur et de la mémoire au niveau du système d'exploitation. Ils ne peuvent pas vous indiquer que 48 des 50 processus de dialogue sont en cours d'exécution tandis que les 2 autres sont en attente.

Cet indicateur permet d'expliquer les problèmes de performances qui semblent n'avoir aucune cause apparente. Le taux d'utilisation du processeur est de 60 %. La mémoire disponible est abondante. Pourtant, les utilisateurs se plaignent de lenteurs. Le goulot d'étranglement réside dans l'allocation des processus de travail, invisible pour les outils de surveillance classiques.

Indicateur n° 3 : Dumps courts et journaux système

Lorsqu'un code ABAP échoue, SAP génère un vidage mémoire succinct. La transaction ST22 enregistre ces vidages avec toutes les informations de contexte : le nom du programme, la ligne de code, les valeurs des variables et la pile d'appels.

Les vidages courts constituent l' une mine d'or . Ils vous indiquent exactement ce qui a échoué et pourquoi. Les outils APM génériques ne peuvent pas les lire.

De même, les journaux système SAP (SM21) et les journaux d'application (SLG1) enregistrent les événements survenant au sein de l'environnement d'exécution ABAP. Ces journaux utilisent des formats propres à SAP que les agrégateurs de journaux génériques ne sont pas en mesure d'analyser de manière pertinente.

La surveillance native SAP extrait ces journaux, les met en corrélation avec les données de performance et les affiche dans leur contexte. Lorsque le temps de réponse des boîtes de dialogue connaît un pic, vous pouvez voir les vidages de mémoire courts qui se sont produits au cours de cette même période. Les outils génériques signalent le pic. Les outils natifs en révèlent la cause.

Comparaison des outils APM : génériques vs natifs

Il ne s'agit pas d'opposer le « bon » au « mauvais ». Les outils APM génériques excellent dans ce pour quoi ils ont été conçus. La question est de savoir si cela inclut SAP.

APM générique (Dynatrace, AppDynamics, Datadog)

Points forts :

• Excellente surveillance de l'interface utilisateur Fiori (instrumentation JavaScript)
• Suivi des API HTTP/REST pour les intégrations
• Indicateurs d'infrastructure (CPU, mémoire, disque, réseau)
• Prise en charge des applications natives du cloud
• Traçage distribué des microservices

Limites de SAP :

• Impossible d'instrumenter l'exécution ABAP
• Impossible de tracer les protocoles DIAG/RFC en mode natif
• Impossible d'accéder aux indicateurs de performance des processus de travail
• Impossible de lire les fichiers de vidage court ou les journaux spécifiques à SAP
• Perte de contexte dans les sessions SAP GUI avec gestion de l'état
• Considérez SAP comme une application de type « boîte noire »

Les outils génériques fonctionnent bien en périphérie de SAP. Ils surveillent efficacement l'interface utilisateur Fiori. Ils suivent les appels API vers et depuis SAP. Ils évaluent l'état de santé de l'infrastructure.

Leur faiblesse réside dans leur cœur même. Le backend ABAP reste opaque. L'exécution effective des transactions métier reste cachée.

Surveillance native SAP (Avantra)

Points forts :

• Aperçu de l'exécution native en temps réel d'ABAP et contexte de performance
• Analyse de la mémoire HANA et performances des requêtes
• Suivi de l'utilisation des processus de travail
• Collecte et corrélation de petits fichiers de vidage
• Décomposition du temps de réponse des boîtes de dialogue
• Suivi des RFC et des IDoc
• Alertes de seuil spécifiques à SAP

Modèle de couverture :

La surveillance native détecte ce que les outils génériques ne peuvent pas voir. En contrepartie, les outils natifs sont spécifiquement axés sur SAP. Ils ne remplacent pas votre solution APM générique pour les applications non-SAP.

Le fossé en matière de traçabilité distribuée

Les outils APM modernes mettent en avant le traçage distribué comme une fonctionnalité clé. Ils suivent les requêtes d'un service à l'autre, en créant des visualisations du flux des transactions.

Certains outils génériques proposent des connecteurs SAP NetWeaver. Ces connecteurs offrent une visibilité limitée sur les composants de la pile Java de SAP. Ils permettent rarement d'effectuer le traçage approfondi « du code à la base de données » au sein de la pile ABAP propriétaire, contrairement à ce qu'ils offrent pour les applications Java standard.

La différence est importante. Dans une application Java, le traçage distribué permet de voir quelle méthode a pris du temps, quelle requête de base de données a été lente et quel appel externe a bloqué le processus. Dans SAP, via un connecteur générique, on voit simplement « SAP a répondu en X millisecondes », sans détail.

La surveillance native SAP fournit ces informations détaillées. Vous pouvez voir le programme ABAP, l'instruction SQL spécifique, l'état du processus de travail et l'allocation de mémoire. Ce niveau de détail permet un dépannage que les outils génériques ne peuvent pas prendre en charge.

Gestion proactive de la performance

La surveillance réactive vous indique ce qui est tombé en panne. La surveillance proactive vous indique ce qui va tomber en panne.

Planification prévisionnelle des capacités

La baisse des performances SAP suit souvent des schémas prévisibles. L'augmentation de la taille des tables entraîne un ralentissement des requêtes. La consommation de mémoire augmente progressivement. Les conflits entre processus de travail s'intensifient à mesure que la charge des utilisateurs augmente.

L'analyse prédictive appliquée à des indicateurs spécifiques à SAP permet de planifier les capacités avant que des problèmes ne surviennent :

• Tendances de croissance des tables : Identifier les tables qui approchent des seuils de taille
• Tendances en matière de consommation de mémoire : Prévoir quand la mémoire HANA devra être étendue
• Tendances en matière d'utilisation des processus de travail : Prévoir quand la capacité actuelle deviendra insuffisante
• Courbes de dégradation du temps de réponse : Détectez les ralentissements progressifs avant que les utilisateurs ne s'en aperçoivent

Les outils APM génériques offrent des fonctionnalités prédictives pour les indicateurs d'infrastructure. Ils permettent de prévoir l'épuisement de l'espace disque et les limites de capacité du processeur. Ils ne peuvent toutefois pas détecter les goulots d'étranglement spécifiques à SAP, car ils n'ont pas accès aux indicateurs propres à SAP.

Comparaison des valeurs de référence

L'analyse des performances doit être replacée dans son contexte. Un temps de réponse de 5 secondes peut être normal pour un calcul de prix complexe, mais catastrophique pour une simple recherche d'article.

La surveillance native SAP établit des valeurs de référence pour des transactions spécifiques. Les tableaux de bord de performance comparent les performances actuelles aux tendances historiques. Les anomalies apparaissent automatiquement.

Les outils génériques fournissent des indicateurs agrégés de base. Ils indiquent par exemple que « le temps de réponse SAP était en moyenne de 2 secondes le mois dernier ». Les outils natifs précisent quant à eux que « VA01 a pris en moyenne 1,2 seconde, VA02 0,8 seconde et ZMM_CUSTOM_REPORT 15 secondes ». Ce niveau de détail permet d'effectuer des comparaisons pertinentes.

Mise en œuvre : stratégie de surveillance à plusieurs niveaux

La réponse n'est pas « remplacer l'APM générique par une surveillance native SAP ». La réponse réside dans une surveillance à plusieurs niveaux qui utilise l'outil adapté à chaque niveau.

Couche 1 : Infrastructure (APM générique)

Votre solution APM d'entreprise actuelle gère efficacement la surveillance de l'infrastructure. Continuez à l'utiliser pour :

• Indicateurs relatifs au processeur, à la mémoire et au disque dur du serveur
• Connectivité réseau et latence
• État de santé de l'hyperviseur/de la plateforme cloud
• Orchestration des conteneurs (le cas échéant)

Couche 2 : Peripherie d'intégration (APM générique + natif)

L'interface entre SAP et les systèmes externes tire parti des deux approches :

• L'APM générique surveille les performances de la passerelle API
• La surveillance native assure le suivi du traitement des RFC et des IDoc
• La corrélation permet d'identifier l'origine des problèmes

Couche 3 : Noyau de l'application SAP (surveillance native)

La pile ABAP et la base de données HANA nécessitent une surveillance native :

• Décomposition du temps de réponse des boîtes de dialogue
• Suivi de l'utilisation des processus de travail
• Collecte et analyse de petits fichiers de vidage
• Performances de la mémoire et des requêtes HANA
• Suivi des tâches par lots et suivi des accords de niveau de service (SLA)

Surveillance hybride Les architectures de surveillance hybrides qui combinent plusieurs couches offrent une visibilité complète. Les outils génériques gèrent ce qu'ils font bien. Les outils natifs gèrent ce que les outils génériques ne peuvent pas voir.

Conclusion : Rapidité = Productivité

Les performances de SAP ont un impact direct sur la productivité de l'entreprise. Lorsque les transactions sont lentes, les utilisateurs doivent patienter. Lorsque les tâches par lots prennent du retard, les processus sont bloqués. Lorsque les intégrations échouent, le flux de données s'interrompt.

Les outils APM génériques n'offrent qu'une vision partielle. Ils observent SAP de l'extérieur. Ils mesurent les symptômes sans en diagnostiquer les causes. Ils signalent les problèmes sans permettre de les résoudre.

Une véritable surveillance des performances des applications SAP permet d'analyser en profondeur l'environnement d'exécution ABAP. Elle suit les processus de travail, les éléments constitutifs du temps de réponse, les mini-dumps et les requêtes HANA. Elle fournit à votre équipe les données nécessaires pour identifier les causes profondes et mettre en œuvre des solutions.

Il n'est pas possible d'analyser un vidage ABAP à l'aide d'un outil Java. Vous devez disposer d'un environnement SAP natif.

Il ne s'agit pas de choisir entre l'un ou l'autre. Conservez votre solution APM d'entreprise pour ce qu'elle fait bien. Ajoutez-y une surveillance SAP native pour ce qu'elle ne peut pas faire. Cette combinaison vous offre la visibilité dont votre environnement SAP a besoin.

4. Foire aux questions

Q : Pourquoi les outils APM génériques ne fonctionnent-ils pas avec SAP ?

R : Les outils APM génériques sont conçus pour les applications Web sans état utilisant les protocoles HTTP/REST. SAP utilise des protocoles propriétaires (DIAG, RFC, IDoc) et gère des sessions utilisateur avec état. Les agents génériques s’installent au niveau du système d’exploitation ou de la JVM et ne peuvent pas instrumenter l’environnement d’exécution ABAP, ce qui fait de l’application SAP principale une « boîte noire ».

Q : Qu'est-ce que le temps de réponse des boîtes de dialogue dans SAP ?

R : Le temps de réponse des dialogues mesure le temps que les utilisateurs doivent attendre avant que SAP ne réagisse à leurs actions. Il se décompose en temps de traitement (CPU), temps de base de données (requêtes), temps d'attente (disponibilité des processus de travail) et temps de réseau. Cette décomposition est essentielle pour diagnostiquer les problèmes de performances. Les outils APM génériques ne voient que le total ; les outils natifs voient chaque composante.

Q : Qu'est-ce qu'un processus de travail et en quoi est-ce important pour la performance ?

R : Les processus de travail sont des ressources fixes sur les serveurs d'application SAP qui gèrent les interactions utilisateur (DIA), les tâches batch (BGD) et les mises à jour de la base de données (UPD). Lorsque tous les processus de travail disponibles sont occupés, les nouvelles requêtes sont mises en file d'attente. L'utilisation des processus de travail est souvent la cause cachée de problèmes de performances que les outils génériques ne parviennent pas à détecter.

Q : Dynatrace ou AppDynamics permettent-ils de surveiller efficacement SAP ?

R : Ces outils surveillent efficacement l'interface utilisateur Fiori de SAP et les composants de la pile Java. En revanche, ils peinent à gérer le backend ABAP, qui constitue le cœur de la logique métier dans la plupart des environnements SAP. Ils ne peuvent pas accéder aux indicateurs des processus de travail, aux vidages de mémoire courts ni aux détails d'exécution ABAP. Ils offrent une visibilité « en périphérie » sans couvrir le « cœur » du système.

Q : Dois-je remplacer mon solution APM d'entreprise par la surveillance native de SAP ?

R : Non. L'approche recommandée est une surveillance à plusieurs niveaux. Utilisez une solution APM d'entreprise pour les indicateurs d'infrastructure, l'état de santé de la plateforme cloud et les applications non SAP. Ajoutez-y une surveillance native SAP pour la visibilité sur l'exécution ABAP, les performances HANA et les indicateurs spécifiques à SAP. Cette combinaison offre une visibilité complète.

Q : Que sont les « short dumps » et pourquoi les outils génériques ne les détectent-ils pas ?

R : Les « short dumps » sont des rapports d'erreur détaillés générés lorsque le code ABAP rencontre une défaillance. Ils contiennent le nom du programme, la ligne de code, les valeurs des variables et la pile d'appels au moment de la défaillance. Ils sont stockés dans un format propre à SAP (accessible via ST22) que les agrégateurs de journaux génériques ne peuvent pas analyser. La surveillance native de SAP les extrait et les met en corrélation automatiquement.