Micro Focus Diagnostics – Trucs et astuces

30 octobre 2021

Micro-focus Diagnostique permet d'isoler et de résoudre rapidement les problèmes de performances des applications de développement et de production en offrant une visibilité au niveau du code au niveau de la transaction.

Ce message contiendra les conseils et astuces mensuels de Micro Focus Diagnostics, qui regrouperont divers problèmes courants dans Micro Focus Diagnostics. Consultez cet article pour obtenir des conseils et astuces de dépannage pour d'autres outils.

Table des matières



  • Micro Focus Diagnostics – Trucs et astuces – Janvier 2021
  • Micro Focus Diagnostics - Trucs et astuces - Février 2021
    • 1. Résolution de l'erreur … impossible de lier les écouteurs à un port de la plage 32000-… au moment du lancement du service .Net Agent Probe Aggregator
    • 2. Instructions pour désactiver la surveillance du client RUM sur les agents .Net et J2EE
    • 3. Lorsque le point VA dans HP Diagnostics : chiffrement par bloc 64 bits 3DES vulnérable à l'attaque SWEET32
    • 4. Instructions pour résoudre l'erreur d'initialisation JVMJ9VM015W pour la bibliothèque j9gc23(2) : Échec de l'instanciation du tas. 2G demandé. N'a pas pu créer la machine virtuelle Java
    • 5. Résoudre le problème lorsque le HP Diagnostics Probe Aggregator n'a pas démarré s'affiche à l'écran
    • 6. Résolution du problème d'intégration dans le diagnostic HP vers HP BSM
    • 7. Trier le problème des fichiers de tendance volumineux dans le dossier d'archive HP Diagnostics 9.26
    • 8. Lorsque le serveur de diagnostics est enregistré sur un autre BSM
    • 9. Instructions pour corriger la référence d'objet non définie sur une instance d'un objet lors de l'enregistrement d'un test de charge de performance
    • 10. Correction de l'erreur lorsqu'elle s'affiche : Diagnostics Next Gen - No Data
  • Micro Focus Diagnostics – Trucs et astuces – Mars 2021
    • 1. Problèmes de diagnostic avec l'intégration à BSM
    • 2. L'installation de l'agent Diagnostics .NET échoue lorsque le service facultatif Probe Aggregator est sélectionné.
    • 3. Comment configurer SSL sur un serveur de diagnostics à l'aide d'un certificat de l'autorité CA ?
    • 4. Erreur d'archive SEVERE : Impossible de créer l'archive après la mise à niveau Diagnostic 9.23 Server
    • 5. Erreur : … initialisation de com.mercury.diagnostics.capture.metrics.jmx.WebSphere6JMXCollector@8b0e7414 java.lang.IncompatibleClassChangeError signalée par l'agent Java de diagnostics en train de sonder un serveur d'applications WebSphere
    • 6. L'interface utilisateur HPE Diagnostics se fige ou se bloque
    • 7. Erreur : le port HttpWebServer 35000 semble être utilisé lors du démarrage de l'agent Diagnostics .NET
    • 8. Configuration de l'agent Diagnostics .NET et de l'agrégateur de sondes pour utiliser des ports autres que ceux par défaut
    • 9. Agent .Net causant une surcharge de mémoire et de CPU pendant le test de charge.
    • 10. Après la mise à niveau, les données d'historique sont perdues, la vue personnalisée et l'application sont perdues
  • Micro Focus Diagnostics – Trucs et astuces – Avril 2021
    • Erreur GRAVE dans les diagnostics lors de la tentative de démarrage du serveur.
    • Comment configurer HP SiteScope afin qu'il puisse être surveillé à l'aide d'un agent Java HP Diagnostics
    • Erreur : le port HttpWebServer 35000 semble être utilisé lors du démarrage de l'agent Diagnostics .NET
    • Quelles autorisations sont nécessaires pour le collecteur Oracle DB ?
    • Clarification de la licence pour HP BSM Diagnostics
    • Informations sur la licence de diagnostic
    • Comment modifier les seuils dans les diagnostics
    • La différence entre l'utilisation normalisée du processeur et l'utilisation totale du processeur
    • Réduisez les frais généraux d'instrumentation.
    • Les métriques collectées prêtes à l'emploi
  • Micro Focus Diagnostics – Trucs et astuces – Mai 2021
    • 1. Comment paramétrer BSM/SHA pour collecter les métriques de Diagnostics ?
    • 2. Comment configurer SSL sur un serveur de Diagnostics à l'aide d'un certificat de l'autorité CA ?
    • 3. JVMJ9VM015W Erreur d'initialisation pour la bibliothèque j9gc23(2) : Échec de l'instanciation du tas. 2G demandé. N'a pas pu créer la machine virtuelle Java
    • 4. Le serveur JBoss ne démarre pas après l'instrumentation de la sonde
    • 5. Erreur : Lorsque le délai d'expiration s'est produit, le thread… signalé par une application Java basée sur Linux s'exécutant dans un environnement VMware avec HP Diagnostics
    • 6. Quoi de neuf dans 9.23 IP2 ?
    • 7. Comment passer de Commander à Mediator ?
    • 8. L'installation de l'agent Diagnostics .NET échoue lorsque le service facultatif Probe Aggregator est sélectionné
    • 9. Comment désactiver la surveillance du client RUM sur les agents .Net et J2EE
    • 10. Le serveur de diagnostics est enregistré sur un autre BSM
  • Micro Focus Diagnostics – Trucs et astuces – Juin 2021
    • 1. Comment restaurer la table des symboles ?
    • 2. Comment HP Diagnostics Collector obtient-il des données ?
    • 3. Est-il possible de modifier la base de données des profils de diagnostic ?
    • 4. Quels sont les fichiers de points utilisés par Java Probe for Instrumentation ?
    • 5. Comment activer la journalisation des requêtes longues dans Diagnostics ?
    • 6. Puis-je collecter le CPU, la mémoire et le réseau d'une base de données Oracle à l'aide d'Oracle Collector ?
    • 7. Le profileur ne s'affiche pas
    • 8. HPD Mediator Server – Utilisation élevée du disque – Nettoyage nécessaire pour libérer de l'espace
    • 9. Diag Mediator ne démarre pas – Archive SEVERE : Impossible de créer l'archive
    • 10. Configuration LDAP dans les diagnostics

