Un pool de work processes de dialogue SAP est une ressource fixe. Le nombre de work processes de dialogue sur une instance de serveur d’applications est configuré lors de l’installation et ne change pas pendant l’exploitation. Lorsqu’ils sont tous occupés, la requête utilisateur suivante ne reçoit pas un thread issu d’un pool dynamique ni un processus nouvellement créé : elle attend. Elle reste dans une file d’attente jusqu’à ce que l’un des work processes occupés termine sa tâche en cours et redevienne disponible.
C’est ce fait architectural qui rend la supervision des work processes différente de la plupart des autres formes de monitoring de performance SAP. La pression mémoire dégrade les performances progressivement. La contention de base de données ralentit certaines requêtes individuellement. La saturation des work processes crée une file d’attente qui grossit, et les files d’attente proches d’une capacité fixe ne progressent pas de manière linéaire. À 70 % d’utilisation, les temps d’attente restent maîtrisables. À 85 %, ils deviennent perceptibles. À 95 %, le système est pratiquement indisponible pour les nouvelles requêtes, même si chaque work process est techniquement en cours d’exécution.
Cet article explique comment superviser les work processes pour détecter la saturation avant qu’elle n’atteigne les utilisateurs, ce que font réellement les différents types de work processes et pourquoi ils échouent différemment, ce que SM50 et SM66 montrent vraiment, ce que la plupart des équipes ne lisent pas correctement, et ce que le monitoring continu doit observer au-delà des vues instantanées fournies par ces transactions.
Comment fonctionnent réellement les work processes, et pourquoi le pool fixe est important ?
L’architecture derrière le goulot d’étranglement
Chaque instance de serveur d’applications SAP NetWeaver ABAP dispose d’un ensemble fixe de work processes répartis par type : dialogue (DIA), arrière-plan (BTC), mise à jour (UPD et UPD2), enqueue (ENQ), spool (SPO) et message (MSG). La configuration se trouve dans le profil d’instance. La modifier nécessite un redémarrage.
Les work processes de dialogue traitent les transactions interactives des utilisateurs. Lorsqu’un utilisateur appuie sur Entrée dans un écran de transaction, il occupe un work process de dialogue pendant la durée de l’étape de traitement de cet écran, le libère lorsque l’écran est renvoyé, puis en occupe un à nouveau pour l’étape suivante. Chaque interaction individuelle se mesure généralement en millisecondes ou en secondes. Le work process n’est pas conservé entre deux écrans.
Cette conception permet au système de servir beaucoup plus d’utilisateurs qu’il ne possède de work processes, tant que les interactions restent courtes. Un système avec 20 work processes de dialogue peut servir confortablement 200 utilisateurs simultanés si l’étape de dialogue moyenne dure 0,1 seconde. Le même système aura du mal avec 50 utilisateurs si un programme conserve un work process de dialogue pendant 90 secondes lors d’une requête de base de données longue.
L’implication pour le monitoring est que la condition dangereuse n’est pas le nombre d’utilisateurs. C’est le taux d’occupation du pool de work processes combiné à la durée des étapes individuelles. Un système dont 90 % des work processes de dialogue sont utilisés dispose de très peu de marge avant que les nouvelles requêtes ne commencent à s’accumuler en file d’attente. Et une file d’attente qui se forme pendant une période de pic, même brièvement, donne aux utilisateurs l’impression que le système ne répond plus.
Ce que les utilisateurs ressentent quand le pool est plein
Du point de vue de l’utilisateur, la saturation des work processes ressemble exactement à une base de données lente ou à un réseau lent. L’écran se fige. Le sablier tourne. Rien ne se passe. L’utilisateur ne voit pas si sa requête est traitée lentement ou si elle attend simplement d’être traitée.
C’est pourquoi les goulots d’étranglement liés aux work processes sont souvent mal diagnostiqués. L’utilisateur signale que le système est lent. L’ingénieur Basis vérifie le CPU et la mémoire, ne trouve rien d’inhabituel, puis clôt le ticket comme résolu. La cause réelle, une saturation temporaire du pool de work processes de dialogue pendant une fenêtre précise de 10 minutes, n’a laissé aucune trace dans les métriques qui ont été consultées.
Pour la détecter, il faut un monitoring qui enregistre l’occupation des work processes dans le temps, et pas seulement l’état actuel. Un système dont les work processes de dialogue sont utilisés à 95 % pendant 10 minutes tous les jours à 09:15 présente un vrai problème opérationnel. Ce problème reste invisible pour toute personne qui ouvre SM50 à 09:30 et voit une répartition de charge saine.
Les types de work processes à superviser différemment
Work processes de dialogue : là où se joue l’expérience utilisateur
L’occupation des work processes de dialogue est la métrique la plus directement liée à la performance visible par les utilisateurs. Lorsqu’elle atteint des niveaux soutenus au-dessus de 80 %, les nouvelles requêtes entrent en file d’attente. Le temps de réponse ressenti par les utilisateurs ne reflète plus seulement le temps de traitement réel, mais le temps d’attente dans la file plus le temps de traitement, ce qui peut être plusieurs fois plus élevé.
Les deux modèles qui provoquent le plus souvent une saturation des work processes de dialogue ne sont pas forcément ceux qui paraissent spectaculaires dans SM50. Le premier correspond à un grand nombre d’utilisateurs exécutant des transactions normalement rapides pendant une fenêtre de pic, lorsque la charge cumulée dépasse la capacité du pool. Le second correspond à un petit nombre d’utilisateurs exécutant des transactions avec des étapes de dialogue anormalement longues : un rapport ABAP personnalisé qui effectue un scan complet d’une table, une détermination de prix qui appelle un service externe de manière synchrone, ou un contrôle d’autorisation qui interroge un profil surdimensionné.
Ces deux modèles produisent le même symptôme du point de vue de l’utilisateur. Ils ont pourtant des causes racines et des remédiations différentes. Le monitoring doit les distinguer. Une forte occupation des work processes de dialogue avec des temps de réponse par étape normaux indique un problème de capacité : trop d’utilisateurs pour la taille du pool. Une forte occupation des work processes de dialogue avec des temps de réponse par étape élevés indique un problème de performance applicative : quelque chose conserve les work processes plus longtemps qu’il ne le devrait.
Work processes d’arrière-plan : une concurrence invisible
Les work processes d’arrière-plan exécutent les jobs batch. Ils sont séparés des work processes de dialogue dans la configuration, mais ils fonctionnent sur le même serveur d’applications et consomment les mêmes ressources CPU, mémoire et capacité de connexion à la base de données. Un job batch exécuté sur un serveur d’applications qui sert également des utilisateurs en dialogue crée une concurrence de ressources que les utilisateurs ressentent sans en voir la cause.
Le problème spécifique est la collision de planification des jobs : plusieurs gros jobs batch planifiés au même moment, ou un job batch dont la durée d’exécution a augmenté avec le temps et chevauche désormais la fenêtre de pic du matin qu’il terminait auparavant avant d’atteindre. Les jobs batch n’échouent pas. Les temps de réponse en dialogue augmentent. Les deux événements semblent sans lien jusqu’à ce qu’on les corrèle sur une chronologie.
L’utilisation des work processes d’arrière-plan mérite sa propre piste de monitoring, séparée du dialogue. Une utilisation soutenue des work processes d’arrière-plan au-dessus de 90 % pendant les heures ouvrées est un problème de planification. Cela signifie que le planning batch consomme l’intégralité du pool de work processes d’arrière-plan pendant une période où les jobs qui terminent tard ou s’allongent n’auront nulle part où démarrer, et où la concurrence avec le dialogue est à son niveau le plus élevé.
Work processes de mise à jour : la file que personne ne regarde jusqu’à ce qu’elle casse
Les work processes de mise à jour gèrent les mises à jour asynchrones de la base de données. Lorsqu’un utilisateur enregistre une transaction dans SAP, l’étape de dialogue se termine et la mise à jour réelle de la base de données est transmise à un work process de mise à jour. L’utilisateur voit immédiatement la confirmation. L’écriture physique intervient peu après, en arrière-plan.
Cette conception améliore le temps de réponse en dialogue en découplant l’interaction visible par l’utilisateur de l’écriture en base de données. La conséquence est qu’un problème de work process de mise à jour ne produit pas immédiatement une erreur visible par l’utilisateur. L’utilisateur a enregistré avec succès. La mise à jour est en file d’attente. Si les work processes de mise à jour sont saturés ou si une tâche de mise à jour se termine avec une erreur, la mise à jour en attente reste dans la file SM13 comme requête échouée. Les données que l’utilisateur pense avoir enregistrées n’ont pas réellement été écrites dans la base de données.
Surveiller SM13 pour détecter les requêtes de mise à jour échouées est une exigence de monitoring souvent oubliée, car les échecs de mise à jour sont rares dans les systèmes stables. Lorsqu’ils surviennent, ils sont critiques : un document métier que l’utilisateur a confirmé comme enregistré n’existe pas dans la base de données. L’utilisateur a peut-être déjà agi en supposant que l’enregistrement avait réussi. Plus le délai entre l’échec et sa découverte est long, plus la remédiation devient complexe.
Un état supplémentaire mérite d’être surveillé séparément : si le service de mise à jour lui-même est désactivé, intentionnellement ou accidentellement, toutes les mises à jour en attente s’accumulent indéfiniment dans la file. Le système continue d’accepter les enregistrements des utilisateurs et de les confirmer. Rien n’est écrit dans la base de données. Cet état est détectable via le statut du système de mise à jour dans SM13 et doit être supervisé avec une alerte critique, pas avec un simple contrôle de routine.
Attention : un service de mise à jour désactivé est l’un des états opérationnels SAP les plus graves et l’un des plus faciles à manquer sans monitoring dédié. Il peut être désactivé par une action administrative dans SM13, via l’option “Deactivate update”, et rester parfois dans cet état après une phase de dépannage. Il n’y a aucune indication visible pour l’utilisateur. Les transactions de dialogue confirment normalement les enregistrements. La file SM13 grossit silencieusement.
Work processes enqueue : un processus, une table de verrouillage
Le work process enqueue gère la table de verrous au niveau SAP, qui contrôle l’accès concurrent aux objets métier dans tout le système. Il existe par défaut un work process enqueue par instance SAP. Dans un paysage multi-instance sans Enqueue Replication Server (ERS) configuré, il existe en pratique un seul work process enqueue pour l’ensemble du système.
Le monitoring enqueue comporte deux dimensions. La première est la disponibilité du work process enqueue : s’il se termine, la gestion des verrous s’arrête, et toute transaction nécessitant un verrou ne peut pas se poursuivre. La seconde est la table de verrous elle-même, surveillée dans SM12. Une table de verrous où les entrées s’accumulent, en particulier des entrées détenues par des programmes en cours depuis longtemps, indique une contention de verrou. Les utilisateurs qui tentent d’accéder aux mêmes objets que les enregistrements verrouillés devront attendre. Dans les environnements à forte concurrence, un petit nombre de verrous conservés longtemps peut créer une condition d’attente en cascade, visible sous forme de lenteur générale en dialogue.
Les entrées SM12 qui persistent plus de quelques minutes dans un système OLTP de production méritent une investigation. Elles sont soit détenues par un job batch long, ce qui peut être un comportement correct, soit par une session utilisateur qui a lancé une transaction, verrouillé des enregistrements, puis n’a pas terminé ni annulé l’opération, ce qui constitue un problème opérationnel à résoudre.
Lire SM50 et SM66 pour ce qu’ils montrent vraiment
Les statuts qui comptent et ceux qui prêtent à confusion
SM50 affiche la table des work processes pour l’instance locale du serveur d’applications. SM66 affiche la même vue sur toutes les instances du système, ce qui en fait l’outil à utiliser pour toute investigation systémique. Les deux affichent les mêmes informations de statut.
La colonne de statut dans la table des work processes montre ce que chaque processus fait actuellement. “Waiting” signifie que le work process est inactif et disponible pour de nouvelles requêtes. “Running” signifie qu’il exécute activement une tâche. “Stopped” et “Ended” indiquent des processus terminés qui nécessitent une investigation et peuvent devoir être redémarrés via le gestionnaire de work processes.
Le statut qui génère le plus de confusion est “On hold” ou “PRIV”. Un work process en mode PRIV est conservé par la roll area d’un utilisateur spécifique, ce qui signifie que le contexte de session de l’utilisateur réside dans la mémoire de ce work process. Dans les anciens systèmes SAP et certains types de transactions, cela signifiait que le work process était exclusivement réservé à cet utilisateur jusqu’à la fin de la session. Dans les systèmes modernes, le comportement est plus nuancé, mais un work process bloqué en PRIV pendant une période prolongée représente toujours une réduction de capacité.
Ce qu’il faut observer dans SM66 pendant une investigation n’est pas seulement le statut individuel des work processes, mais le ratio : combien de work processes de dialogue sont simultanément en statut “Running”, et que sont-ils en train d’exécuter ? Un système sain en période de pic peut avoir 60 à 70 % de ses work processes de dialogue en cours d’exécution à un moment donné. Un système à 95 % avec plusieurs processus exécutant le même code transaction correspond à un système où un programme précis provoque un goulot d’étranglement.
L’étape de dialogue longue : quand investiguer et quand agir
Chaque ligne dans SM50 et SM66 affiche le temps écoulé pour l’action en cours dans la colonne “Time”. Pour les work processes de dialogue, il s’agit du temps écoulé depuis le début de l’étape de dialogue en cours. Une étape de dialogue qui tourne depuis 45 secondes est anormale. Une étape qui tourne depuis 8 minutes sans se terminer est un problème actif : elle consomme un work process qui ne peut pas servir d’autres utilisateurs.
Les informations immédiatement disponibles dans la vue des work processes sont le mandant, l’utilisateur, le code transaction, le nom du programme et le type d’action, par exemple sequential read, direct read ou insert. Cela suffit pour identifier ce qui s’exécute et qui l’a lancé. La décision de tuer ou non le work process dépend de ce qu’il fait : un rapport personnalisé lancé par erreur en production par un développeur contre une grande table peut être immédiatement terminé. Une tâche de mise à jour qui écrit un important mouvement de marchandises doit être laissée jusqu’à son terme.
La colonne “Time” dans SM50 n’enregistre pas l’historique. Elle montre seulement le temps écoulé actuel. Un work process qui a tourné pendant 12 minutes et vient de se terminer apparaît à 0 seconde l’instant suivant. C’est pourquoi SM50 et SM66 sont des outils de diagnostic pour les incidents actifs, pas des instruments de monitoring. Ils montrent ce qui se passe maintenant. Ils ne peuvent pas dire ce qui s’est passé à 09:15 ce matin.
À quoi ressemble une instance saturée avant que les utilisateurs appellent ?
En pratique, la saturation des work processes de dialogue suit un modèle reconnaissable dans SM66 dans les 2 à 5 minutes qui précèdent les premiers signalements utilisateurs. Presque tous les work processes de dialogue affichent simultanément le statut “Running”. Plusieurs d’entre eux affichent des temps écoulés supérieurs à 10 secondes. Les codes transaction visibles dans la liste sont concentrés sur un petit nombre de programmes. Le compteur de file d’attente dans la vue d’ensemble des work processes commence à augmenter.
La difficulté est que ce modèle suppose que quelqu’un regarde SM66 en temps réel, ce qui n’est pas soutenable. L’équivalent en monitoring est une collecte continue de l’occupation des work processes de dialogue, avec une alerte qui se déclenche lorsque l’occupation soutenue dépasse un seuil, et non lorsqu’elle connaît un pic momentané. Un pic à 95 % d’occupation qui dure 30 secondes pendant une étape de traitement d’écran n’est pas la même situation qu’une occupation de 90 % maintenue pendant une fenêtre de 10 minutes.
Les métriques à superviser en continu, pas seulement quand quelque chose casse
Taux d’utilisation par type de work process et par fenêtre temporelle
La métrique de base pour chaque type de work process est le taux d’utilisation : le pourcentage de work processes de ce type en usage actif à un instant donné, exprimé sous forme de tendance dans le temps plutôt que comme une lecture ponctuelle. Une plateforme de monitoring doit l’enregistrer à des intervalles inférieurs à la minute afin de capturer les épisodes courts de saturation qui resteraient autrement invisibles.
Seuils d’alerte utiles pour démarrer : une utilisation des work processes de dialogue au-dessus de 80 % pendant plus de 3 minutes déclenche un avertissement. Au-dessus de 90 % pendant plus de 1 minute, elle déclenche une alerte critique. Une utilisation des work processes d’arrière-plan au-dessus de 85 % pendant les heures ouvrées déclenche un avertissement. Une utilisation des work processes de mise à jour au-dessus de 70 % pendant plus de 5 minutes déclenche un avertissement, car les goulots d’étranglement de débit sur les mises à jour, contrairement aux goulots d’étranglement de dialogue, ne produisent pas de symptômes immédiatement visibles par les utilisateurs, mais créent un risque croissant dans la file de mise à jour.
Ces seuils sont des points de départ. Les bonnes valeurs dépendent de la taille du pool de work processes et du profil de charge normal. Une instance avec 40 work processes de dialogue dispose de plus de marge à 85 % d’utilisation qu’une instance avec 10. Calibrer les seuils selon le profil d’instance spécifique, plutôt qu’appliquer des pourcentages génériques, fait la différence entre des alertes actionnables et des alertes qui génèrent du bruit.
Décomposition du temps de réponse : où part le temps ?
Le temps de réponse en dialogue dans SAP est la somme de plusieurs composants : le temps d’attente d’un work process, c’est-à-dire le temps pendant lequel la requête a attendu qu’un work process soit disponible, le temps de traitement, c’est-à-dire l’exécution ABAP réelle, le temps base de données, c’est-à-dire l’exécution des requêtes, le roll time, c’est-à-dire les changements de contexte, et le temps réseau, c’est-à-dire l’envoi de la réponse au navigateur ou au client GUI.
La plupart des rapports de monitoring du temps de réponse en dialogue affichent le temps de réponse total. C’est utile pour suivre les tendances, mais insuffisant pour diagnostiquer la cause lorsque les temps de réponse augmentent. Une augmentation causée par l’attente d’un work process nécessite une réponse différente d’une augmentation causée par une requête de base de données lente. La première indique un problème de capacité ou de planification. La seconde indique un problème de programme ou d’index.
Un monitoring qui décompose le temps de réponse par composant et déclenche des alertes sur les anomalies de composants spécifiques, plutôt que seulement sur le total, fournit la précision diagnostique dont l’équipe d’exploitation a besoin pour agir correctement lorsqu’un changement survient. Une augmentation du temps de réponse total de 1,2 seconde à 3,4 secondes, avec l’augmentation concentrée dans le composant “wait for work process”, est sans ambiguïté : le pool de work processes était le goulot d’étranglement à ce moment-là.
La file de mise à jour : SM13 et ce que signifie l’accumulation
SM13 montre l’état de la file des requêtes de mise à jour. Dans un système sain, cette file est courte et se vide rapidement. Les requêtes de mise à jour sont créées par les enregistrements utilisateurs et consommées par les work processes de mise à jour en quelques secondes ou minutes. La file peut grossir brièvement pendant une période de pic, lorsque de nombreux utilisateurs enregistrent simultanément. Elle ne doit pas s’accumuler de façon persistante.
Trois états dans SM13 méritent une attention de monitoring spécifique. Les requêtes de mise à jour échouées, ou les entrées avec statut d’erreur, représentent des transactions enregistrées dont les écritures en base de données n’ont pas abouti. Elles nécessitent une revue manuelle, puis soit une relance manuelle, soit une annulation après résolution de la cause racine. Relancer automatiquement des mises à jour échouées sans comprendre l’échec initial peut aggraver le problème. Un nombre d’entrées qui augmente sans erreur, mais avec des entrées qui ne vieillissent pas correctement, indique que le débit des work processes de mise à jour est insuffisant pour le volume actuel d’enregistrements : la file est traitée, mais pas assez vite. Enfin, un nombre d’entrées statique, qui ne diminue pas, combiné à un service de mise à jour désactivé, correspond à l’état critique décrit plus haut et nécessite une escalade immédiate.
Les modèles qui prédisent la saturation avant qu’elle ne se produise
Le profil de charge qui masque le goulot d’étranglement
Les métriques moyennes sont de mauvais indicateurs de saturation des work processes. Un système qui affiche 45 % d’utilisation moyenne des work processes de dialogue sur la journée ouvrée semble sain. Cette moyenne peut pourtant être composée de 15 % d’utilisation pendant les heures du matin et d’un pic récurrent à 95 % de 12:00 à 12:20, lorsqu’un job de reporting s’exécute en même temps que le pic de charge utilisateur de la pause déjeuner.
La moyenne ne révèle pas le pic. Le pic est l’endroit où les utilisateurs ressentent les problèmes. Un monitoring qui travaille avec des moyennes à 5 minutes peut lisser entièrement ce pic. La fenêtre précise de 20 minutes pendant laquelle le système est réellement saturé apparaît simplement comme une hausse modérée dans la moyenne quotidienne.
Une supervision efficace des work processes utilise des intervalles de collecte courts, de 30 secondes à 1 minute, et conserve les données brutes de série temporelle, pas seulement des moyennes agrégées. L’objectif est de pouvoir reconstruire exactement l’état du pool de work processes pendant n’importe quelle fenêtre de 5 minutes sur les 30 derniers jours, afin de corréler une lenteur signalée par les utilisateurs à un état système réel plutôt qu’à une estimation basée sur des moyennes.
Concurrence entre arrière-plan et dialogue pendant les heures de pic
Le modèle de saturation des work processes le plus prévisible dans de nombreux environnements SAP est le chevauchement entre la durée d’exécution des jobs batch et le pic de charge utilisateur. Un job d’arrière-plan qui démarre normalement à 06:00 et se termine à 08:30 ne pose pas de problème lorsque la charge utilisateur commence à 08:00. Si ce même job commence à prendre 3 heures parce que le volume de données a augmenté au fil de l’année, il s’exécute désormais pendant la fenêtre de pic de 08:00 à 09:00, consomme des work processes d’arrière-plan et concurrence les utilisateurs de dialogue pour le CPU.
Ce modèle se développe généralement progressivement et n’est souvent remarqué que lorsque les utilisateurs commencent à signaler des lenteurs matinales qui n’existaient pas six mois plus tôt. Surveiller les temps de fin des jobs par rapport à leurs durées de référence, puis corréler les fenêtres d’exécution des jobs avec les tendances de temps de réponse en dialogue, permet de détecter ce chevauchement avant qu’il ne devienne assez sévère pour générer des plaintes utilisateurs.
L’alerte spécifique à configurer : signaler tout job d’arrière-plan qui est encore en cours à un moment où son historique indique qu’il devrait être terminé depuis plus de 30 minutes. Pas parce que le job échoue, mais parce que l’allongement de son temps d’exécution crée une concurrence de ressources dans une fenêtre qu’il était censé éviter.
En pratique : la distribution des work processes sur plusieurs instances de serveur d’applications n’élimine pas le risque de saturation. Elle le répartit. Une charge utilisateur mal distribuée, ou une configuration de groupe de connexion qui route la majorité des utilisateurs vers une seule instance, peut créer une saturation sur une instance alors que les autres sont sous-utilisées. SM66 montre la vue inter-instances, mais la logique d’alerte doit évaluer chaque instance indépendamment, et pas seulement la moyenne globale du système.
Construire une supervision des work processes qui détecte les problèmes tôt
L’exigence pratique pour la supervision des work processes est une collecte continue de données à intervalles courts, stockée sous forme de séries temporelles plutôt que de snapshots. La plupart des environnements SAP s’appuient sur SM50 et SM66 comme outils de diagnostic réactifs, un rôle pour lequel ils sont adaptés. Ils ne remplacent pas un monitoring qui enregistre l’état des work processes dans le temps.
Les métriques à collecter par instance de serveur d’applications, par type de work process, toutes les 30 à 60 secondes sont : le nombre de work processes dans chaque statut, running, waiting, stopped, le taux d’utilisation actuel, et, pour les work processes individuels qui affichent des durées d’exécution anormalement longues, le nom du programme et le temps écoulé. Ces données, conservées pendant au moins 30 jours, constituent la base pour corréler les incidents signalés par les utilisateurs avec l’état réel du système.
La configuration des alertes doit distinguer les types de work processes au lieu d’appliquer un seul seuil à tous. L’utilisation des work processes de dialogue nécessite des seuils plus bas et une escalade plus rapide, car son impact sur les utilisateurs est immédiat. L’utilisation des work processes d’arrière-plan peut tolérer des niveaux soutenus plus élevés pendant les fenêtres batch planifiées. Les alertes sur les work processes de mise à jour doivent se concentrer sur l’accumulation de file et le nombre d’échecs plutôt que sur l’utilisation, car les échecs de mise à jour ont un mode de défaillance différent de la saturation du dialogue ou de l’arrière-plan.
Les deux capacités de monitoring qui apportent le plus de valeur diagnostique au-delà de l’alerte de base sont la décomposition du temps de réponse et la corrélation entre les métriques de work processes et les données de planification des jobs. La décomposition du temps de réponse identifie si une lenteur est liée aux work processes ou à la base de données, sans nécessiter d’investigation manuelle. La corrélation avec la planification des jobs identifie les conflits de ressources entre batch et dialogue avant qu’ils n’aient un impact visible sur les utilisateurs.
Aucune de ces capacités ne nécessite une implémentation complexe. Elles nécessitent une plateforme de monitoring qui collecte les bonnes données à la bonne granularité et les présente dans une vue qui n’oblige pas l’équipe d’exploitation à reconstruire la situation à partir de plusieurs écrans de transaction séparés pendant un incident actif.
Le pool fixe est aussi un pool prévisible
La saturation des work processes est l’un des modes de défaillance les plus prévisibles dans les opérations SAP, précisément parce que la ressource est fixe et que les modèles de demande sont généralement réguliers. Un système qui sature à 09:15 chaque lundi le fera à nouveau le lundi suivant si rien ne change. Le job batch qui chevauche désormais le pic de charge utilisateur continuera à le faire à mesure que sa durée d’exécution augmente.
Ce ne sont pas des surprises. Ce sont des tendances, et les tendances sont visibles dans les données de monitoring avant de devenir des incidents. L’équipe d’exploitation qui examine chaque semaine les tendances d’utilisation des work processes, en les croisant avec les changements de planning batch et la croissance du volume utilisateur, est celle qui propose une augmentation du nombre de work processes ou un ajustement de planning avant que les utilisateurs ne signalent un problème, pas après.
Détecter un goulot d’étranglement de work processes avant que les utilisateurs ne le ressentent n’est pas une question d’outillage plus complexe. C’est une question de bonnes données, à la bonne granularité, et de discipline pour observer les tendances plutôt que de vérifier uniquement l’état actuel lorsqu’un utilisateur appelle.
Redpeaks collecte les métriques de work processes SAP au niveau instance toutes les 30 secondes, avec des tendances d’utilisation par type, une décomposition du temps de réponse et une corrélation avec l’activité des jobs batch. Les alertes sont configurables par instance et par type de work process. Découvrez la couverture de monitoring des work processes.
