Buenas Prácticas de Importación de Logs

LiMon monitoriza tus servidores de licencias desde la red en tiempo real. Además, te permite importar los archivos de log que esos servidores escriben — desde la línea de comandos, la interfaz web o la API REST. Este artículo trata de por qué ese segundo canal importa incluso cuando ya tienes monitorización en tiempo real, qué contiene de verdad el log de cada vendor y qué separa una importación fiable de una que va corrompiendo tus números en silencio.

¿La monitorización en tiempo real no hace redundante la importación de logs?

Es una pregunta razonable. Los logs de los servidores contienen los checkouts, los checkins y normalmente algo más, según el vendor. A primera vista podrías pensar que una ingesta de logs programada duplica lo que el polling de red ya hace — y que podrías quedarte con uno u otro. No exactamente.

El polling de red te da el ahora: quién tiene qué ocupado en este momento, si el daemon está sano, si el pool está al 100%. Es lo que te avisa de que algo está ardiendo antes de que lleguen los tickets. Una ingesta nocturna de logs no puede hacer eso — cuando ve un evento, el usuario ya ha entrado y salido.

Los logs son el histórico, y deberían ser un registro limpio de él. Ya no lo son y eso es a propósito. Hoy la mayoría de vendors lo dicen de forma explícita en las cabeceras de los archivos: el contenido es “solo para depuración” y no apto para análisis de uso. Eventos de checkin/checkout desordenados, timestamps que faltan, relecturas del archivo de licencia que duplican líneas de registro, reconexiones de cliente que generan entradas que ningún usuario real produjo — la lista es larga y la intención está clara. Los vendors preferirían que comprases su suite de análisis propietaria, o que contrataras a sus servicios profesionales, antes que extraer información útil de los logs gratuitos que ya producen.

Sus clientes son las casas comerciales de software que licencian a través de ellos, no tú. No es su negocio ayudarte a que les compres menos a sus clientes.

Así que el valor de importar los logs no es que sean perfectos. Es que, tratados con cuidado, rellenan tres huecos que el polling por sí solo deja abiertos.

Lo que el polling se pierde y los logs sí recogen

Sesiones cortas. El polling es programado. Si un checkout empieza y termina entre dos sondeos, LiMon no lo ve. Para un editor como NX, que los ingenieros dejan abierto durante horas, perder alguna sesión es un error de redondeo. Para trabajos de ABAQUS que resuelven una simulación FEA en menos de un minuto, el polling puede hacer que una funcionalidad parezca ociosa cuando en realidad tu equipo la usa habitualmente. El archivo de log tiene la traza completa.

Denegaciones. El polling te dirá que el pool está al 100%. El log te dirá quién intentó coger una licencia y se quedó sin ella. Esa es la diferencia entre “estamos usando todo lo que tenemos” y “no tenemos suficiente”. Sin esa información, la contención solo sale a la luz a través de tickets y llamadas — momento en el que ya has perdido la discusión con finanzas sobre por qué la renovación necesita más asientos. Los recuentos de denegaciones también te permiten cuantificar el coste real de decir que no, que es justo el número que necesitas al lado del “coste de más asientos”.

Eventos del lado servidor que la vista de red no expone. Los vendors guardan en los logs información realmente útil que el propio protocolo no revela. Un servidor que está fallando al servir algunas de sus propias licencias. Clientes con la versión equivocada del programa. Peticiones de funcionalidades que no tienes licenciadas. La mayoría de estos eventos son silenciosos hasta que vas a buscarlos, y solo los encuentras en los logs.

Las denegaciones son la razón por la que la importación de logs vale la pena. Los usuarios se quejan. El comercial del vendor te sugiere ampliar el pool. El polling por sí solo te da la utilización — una señal fuerte, no un veredicto. El log te da los eventos de denegación en sí: a quién rechazaron, en qué funcionalidad, con qué frecuencia. Juntas, las dos fuentes argumentan en las dos direcciones. A veces confirman el caso para más asientos. Otras veces muestran que las denegaciones se concentran en un puñado de equipos compitiendo por unas licencias escasas, y algún ajuste de horarios puede ahorrarte la ampliación.

Qué contiene realmente cada formato

Los formatos de log soportados se parecen vistos desde lejos — timestamps, nombres de usuario, nombres de funcionalidades — pero cada uno tiene sus propios huecos.

Debug log de FlexLM (lmgrd -l <ruta>)

El más rico del grupo. Registra OUT, IN, DENIED, QUEUED, salud del vendor daemon, reinicios de lmgrd y relecturas del archivo de licencia. Pegas:

• El comportamiento de rotación por defecto trunca el archivo al reiniciar. Arranca siempre lmgrd con -l +ruta para que el log haga append en lugar de sobrescribir.
• Las licencias prestadas (LINGER) aparecen como sesiones largas incluso después de que el usuario se haya desconectado. Sin filtrarlas, contarás de más la concurrencia.
• Algunos vendor daemons emiten caracteres no ASCII en nombres de usuario o de host en el locale del sistema, que rara vez es lo que un parser ingenuo espera.

Report log de RLM (REPORTLOG +<ruta>)

Diseñado para contabilidad más que para depuración. Formato más limpio que el de FlexLM, con registros explícitos START/PRODUCT/OUT/IN/DENY/STOP. Pegas:

• El prefijo + en la ruta es obligatorio para el modo append. Sin él, cada reinicio de RLM borra el archivo.
• Los report logs no incluyen eventos de cola. Si te importa la presión de cola, también necesitas el rlm.log estándar.
• Las licencias en roaming pueden extenderse más allá de la sesión real del usuario durante horas.

