Activation de l'ID de traçage global

Vous pouvez utiliser un ID de traçage global, ainsi que des zones personnalisées, dans vos fichiers de journalisation. L'ID global facilite la détermination des problèmes. Vous pouvez l'utiliser avec tous vos serveurs, y compris Liberty et WebSphere Application Server.

HCL Commerce Server utilise une architecture de micro-service modernisée, qui inclut le serveur de transactions, le serveur de recherche, le serveur de magasin, le serveur de personnalisation et le serveur d'utilitaires. Cette conception offre de nombreux avantages, y compris un environnement de développement indépendant, un cycle sophistiqué de génération et de déploiement, une distribution de volume d'accès plus raisonnable et une séparation claire pour la personnalisation, entre autres. Cela augmente toutefois la complexité de la détermination des problèmes. Les serveurs sont séparés, et ils ont besoin d'une invocation de service pour l'interaction. Un grand volume de requêtes passe par les serveurs, et il peut être difficile d'obtenir une image complète des serveurs qui participent à la résolution d'une requête spécifique. Trouver la cause profonde d'un problème dans un système distribué peut être difficile en s'appuyant sur un système de journalisation conçu pour une architecture monolithique.

HCL Commerce La version 9.0.1.3 introduit un ID de traçage global renforcé qui améliore la détermination des problèmes. En plus d'utiliser l'ID de traçage, vous pouvez ajouter des zones personnalisées dans le fichier de journalisation. Vous pouvez définir une taille maximale (en mégaoctets) pour chaque fichier de suivi, et définir un nombre maximum de fichiers de suivi dans WebSphere Application Server et Liberty. Ces améliorations vous permettent d'intégrer des fichiers journaux de différents canaux. En suivant l'ID de traçage global ou les zones personnalisées, vous pouvez trouver la cause profonde des problèmes beaucoup plus rapidement.

Avant de commencer

Installer le serveur Kafka et le serveur ZooKeeper

Se reporter au guide officiel de Kafka et de ZooKeeper

Se connecter à Kafka et à ZooKeeper

Nous pouvons utiliser les commandes Run Engine par défaut pour configurer le paramètre Kafka et ZooKeeper dans le serveur de transactions, de recherche et de magasin.

Configurer le serveur de transactions pour le connecter à Kafka et à ZooKeeper

Exécutez la commande

set-kafka-server                                             KafkaServers                                         TopicPrefix                                         listOfZooKeeper

, où :

KafkaServers: Liste des serveurs Kafka, qui sont séparés par une virgule. Les ID Kafka doivent suivre le modèle hostname:port.
TopicPrefix: Préfixe du sujet de Kafka.
listOfZooKeeper: La liste des ZooKeepers (zookeeperId1, zookeeperId2,.., zookeeperIdn) doit être séparée par des virgules. Les ID ZooKeeper doivent suivre le modèle : hostname:port

Par exemple,

set-kafka-server 9.110.182.165:9092,9.110.182.166:9092,9.110.182.167:9092 
testTopic 9.110.182.165:2181,9.110.182.166:2181,9.110.182.167:2181

Reportez-vous aux liens suivants pour connaître la syntaxe de paramètre utilisée par les différents types de serveurs :

Configurer le serveur de magasi =n pour le connecter à ZooKeeper

Par exemple,

set-kafka-server testTopic 9.110.182.165:2181,9.110.182.166:2181,9.110.182.167:2181

Conseil, le préfixe du sujet doit être le même que celui que vous créez dans le serveur de transactions

Configurer le serveur de recherche pour le connecter à ZooKeeper

Par exemple,

set-kafka-server testTopic 9.110.182.165:2181,9.110.182.166:2181,9.110.182.167:2181

Remarque : Le préfixe de sujet doit être le même que celui que vous créez dans le serveur de transactions.

Pourquoi et quand exécuter cette tâche

Il existe deux façons de configurer l'ID de traçage global : à l'aide de l'API REST par défaut ou en mettant à jour les configurations JVM.

Procédure

Configurez l'ID de traçage global via l'API REST par défaut.
Vous pouvez configurer l'ID de traçage global dans les environnements d'exécution à l'aide de l'API REST par défaut. Pour plus d'informations, voir Référence de l'API REST de la journalisation étendue. L'API REST ne peut être gérée que par l'utilisateur SPI.

Pour activer l'ID, appelez l'API de ressource de journalisation étendue pour envoyer le message à Kafka et diffusez le message à tous les serveurs. La méthode est PUT, et l'authentification de base pour l'ID spiuser et le mot de passe correspondant doit être incluse dans l'en-tête.
```
PUT https://transactionServerHost:transactionServerPort/wcs/resources/extendedlogger/asyncconfig?enableFlag=true®istrationFlag=true&customFields=XEL_example
```
Où se trouvent les paramètres de l'API REST :

