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 solutions 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 solution ThingWorx.
Surveillance directe d'une JVM
Les outils de surveillance directe de JVM sont fournis par Oracle ou par le Sous-système de support. La collecte de 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 solutions 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 du Sous-système de support.
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.
Pour Java 8 :
-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”
Pour Java 9 et versions ultérieures :
-Xlog:gc:file=/logs/gc.log:time,level,tags
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="-Xlog:gc:file=/logs/gc.log:time,level,tags"
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.log existant vers gc.log.restart avant de démarrer le serveur Apache Tomcat :
# Backup the gc.log file to gc.log.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.restart"
fi
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.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 :
Pour Java 8 :
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
Pour Java 9 et versions ultérieures :
-Xlog:gc:file=/logs/gc.log:time,level,tags
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 du Sous-système de support
Pour plus d'informations, consultez la rubrique Sous-système de support.
VisualVM et autres outils de surveillance JMX
VisualVM est un outil de surveillance qui collecte des données pour des solutions Java. Vous pouvez utiliser VisualVM pour surveiller les solutions 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 solutions exécutées localement ou sur des ordinateurs distants.
VisualVM fournit une interface qui vous permet de visualiser graphiquement les informations relatives aux solutions 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 la solution :
• 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 de solution 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 la solution à 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 la solution si les ressources disponibles sur la plateforme ThingWorx 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 > > > :
• 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.