Denegaciones de licencias y defensa ante auditorías

Dos conversaciones deciden lo que gastas en licencias de ingeniería, y rara vez llegas a ninguna con la evidencia que necesitas. La primera es la renovación anual: el comercial del proveedor tiene una oferta, un precio de tarifa y un objetivo que cumplir. Tú tienes una intuición sobre si realmente utilizas lo que ya pagas.

La segunda es la auditoría o el true-up, donde el proveedor afirma lo que debes y la carga de rebatirlo cae sobre ti. Ambas conversaciones se reducen a la misma pregunta: ¿puedes demostrar lo que tu organización utilizó de verdad?

Esta es la parte fácil de pasar por alto. En los entornos para los que LiMon está pensado, con servidores de licencias flotantes en tu propia red y sin phone-home, el proveedor tampoco tiene esa respuesta. Tus servidores no envían datos de uso fuera de tu red. Eso juega en ambas direcciones: el proveedor llega con precios de tarifa, derechos adquiridos, cláusulas de auditoría y los registros que el contrato te obligue a facilitar. Tu uso real es lo que tú puedas demostrar. Si no has conservado tu propio histórico, no hay más cifra medida en la reunión que la suya.

Por eso necesitas conservar ese registro. LiMon cubre una parte al vigilar tus servidores de licencias desde la red: los consulta continuamente y almacena lo que ve, de modo que el histórico empieza a crecer desde el día del despliegue.

El sondeo sigue teniendo puntos ciegos. Una sesión puede empezar y terminar entre dos consultas, y algunas denegaciones solo aparecen en el log del servidor. Esos logs también pueden cubrir el periodo anterior a LiMon. Importarlos — desde la línea de comandos, la interfaz web o la API REST — completa la imagen. La parte difícil, y el tema central de este artículo, es conseguir un resultado lo bastante fiable como para presentarlo ante un proveedor.

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

Es una pregunta razonable. Los logs del servidor contienen checkouts, checkins y normalmente algo más, según el gestor de licencias y su configuración. A primera vista, importar logs puede parecer un duplicado del sondeo de red, como si pudieras elegir uno u otro. No es así.

El sondeo de red te da el ahora: quién tiene cada licencia, si el daemon está sano y si el pool ha llegado al 100 %. Como LiMon guarda cada consulta, también construye un histórico muestreado desde el momento del despliegue. Esa vista en tiempo real te avisa de un problema antes de que lleguen los tickets. Una importación posterior no puede hacer eso.

Los logs aportan alcance: muestran lo que ocurrió entre consultas, las denegaciones que una consulta en vivo no puede reconstruir y el periodo anterior al inicio de la monitorización.

No existe un único “log del proveedor” limpio. FlexNet Publisher describe su debug log como salida de diagnóstico y lo separa expresamente de los informes de uso. El report log de RLM, en cambio, está documentado para generar informes e incluso autentica su contenido. LM-X y DSLS solo exponen determinada actividad cuando se activan las opciones correctas de logging o trazabilidad.

Incluso los formatos más completos son registros operativos, no tu argumento de renovación. Hay que interpretar reinicios, relecturas, reintentos, rotaciones y sesiones incompletas. Convertirlos en evidencia que puedas defender es tarea tuya.

Conviene entender por qué ese trabajo recae en ti. Los fabricantes de gestores de licencias tienen pocos motivos para priorizar la utilidad de estos logs como evidencia. Sus clientes son las empresas de software que licencian a través de ellos, no tú, y varios preferirían venderte un producto propietario de informes o un proyecto de servicios antes que verte explotar los logs que ya tienes. No están en el negocio de ayudarte a comprar menos a sus clientes — y desde luego no están en el de construir el argumento que usarías contra ellos en la renovación.

El valor de importar los logs no está en que sean perfectos. Está en que, tratados según su formato real, cubren tres huecos que el sondeo por sí solo deja abiertos.

Lo que el sondeo no ve y los logs sí recogen

Sesiones breves. El sondeo es periódico. Si un checkout empieza y termina entre dos consultas, 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 un trabajo de Abaqus que termina una simulación en menos de un minuto, el sondeo puede hacer que una feature parezca inactiva cuando el equipo la utiliza con frecuencia.

Ese punto ciego juega en tu contra. Si consideras inactiva una feature con mucha actividad y recortas sus puestos para ahorrar, puedes pasar el trimestre siguiente atendiendo denegaciones.

Denegaciones. El sondeo te dirá que el pool está al 100 %. El log puede decirte quién intentó obtener una licencia y no la consiguió. Esa es la diferencia entre “estamos utilizando todo lo que tenemos” y “la demanda superó la oferta”, y es la aportación más valiosa de los logs. Merece su propia sección.

