Una de las novedades de Lync Server 2013, es la posibilidad de centralizar los distintos registros de todos los servidores de la implementación y de forma simultánea. Esto nos permite desde un único servidor, analizar los ficheros de registro que el resto de servidor nos envían a través del Agente del Servicio de Registro Centralizado (ClsAgent.exe).
Arquitectura del Servicio de Registro Centralizado
Como comentaba, todos los equipos de vuestra implementación de Lync tienen un servicio con el nombre Lync Server Centralized Logging Service Agent
Como vemos su estado es En ejecución, el tipo de inicio por defecto es Automático (inicio retrasado) y si vamos a las propiedades del servicio vemos que nos ofrecer información detalla del mismo
Explicación de MSFT sobre los agentes y servicios del registro centralizado:
Agente del servicio de registro centralizado ClsAgent.exe es el archivo ejecutable del servicio que se comunica con el controlador y recibe los comandos que el administrador ejecuta para el controlador. El agente se ejecuta como un servicio en cada equipo de Lync Server. Cuando el agente recibe un comando, lo ejecuta, envía mensajes a los componentes definidos para seguimiento y escribe los registros de seguimiento en el disco. También lee los registros de seguimiento de su equipo y envía los datos de seguimiento de nuevo al controlador cuando se solicitan. ClsAgent escucha los comandos en los siguientes puertos: TCP 50001, TCP 50002 y TCP 50003.
Controlador del servicio de registro centralizado ClsControllerLib.dll es el motor de ejecución de comandos del Shell de administración de Lync Server y de ClsController.exe. CLSControllerLib.dll envía los comandos Start, Stop, Flush y Search a ClsAgent. Cuando se envían comandos de búsqueda, los registros resultantes se devuelven a ClsControllerLib.dll y se agregan. El controlador es responsable de enviar comandos al agente, de recibir el estado de dichos comandos y de administrar los datos del archivo de registro que devuelven todos los agentes sobre cualquier equipo del ámbito de búsqueda, y de 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 se limita a un subconjunto de las características y funciones que están disponibles en el Shell de administración de Lync Server. Puede obtener ayuda para ClsController.exe en la línea de comandos; para ello, escriba ClsController en el directorio predeterminado C:\Archivos de programa\Archivos comunes\Microsoft Lync Server 2013\ClsAgent
Como vemos los puertos que se utilizan para este serivicio son en TCP el rango 50001-50003. Esto es algo que debemos tener muy en cuenta si tenemos VLAN filtradas por ACL o servidores EDGE en la DMZ, puesto que en la interface interna del EDGE debemos permitir la comunicación con el controlador a dichos puertos (esquema de un EDGE).
Si queremos comprobar que estos puertos están a la “escucha” podemos comprobarlo primero con netstat -an | find “.5000” y vemos que el estado es LISTENING
Sí ahora queremos verificar que controlador puede conectarse a alguno de estos puertos, podemos lanzar un telnet hacia el servidor con el puerto 50001 por ejemplo: telnet fqdn-controlador 50001. Una vez que lancemos el telnet podemos comprobar directamente en la pantalla de telnet si se ha conectado, puesto que nos aparece el cursor en la parte superior izquiera parpadeando
Y además si ejecutamos en el servidor al cual le hemos lanzado la conexión de telnet hacia el puerto 50001 un
netstat -an | find “.50001” podemos la dirección IP desde la cual nos hemos conectado y el estado a
ESTABLISHED
En caso contrario, debéis revisar las reglas de vuestros Firewalls puesto que en el Firewall de Windows ya vienen habilitadas las excepciones por defecto. Para verificarlo debéis acceder a la administración avanzada del Firewall, filtramos por Grupos en este caso el CS y vemos que tenemos los puertos 50001-50003 disponibles para conectarse desde cualquier origen
Una vez que hemos verificado que tenemos nuestra configuración del agente disponible, vamos a ver como podemos configurar la centralización de los registros en un servidor que hará las funciones de controlador. Lo primero que vamos a hacer, es revisar la configuración inicial del servicio. Para ello utilizaremos el siguiente cmdlet: Get-CsClsConfiguration (Información ampliada: http://technet.microsoft.com/es-es/library/jj619179.aspx). Vemos que se aplica a nivel global y distintas configuraciones en cuanto al tamaño de los ficheros (.ETL y .CACHE), su ubicación predeterminada (%temp%\Tracing), el % máximo de utilización de espacio en disco de los ficheros .CACHE (80), además del periodo de retención (14 días) entre otras opciones.
Estos son todos los cmdlets para configurar y gestionar el sersvicio de centralización de registros:
Abarcar todo en un solo artículo cómo podéis apreciar es inviable, pero vamos a ver como podemos configurar un escenario simple. Primero comentaros que todo se hace vía línea de comandos y para poder manenjar los agentes podemos hacerlo mediante ClsController.exe ubicado en C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent. Si ejecutamos el ClsController.exe sin parámetros nos creará automáticamente la carpeta Tracing en “%TEMP%\Tracing” y “C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing”. Las distintas ubicaciones vienen dadas por que en función del usuario que ejecute el comando le creará su carpeta Tracing, y la segunda carpeta Tracing es porque el servicio Lync Server Centralized Logging Service Agent se inicia como Servicio de Red
Una vez ejecutamos el comando sin modificadores nos mostrará en pantalla las distintas opciones disponibles:
ClsController (COMANDO) [(OPCIONES)] [(ÁMBITO)]
-start : Inicia la sesión de seguimiento de un escenario determinado. Opción obligatoria: scenario. Otra opción válida: duration
-stop : Detiene la sesión de seguimiento de un escenario determinado. Opción obligatoria y única válida: scenario
-query : Lista de consulta de escenarios que se están siguiendo. Opciones válidas: ninguna
-flush : Vacíe los registros y haga que estén disponibles para buscar de inmediato. Opciones válidas: ninguna
-update : Actualice la duración activa (no predeterminada) en la que debe seguirse el escenario. Opción obligatoria y única válida: duration
-search : Registros de búsqueda. Los resultados se devuelven en un archivo de texto. Opciones válidas: matchall, matchany, skipnetworklogs, keepcache, sta
rttime, endtime, loglevel, components, correlationids, uri, callid, confid, phone, ip, sipcontents
-scenario: nombre del escenario. Nombres de escenarios válidos según lo especificado al final
-duration: duración (minutos) en la que realizar el seguimiento del escenario determinado. Duración predeterminada: 4 horas
-matchall: especifique esto para requerir que la búsqueda cumpla todos los criterios especificados.
-matchany: especifique esto para requerir que la búsqueda cumpla alguno de los criterios especificados. Esta opción es la predeterminada.
-skipnetworklogs: si se omiten los registros especificados en el uso compartido de red (si está configurado). Esto mejora el rendimiento de la búsqueda si no ne
cesita datos de registros de red
-keepcache : si se especifica, el archivo .cache intermedio, junto con los resultados de búsqueda, se crea en el directorio actual
-starttime: (marca de tiempo) marca de tiempo desde la que buscar las entradas del registro
-endtime: (marca de tiempo) marca de tiempo para buscar las entradas del registro
-loglevel: (fatal|error|warn|info|verbose|noise): nivel de registro menos grave en el que buscar. Por ejemplo, si se especifica ‘advertencia’, la búsqueda se limitará a ‘warn’, ‘error’ y ‘fatal’
-components: lista de nombres de componentes separados por comas para restringir el ámbito de la búsqueda
-correlationids : lista de ids. separada por comas para restringir el ámbito de búsqueda
-uri: ámbito de uri para el comando de búsqueda. Debe ser una coincidencia exacta
-callid: ámbito de Id. de llamada para el comando de búsqueda. Debe ser una coincidencia exacta
-confid: ámbito de Id. de conferencia para el comando de búsqueda. Debe ser una coincidencia exacta
-phone: ámbito de número de teléfono para el comando de búsqueda. Debe ser una coincidencia exacta
-ip: ámbito de dirección ip para el comando de búsqueda. Debe ser una coincidencia exacta
-Pools: lista separada por comas de fqdn de grupos
-Computers : lista separada por comas de fqdn de PC
Nombres de escenarios válidos:
AlwaysOn
MediaConnectivity
ApplicationSharing
AudioVideoConferencingIssue
HybridVoice
IncomingAndOutgoingCall
VoiceMail
IMAndPresence
AddressBook
DeviceUpdate
LYSSAndUCS
CLS
SP
WAC
UserReplicator
HostedMigration
MonitoringAndArchiving
LILRLegacy
LILRLYSS
MeetingJoin
RGS
CPS
XMPP
CAA
ACPMCU
Authentication
HADR
Powershell
FilterApps
Los comandos más comunes son los siguientes:
-
ClsController.exe -start –scenario <scenario> –pools <pool fqdn>
-
ClsController.exe -stop –scenario <scenario> –pools <pool fqdn>
-
ClsController.exe -flush –pools <pool fqdn>
-
ClsController.exe -search –pools <pool fqdn> –components <component> –loglevel <loglevel>
Ejemplo: ClsController.exe -start -scenario MediaConnectivity -computers srv-lync02.asirsl.com
Si accemos al servidor SRV-LYNC02.ASIRSL.COM vemos que en la ubicación de la carpeta Tracing del servicio de red que ya tenemos nuestro fichero .ETL
Como he habilitado -scenario MediaConnectivity lanzo una llamada desde mi cliente Lync y compruebo que el tamaño del fichero de Log ha aumentado de 64KB a 2.112KB
Ahora pararé el registro también desde el servidor remoto con el comando: ClsController.exe –stop-scenario MediaConnectivity -computers srv-lync02.asirsl.com
Sí ahora tratamos de acceder nuevamente a la carpeta en donde teníamos los ficheros .ETL veremos que ahora tenemos dos ficheros: .CACHE y .HDR
Mientras que la captura está iniciada el fichero es el .ETL pero una vez finalizada se convierten en .CACHE y HDR. Si abrimos el fichero .HDR podremos ver la información sobre la captura realizada:
El fichero de la captura es el .CACHE, pero al ser un binario no podemos abrirlo directamente con el Snooper (
Microsoft Lync Server 2013 Debugging Tools), para ello primero debemos ejecutar
Search-CsClsLogging para exportar el registro a txt. Para ello debemos ejecutar el siguiente cmdlet:
Search-CsClsLogging -Computers fqdn_servidor -OutputFilePath <ruta_fichero_exportado>Si ahora vamos a la carpeta C:\Temp tendremos el fichero de registro exportado a .txt el cual podremos abrir ahora desde Snooper que será más sencillo de analizar
Vamos a File – Open File (Ctrl + O) y luego desde el mini explorar buscar el fichero exportado a txt anteriormente con Search-CsClsLogging
Ahora podremos analizarlo con más facilidad
Como podemos apreciar es una herramienta muy pontente, y nos da infinidad de posiblidades. En el listado de cmdlets expuestos tenéis las URL que os llevarán a la página oficial de MSFT para explicar cada uno de ellos con más nivel de detalle. Todas las opciones las tenemos disponibles con ClsController.exe pero también comos os había comentado anteriormente mediante cmdlets PowerShell. Claramente con PowerShell tenemos más flexibilidad y potencia, ahora ya es cuestión de cada uno de sus necesidades y con lo que se sienta más cómodo. Lo que yo había hecho con
ClsController.exe -start se puede hacer y más amplicado con
Start-CsClsLogging.
Como resumen yo lo que había hecho es primero iniciar y parar la captura, para posteriormente con Search-CsClsLogging exportar el fichero a .txt para abrirlo con Snooper de forma gráfica. Podemos iniciar el registro de un servidor o de toda la implementación, filtrarlo por fechas, sesiones, etc.. súper útil.
Espero que os sea de utilidad!!