Micro Focus Diagnostics – Trucs et astuces – Janvier 2021

1. Récupérer les échantillons de l'Agent collecteur de diagnostics en cas de panne

Il arrive souvent que les utilisateurs ne puissent pas obtenir les échantillons de leur agent de diagnostic respectif. Ils ont rencontré des problèmes d'accès et d'autorisation. Et il y a une erreur à l'écran, avec toutes les informations d'identification indiquées ci-dessous :

|__+_|

Cette erreur peut également être corrigée ; il vous suffit de suivre attentivement les étapes ci-dessous :

  1. Vous devez naviguer vers Maintenance , puis en dessous, cliquez sur enregistrer .
  2. Ensuite, vous devez cliquer sur le Composants enregistrés ; ensuite, vous devez trouver le Nexus_BD .

Ces étapes vous guideront pour annuler l'enregistrement, et il vous suffit d'attendre un certain temps pour qu'il puisse s'enregistrer à nouveau pour informer les métriques une fois de plus. Cette solution devrait être efficace et résoudra toutes les erreurs liées à l'authentification qui se sont produites auparavant.

Il est également recommandé à l'utilisateur de vérifier les paramètres du serveur proxy que les utilisateurs peuvent trouver sur le serveur Mediator. Le serveur Mediator se trouve dans le fichier /etc/server.properties puis sur le serveur Commander sous le chemin similaire au fichier /etc/.

2. Instructions pour s'attaquer au Diagnostics .net Agent ProbeAggregator lorsqu'il dépasse la taille du tas Java

Ce problème se produit lorsque Diagnostics 9.50 et l'agent .net 9.50 sont installés dans Windows Système opérateur plate-forme serveur 2012. Les utilisateurs rencontrent ce problème lorsqu'ils remarquent que le fichier . Rapporter l'agent n'est pas en mesure de collecter les données nécessaires.

Lorsque les détails du journal sont vérifiés, une erreur indique : java.lang.OutOfMemoryError : espace de tas Java sur le ProbeAggregatorJSW.log fichier que l'utilisateur exécute actuellement sur l'appareil. La cause principale de cette erreur est le facteur java.lang.OutOfMemoryError du fichier respectif.

