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.

Nota

ClsAgent puede buscar en los archivos que se trasladan al recurso compartido de archivos desde el equipo local. Después de que ClsAgent mueve los archivos al recurso compartido de archivos, ClsAgent no realiza el mantenimiento de limpieza y eliminación de archivos. Es necesario definir una tarea administrativa para supervisar el tamaño de los archivos en el recurso compartido de archivos y eliminarlos o archivarlos.

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.

Importante

De forma predeterminada, el escenario AlwaysOn no se ejecuta en la implementación. Es preciso iniciarlo explícitamente. Una vez iniciado, continuará ejecutándose hasta que se detenga explícitamente, y el estado en ejecución persistirá aunque se reinicien los equipos. Para obtener más información sobre los escenarios de inicio y detención, consulte Uso de Inicio para el servicio de registro centralizado para capturar registros en Lync Server 2013 y Usar detener para el servicio de registro centralizado en Lync Server 2013.

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.

Propina

Cuando se presenta con un escenario de problema en Lync Server, empiece por preguntarse "¿Qué ya sé yo del problema?" Si cuantifica los límites del problema, puede eliminar una gran parte de las entidades operativas en Lync Server.
Considere un escenario de ejemplo en el que sabe que los usuarios no están obteniendo resultados actualizados cuando buscan un contacto. No tiene sentido buscar problemas en los componentes multimedia, Telefonía IP empresarial, conferencias y otros componentes. Lo que quizás no sepa es dónde está realmente el problema: ¿en el cliente o es un problema del lado del servidor? El replicador de usuarios recopila los contactos de Active Directory y se entregan al cliente a través del servidor de libreta de direcciones (ABServer). ABServer obtiene sus actualizaciones de la base de datos de RTC (donde el replicador de usuarios las escribió) y las recopila en archivos de la libreta de direcciones a la 1:30 de forma predeterminada. Los clientes de Lync Server recuperan la nueva libreta de direcciones en una programación aleatoria. Como sabe cómo funciona el proceso, puede reducir la búsqueda de la causa potencial de un problema relacionado con los datos recopilados de Active Directory por el Replicador de usuarios, el ABServer no recupera y crea los archivos de libreta de direcciones o los clientes no descargan el archivo de libreta de direcciones.