Outils de surveillance

Bonnes pratiques pour le développement d'applications > Surveillance des applications ThingWorx > Outils de surveillance

La plateforme ThingWorx est développée sur la base de la technologie Java. Les outils de diagnostic et de surveillance décrites dans cette section sont conçus pour collecter des mesures de performances et autres données à partir de la machine virtuelle Java (JVM). Utilisez ces outils pour surveiller vos applications ThingWorx au niveau de couche JVM. Les outils permettent d'obtenir les données suivantes de la JVM :

• Opérations en mémoire : vérifiez si les ressources mémoire allouées au serveur sont suffisantes et combien de temps prennent les opérations de récupération de place de la JVM.

• Performances de thread : vérifiez s'il existe des transactions qui s'éternisent ou des problèmes de threads susceptibles d'entraîner des problèmes de performances de votre application ThingWorx.

PTC System Monitor (PSM)

PTC System Monitor (PSM) est un système de surveillance des performances d'application basé sur Dynatrace. PTC a personnalisé Dynatrace en fonction des exigences de surveillance des applications ThingWorx. PSM fournit aux administrateurs système des outils permettant de détecter, diagnostiquer et réparer les problèmes qui ont une incidence sur l'intégrité opérationnelle de l'application. Il surveille à la fois les systèmes de test et de production. Il n'affecte pas les performances de l'application ThingWorx. Ce module est disponible dans le cadre de votre contrat de maintenance et ne nécessite pas d'acheter de licences supplémentaires pour la surveillance de la plateforme de base.

PSM surveille l'activité des threads qui se produit au niveau de la JVM et distille cette activité en une technologie propriétaire nommée PurePaths. PSM PurePath contient des détails concernant le chemin d'exécution du service ThingWorx sur le serveur et le temps d'exécution. Il contient également des informations de contexte, telles que les instructions SQL exécutées.

Fonctionnalités de PSM

PSM vous permet d'effectuer les opérations suivantes :

• Augmentation du temps d'exécution de l'application avant sa défaillance :

◦ Il envoie des notifications en cas de dépassement des seuils, par exemple, lors d'une utilisation intensive de l'UC. Cela permet à l'administrateur de prendre des mesures correctives afin de résoudre les problèmes avant qu'ils ne se transforment en incident au niveau du système.

◦ Il fournit une vue historique de l'utilisation des ressources système. Cela vous permet d'estimer les besoins de capacité futurs en matière de ressources système.

• Amélioration des fonctionnalités de surveillance :

◦ Il utilise des tableaux de bord simplifiés et personnalisables pour synthétiser l'intégrité du système et des composants.

◦ Fournit des fonctionnalités d'exploration détaillée des transactions individuelles, des utilisateurs et des composants serveur pour des informations approfondies.

◦ Contient une liste d'incidents intégrée concernant les problèmes affectant l'intégrité du système.

• Amélioration des fonctionnalités de diagnostic via des données en temps réel :

◦ Il utilise la technologie PurePath pour collecter des données de diagnostic en temps réel et consigner des mesures de performances historiques.

◦ Il permet de ne plus consacrer de temps à reproduire les problèmes avec des paramètres supplémentaires ni à résoudre les problèmes en recourant au support technique PTC.

PSM collecte et enregistre en continu les données en temps réel de votre application ThingWorx et stocke ces données pendant de longues périodes. Les données collectées par PSM vous permettent de surveiller en continu les mesures de performances suivantes qui influent sur les applications personnalisées. Cela permet à votre équipe de développement ou au service de support PTC de reproduire les événements qui aboutissent au problème de performances :

• Performances mémoire JVM

• Temps d'exécution de service à l'aide des données temporelles PurePath

• Mémoire du système d'exploitation, UC et mesures des requêtes de base de données

• Erreurs des journaux ThingWorx et autres incidents

Surveillance directe d'une JVM

Les outils de surveillance directe de JVM sont fournis par Oracle ou par l'extension ThingWorx Support Tools. Ces outils peuvent être utilisés conjointement avec PSM pour obtenir des données de performance détaillées. Si vous n'utilisez pas le système PSM, le fait de collecter les données directement à partir de la JVM constitue une bonne alternative pour identifier et résoudre les problèmes de performances. Il est recommandé de surveiller les diagnostics JVM suivants pour vos applications ThingWorx :

• Surveillance des performances mémoire dans la durée à l'aide de la journalisation Garbage Collection, une fonctionnalité intégrée de la JVM.

• Collecte et analyse au niveau des threads à l'aide de l'extension Support Tools ThingWorx.

Surveillance de la consommation de la mémoire d'un serveur ThingWorx

