Información general del servicio de registro centralizado en Lync Server 2013

Última modificación del tema: 2013-02-22

El servicio de registro centralizado está diseñado para proporcionar un medio para la recopilación controlada de datos, con un alcance amplio o estrecho. Puede recopilar datos de todos los servidores de la implementación al mismo tiempo, definir elementos específicos para realizar el seguimiento, establecer marcas de seguimiento y devolver resultados de búsqueda desde un único equipo o una agregación de todos los datos de todos los servidores. El servicio de registro centralizado se ejecuta en todos los servidores de la implementación. La arquitectura del servicio de registro centralizado se compone de los siguientes agentes y servicios:

• El agente de servicio de registro centralizado ClsAgent.exe es el ejecutable del servicio que se comunica con el controlador y recibe los comandos que emite el administrador. El agente se ejecuta como servicio en cada equipo de Lync Server. Cuando el agente recibe un comando, ejecuta el comando, envía mensajes a los componentes definidos para el seguimiento y escribe los registros de seguimiento en disco. También lee los registros de seguimiento para su equipo y envía los datos de seguimiento de nuevo al controlador cuando se solicita. El ClsAgent escucha los comandos en los puertos siguientes: TCP 50001, TCP 50002, y TCP 50003.

• El controlador de servicio de registro centralizado ClsControllerLib.dll es el motor de ejecución de comandos para el Shell de administración de Lync Server y para ClsController.exe. CLSControllerLib.dll envía los comandos Start, Stop, Flush y Search al ClsAgent. Cuando se envían los comandos de búsqueda, los registros de resultados se devuelven a ClsControllerLib.dll y se agregan. El controlador es responsable de enviar comandos al agente, recibir el estado de esos comandos y administrar los datos del archivo de registro de búsqueda, ya que se devuelven de todos los agentes en cualquier equipo en el ámbito de búsqueda, y agregar los datos de registro en un conjunto de resultados significativo y ordenado. La información de los temas siguientes se centra en el uso del Shell de administración de Lync Server. ClsController.exe está limitado a un subconjunto de las características y funciones que están disponibles en el Shell de administración de Lync Server. La ayuda para ClsController.exe está disponible en la línea de comandos escribiendo ClsController en el directorio predeterminado C:\Archivos de programa\Archivos comunes\Microsoft Lync Server 2013\ClsAgent.

Comunicaciones de ClsController con ClsAgent

Emite comandos con la interfaz de la línea de comandos de Windows Server o con el Shell de administración de Lync Server. Los comandos se ejecutan en el equipo donde haya iniciado sesión y se envían a ClsAgent de forma local o a los demás equipos y grupos de la implementación.

ClsAgent mantiene un archivo de índice de todos los archivos .CACHE disponibles en la máquina local. ClsAgent los asigna de manera que se distribuyan uniformemente entre todos los volúmenes definidos por la opción CacheFileLocalFolders, sin consumir nunca más del 80 % de cada volumen (es decir, la ubicación de la memoria caché local y el porcentaje se pueden configurar con el cmdlet Set-CsClsConfiguration). ClsAgent también es responsable de limpiar los archivos de registro de seguimiento de eventos (.etl) antiguos almacenados en la memoria caché de la máquina local. Después de dos semanas (que es el período de tiempo que se puede configurar con el cmdlet Set-CsClsConfiguration), estos archivos se copian a un recurso compartido de archivos y se eliminan del equipo local. Para más detalles, consulte Set-CsClsConfiguration. Cuando se recibe una solicitud de búsqueda, se usan los criterios de búsqueda para seleccionar el conjunto de archivos .etl en la memoria caché a fin de realizar la búsqueda en función de los valores del índice que mantiene el agente.

Los archivos de registro resultantes se pueden leer y analizar con distintas herramientas, incluyendo Snooper.exe y cualquier herramienta que pueda leer un archivo de texto, como Notepad.exe. Snooper.exe forma parte de las Herramientas de depuración de Lync Server 2013 y está disponible como descarga web desde https://go.microsoft.com/fwlink/?LinkId=285257.

Al igual que OCSLogger, el servicio de registro centralizado tiene varios componentes con los que realizar el seguimiento y proporciona opciones para seleccionar marcas, como TF_COMPONENT y TF_DIAG. El servicio de registro centralizado también conserva las opciones de nivel de registro de OCSLogger.

La ventaja más importante de usar el Shell de administración de Lync Server en lugar de ClsController de la línea de comandos es que puede configurar y definir nuevos escenarios con proveedores seleccionados que se destinan al espacio del problema, marcas personalizadas y niveles de registro. Los escenarios disponibles para ClsController se limitan a los que están definidos para el archivo ejecutable.

En versiones anteriores, OCSLogger.exe se proporcionaba para que los administradores y el personal de soporte pudieran recopilar archivos de seguimiento de los equipos de la implementación. A pesar de sus ventajas, OCSLogger tenía una limitación. Solo se podían recopilar los registros de un equipo al mismo tiempo. Podía realizar el registro de varios equipos usando copias diferentes de OCSLogger, pero al final obtenía varios registros y ninguna manera sencilla de agregar los resultados.

Cuando un usuario solicita una búsqueda de registros, ClsController determina a qué máquinas se enviará la solicitud (en función de los escenarios seleccionados). También determina si es necesario enviar la búsqueda al recurso compartido de archivos donde se encuentran los archivos .etl guardados. Cuando los resultados de búsqueda se devuelven a ClsController, el controlador combina los resultados en un único conjunto de resultados ordenados por tiempo, que se presenta al usuario. Los usuarios pueden guardar los resultados de búsqueda en la máquina local para su posterior análisis.

Cuando inicia una sesión de registro, especifica los escenarios relativos al problema que está intentando resolver. Puede tener dos escenarios en ejecución al mismo tiempo. Uno de los dos tiene que ser el escenario AlwaysOn. Como su nombre indica, siempre necesita estar en ejecución en la implementación, recopilando información sobre todos los equipos, grupos y componentes.

Cuando se produce un problema, inicie un segundo escenario relacionado con el problema notificado. Reproduzca el problema y detenga el registro del segundo escenario. Empiece las búsquedas de registros relativas al problema notificado. La colección agregada de registros produce un archivo de registro que contiene mensajes de seguimiento de todos los equipos del ámbito de sitio o global de la implementación. Si la búsqueda devuelve más datos de los que es razonable analizar (lo que normalmente se conoce como relación señal-ruido, en la que el ruido es demasiado alto), ejecute otra búsqueda con parámetros más limitados. En este punto, puede empezar a observar que aparecen patrones que le ayudarán a centrarse mejor en el problema. Por último, después de realizar un par de búsquedas más refinadas, podrá encontrar los datos relativos al problema y averiguar la causa principal.