Eventos del servidor que una consulta de estado no expone. Los gestores guardan información útil que puede no aparecer en el protocolo de consulta: un daemon que no consigue servir determinadas licencias, clientes que solicitan una versión incompatible o peticiones de features que no has adquirido. Muchos de estos eventos permanecen invisibles hasta que inspeccionas el log.

Denegaciones: prueba, no solo presión

Una denegación ocurre cuando un usuario solicita una licencia y el servidor no la concede. FlexLM escribe DENIED; RLM, DENY; LM-X y DSLS registran los rechazos cuando están activados el logging o la trazabilidad necesarios. El registro puede identificar al usuario, la feature, la hora y el motivo. Esa concreción es justo lo que suele faltarle a un argumento de renovación.

Sin esa evidencia, la conversación suele desarrollarse así. Los usuarios se quejan. El comercial del proveedor, cuya respuesta previsible a un problema de capacidad es “compra más puestos”, está listo para ayudarte. El sondeo aporta la utilización, una señal clara de que vas al límite pero no un veredicto. Sin denegaciones no puedes cuantificar ni describir el patrón del déficit, así que la negociación se apoya en anécdotas y acaba imponiéndose el relato comercial.

Los datos de denegación cambian la conversación en ambas direcciones. Esa es la idea: son evidencia, no munición.

• A veces confirman la ampliación. Doscientas denegaciones distintas al mes en una sola feature, repartidas por todo el equipo de ingeniería, indican un problema real de capacidad. Ahora puedes discutir un número concreto de puestos respaldado por un patrón concreto.
• Otras veces la desmontan. Los mismos datos muestran que las denegaciones se concentran en tres usuarios cuyos procesos batch nocturnos coinciden durante diez minutos a las dos de la mañana. Eso se resuelve ajustando horarios, no comprando. Acabas de evitar una ampliación que habrías aprobado por intuición.

Los recuentos de denegaciones también te permiten cuantificar el coste de decir que no: horas de ingeniería perdidas esperando una licencia y tareas que no llegaron a ejecutarse. Esa es la cifra que finanzas quiere junto al “coste de más puestos”, y solo puedes obtenerla de los logs.

Dos advertencias, porque un recuento que no puedes defender es peor que ninguno. Primera: un usuario frustrado que reintenta cinco veces en un minuto puede generar cinco líneas durante un único periodo de bloqueo. Si cuentas eventos sin interpretarlos, exagerarás el problema. RLM ayuda a evitarlo: su registro DENY incluye el campo last_attempt, y la documentación del fabricante indica que solo un valor distinto de cero representa la denegación final para la aplicación.

Segunda: la evidencia depende de la configuración. LM-X requiere logging extendido y DSLS necesita que se active la trazabilidad del uso. Si esa captura nunca estuvo habilitada, un informe sin denegaciones no demuestra que nadie las sufriera.

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

Una auditoría de software, o su versión más amable, el true-up, empieza con el proveedor explicándote lo que cree que desplegaste y utilizaste y pidiéndote que lo reconcilies. Esa asimetría es todo el problema. Llega con una posición basada en tus derechos adquiridos, precios de tarifa, registros de despliegue y aquello que el contrato te obligue a declarar; tú reaccionas a ella.

El proveedor no puede ver un entorno on-premises aislado, pero eso no ayuda si las únicas cifras de uso sobre la mesa son las que ha inferido. Lo único que equilibra la conversación es disponer de un registro independiente de lo que tus servidores sirvieron realmente.

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 conserva 90 días no puede responder por un periodo cuyos datos ya no existen. Como mínimo, conserva evidencia de todo el periodo que pueda abarcar una renovación, un true-up o una auditoría. La captura debe funcionar antes de que la necesites; no puedes reconstruir un trimestre cuyos logs ya se perdieron.
• Reconciliada, no en bruto. Entregar al proveedor una colección de debug logs le permite interpretar las partes dudosas y expone nombres de usuario y equipos que conviene anonimizar primero. Lo que resiste preguntas es un histórico normalizado y deduplicado donde se han tratado reintentos, relecturas, rotaciones y sesiones incompletas: una cifra que puedes explicar línea por línea.
• Centrada en el pico. Las licencias concurrentes están limitadas por la demanda simultánea, no por el uso medio. El análisis depende de un pico correcto, y para calcularlo hay que emparejar checkouts y checkins. Si omites los segundos, todas las sesiones parecen infinitas.