La machine virtuelle Java (JVM) gère sa propre mémoire (segment de mémoire) de manière native à l'aide du Garbage Collector (GC). GC identifie et supprime les objets du segment de mémoire Java qui ne sont utilisés. Vous pouvez surveiller la consommation de la mémoire d'un serveur ThingWorx en journalisant les détails collectés par le GC.

Vous pouvez utiliser le fichier journal CG pour identifier les tendances de la consommation de mémoire. Selon les tendances, vous pouvez vérifier si le paramètre de segment de mémoire maximum du serveur Apache Tomcat doit être modifié en vue d'obtenir de meilleures performances. Par conséquent, il est recommandé de configurer la journalisation de GC sur le serveur Apache Tomcat.

La JVM possède des indicateurs qui sont appelés lors de l'exécution. Ces indicateurs sont utilisés pour écrire les statistiques concernant les événements GC, tels que le type d'événement GC, la quantité de mémoire consommée au début de l'événement, la quantité de mémoire libérée par l'événement GC et la durée de l'événement GC.

Le fichier journal GC est écrasé à chaque démarrage de la JVM. Il est conseillé de sauvegarder le fichier journal lors du redémarrage du serveur. Cela vous aide à évaluer si la consommation de la mémoire a entraîné le redémarrage du serveur.

Vous pouvez utiliser des outils d'analyse tels que GCEasy.io et Chewiebug GC Viewer pour analyser les journaux à partir de Garbage Collection.

Comment configurer la journalisation Garbage Collector sur Linux (setenv.sh)

Procédez comme suit pour configurer la journalisation Garbage Collector sur Linux :

1. Ouvrez le script $CATALINA_HOME/bin/setenv.sh dans un éditeur de texte.

Le fichier de script setenv.sh peut ne pas être disponible dans toutes les installations. Si le fichier n'existe pas, créez un nouveau fichier setenv.sh dans l'emplacement voulu.

2. Ajoutez le texte suivant à la fin de la variable JAVA_OPTS entre guillemets doubles.

-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

Si JAVA_OPTS n'est pas spécifié dans le fichier setenv.sh ou si le fichier setenv.sh est nouveau, ajoutez-y la ligne suivante :

JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”

Prenez en considération les points suivants :

▪ L'option -XX:+PrintGC renvoie un journal de sortie moins détaillé. Par exemple, le journal généré comporte les détails suivants :

2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]

▪ L'option -XX:+PrintGCDetails renvoie le journal généré détaillé. Par exemple, le journal généré comporte les détails suivants :