enableFlag

Utilisé pour activer ou désactiver la journalisation étendue. La valeur true activera la journalisation, tandis que false la désactivera.

registrationFlag

Utilisé pour inscrire ou désinscrire des zones personnalisées. La valeur true signifie s'inscrire, tandis que la valeur false est utilisée pour se désinscrire. Lorsque registrationFlag est false et que customFields n'est pas utilisé, toutes les zones personnalisées ne seront pas inscrites.

customFields

Utilisé pour enregistrer les zones personnalisées ajoutées dans le journal étendu. Ce paramètre doit commencer par "XEL_". Si vous excluez ce préfixe, aucune information personnalisée ne sera imprimée dans le journal étendu. Si vous avez besoin d'ajouter de nombreuses zones, séparez-les de virgules. Lorsqu'une requête est lancée, ajoutez les zones personnalisées dans l'en-tête, puis les zones personnalisées seront imprimées dans le journal étendu.

DeployController

Cette valeur est utilisée pour définir les serveurs correspondants pour consommer le message. Si cette valeur n'est pas définie dans le message, tous les serveurs réagiront à l'action. Si elle est définie, seuls les conteneurs correspondants répondront et prendront effet. La valeur est les noms d'hôtes de conteneur, séparés par des virgules.

Remarque : Cette méthode met à jour la mémoire de travail pour les conteneurs serveur, mais ne modifie pas les images Docker pour les serveurs. Par conséquent, ces configurations ne sont pas persistantes. Elles seront perdues après que vous redémarrez les serveurs.
Rendez l'ID de traçage global persistant via les configurations JVM.
Vous pouvez activer et configurer le traçage global à l'aide de deux paramètres JVM :

global.tracing.enabled

Utilisé pour activer ou désactiver la journalisation étendue. La valeur true est utilisée pour activer la journalisation étendue, tandis que false la désactive.

global.tracing.custom.fields

Utilisé pour enregistrer les zones personnalisées. Si de nombreuses zones doivent être ajoutées, séparez-les par des virgules.

En configurant votre logique Docker d'application, vous pouvez vous assurer que ces paramètres sont définis automatiquement pendant le démarrage du Docker. Cette approche nécessite que vous regénériez les images docker du serveur pour résoudre l'exigence de configuration spécifique. Pour obtenir un tutoriel sur la personnalisation de l'image Docker par défaut en fonction de vos besoins spécifiques, voir Tutoriel : Personnalisation de la logique de démarrage Docker.
La commande set-system-property du moteur de course peut être utilisée pour définir les paramètres JVM. Reportez-vous aux liens suivants pour obtenir des informations sur la commande dans différents serveurs :

Résultats

Lorsque la journalisation étendue est activée, un fichier nommé extended.log.0 est créé. Lorsque extended.log.0 atteint la taille maximale, il est déployé pour générer un nouveau fichier extended.log.1. Le numéro dans le nom de fichier est utilisé pour distinguer les journaux font l'objet d'une rotation. Les journaux sont créés dans les répertoires suivants :

/opt/WebSphere/AppServer/profiles/default/logs/**/extended.log.*
/opt/WebSphere/Liberty/usr/servers/default/logs/**/extended.log.*

Remarque : HCL Commerce Version 9.1.10.0 or later

Le texte suivant s'applique uniquement aux versions 9.1.10.0 et ultérieures.

La fonction de connexion étendue est obsolète et les journaux au format JSON sont recommandés à la place.

Activer la journalisation de WebSphere Application Server avec la sortie JSON

Si une valeur WebSphere Application Server traditionnelle est configurée pour le mode HPEL, les données de journal et de trace sont générées au format binaire en non en texte normal. A l'aide d'HPEL LogViewer, les données de journal peuvent être exportées en continu au format JSON et affichées dans un tableau de bord Kibana.

Les journaux WebSphere Application Server sont générés au format texte normal par défaut, ce que l'on appelle la journalisation en mode de base. Pour améliorer les capacités de journalisation et de trace, mettez à niveau le mode de journalisation vers HPEL (High Performance Extensible Logging).

HPEL LogViewer est un outil de ligne de commande WebSphere Application Server permettant d'utiliser les référentiels de données de journalisation et de trace HPEL. Les fonctions de filtrage et de formatage de l'outil facilitent l'identification des éléments clés dans les référentiels de données.