Cette erreur peut être facilement résolue manuellement. l'utilisateur n'a qu'à suivre les étapes ci-dessous :

    Ouvrez probeaggregator.cmd en vous aidant du bloc-notes. Augmentez ensuite la valeur -Xmx à une valeur supérieure.

Par exemple, elle peut être deux fois supérieure à la valeur précédente ou selon les besoins en ressources système.

3. Détails concernant la configuration du serveur de diagnostic

Comprendre comment configurer le serveur de diagnostic par vous-même peut sembler une tâche difficile, mais les utilisateurs peuvent le faire à l'aide de certains conseils. De nombreux utilisateurs ont rencontré une erreur dans la page de scénario de diagnostic du centre de performances.

On observe que cela se produit généralement lorsqu'ils travaillent sur l'icône des paramètres. Le message d'erreur qui s'affiche est donné ci-dessous :

|__+_|

Cette erreur peut être corrigée, mais avant cela, l'utilisateur doit disposer d'informations complètes sur le produit qui a été installé et sur sa version également. Selon la technologie d'application que vous utilisez, vous devrez installer un agent Java ou .NET.

Parallèlement à cela, l'instrument spécifique de cette application doit également être obtenu car il sera responsable de l'envoi des données à votre serveur de diagnostic. L'utilisateur doit s'assurer que la version particulière du serveur Diagnostics n'est pas inférieure à celle de l'un des agents Diagnostics.

4. Suppression d'Oracle Java JRE 1.8.x / 8.x de C:Program Files (x86)

Il a souvent été observé que le serveur de diagnostics 9.26 Oracle Java JRE 1.8.x / 8.x crée des problèmes lors de son fonctionnement. Les utilisateurs ont quelques plaintes, alors qu'ils ont actuellement 2 des serveurs de diagnostic.

Les deux exécutent une ancienne version 9.26, les utilisateurs souhaitent supprimer les fichiers Oracle Java précédents, mais craignent que cela n'affecte l'application Diagnostics de quelque manière que ce soit.

La réponse à cette question est que la suppression du précédent Oracle Java JRE 1.8.x / 8.x depuis C:Program Files (x86) les fichiers n'affecteraient pas le fonctionnement de l'application Diagnostics.

Une fois que vous avez fini de retirer le Oracle Java JRE 1.8.x / 8.x depuis C:Program Files (x86) fichiers, il vous suffit d'accéder au JRE intégré du serveur de diagnostics.

Au moment de l'installation, le JRE est livré avec le serveur Diagnostics sous forme embarquée, supprimant ainsi Oracle Java JRE 1.8.x / 8.x depuis C:Program Files (x86) ne serait pas un problème.

5. Affichage des paramètres du pool JMX de la connexion Hikari

Les utilisateurs ont souvent des problèmes concernant les paramètres JMX du pool de connexion Hikari, car ils ne peuvent pas le voir pour l'inspecter ou le surveiller. Il existe également un problème concernant la configuration du fichier metrics.config à tout moment.

On observe que l'équipe qui utilise ledit l'application doit surveiller les activités des paramètres JMX. Lors de l'utilisation du pool de connexions Hikari, l'équipe souhaite surveiller toutes les informations relatives à Hikari, telles que son nom d'objet, son nom de classe et toutes les descriptions qui l'accompagnent.

Les utilisateurs observent également que dans le métrique.config fichier pour l'agent Java 9.51, certaines métriques Hikari (ces lignes de fichier metric.config comprises entre 358 et 365) sont présentes. Vous pouvez trouver le fichier metrics.config dans la section de la plate-forme Java par les définitions d'ensemble données ci-dessous :

|__+_|

6. Résolution du problème lorsque les diagnostics ne collectent qu'une seule demande de serveur pour Open Text

Il arrive souvent que les utilisateurs rencontrent un problème dans la collecte des requêtes du serveur dans les diagnostics. Les diagnostics semblent ne collecter qu'une seule demande de serveur pour l'Open Text. La demande de serveur spécifique qu'il collecte est un instruction get(). Diagnostique, lequel est 9.50.1.156 sur la norme Windows Server 2016.