2017-10-10T13:18:36.663-0400: 35.578: [GC (Allocation Failure) 2017-10-10T13:18:36.663-0400: 35.578: [ParNew: 76148K->6560K(76672K), 0.0105080 secs] 262740K->193791K(515776K), 0.0105759 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

3. Ajoutez les lignes suivantes à la fin du script setenv.sh. Ce code sauvegarde automatiquement un fichier gc.out existant vers gc.out.restart avant de démarrer le serveur Apache Tomcat :

# Backup the gc.out file to gc.out.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.restart"
fi

4. Enregistrez les modifications dans le fichier.

5. Redémarrez le service Apache Tomcat à l'aide du contrôleur de service qui s'applique à votre système d'exploitation.

Comment configurer la journalisation Garbage Collector sous Windows (Apache Service Manager)

Procédez comme suit pour configurer la journalisation Garbage Collector sous Windows :

1. Dans l'Explorateur Windows, accédez à <Tomcat_home>\bin.

2. Démarrez l'exécutable dont le nom comporte w. Par exemple, Tomcat<version number>w.exe.

3. Cliquez sur l'onglet Java.

4. Dans le champ Options Java, ajoutez les lignes suivantes :

-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

Pour plus d'informations sur la différence entre les options -XX:+PrintGC et -XX:+PrintGCDetails, consultez la section Comment configurer la journalisation Garbage Collector sous Linux (setenv.sh).

5. Cliquez sur Appliquer pour enregistrer les modifications apportées à la configuration du service.

6. Sous l'onglet Général, cliquez sur Arrêter.

7. Cliquez sur Démarrer pour redémarrer le service Apache Tomcat.

Le nouveau journal Garbage Collector est enregistré dans le fichier %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out.

Collecte de données de diagnostic à l'aide de l'extension Support Tools

L'extension Support Tools ThingWorx est utilisée pour collecter des informations pour le support technique ThingWorx. Ces informations sont utilisées lors de la résolution des problèmes de votre application ThingWorx. L'extension collecte les données de diagnostic suivantes :

• Thread Dumps Java : détails sur tous les threads qui sont en cours d'exécution sur une machine virtuelle Java à un moment spécifique. L'activité des threads peut être enregistrée sur des périodes spécifiées.

• Vidage de segment de mémoire Java : détails de tous les objets dans l'espace de segment de mémoire d'une machine virtuelle Java à un moment spécifique.

PTC vous recommande d'installer cette extension sur votre instance ThingWorx. L'extension est disponible sur la page de téléchargement des logiciels PTC à l'adresse support.ptc.com.

VisualVM et autres outils de surveillance JMX

VisualVM est un outil de surveillance qui collecte des données pour des applications Java. Vous pouvez utiliser VisualVM pour surveiller les applications ThingWorx. Il collecte des informations sur l'utilisation de la mémoire et de l'UC. Il génère et analyse les vidages du segment de mémoire et assure le suivi des fuites de mémoire. Vous pouvez collecter des données pour les applications exécutées localement ou sur des ordinateurs distants.

VisualVM fournit une interface qui vous permet de visualiser graphiquement les informations relatives aux applications Java.

VisualVM est fourni avec Java JDK. Pour plus d'informations sur les paramètres de connexion de VisualVM, reportez-vous à la section du ThingWorxCentre d'aide Paramétrage des options Java d'Apache Tomcat.

D'autres outils qui s'intègrent à la JVM à l'aide de l'API Java Management Extensions (JMX) fournissent également des fonctionnalités de surveillance similaires.

VisualVM enregistre les mesures clés suivantes qui affectent les performances de l'application :

• Performances mémoire JVM

• Temps nécessaire à l'exécution des threads

• Mesures de l'UC et de la mémoire du système d'exploitation

• Surveillance du pool de connexions à la base de données

VisualVM suit les données en temps réel pendant environ 20 minutes.

Surveillance des journaux d'application ThingWorx

Les journaux d'application ThingWorx doivent être surveillés régulièrement en cas d'erreurs ou d'autres opérations anormales. Des erreurs peuvent se produire soit au niveau de la couche de plateforme, soit dans les scripts personnalisés utilisés avec ThingWorx. Il est recommandé de consulter quotidiennement les messages dans le journal des erreurs.

Configurez l'option LoggingSubsystem pour l'écriture de la trace de pile concernant les erreurs

L'option Activer le traçage de la pile dans LoggingSubsystem consigne dans les fichiers journaux les messages d'erreur et les traces de pile associées. Par défaut, l'option LoggingSubsytem n'est pas configurée pour écrire les traces de pile (piles d'appels) sur le disque. Définissez l'option Activer le traçage de la pile de manière à enregistrer les piles d'appels des exceptions et les messages d'erreur dans le fichier ErrorLog.log disponible dans le dossier ThingworxStorage/logs. Il est recommandé de définir cette option pour que les détails des appels de fonction soient disponibles dans la trace de pile lors du débogage d'une erreur.

Conservez les journaux de l'application

Le niveau de journalisation détermine le degré de granularité à afficher dans les journaux. Il est conseillé de conserver le niveau de journalisation de l'application à un niveau de détail minimum tel que Infos ou Avertissement, sauf si vous êtes en train de résoudre un problème de manière active. Attention lorsque vous augmentez le niveau de détail sur Débogage, Suivi ou Tout. Cela peut avoir un effet négatif sur les performances de ThingWorx. Il peut en résulter un comportement imprévisible de l'application si les ressources disponibles sur la plateforme sont insuffisantes.

Les journaux sont enregistrés sous la forme de fichiers distincts sur le serveur dans le dossier /ThingworxStorage/logs. Les journaux sont archivés dans le dossier archives présent dans le dossier logs. Les règles de rotation du journal sont basées sur la taille de fichier et l'heure configurées dans les Paramètres de rétention du journal du sous-système de journalisation. Ces paramètres peuvent être modifiés et appliqués au moment de l'exécution.

Vous pouvez spécifier les configurations de substitution suivantes dans Système > Sous-systèmes > LoggingSubsystem > Configuration :

• Taille du fichier : le fichier journal est archivé lorsque sa taille atteint ou dépasse la taille définie dans le champ Taille de fichier max. (Ko). La taille de fichier par défaut d'un journal est fixée à 100 000 Ko. La taille de fichier maximale que vous pouvez définir est de 1 million de Ko.

• Temps : les fichiers sont substitués quotidiennement à minuit, lorsqu'un événement de journal est déclenché. Les fichiers journaux sont déplacés vers le dossier archives. Par défaut, dès lors qu'un journal se trouve dans le dossier archives depuis plus de sept jours, il est supprimé. Vous pouvez modifier la valeur par défaut dans le champ Nbre max. de jours pour archive. Vous pouvez spécifier une valeur entre 1 et 90 jours.

Il est important de surveiller les tailles de journal. Purgez les fichiers journaux de manière cohérente en les sauvegardant au préalable ou en les ignorant lorsqu'ils contiennent des informations obsolètes.