Sé honesto sobre lo que esto hace y lo que no. Los logs son tu registro; no siempre cuadrarán al token con las cifras del proveedor y no constituyen un escudo legal. Lo que te dan es una cifra propia que puedes defender, en lugar de obligarte a aceptar la suya. Esa suele ser la diferencia entre negociar y limitarte a firmar.

Qué contiene realmente cada formato

Los formatos compatibles se parecen vistos desde lejos: marcas de tiempo, nombres de usuario y nombres de features. Sin embargo, su semántica y su configuración difieren lo suficiente como para que tratarlos del mismo modo produzca evidencia incorrecta.

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

Es el flujo de diagnóstico más rico del grupo. Registra OUT, IN, DENIED, QUEUED, el estado del daemon del proveedor, los reinicios de lmgrd y las relecturas del archivo de licencia. Aspectos que debes vigilar:

• Si arrancas lmgrd con -l ruta, el daemon sobrescribe ese archivo al iniciarse. Utiliza -l +ruta cuando necesites añadir contenido y aplica después una política de rotación y archivo controlada.
• Las entradas normales solo incluyen la hora. En las versiones de FlexNet Publisher que lo admiten, -datestamp añade a cada entrada una fecha ISO 8601 con el desplazamiento horario y evita ambigüedades al cruzar la medianoche o un cambio de horario.
• Los préstamos y checkouts con permanencia no se comportan como sesiones interactivas normales. Conserva esos indicadores y aplica la política de la licencia antes de incluirlos en el análisis de concurrencia.

Report log de RLM (REPORTLOG +<ruta>)

Está diseñado para generar informes de uso, no solo para depurar. Incluye registros explícitos START, PRODUCT, OUT, IN, DENY, eventos de cola y salida de cola, y paradas del servidor. Esto lo convierte en el formato más adecuado para auditorías de los cuatro sin procesamiento adicional. RLM también autentica secciones del report log para que las modificaciones posteriores puedan detectarse. Aspectos que debes vigilar:

• El prefijo + en la ruta activa el modo append. Sin él, al abrir el report log configurado se sobrescribe el archivo.
• Una línea DENY no representa necesariamente una denegación final para la aplicación. Utiliza el campo last_attempt; Reprise documenta que un valor distinto de cero corresponde al último intento.
• Las versiones y formatos del report log (std, small, detailed) cambian los campos disponibles en los registros de checkout y checkin. Conserva la cabecera y analiza cada archivo según la versión que declara.

Log de uso de LM-X

Los logs del servidor LM-X contienen actividad de checkout y checkin y pueden configurarse con detalle normal o extendido. Aspectos que debes vigilar:

• Las estadísticas de peticiones denegadas requieren logging extendido. En LM-X 6, configura log.format: extended en el YAML o utiliza la interfaz del License Server. Las versiones anteriores usan LOG_FORMAT=EXTENDED.
• LM-X permite excluir tipos de mensaje, como checkout y checkin. Revisa las exclusiones antes de interpretar un log incompleto como ausencia de actividad.
• La rotación puede ser diaria, semanal, mensual o estar desactivada. Recoge tanto los archivos rotados como el activo y conserva el servidor de origen cuando consolides varios nodos.

Log del servidor DSLS con trazabilidad de uso

DSLS escribe logs del servidor, pero el detalle de concesiones, liberaciones, timeouts y rechazos solo aparece cuando se activa License Usage Tracing para las licencias correspondientes. Puedes hacerlo desde la herramienta de administración o mediante DSLicSrv -admin y el comando setLicenseUsageTraces. Aspectos que debes vigilar:

• La trazabilidad no es retroactiva. Si estaba desactivada, no puedes reconstruir el periodo ausente mediante consultas de estado posteriores.
• Cada miembro de un clúster de failover escribe sus propios logs. Recoge los de todos los miembros y conserva la identidad del servidor antes de consolidar los eventos.
• DSLS inicia un log nuevo al reiniciar el servidor o alcanzar el límite de tamaño configurado. El consumo de tokens y créditos también puede aparecer en archivos TokenUsage...log separados, cuyas cantidades no deben interpretarse como puestos concurrentes normales.

Los modos de fallo silenciosos

La mayoría de las importaciones defectuosas no fallan de forma evidente. Producen cifras que parecen razonables pero están ligeramente equivocadas, el peor resultado posible cuando piensas utilizarlas en una renovación o una auditoría. Vigila estos patrones tanto si construyes tu propio proceso como si evalúas el de otra empresa.