Les utilisateurs ont déjà installé l'agent .NET fourni avec Diagnostics 9.50 en général. Le serveur OpenText est responsable de exécuter le serveur Windows 2012 R2.OpenText utilise généralement IIS pour fournir du contenu.

Il est recommandé à l'utilisateur d'utiliser l'instrumentation personnalisée initialement à des fins de sécurité. Au début, nous pourrions exécuter sur le serveur de diagnostics 9.4x, ou nous pouvons également accéder aux fichiers .dll appropriés applicables. Cela est nécessaire pour établir une plate-forme sécurisée pour la surveillance conformément aux exigences des diagnostics.

Afin d'instrumenter le côté Java, l'utilisateur doit utiliser l'agent Java. Ensuite, ils doivent vérifier attentivement la documentation et rester à jour à ce sujet afin de pouvoir instrumenter facilement la JVM.

Il est nécessaire pour acquérir des informations plus détaillées concernant OpenText. Il est également important que leur support/R&D soit directement contacté afin d'obtenir la documentation ou des instructions directes qui pointent vers les principales DLL .NET qui doivent être instrumentées.

7. Spécification de plusieurs cibles JBoss possibles et prise en charge des scripts d'agent Java

Les utilisateurs ont souvent des questions concernant la spécification de plusieurs cibles pour les installations de l'agent Java de diagnostic pour la surveillance Tomcat ou JBoss, si elle est prise en charge pour les scripts d'agent Java ou non.

Ils ont observé qu'à l'ajout des lignes de configuration spécifiques pour JBoss, il y met des caractères spéciaux, et le manuel semble n'avoir que les éléments UNIX/Linux qui sont mélangés avec les variables Windows, comme $JAVA_HOME contre %JAVA_HOME% .

On observe qu'il copie et colle ces mêmes informations, ce qui entraîne simplement l'insertion des caractères spéciaux dans le standalone.bat. Ainsi, cela devient inquiétant, et c'est la raison pour laquelle le service de l'application se comporte de manière anormale. De même, une version en texte brut pour celle donnée ci-dessous serait appropriée pour ce problème, pour la version Windows :

|__+_|

Ce problème peut être résolu pendant que nous travaillons sur JBoss 7 JVM. Dans la version spécifique de JBoss 7, le serveur de domaine a un domaine.xml déposer; la section suivante a été ajoutée à chacun des éléments Server-group-

Ici, les problèmes sont analysés qui se sont produits suite à la documentation d'installation, et cela nous permet également de trouver la solution pour le même:

  1. Il a été noté que les nœuds non principaux n'étaient pas en mesure de charger l'agent ; c'est parce que le chemin de l'agent de diagnostics est spécifiquement unique sur chaque serveur. Les mêmes paramètres de groupe de serveurs sont généralement transmis à chaque serveur dudit cluster. Cela peut être résolu à l'aide d'un caractère générique situé dans la section ci-dessus ; ça commence par Xbootclasspath .
  1. Puis dans la console de monitoring, on s'aperçoit que les sondes n'étaient pas bien visibles, et les utilisateurs ont du mal à continuer. Le problème est resté le même même en utilisant le %0 variable dans Probe.id, ce qui rendait difficile la visualisation et l'introspection du serveur et de la JVM que l'utilisateur regardait réellement dans la console. Ce problème peut être résolu en passant simplement une variable d'environnement, c'est-à-dire $VIPNAME dans le XML , avec le nom JVM. Veuillez noter que le nom JVM est également le nom du groupe de serveurs.

Dans la deuxième section mentionnée ci-dessus, on observe que la sonde.id est en fait le nom de l'application et le VIP, ce qui permet à l'utilisateur d'identifier assez clairement quelle JVM est surveillée à l'aide de la console. À l'aide de cette méthode de dénomination, l'utilisateur peut également ajouter autant de serveurs ou de JVM qu'il le souhaite, et cela sera désormais affiché avec précision dans la console.

8. Mise à niveau du serveur de diagnostic 9.50 et conservation des paramètres de configuration et des données historiques

