Vue d’ensemble du service de journalisation centralisée dans Lync Server 2013

 

Rubrique Dernière modification : 2013-02-22

Le service de journalisation centralisée est conçu pour fournir un moyen de collecte contrôlée des données, avec une étendue large ou étroite. Vous pouvez collecter des données à partir de tous les serveurs du déploiement simultanément, définir des éléments spécifiques à suivre, définir des indicateurs de trace et retourner des résultats de recherche à partir d’un seul ordinateur ou une agrégation de toutes les données de tous les serveurs. Le service de journalisation centralisée s’exécute sur tous les serveurs de votre déploiement. L’architecture du service de journalisation centralisée est composée des agents et services suivants :

• L’agent de service de journalisation centralisée ClsAgent.exe est l’exécutable de service qui communique avec le contrôleur et reçoit les commandes émises par l’administrateur. L’agent est exécuté en tant que service sur chaque ordinateur Lync Server. Lorsque l’agent reçoit une commande, il exécute la commande, envoie des messages aux composants définis pour le suivi et écrit les journaux de trace sur le disque. Il lit également les journaux de trace de son ordinateur et renvoie les données de trace au contrôleur lorsque cela est demandé. ClsAgent écoute les commandes sur les ports suivants : TCP 50001, TCP 50002 et TCP 50003.

• L'ClsControllerLib.dll de contrôleur de service de journalisation centralisée est le moteur d’exécution de commandes pour Lync Server Management Shell et pour ClsController.exe. CLSControllerLib.dll envoie les commandes Start, Stop, Flush et Search au ClsAgent. Lorsque des commandes de recherche sont envoyées, les journaux d’activité résultants sont retournés au ClsControllerLib.dll et agrégés. Le contrôleur est chargé d’envoyer des commandes à l’agent, de recevoir l’état de ces commandes et de gérer les données du fichier journal de recherche lorsqu’elles sont retournées par tous les agents sur n’importe quel ordinateur de l’étendue de recherche, et d’agréger les données de journal dans un jeu de sortie explicite et ordonné. Les informations contenues dans les rubriques suivantes sont axées sur l’utilisation de Lync Server Management Shell. ClsController.exe est limité à un sous-ensemble des fonctionnalités et fonctions disponibles dans Lync Server Management Shell. L’aide pour ClsController.exe est disponible sur la ligne de commande en tapant ClsController le répertoire par défaut C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent.

Communications entre ClsController et ClsAgent

Vous émettez des commandes à l’aide de l’interface de ligne de commande Windows Server ou de Lync Server Management Shell. Les commandes sont exécutées sur lʼordinateur auquel vous êtes connecté et envoyées au ClsAgent localement ou à dʼautres ordinateurs et pools dans votre déploiement.

ClsAgent maintient un fichier d’index de tous les fichiers .CACHE dont il dispose sur l’ordinateur local. ClsAgent les alloue de sorte qu’ils soient distribuées de manière égale parmi les volumes définis par l’option CacheFileLocalFolders, en ne consommant jamais plus de 80 % de chaque volume (autrement dit, l’emplacement du cache local et le pourcentage sont configurables à l’aide de l’applet de commande Set-CsClsConfiguration). ClsAgent est également responsable de la suppression des anciens fichiers journaux de suivi d’événements mis en cache (.etl) sur l’ordinateur local. Après deux semaines (le délai est configurable à l’aide de l’applet de commande Set-CsClsConfiguration), ces fichiers sont copiés sur un partage de fichiers et supprimés de l’ordinateur local. Pour plus d’informations, voir Set-CsClsConfiguration. Lors de la réception d’une demande de recherche, les critères de recherche sont utilisés pour sélectionner le jeu de fichiers .etl mis en cache afin d’effectuer la recherche en fonction des valeurs dans l’index conservé par l’agent.

Remarque

Les fichiers déplacés vers le partage de fichiers à partir de l’ordinateur local peuvent être consultés par ClsAgent. Une fois que ClsAgent a déplacé les fichiers vers le partage, le vieillissement et la suppression des fichiers ne sont pas conservés par ClsAgent. Vous devez définir une tâche d’administration pour contrôler la taille des fichiers sur le partage de fichiers et les supprimer ou les archiver.

Les fichiers journaux résultants peuvent être lus et analysés à l’aide de divers outils, notamment Snooper.exe et tout outil capable de lire un fichier texte, tel que Notepad.exe. Snooper.exe fait partie des outils de débogage Lync Server 2013 et est disponible en téléchargement web à partir de https://go.microsoft.com/fwlink/?LinkId=285257.

Comme OCSLogger, le service de journalisation centralisée a plusieurs composants à suivre et fournit des options pour sélectionner des indicateurs, tels que TF_COMPONENT et TF_DIAG. Le service de journalisation centralisée conserve également les options de niveau de journalisation d’OCSLogger.