Dans votre environnement WebSphere Application Server de VM Quickstarter, remplacez le mode de journalisation de base par le mode HPEL.
Exécutez la commande LogViewer suivante, qui génère les données de journal et de trace dans le fichier journal spécifié au format JSON et les surveille en continu.
```
<WAS_ROOT>/bin/logViewer.sh -outLog <logviewer-output-log-file> -format json -resumable -resume -monitor &
```

Activer la journalisation de WebSphere Application Server Liberty avec la sortie JSON

Lorsque le fichier WebSphere Application Server messages.log Liberty est généré au format JSON, la sortie peut être affichée dans un tableau de bord Kibana.

La propriété de journalisation messageFormat d'un serveur Liberty contrôle le format de sortie du fichier messages.log. Par défaut, la propriété messageFormat est définie sur De base, ce qui génère une sortie en texte normal. La modification du paramètre messageFormat en JSON permet à la sortie d'apparaître sur le tableau de bord Kibana.

Dans le fichier server.xml de votre serveur Liberty, si vous souhaitez définir la propriété de journalisation messageFormat au format JSON, utilisez logging messageFormat="json" et si vous souhaitez que votre propriété consolseFormat soit au format JSON, utilisez consoleFormat="json" pour indiquer les sources à inclure dans la sortie.

Si vous souhaitez configurer le CRS, accédez au répertoire workspace_dir\Liberty\servers\crsServer\configDropins\overrides suivant. Modifier le fichier de configuration personnalisé server.xml. Si le fichier n'existe pas, créez-le.

configDropins/overrides/server.xml
<logging messageFormat="json" consoleFormat="json" traceSpecification="com.ibm.commerce.component.*=all">
</logging>

La fonction ExtendedLogging et GlobalTracingID peut être activée sans Kafka en activant la journalisation JSON fournie par WebSphere Liberty et WebSphere Application Server. Lorsque vous activez ces deux options de journalisation, vous obtenez des traces comparables comme indiqué ci-dessous ;

Dans l'application CRS.

{"type":"liberty_message","host":"LP1-AP-51879416.PROD.HCLPNP.COM","ibm_userDir":"W:\/IBM\/WebSphere\/Liberty\/usr\/","ibm_serverName":"crsServer","message":"Cannot find class impl with specified xpath: ComponentIntegrationServices\/Marketing\/@serviceImpl, will use default one instead.","ibm_threadId":"00000035","ibm_datetime":"2022-02-01T20:23:26.708+0530","module":"com.ibm.commerce.component.util.service.ComponentMarketingServiceFactory","loglevel":"WARNING","ibm_methodName":"initialize() executionContext:","ibm_className":"com.ibm.commerce.component.util.service.ComponentMarketingServiceFactory","ibm_sequence":"1643727206708_00000000000F2","ext_xRequestId":"ADHfu68Bvcs1kiA7","ext_thread":"Default Executor-thread-4"}

{"type":"liberty_message","host":"LP1-AP-51879416.PROD.HCLPNP.COM","ibm_userDir":"W:\/IBM\/WebSphere\/Liberty\/usr\/","ibm_serverName":"crsServer","message":"Configured name binding, com.ibm.commerce.foundation.server.services.search.contextpath, is not defined in server","ibm_threadId":"00000035","ibm_datetime":"2022-02-01T20:23:27.360+0530","module":"com.ibm.commerce.component.util.BackendServersConfigurationUtil","loglevel":"WARNING","ibm_methodName":"getComponentConfigThroughJNDI(String componentId, String configGroup, String propertyName, String defaultValue) executionContext:","ibm_className":"com.ibm.commerce.component.util.BackendServersConfigurationUtil","ibm_sequence":"1643727207360_00000000000F3","ext_xRequestId":"ADHfu68Bvcs1kiA7","ext_thread":"Default Executor-thread-4"}

Dans l'application TS.

{"type":"was_message","host":"LP1-AP-51879416.PROD.HCLPNP.COM","ibm_cellName":"localhost","ibm_nodeName":"localhost","ibm_serverName":"server1","ibm_sequence":"1643727200393_0000000000C68","message":"CMN1501E: User -1002 does not have the authority to perform action \"AjaxAccountAddressForm\" on resource \"com.ibm.commerce.command.HttpForwardViewCommandImpl\" for command \"null\".","ibm_datetime":"2022-02-01T20:23:20.393+0530","ibm_methodName":"isAllowed","ibm_className":"AccManager","ibm_threadId":"000001bc","module":"com.ibm.websphere.commerce.log.CommerceSrvr","loglevel":"SEVERE","ext_appName":"WC","ext_xRequestId":"ADHfu68Bvcs1kiA7"}