Les utilisateurs rencontrent souvent des difficultés lors de la mise à niveau du serveur de diagnostics 9.50 vers la version la plus récente, 9.51. Les utilisateurs souhaitent conserver les paramètres de configuration et les données historiques tout en conservant la version 9.50 du serveur de diagnostics puis en important les applications de la version précédente. On observe également que la mise à niveau vers la version 9.51 a entraîné un échec absolu.

Il est tout à fait possible de passer en 9.51 à partir de la version précédente du serveur de diagnostic 9.50 tout en conservant les paramètres de configuration et les données historiques. Pour conserver lesdites modifications par rapport aux versions précédentes et mettre à niveau le serveur de diagnostics, l'utilisateur peut simplement suivre attentivement les étapes indiquées ci-dessous :

  1. Vous devez arrêter la version antérieure et terminer tous les processus de Diagnostics 9.50.
  2. Ensuite, vous devez vous assurer de sauvegarder le /etc dossier n'importe où en dehors du serveur de diagnostic, afin qu'il ne soit pas perdu dans la procédure.
  3. Ensuite, vous devez sauvegarder le /archiver dossier en dehors du serveur Diagnostics.
  4. Ensuite, vous devez désinstaller complètement Diagnostics 9.50.
  5. Vous devez maintenant installer complètement Diagnostics 9.51.
  6. Après cela, vous devez arrêter les services Diagnostics 9.51.
  7. Remplacez ensuite le /etc . et le /archiver dossiers présents avec les sauvegardes des étapes 2 et 3 ci-dessus.
  8. Démarrez maintenant manuellement les services Diagnostics 9.51.

9. Instructions pour instrumenter l'application Oracle sans avoir besoin d'une console (CPE OCTIM19G1061847)

Les utilisateurs ont installé avec succès un agent de diagnostics sur le serveur d'applications Oracle. Le problème survient lorsque la console Application Server Control n'est pas activée ou activée. En raison de ce problème, les utilisateurs ne peuvent pas suivre la procédure dûment mentionnée dans le guide Diagnostics Java.

Il est en effet possible d'ajouter soi-même les paramètres JVM, sans avoir besoin de la console Application Server Control. La version du serveur d'applications actuellement utilisée par l'EBS est 10.1.3.5.

L'utilisateur peut généralement effectuer cette procédure sans console, il suffit d'instrumenter le module central. Après cela, vous devrez les ajouter à la section des options Java de démarrage en conséquence :

|__+_|

10. Résolution de l'erreur lorsque l'agent Java de diagnostic ne parvient pas à se refléter après le redémarrage à l'aide de l'interface graphique

Les utilisateurs rencontrent souvent des erreurs lorsqu'ils redémarrent l'agent de diagnostic Java lors de l'utilisation du gestionnaire de nœuds dans l'interface graphique. L'erreur concerne l'agent Java de diagnostic lorsqu'il ne réagit pas ou ne réfléchit pas après le redémarrage.

La situation est que cela ne se reflète que lorsque l'équipe d'application redémarre le script manuellement. Cela peut sembler gênant s'il s'agit d'un problème récurrent. Ils remarquent que le démarrage de l'application via le gestionnaire de nœuds dans l'interface graphique ne peut pas du tout refléter le niveau de données de l'application.

Cette erreur peut être résolue si l'utilisateur prend certaines mesures nécessaires. Lorsque l'utilisateur lance startWeblogic.sh, cet agent spécifique reflète toutes les données de l'application. Ensuite, l'utilisateur doit inspecter minutieusement toutes les informations disponibles.

Ils pourront alors localiser le gestionnaire de nœuds et constater qu'il utilise un script différent pour démarrer l'agent de diagnostic Java. Pour cette raison particulière, l'utilisateur avait traversé l'erreur à cause de ce script particulier qui n'était pas compatible et qui a donc entraîné cette erreur.

  1. L'utilisateur doit régler soigneusement le StartEnabledScript et vérifiez si les fichiers sont corrects et non corrompus.
  2. Ensuite, ils doivent créer le gestionnaire de nœuds à l'aide du démarrer Weblogic.sh script pour relancer l'application.
  3. Ensuite, les utilisateurs doivent s'assurer que la procédure a été suivie sérieusement, au cas où il y aurait un suivi à l'écran.