Log de uso de LM-X

LM-X escribe registros estructurados por checkout por defecto, lo que hace el parseo relativamente directo. Pegas:

• LM-X separa el “uso de licencia” de las “denegaciones”. Puede que necesites activar ambos con LICENSE_LOG=1 y asegurarte de capturar el log de denegaciones.
• Los logs por servidor necesitan consolidación si tienes un pool redundante; LM-X no los fusiona automáticamente.

Histórico de uso de DSLS

DSLS (el servidor de licencias de Dassault Systèmes) guarda el uso en su propia base de datos que exportas con DSLicSrv -admin. Pegas:

• DSLS rota su histórico según su propia agenda; si no exportas al menos a diario, pierdes granularidad.
• Los productos basados en tokens (CATIA, 3DEXPERIENCE) reportan consumo de tokens, no de asientos. El mapeo de token a asiento varía según el producto y la versión.

Los modos de fallo silenciosos

La mayoría de las importaciones malas no fallan a gritos. Producen números que parecen razonables pero están ligeramente equivocados. Estos son los patrones a vigilar tanto si estás montando tu propio pipeline como si estás evaluando el de otro.

Rotación sin solapamiento. Los logs rotan a medianoche, el job de importación corre a la 1 de la mañana, y cualquier cosa escrita entre medias desaparece. La solución es mantener el archivo de la rotación anterior legible al menos 48 horas y rastrear la posición de importación por offset de bytes o hash de contenido, no por timestamp del archivo.

Desfase de zona horaria. Los servidores de licencias corren en la zona horaria que tenga el SO — a veces UTC, a veces local, a veces local sin gestión de horario de verano. Cada cambio semestral de horario se convierte en un hueco de una hora o un duplicado de una hora. Verifica lo que el servidor emite de verdad antes de normalizar.

Codificación y locale. Los nombres de usuario que vienen de Active Directory suelen llevar caracteres acentuados. FlexLM y RLM los emiten en el locale del sistema (CP1252 en Windows, UTF-8 en la mayoría de Linux modernos). Müller se convierte en M?ller si tu importador asume UTF-8 en todas partes, y tus informes por usuario dejan de cuadrar con la realidad.

Líneas truncadas bajo carga. Cuando el servidor de licencias está ocupado y el directorio de log vive en almacenamiento lento (NFS es un culpable habitual), las líneas individuales se pueden truncar a media escritura. Un parser robusto marca esas como errores de parseo en lugar de interpretar en silencio una línea parcial como algo que no es.

Saltarse los eventos IN. Filtra solo OUT y DENIED y todos los checkouts parecen durar para siempre. Este es el motivo más común por el que los informes de concurrencia muestran picos absurdos. Importa siempre el ciclo de vida completo del evento, aunque tus informes solo miren los timestamps de inicio.

Polling y logs trabajando juntos

La parte difícil no es parsear los logs. Es combinarlos con lo que el polling ya vio, sin contar dos veces y sin dejar huecos.

LiMon se encarga de esa reconciliación en segundo plano. Las importaciones se pueden disparar bajo demanda o programadas, desde la línea de comandos o desde la interfaz web, y los dos caminos se coordinan entre sí — una importación automática nocturna no va a pisar la subida ad-hoc de un operador para el mismo servidor. Una vez los eventos en bruto están dentro, LiMon reconstruye el rango de fechas afectado, fusionando la nueva evidencia del log con las sesiones que ya tenía del polling, para que los paneles y los informes de esas fechas reflejen una imagen combinada en lugar de dos versiones de la verdad.

Ese registro combinado es lo que alimenta el resto del producto: las vistas de optimización de coste que siguen la utilización y la contención en el tiempo, y los informes ejecutivos para negociaciones de renovación y respuestas a auditoría. Los informes son al final lo que justifica el trabajo cuidadoso de importación — una conversación de renovación va muy distinta cuando puedes entregar al vendor un desglose limpio de doce meses que cuando solo puedes describir lo que recuerdas.

Una pequeña lista de comprobación

Si estás revisando tu propio flujo de trabajo hoy, sea cual sea la herramienta:

1. Verifica si tus servidores de licencias corren con logging en modo append (lmgrd -l +ruta, REPORTLOG +ruta).
2. Confirma la zona horaria que el servidor emite de verdad en sus archivos de log.
3. Asegúrate de que tu importador rastrea posición por offset de bytes, no por timestamp del archivo.
4. Revisa unas pocas líneas con caracteres no ASCII y confirma que llegan correctamente a tu almacén.
5. Coge una funcionalidad y reconcilia el recuento de eventos OUT con el de IN — deberían estar cerca. Un pequeño desfase por sesiones abiertas al apagar es normal.

Si alguno de esos puntos devuelve sorpresas, el resto de tus números también está en riesgo.

Dónde encaja LiMon

La mayoría de los equipos que gestionan licencias de ingeniería tienen mejores cosas que hacer que mantener su propio pipeline de parseo. LiMon hace el polling, la ingesta de logs y la reconciliación en un único stack on-premises — sin agentes en los servidores de licencias, sin nube, sin envío de datos. Solicita una evaluación para probar el flujo, y elige Standard o Professional para la escala de servidores, los informes de defensa ante auditoría y los informes de ahorro que cierran el círculo entre “lo monitorizamos todo” y “podemos demostrarlo en la llamada de renovación”.