Visão geral do Serviço de Log Centralizado no Lync Server 2013

 

Tópico última modificação: 22-02-2013

O Serviço de Log Centralizado foi projetado para fornecer um meio para a coleta controlada de dados, com um escopo amplo ou estreito. Você pode coletar dados de todos os servidores na implantação simultaneamente, definir elementos específicos para rastrear, definir sinalizadores de rastreamento e retornar resultados de pesquisa de um único computador ou uma agregação de todos os dados de todos os servidores. O Serviço de Log Centralizado é executado em todos os servidores em sua implantação. A arquitetura do Serviço de Log Centralizado é composta pelos seguintes agentes e serviços:

• O agente de serviço de log ClsAgent.exe é o executável de serviço que se comunica com o controlador e recebe os comandos que o controlador é emitido pelo administrador. O agente é executado como um serviço em cada computador do Lync Server. Quando o agente recebe um comando, ele executa o comando, envia mensagens para os componentes definidos para rastreamento e grava os logs de rastreamento no disco. Ele também lê os logs de rastreamento de seu computador e envia os dados de rastreamento de volta para o controlador quando solicitado. O ClsAgent escuta comandos nas seguintes portas: TCP 50001, TCP 50002 e TCP 50003.

• O controlador de serviço de log ClsControllerLib.dll é o mecanismo de execução de comando para o Shell de Gerenciamento do Lync Server e para ClsController.exe. CLSControllerLib.dll os comandos Iniciar, Parar, Liberar e Pesquisar para o ClsAgent. Quando comandos de pesquisa são enviados, os logs resultantes são retornados ao ClsControllerLib.dll e agregados. O controlador é responsável por enviar comandos para o agente, receber o status desses comandos e gerenciar os dados do arquivo de log de pesquisa conforme eles são retornados de todos os agentes em qualquer computador no escopo de pesquisa e agregar os dados de log em um conjunto de saída significativo e ordenado. As informações nos tópicos a seguir se concentram no uso do Shell de Gerenciamento do Lync Server. ClsController.exe está limitado a um subconjunto dos recursos e funções que estão disponíveis no Shell de Gerenciamento do Lync Server. A ajuda para ClsController.exe ClsController está disponível na linha de comando digitando o diretório padrão C:\Arquivos de Programas\Arquivos Comuns\Microsoft Lync Server 2013\ClsAgent.

Comunicações do ClsController com o ClsAgent

Você emite comandos usando a interface de linha de comando do Windows Server ou usando o Shell de Gerenciamento do Lync Server. Os comandos são executados no computador que você fez logon e enviados ao ClsAgent localmente, ou para outros computadores e pools em sua implantação.

