Denegaciones de Licencias y Defensa ante Auditoría

Dos conversaciones deciden lo que gastas en licencias de ingeniería, y rara vez entras en ninguna con la evidencia que necesitas. La primera es la renovación anual, donde el comercial del vendor tiene un presupuesto, un precio de tarifa y un número que alcanzar — y tú tienes una corazonada sobre si siquiera usas lo que ya pagas. La segunda es la auditoría o true-up, donde el vendor afirma lo que debes y la carga de rebatirlo cae sobre ti. Ambas se reducen a la misma pregunta: ¿puedes demostrar lo que tu organización usó de verdad?

Aquí está la parte fácil de pasar por alto: para los equipos para los que LiMon está pensado — servidores de licencias flotantes corriendo en tu propia red, sin phone-home — el vendor tampoco tiene esa respuesta. Tus servidores FlexLM, RLM, LM-X y DSLS no reportan uso a nadie. Eso aplica en ambas direcciones: es por lo que el vendor se apoya en precios de tarifa, recuentos de asientos y derechos de auditoría en lugar de tus números reales, y es por lo que, si no has guardado tu propio registro, no hay más número en la sala que el suyo.

Así que el trabajo es guardar ese registro. LiMon hace parte solo con vigilar tus servidores de licencias desde la red: los sondea de forma continua y almacena lo que ve, así que un histórico de uso se va acumulando desde el día que lo despliegas. Pero el polling tiene puntos ciegos que no puede cerrar por sí solo — las sesiones demasiado cortas para caer entre dos sondeos, y sobre todo las denegaciones, que un sondeo programado capta solo a vislumbres, si es que el vendor las expone en vivo. Los archivos de log que esos servidores ya escriben rellenan esos huecos, y cubren el tiempo anterior al despliegue de LiMon. Importarlos — desde la línea de comandos, la interfaz web o la API REST — es cómo completas el registro. La parte difícil, y la mayor parte de este artículo, es asegurarte de que lo que importas es lo bastante fiable como para ponerlo delante de un vendor.

¿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% — y, como LiMon almacena cada sondeo, un histórico que va corriendo desde el momento en que lo despliegas. Esa vista en vivo es lo que te avisa de que algo está ardiendo antes de que lleguen los tickets, y una ingesta nocturna de logs no puede hacerlo: cuando ve un evento, el usuario ya ha entrado y salido. Lo que los logs añaden es alcance — a lo que pasó entre sondeos, a las denegaciones que un sondeo en vivo no puede reconstruir por completo, y a los meses antes de que empezaras a mirar.

Esos logs deberían ser un registro limpio de ese histórico. 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 — y desde luego no es su negocio construir el caso que usarías contra ellos en la renovación.

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 — y el hueco juega en tu contra: das por ociosa una funcionalidad muy usada, recortas sus asientos para ahorrar, y te pasas el trimestre siguiente lidiando con las denegaciones.

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” — y es lo más valioso que te dan los logs. Tiene su propia sección más abajo.

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.

Denegaciones: prueba, no solo presión

Una denegación es el evento en el que un usuario pidió una licencia y el servidor no tenía ninguna que darle. FlexLM lo escribe como DENIED, RLM como DENY, LM-X y DSLS en sus propios registros de denegación. Cada uno nombra al usuario, la funcionalidad y el momento — y esa concreción es justo lo que a un argumento de renovación suele faltarle.

Así va la conversación normalmente sin ella. Los usuarios se quejan a ti. El comercial del vendor — cuya respuesta a cualquier pregunta de capacidad es “compra más asientos” — está encantado de ayudarte a hacer justo eso. El polling por sí solo te da la utilización, una señal fuerte de que vas al límite pero no un veredicto. Lo que no puedes hacer es poner un número al déficit, así que la negociación va sobre anécdotas y gana el relato del comercial.

Los datos de denegación cambian eso en las dos direcciones, que es el punto — son evidencia, no munición:

• A veces confirman la ampliación. Doscientas denegaciones al mes en una sola funcionalidad, repartidas por todo el equipo de ingeniería, es un problema real de capacidad. Ahora pides un número concreto de asientos respaldado por un recuento concreto, no suplicando.
• Otras tantas la desmontan. Saca los mismos datos y descubres que las denegaciones se concentran en tres usuarios lanzando trabajos batch nocturnos que colisionan diez minutos a las 2 de la mañana. Eso es un ajuste de horarios, no una compra — y te acabas de ahorrar una ampliación que habrías aprobado a ojo.

Los recuentos de denegaciones también te permiten cuantificar el coste de decir que no: horas de ingeniero perdidas esperando una licencia, trabajos que no corrieron. Ese es el número que finanzas quiere al lado de “coste de más asientos”, y el único que solo puedes producir desde los logs.