Rotación sin continuidad. El importador sigue el nombre del archivo activo, el servidor lo renombra durante la rotación y una parte todavía no leída queda en el archivo rotado. Conserva e importa tanto el archivo activo como los rotados. Registra el progreso mediante la identidad del archivo más un offset, o mediante la identidad del evento, no solo con la fecha de modificación.

Ambigüedad horaria. Los formatos no registran el tiempo de la misma manera. Las versiones modernas del report log de RLM incluyen la zona horaria; FlexNet puede añadir fecha ISO y desplazamiento con -datestamp; otros registros dependen de la hora local del servidor. Averigua qué emite cada fuente antes de normalizarla. De lo contrario, un cambio de horario puede parecer un hueco o una hora duplicada.

Codificación y configuración regional. Los nombres de Active Directory suelen contener caracteres acentuados, mientras que algunos daemons antiguos escriben con la codificación del sistema operativo y no en UTF-8. Müller se convierte en M?ller cuando el importador se equivoca, y los informes por usuario dejan de cuadrar. Detecta o configura la codificación de origen y normaliza después a UTF-8.

Líneas parciales durante la recogida. Leer el archivo activo mientras el daemon sigue escribiendo puede exponer una última línea incompleta, sobre todo en almacenamiento lento o remoto. Un importador robusto conserva el fragmento para la siguiente pasada o lo marca; nunca lo convierte en un evento completo.

Omitir los checkins. Si importas únicamente OUT y denegaciones, todos los checkouts parecen durar eternamente. Es una vía rápida hacia picos absurdos y recomendaciones de comprar puestos que no necesitas. Importa el ciclo de vida completo aunque un informe concreto solo muestre la hora de inicio.

Cómo trabajan juntos el sondeo y los logs

La dificultad no está solo en analizar los logs. Está en combinarlos con lo que ya observó el sondeo, sin contar dos veces ni dejar huecos.

LiMon acepta archivos individuales o carpetas desde la interfaz web, y el mismo flujo está disponible desde la línea de comandos y mediante la API REST. Eliges el servidor y los tipos de evento que quieres procesar; LiMon mantiene visibles el estado del lote y el histórico de importaciones.

Una vez dentro los eventos en bruto, LiMon empareja checkouts con checkins, deduplica dentro de una tolerancia temporal y reconstruye el rango de fechas afectado, de modo que la nueva evidencia de los logs se fusiona con las sesiones que ya tenía del sondeo. Los paneles y los informes de esas fechas reflejan entonces la imagen combinada en lugar de dos versiones de la verdad.

view → Importación de logs

Ese registro combinado alimenta las vistas de optimización de costes, que siguen la utilización y la contención a lo largo del tiempo, y los informes ejecutivos utilizados en renovaciones y auditorías.

Los informes son los que justifican el cuidado puesto en la importación. Una renovación se desarrolla de forma muy distinta cuando puedes mostrar un desglose limpio de doce meses, con denegaciones incluidas, que cuando solo puedes describir lo que recuerda el equipo.

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. Comprueba la configuración de captura: modo append para FlexNet y RLM (lmgrd -l +ruta, REPORTLOG +ruta), logging extendido para LM-X y License Usage Tracing para DSLS.
2. Confirma la fecha, la zona horaria y la información sobre el horario de verano que emite cada fuente.
3. Asegúrate de que la rotación no deje eventos sin leer en archivos renombrados y conserva el histórico durante el periodo que exijan tus contratos y tu política interna.
4. Revisa unas pocas líneas con caracteres no ASCII y confirma que llegan correctamente a tu almacén.
5. Elige una feature y contrasta sus checkouts con los checkins. Explica las sesiones abiertas durante un apagado y cualquier diferencia restante.
6. Obtén las denegaciones de una feature con carga y contrástalas con la realidad. En RLM, respeta last_attempt; en los demás formatos, distingue los reintentos repetidos de periodos de bloqueo independientes.

Si alguna de esas comprobaciones revela una sorpresa, el resto de tus cifras también puede estar en riesgo. Lo mismo ocurre con el argumento que pensabas construir con ellas.

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 proceso de análisis. LiMon reúne el sondeo, la importación de logs y los informes históricos en un único entorno on-premises: sin agentes en los servidores de licencias, sin nube y sin phone-home.

Solicita una evaluación para probar el flujo y elige después Standard o Professional según la escala y los informes que necesites. El mantenimiento activo desbloquea las vistas de Intelligence, incluidas Defensa ante Auditorías y Ahorro: informes interactivos que puedes explorar y exportar cuando un proveedor o tu director financiero necesita un documento. Esa es la diferencia entre “lo hemos monitorizado todo” y “podemos demostrarlo en la reunión de renovación”.