O ClsAgent mantém um arquivo de índice de todos os arquivos .CACHE que ele tem na máquina local. O ClsAgent os aloca de forma que fiquem distribuídos uniformemente nos volumes definidos na opção CacheFileLocalFolders, nunca consumindo mais de 80% de cada volume (isto é, o local do cache local e a porcentagem são configuráveis usando o cmdlet Set-CsClsConfiguration). O ClsAgent é responsável também por expirar arquivos de log de rastreamento de eventos antigos no cache (.etl) para fora da máquina local. Após duas semanas (isto é, o cronograma configurável usando o cmdlet Set-CsClsConfiguration, esses arquivos são copiados para um compartilhamento de arquivos e excluído do computador local. Para obter detalhes, consulte Set-CsClsConfiguration. Quando uma solicitação de pesquisa é recebida, os critérios de pesquisa são usados para selecionar o conjunto de arquivos .etl em cache para fazer a pesquisa baseada nos valores no índice mantido pelo agente.

Nota

Arquivos que são movidos do computador local para o compartilhamento de arquivos podem ser pesquisados pelo ClsAgent. Assim que o ClsAgent move os arquivos para o compartilhamento de arquivos, a expiração e remoção de arquivos não são mantidas pelo ClsAgent. Você deve definir uma tarefa administrativa para monitorar o tamanho dos arquivos no compartilhamento de arquivos e excluí-los ou arquivá-los.

Os arquivos de log resultantes podem ser lidos e analisados usando várias ferramentas, incluindo Snooper.exe e qualquer ferramenta que possa ler um arquivo de texto, como Notepad.exe. Snooper.exe faz parte das Ferramentas de Depuração do Lync Server 2013 e está disponível como um download da Web de https://go.microsoft.com/fwlink/?LinkId=285257.

Assim como o OCSLogger, o Serviço de Log Centralizado tem vários componentes para rastrear e fornece opções para selecionar sinalizadores, como TF_COMPONENT e TF_DIAG. O Serviço de Log Centralizado também retém as opções de nível de log do OCSLogger.

A vantagem mais importante de usar o Shell de Gerenciamento do Lync Server em relação ao ClsController de linha de comando é que você pode configurar e definir novos cenários usando provedores selecionados direcionados ao espaço de problema, sinalizadores personalizados e níveis de registro em log. Os cenários disponíveis no ClsController são limitados àqueles definidos pelo executável.

Nas versões anteriores, o OCSLogger.exe era fornecido para permitir que os administradores e equipe de suporte coletassem arquivos de rastreamento de computadores na implantação. O OCSLogger, apesar de todos seus pontos fortes, tinha um problema. Você podia apenas coletar logs em um computador, em um dado momento. Você podia fazer logon em vários computadores usando cópias separadas do OCSLogger, mas terminava com vários logs e sem uma maneira fácil de agregar os resultados.

Quando um usuário solicita uma pesquisa de log, o ClsController determina quais máquinas devem receber as solicitações (isto é, baseado nos cenários selecionados). Ele também determina se a pesquisa precisa ser enviada ao compartilhamento de arquivos quando os arquivos .etl salvos forem localizados. Quando os resultados da pesquisa retornam ao ClsController, o controlador funde os resultados em um único conjunto de resultados ordenado pelo horário, que é apresentado ao usuário. Os usuários podem salvar os resultados da pesquisa em sua máquina local para análises posteriores.

Ao iniciar uma sessão de log, você especifica cenários que são relativos ao problema que está tentando resolver. Você pode ter dois cenários sendo executados a qualquer momento. Um desses cenários deve ser o cenário AlwaysOn (sempre ativado). Como o nome implica, ele deve estar sempre sendo executado em sua implantação, coletando informações em todos os computadores, pools e componentes.

Importante

Por padrão, o cenário AlwaysOn não está em execução em sua implantação. É necessário iniciar explicitamente o cenário. Assim que for iniciado, ele continuará sendo executado até que seja interrompido explicitamente, e o estado de execução persistirá nas reinicializações dos computadores. Para obter detalhes sobre como iniciar e parar cenários, consulte Using Start for the Centralized Logging Service to capture logs in Lync Server 2013 and Using Stop for the Centralized Logging Service in Lync Server 2013.

Quando ocorrer um problema, inicie um segundo cenário que está relacionado ao problema relatado. Reproduza o problema e interrompa o log para o segundo cenário. Inicie suas pesquisas de log relativas ao problema relatado. A coleção agregada de logs produz um arquivo de log que contém mensagens de rastreamento de todos os computadores em seu site ou escopo global de sua implantação. Se a pesquisa retornar mais dados que você possa analisar (geralmente conhecido como razão sinal-ruído, onde o ruído é muito alto), execute outra pesquisa com parâmetros mais restritos. Neste ponto, você pode começar a notar padrões que são exibidos e que podem ajudar a obter um foco mais claro do problema. Finalmente, após realizar algumas pesquisas refinadas, você poderá encontrar dados que sejam relevantes ao problema e descobrir a causa.

Ponta

Quando for apresentado um cenário de problema no Lync Server, comece se perguntando "O que eu já sei sobre o problema?" Se você quantificar os limites do problema, poderá eliminar uma grande parte das entidades operacionais no Lync Server.
Considere um exemplo de cenário no qual você sabe que os usuários não estão recebendo resultados atualizados ao procurar por um contato. Não há nenhum ponto em procurar problemas nos componentes de mídia, Enterprise Voice, conferência e vários outros componentes. Você pode não saber onde está realmente o problema: no cliente, ou é um problema no lado dos servidor? Os contatos são coletados do Active Directory pelo Replicador de Usuários e entregues ao cliente por meio do ABServer (Servidor de Catálogo de Endereços). O ABServer obtém suas atualizações dos banco de dados RTC (onde o User Replicator os grava) e os coleta nos arquivos do catálogo de endereços, por padrão, às 1:30 AM. Os clientes do Lync Server recuperam o novo catálogo de endereços em uma agenda aleatória. Como você sabe como o processo funciona, é possível reduzir a pesquisa da possível causa para um problema relacionado aos dados coletados do Active Directory pelo Replicador de Usuários, o ABServer não recuperar e criar os arquivos do catálogo de endereços ou os clientes não baixarem o arquivo do catálogo de endereços.