Read this article in English 
Votre Guide Pratique pour le Monitoring de SAP BusinessObjects
Depuis que je travaille avec SAP BusinessObjects, j’ai toujours trouvé que le monitoring était compliqué à mettre en place dans la plateforme.
Ces dernières années, SAP a fait des efforts et a fourni des fonctionnalités de surveillance dans la console centrale de gestion (CMC). Cependant, l’installation et la configuration ne sont pas aussi simples que ce que j’aurais souhaité. La charge sur le système est également assez élevée en raison de l’utilisation d’un Adaptive Processing Server (APS) dédié.
La surveillance est donc souvent désactivée pour minimiser l’impact sur les systèmes déjà fortement sollicités et n’est activée qu’en cas de besoin.
Pourtant il est important de comprendre le fonctionnement du système SAP BusinessObjects pour en assurer la stabilité et les performances. Être capable de collecter et de surveiller dans le temps les mesures clés de l’utilisation de l’ensemble du système SAP BusinessObjects, y compris les systèmes sous-jacents, est essentiel pour y parvenir.
Ainsi, des décisions fondées sur des données peuvent être prises pour garantir une performance optimale du système, par exemple des données liées à l’utilisation, l’analyse des tendances, la charge de travail et la stabilité.
Le suivi est également utile pour faire la bonne proposition lors d’une mise à niveau ou d’une migration. L’élaboration d’une analyse de rentabilité pour justifier l’acquisition de matériel physique ou d’une plateforme de virtualisation est un autre exemple où les données liées à la surveillance sont fondamentales.
Les capacités de surveillance sont standard dans 360Suite depuis la sortie de 360Live il y a quelques années. Nos développeurs ont décidé de garder une longueur d’avance et d’utiliser HMTL5 au lieu d’Adobe Flash, un logiciel gourmand en ressources, dont le support prendra fin le 31 décembre 2020. NB: Patcher vers BI 4.2 SP08 ou BI 4.3 permet de corriger ce problème.
Comme toutes les offres de 360Suite, l’automatisation du processus de contrôle est au cœur de l’application. La solution peut générer des notifications lorsque les seuils critiques sont atteints, et peut déclencher des actions en réponse.
La solution n’a pas besoin d’être installée sur l’environnement SAP BusinessObjects qu’elle surveille. Elle peut être installée sur son propre serveur et elle communique avec SAP BusinessObjects via son SDK.
Monitoring De SAP BusinessObjects – Checklist De Démarrage
Les étapes ci-dessous présentent un workflow qui fonctionnerait pour la plupart des déploiements.
1. Installer 360Live
Installez le package complet qui contient un Tomcat et une machine virtuelle Java, un PostgreSQL et 360Live. Un assistant vous guide tout au long du processus d’installation. Il est important que vous puissiez accéder aux bibliothèques du SDK SAP BusinessObjects (soit à partir d’une installation complète de SAP BusinessObjects, soit par simple copier-coller du dossier sur le serveur). Cette étape est indispensable car nos solutions utilisent l’API SAP BusinessObjects pour communiquer avec le système, et ainsi ne pas mettre en péril votre sécurité et votre conformité de licences SAP.
Après l’installation, une simple étape de configuration est nécessaire pour connecter l’application 360Live à la base de données PostgreSQL. Si vous souhaitez utiliser les métriques 360Live pour la charge mémoire et la charge CPU de votre système SAP BusinessObjects, vous devez alors vous assurer que l’agent 360Probe fonctionne sur le(s) serveur(s) physique(s) exécutant SAP BusinessObjects.
2. Mise en place initiale du Monitoring
Créer de nouveaux moniteurs sur les éléments essentiels pour vous, afin d’évaluer la santé actuelle du système. Vous pouvez créer vous-même des tableaux de bord qui englobent plusieurs moniteurs afin d’avoir une vue sauvegardée de certaines mesures que vous pourrez consulter régulièrement. De nouveaux moniteurs peuvent également être ajoutés à la volée à l’intérieur des tableaux de bord existants.
N’oubliez pas que les moniteurs affichent les mesures en temps réel. Ils n’enregistrent donc pas les valeurs dans le temps.
Pour une telle fonction, utilisez plutôt des observateurs : ils vous permettent d’enregistrer des données historiques et de vérifier les tendances dans le temps.
Les principaux services à suivre devraient être les suivants :
- CMS et base de données d’audit
- Système d’exploitation
- Services liés à la CMS
- L’Input et l’Output File Repository Servers
- Les services de traitement
- Webis de longue durée
3. Réparez les serveurs défaillants
Voici quelques actions à effectuer :
- Redémarrez les services si nécessaire ou s’ils sont devenus instables.
- Augmentez la valeur de la mémoire Java -Xmx de chaque service Adaptive Processing Server ou Adaptive Job Server
- Augmentez les valeurs de cache du service Webi Processing Server.
- Désactivez la journalisation si elle est activée par défaut.
En bref, prenez toutes les mesures correctives nécessaires pour que les services SAP BusinessObjects redeviennent performants. Les solutions 360Suite étant installées en dehors du serveur SAP BusinessObjects, le monitoring et les actions pourraient être entrepris en cas de crash système.
4. Configurez votre serveur SMTP pour permettre l’envoi de notifications par email
Fournissez les informations d’identification nécessaires pour permettre à 360Live de vous déclencher des alertes e-mail lorsque les seuils définis sont atteints. C’est ce qui fait l’intérêt de 360Live et ce qui le différencie de toute autre solution similaire ; lorsque notre solution envoie ces notifications, elle déclenche des actions en réponse (voir ci-après)comme par exemple lors d’un arrêt de service.
5. Déclenchez des actions d’auto-remédiation
Chaque fois qu’un déclencheur est atteint, et si vous avez correctement configuré vos alertes par courrier électronique, vous recevrez une notification. À partir de là, vous serez en mesure d’exécuter des tâches en réponse au déclencheur.
Par exemple :
- Lorsqu’un service est arrêté ou renvoie trop d’erreurs : le redémarrer
- Dans un cluster actif/passif, si les demandes dépassent un seuil : Démarrer un nouveau service
- Si vous manquez d’espace disque : Exécutez un script pour effacer les fichiers temporaires
Cette fonction est extrêmement utile car elle vous permet d’être proactif dans le suivi de votre déploiement SAP BusinessObjects.
6. Créez et planifiez vos Observateurs
J’ai déjà mentionné les Observateurs, car les métriques ne suffisent pas pour enregistrer leurs valeurs dans le temps. Les Observateurs le permettent.
Ce sont des dispositifs de surveillance spéciaux qui contiennent une ou plusieurs règles définies par l’utilisateur pour évaluer l’état d’un service. Lorsque cet état de service est atteint, il envoie une notification et effectue une action pré-configurée.
Cette vidéo présente la création d’un observateur sur le service Adaptive Job Server qui a pour but d’envoyer un e-mail si le service tombe en panne et qui le redémarrera automatiquement :
Les indicateurs de performance clés ci-dessus constituent un bon point de départ pour suivre les activités quotidiennes. Grâce à l’accès aux mesures historiques, vous pouvez facilement isoler le coupable d’un dysfonctionnement et procéder à un dépannage et à une analyse détaillée.
Une fois les points de friction identifiés, vous pouvez ajuster finement les différentes parties du système SAP BusinessObjects. Vous pouvez augmenter la taille du CPU, de la RAM et du cache de service, définir un plus grand nombre de requêtes parallèles, optimiser la planification des requêtes, ajouter des nœuds ou encore, mieux répartir les services en vue d’un basculement et d’une haute disponibilité.
Planifier la surveillance de SAP BusinessObjects avec 360Live sur le long terme
Afin de monitorer de manière proactive la santé de votre environnement SAP BusinessObjects, vous pouvez par exemple définir certains indicateurs qui méritent d’être surveillés dans le temps :
- Disponibilité du CMS : Vous pouvez configurer une alerte pour signaler si le CMS est arrêté, avec la possibilité de déclencher un redémarrage du service si nécessaire.
- Charge du processeur et mémoire utilisée par le système d’exploitation : vérifiez le pourcentage actuel de temps processeur consommé par le processus pour exécuter le service. Pour la mémoire, vous pouvez consulter la taille actuelle de la mémoire de travail (privé et partageable) utilisée par le processus pour l’exécution du service.
- Serveur CMS : il existe pléthore de mesures pour les paramètres du CMS, mais celles qui valent la peine d’être regardées tournent autour du nombre de sessions établies, car il indique la consommation de licences nommées ou simultanées, comme indiqué dans votre code clé. Gardez également un œil sur les indicateurs tels que ceux liés aux connexions à la base de données pour vous assurer que le CMS contient un nombre de connexions suffisamment important. Il convient également de vérifier les temps de réponse, car une durée supérieure à 10 000 millisecondes peut indiquer la nécessité de dimensionner le service CMS et/ou sa base de données.
- Serveurs Input et Output File Repository : vous pouvez surveiller la croissance et l’utilisation au fil du temps en ce qui concerne l’utilisation de l’espace disque et le nombre de fichiers actifs. Gardez à l’esprit que limiter le nombre d’instances générées par les tâches de planification est la meilleure stratégie pour optimiser le service Output File Repository Server. Une demande d’un utilisateur pour une instance d’un rapport s’exécutera plus lentement lorsqu’il essaiera de la trouver parmi les milliers d’instances stockées.
- Serveurs de traitement : certaines mesures sont spécifiques à certains services, mais il existe des mesures communes qui méritent d’être prises en compte, telles que : les threads de serveurs occupés qui indiqueront si le système ne peut pas traiter des demandes supplémentaires en parallèle, les temps de traitement qui pourraient indiquer un besoin de serveurs supplémentaires sur le système, les mesures de mémoire pour garantir une allocation suffisante pour la machine virtuelle Java, et l’utilisation de l’espace disque.
- Utilisation de l’audit : le nombre actuel d’événements d’audit en attente pourrait indiquer soit que l’audit n’est pas correctement configuré, soit qu’un système fortement chargé génère des événements d’audit plus rapidement que l’auditeur ne peut les traiter.
- Statut des jobs sur le service Job Server : vous pouvez vérifier le nombre de demandes de travaux reçus par rapport au nombre d’échecs de création de tâches. Un taux d’échec élevé sera révélateur d’un problème avec le service Job Server, tel qu’un manque de ressources, un service mal dimensionné en termes de mémoire Java ou même des utilisateurs utilisant trop la planification comme moyen d’actualisation de leurs documents. Un nombre élevé de tâches simultanées reflète le niveau de charge du serveur.
- Durée d’exécution des sessions Webi : vous pouvez définir un seuil pour les Webis de longue durée afin d’être alerté lorsqu’un document dépasse une durée prévue. L’alerte fournira des informations telles que l’utilisateur, le document, le serveur et le type d’action (à la demande, planifiée, récurrente). Vous pouvez également voir à tout moment quels documents Webi sont en cours d’exécution sur la plateforme.
A nouveau, si vous souhaitez conserver l’historique de données d’un indicateur, il convient d’utiliser des Observateurs.
Essayez vous-même le monitoring SAP BusinessObjects avec 360Live
Grâce aux moniteurs et aux observateurs de 360Live, la mise en œuvre d’une stratégie de surveillance SAP BusinessObjects robuste est rapide, simple et légère, ce qui vous permet d’avoir une vue d’ensemble de votre système.
Comme pour toutes nos solutions, notre objectif ultime est de reconnecter l’informatique et les métiers. Nous voulons que vous mainteniez un système performant, sécurisé et disponible. Nous voulons que vos utilisateurs soient des consommateurs SAP BusinessObjects efficaces, autonomes et satisfaits.
Alors, qu’attendez-vous ? Essayez la surveillance 360Live pour vous-même !