L’avantage le plus important d’utiliser Lync Server Management Shell sur la ligne de commande ClsController est que vous pouvez configurer et définir de nouveaux scénarios à l’aide de fournisseurs sélectionnés qui ciblent l’espace de problème, les indicateurs personnalisés et les niveaux de journalisation. Les scénarios accessibles à ClsController se limitent à ceux définis pour l’exécutable.

Dans les versions précédentes, OCSLogger.exe a été fournie pour permettre aux administrateurs et au personnel du support technique de collecter des fichiers de trace à partir d’ordinateurs du déploiement. OCSLogger, pour toutes ses forces, avait une lacune. Vous ne pouvez collecter les journaux que sur un ordinateur à la fois. Vous pouvez vous connecter à plusieurs ordinateurs à l’aide de copies distinctes d’OCSLogger, mais vous vous êtes retrouvé avec plusieurs journaux d’activité et aucun moyen simple d’agréger les résultats.

Quand un utilisateur demande une recherche de journal, ClsController détermine à quel ordinateur envoyer la demande (en fonction des scénarios sélectionnés). Il détermine également si la recherche doit être envoyée au partage de fichiers où les fichiers .etl enregistrés se trouvent. Lorsque les résultats de la recherche sont renvoyés à ClsController, le contrôleur les fusionne en un jeu de résultats unique présenté à l’utilisateur. Les utilisateurs peuvent enregistrer les résultats de recherche sur leur ordinateur local afin d’effectuer une analyse approfondie.

Lorsque vous commencez une session de journalisation, vous spécifiez des scénarios adaptés au problème que vous tentez de résoudre. Vous pouvez exécuter deux scénarios simultanément. L’un d’entre eux doit être le scénario AlwaysOn. Comme son nom l’indique, il doit toujours être en cours d’exécution dans votre déploiement et recueillir des informations sur tous les ordinateurs, pools et composants.

Important

Par défaut, le scénario AlwaysOn ne s’exécute pas dans votre déploiement. Vous devez le démarrer de manière explicite. Une fois démarré, il continue à s’exécuter jusqu’à ce que vous l’arrêtiez de manière explicite et l’état d’exécution est conservé entre les redémarrages de l’ordinateur. Pour plus d’informations sur les scénarios de démarrage et d’arrêt, consultez Using Start for the Centraled Logging Service to capture logs in Lync Server 2013 and Using Stop for the Centraled Logging Service in Lync Server 2013.

Lorsqu’un problème survient, démarrez un second scénario en rapport avec le problème signalé. Reproduisez le problème et arrêtez la journalisation pour le second scénario. Commencez vos recherches de journaux relatives au problème signalé. La collection agrégée de journaux génère un fichier journal qui contient des messages de suivi issus de tous les ordinateurs de l’étendue globale ou de site de votre déploiement. Si la recherche renvoie plus de données que vous ne pouvez raisonnablement en analyser (rapport signal-bruit où le bruit est trop élevé), exécutez une autre recherche avec des paramètres affinés. À ce stade, vous commencerez peut-être à remarquer certains modèles qui peuvent vous aider à appréhender plus étroitement le problème. Après deux ou trois recherches affinées, vous finirez par trouver des données pertinentes au problème et en déterminer la cause racine.

Pointe

Lorsqu’un scénario de problème est présenté dans Lync Server, commencez par vous demander « Que sais-je déjà sur le problème ? » Si vous quantifiez les limites du problème, vous pouvez éliminer une grande partie des entités opérationnelles dans Lync Server.
Considérez un exemple de scénario dans lequel vous savez que les utilisateurs n’obtiennent pas de résultats à jour lors de la recherche d’un contact. Il est inutile de rechercher des problèmes dans les composants multimédias, Voix Entreprise, conférence et un certain nombre d’autres composants. Vous ignorez peut-être toutefois où réside réellement le problème : sur le client ou du côté serveur ? Les contacts sont collectés à partir d’Active Directory par le réplicateur d’utilisateurs et remis au client par le serveur de carnets d’adresses (ABServer). ABServer obtient ses mises à jour à partir de la base de données RTC (où elles ont été écrites par le réplicateur d’utilisateurs) et les rassemble dans des fichiers de carnet d’adresses, par défaut à 01h30. Les clients Lync Server récupèrent le nouveau carnet d’adresses selon une planification aléatoire. Étant donné que vous savez comment fonctionne le processus, vous pouvez réduire votre recherche de la cause potentielle d’un problème lié aux données collectées à partir d’Active Directory par le réplicateur d’utilisateurs, l’ABServer ne récupérant pas et ne créant pas les fichiers de carnet d’adresses, ou les clients ne téléchargent pas le fichier de carnet d’adresses.