Dos advertencias, porque un recuento de denegaciones que no puedes defender es peor que ninguno. Primera: un usuario frustrado reintentando un checkout cinco veces en un minuto son cinco líneas DENIED pero una denegación real — cuenta los eventos de forma ingenua y exagerarás el problema y perderás credibilidad en cuanto el vendor pregunte. Segunda: algunos vendors solo escriben las denegaciones en un flujo aparte que tienes que activar (ver LM-X más abajo); si nunca se activó, la ausencia de denegaciones en el log no es prueba de que no las hubiera.

Defensa ante auditoría: tus números antes que su factura

Una auditoría de software — o su primo educado, el true-up — empieza con el vendor diciéndote lo que cree que desplegaste y usaste, y pidiéndote que lo reconcilies. La asimetría es todo el problema: llegan con una posición, construida a partir de tus recuentos de derechos, precios de tarifa, registros de despliegue y lo que hayas estado contractualmente obligado a autoreportar — y tú reaccionas a ella. No pueden ver tus servidores on-prem, pero eso no te ayuda si las únicas cifras de uso sobre la mesa son las que ellos infirieron. Lo único que lo iguala es haber mantenido de forma independiente tu propio registro continuo de lo que tus servidores sirvieron de verdad.

Ese registro es lo que construye una importación de logs limpia. En concreto, la evidencia de defensa ante auditoría es:

• Continua, no muestreada. Una auditoría puede mirar doce meses atrás o más. Un panel que solo guarda el detalle de los últimos 90 días no puede responder por un periodo del que ya no tienes datos. La evidencia hay que retenerla al menos durante todo tu plazo contractual, lo que significa que la importación tiene que haber estado corriendo antes de necesitarla — no puedes reconstruir un trimestre cuyos logs se rotaron y perdieron.
• Reconciliada, no en bruto. Entregar a un vendor un montón de debug logs le invita a interpretar las partes sucias a su favor. Lo que aguanta es un histórico de uso normalizado y deduplicado donde las sesiones LINGER, las relecturas y los artefactos de reconexión (más abajo) ya se han tenido en cuenta — un número que puedes explicar línea por línea.
• Consciente del pico. El licenciamiento por uso concurrente se cobra sobre tu pico de uso simultáneo, no sobre la media. Tu defensa se sostiene o cae sobre un pico exacto, y un pico exacto depende de acertar con los eventos de checkin (sáltatelos y toda sesión parece infinita — ver los modos de fallo).

Sé honesto contigo mismo sobre lo que esto hace y no hace. Tus logs son tu registro; no siempre cuadrarán con los del vendor al token, y no son un escudo legal. Lo que te compran es poder entrar en la conversación con un número defendible propio en lugar de aceptar el suyo — que suele ser la diferencia entre negociar y firmar.

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, y cada uno captura las denegaciones de forma un poco distinta.

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 — un log truncado es un hueco en tu rastro de auditoría.
• 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 — y un pico inflado es un número que no puedes defender.
• 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 — lo que lo hace el más apto para auditoría de los cuatro de serie. 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 — si estaba apagado, tu histórico de denegaciones de ese periodo sencillamente no existe.
• 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 que no recuperas.
• 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 — equivócate y tus números de auditoría estarán mal a favor del vendor.

Los modos de fallo silenciosos

La mayoría de las importaciones defectuosas fallan discretamente. Producen números que parecen razonables pero están ligeramente equivocados — que es el peor desenlace cuando vas a apostar una renovación o una respuesta a auditoría sobre ellos. 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 — y como el licenciamiento concurrente se cobra sobre el pico, es también la vía más rápida para convencerte de comprar asientos que no necesitas. 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, denegaciones incluidas, que cuando solo puedes describir lo que recuerdas.

Una pequeña lista de comprobación para auditoría

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) — y, en LM-X, que el logging de denegaciones esté realmente activado.
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, y de que retienes el histórico al menos durante todo tu plazo contractual.
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.
6. Saca un recuento de denegaciones de una funcionalidad con carga y contrástalo con la realidad — ¿son déficits distintos, o un usuario reintentando?

Si alguno de esos puntos devuelve sorpresas, el resto de tus números también está en riesgo — lo que significa que también lo está el caso que harías con ellos.

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 el nivel de plataforma para tu escala de servidores. El mantenimiento activo desbloquea las vistas de Intelligence — Defensa ante Auditoría y Ahorro entre ellas — paneles interactivos que exploras en vivo y exportas cuando un vendor o tu director financiero necesitan un documento. Esa es la diferencia entre “lo monitorizamos todo” y “podemos demostrarlo en la llamada de renovación”.