Un compañero te escribe un martes: “Oye, ¿tenemos NX Motion? ¿Me puedes dar acceso?”
Gestionas treinta y pico servidores de licencias repartidos en tres sedes, un calendario de renovaciones que nunca se vacía del todo y un esquema de nombres de fabricante que llama a esa cosa nx_motion_ult en un servidor y algo ligeramente distinto en otro. Ni siquiera estás seguro de que “NX Motion” sea el nombre real de la feature. La respuesta honesta a tu compañero es “dame un rato” — y luego llega la parte de lanzar múltiples lmstats, entrar por SSH a las máquinas, abrir ficheros de licencias y buscar cadenas de lo que crees que puede llamarse esa feature.
Esa tarde es el problema del que va este artículo. Casi cualquier pregunta sobre licencias que recibe tu equipo se reduce a una de tres formas:
- ¿Dónde está? — Conoces un nombre a medias y necesitas localizar dónde vive en todo el parque.
- ¿Por qué él puede y yo no? — Dos personas, la misma aplicación, distinta suerte. Una obtiene licencia, la otra recibe un mensaje diciendo que esa feature no existe.
- ¿Cuándo cambió esto? — Una cantidad bajó, una feature desapareció, una caducidad varió de fecha, y alguien quiere saber cuándo e incluso por qué.
LiMon tiene una pantalla dedicada para cada responder cada pregunta. Ninguna te exige recordar un servidor, un puerto ni como llama exactamente el fabricante a la feature.
“¿Dónde está?” — Búsqueda de licencias en el parque
La primera pantalla es donde aterriza la pregunta de tu compañero. En la navegación de LiMon se llama Encuentra una licencia y hace una sola cosa: escribes parte de un nombre y te dice en qué sitios existe esa feature, en todos los servidores monitorizados.
El detalle que la hace útil en un parque real es contra qué compara. Los servidores de licencias hablan en mnemónicos crudos de fabricante — nx_motion_ult, CATIA_V5_HARDWARE, 86984ACD2025. Las personas hablan en nombres de producto — “NX Motion”, “CATIA Hardware Design”, “AutoCAD 2025”. LiMon mantiene un mapeo entre ambos (esa es otra historia), y la caja de búsqueda compara tu término contra los dos: el nombre crudo de la feature y el nombre amigable resuelto. Así que “NX Motion”, “nx_motion” o simplemente “motion” encuentran lo mismo. No hace falta saber ya la respuesta para preguntar — con dos caracteres basta para empezar.
Los resultados vuelven agrupados por feature, y esa agrupación es justo el objetivo. Para cada coincidencia obtienes:
- El nombre crudo del fabricante y el nombre amigable, uno al lado del otro.
- Un total a nivel de parque — cuántas de esta licencia tienes en total y en cuántos servidores distintos está.
- Un desglose por ubicación — cada servidor que tiene la feature, con su propia cantidad, fecha de caducidad (en blanco = perpetua), etiqueta de sede y estado actual (
UP,DOWN,ERROR, en baja).
Esa última lista es lo que cierra el ticket. Tu compañero preguntó dónde está NX Motion; la respuesta es ahora concreta — “7 puestos de NX Motion Ultimate en dos servidores — 5 en Múnich, 2 en Turín en una máquina que ahora mismo está caída — más 4 de NX Motion Simulation en el servidor RLM de Múnich” — en lugar de una promesa de mirarlo. Los resultados trajeron tanto el nx_motion_ult de FlexLM como el NXMOTIONSIM de RLM bajo sus nombres amigables, que es justo el comportamiento de “el nombre exacto da igual” que quieres. Y si no hay coincidencias, la búsqueda lo dice sin rodeos: un resultado vacío es un “no lo tenemos” legítimo y rápido, no un error ni un silencio ambiguo.
Esta es la pantalla que sustituye a una tarde de SSH y grep. Una búsqueda, todo el parque, tanto sobre el código de la feature como sobre su nombre amigable mapeado en LiMon.
“¿Por qué él puede y yo no?” — Cobertura de features
La segunda pregunta es más traicionera, porque a primera vista parece un fallo. Dos ingenieros, ambos usando lo que la empresa llama “HyperWorks”. Uno saca una licencia y se pone a trabajar. El otro recibe una denegación — aunque sobran puestos libres y otros compañeros pueden acceder a esa misma feature en ese momento — y, lógicamente, da por hecho que algo no funciona.
A menudo no hay nada roto. La aplicación se sirve, sencillamente, desde más de un servidor de licencias — distintas sedes, servidores regionales, una máquina independiente para cierto equipo — y esos servidores no llevan un conjunto idéntico de features. El ingeniero que tuvo éxito apuntaba a un servidor que sí tiene la feature que necesitaba. El que falló apuntaba a uno que no la tiene. El mismo nombre de aplicación, distinto inventario por debajo.
LiMon lo expone en la página de detalle de la aplicación como Cobertura de funciones. Toma una aplicación, mira todos sus servidores de producción activos e informa de las funciones que no están presentes en todos ellos. La regla que aplica es deliberadamente simple:
- Compara solo despliegues de producción. Los servidores de test y desarrollo, que suelen diferir, no enturbian la imagen.
- Una feature cuenta como presente en un servidor cuando sirve realmente la licencia — la cantidad se ignora. Esta vista responde a “¿está siquiera ahí?”, no a “¿es suficientemente grande?”. (Para “¿es suficiente?”, está el análisis de uso y ahorro, otra pantalla.)
- Necesita al menos dos servidores de producción para significar algo. Con uno solo no hay nada que comparar, y LiMon oculta la vista en lugar de mostrarte una respuesta trivialmente “completa”.
Cuando todos los servidores de producción llevan todas las features, la vista te lo dice en una línea — todas las funciones presentes en todos los servidores de producción — y puedes dejar de buscar; la denegación es otra cosa (un techo de cantidad, una restricción de usuario/host, un puesto prestado o en roaming). Pero cuando hay un hueco, la vista lista exactamente las features con un agujero en su cobertura — lo que está en todos los servidores desaparece, así que lo que queda es el conjunto problemático — y una marca verde o un guión gris muestran qué servidores tienen cada una y cuáles no:
Con esto puedes responder rápidamente preguntas del tipo: “¿Tenemos X feature en la oficina de Múnich? ¿Y si no es así dónde?”. El ingeniero denegado necesitaba MotionSolve, su puesto apuntaba al servidor de Múnich, y Múnich no la tiene — denegado — mientras los compañeros que sacaban licencia de la máquina LM-X de Londres no veían ningún problema. El “fallo” es un hueco de cobertura, y ahora tiene nombre y ubicación. Lo siguiente es decidir: añadir la feature a los servidores que no la tienen, redirigir a ese equipo a un servidor que sí la tiene, o confirmar que el hueco es intencionado e informar que contractualmente no tienen acceso a esa feature. En cualquier caso, ya no estás adivinando.
Una nota sobre lo que esta vista es y no es: informa de la presencia a nivel de servidor, no de quién fue denegado. No lista los usuarios afectados ni reproduce los eventos de denegación — eso llega con el análisis de denegaciones de los informes. Lo que te da Cobertura de Funciones es la explicación estructural que hay debajo de la queja, que suele ser la parte difícil de ver y fácil de discutir.
“¿Cuándo cambió esto?” — Historial de licencias
La tercera pregunta aparece a posteriori. El pool que tenía 50 puestos ahora muestra 45. Una feature que jurarías que estaba ya no está. Una fecha de caducidad con la que contabas para la conversación de renovación ha cambiado y nadie recuerda por qué. Alguien —quizá tú, hace tres meses— hizo un cambio, y ahora necesitas el rastro.
LiMon mantiene ese rastro automáticamente. En cada ciclo de sondeo compara el inventario de licencias actual de cada servidor con lo que vio por última vez, y cualquier diferencia se convierte en una entrada fechada y tipada en el Historial de Licencias. No lo activas ni tienes que configurar nada; es una ventaja secundaria de monitorizar.
Registra cinco tipos de cambio, y la línea temporal codifica cada uno por color para que el rastro de una renovación se lea de un vistazo:
- Added (Añadida) — una feature apareció en un servidor que no la tenía (una nueva titularidad, un despliegue).
- Removed (Eliminada) — una feature desapareció por completo (un módulo caducado, una baja).
- Quantity Changed (Cantidad cambiada) — el número de puestos se movió, mostrado como un sencillo 45 → 50.
- Version Changed (Versión cambiada) — la versión licenciada avanzó, p. ej. V5-6R2023 → V5-6R2024.
- Expiration Changed (Caducidad cambiada) — la fecha de caducidad de una feature se movió, p. ej. 2025-06-30 → 2025-12-31, que es el recibo de que una renovación realmente entró.
Cada entrada lleva la feature, el servidor donde ocurrió, los valores antes → después y una marca de tiempo. Y como el qué y el cuándo se capturan automáticamente pero el por qué vive en la cabeza de alguien, cada entrada admite un motivo opcional que puedes anotar desde la Admin UI — “Renovación anual — puestos adicionales comprados”, “Feature obsoleta — ya no se usa”. Seis meses más tarde, cuando finanzas pregunte por qué subió la línea de CATIA, la respuesta ya está escrita junto al evento en lugar de reconstruirse a partir de correos.
Para los casos que el sondeo no puede ver — un cambio en papel, una compra con fecha futura que quieres dejar registrada antes de que aparezca en lmstat — también puedes añadir entradas a mano desde la Admin UI, de modo que el historial quede completo en vez de reflejar solo lo que un servidor haya reportado.
En el frontend puedes ver este historial en la página de detalles de cada servidor y cada aplicación. En la Admin UI puedes ver todos los cambios en todo el parque en una sola vista y filtrar la línea temporal por servidor, por feature, etc. Esta es la diferencia entre “creo que subimos CATIA la primavera pasada” y “pasamos de 80 a 100 el 14 de marzo, y registramos este motivo”.
Tres preguntas, un parque
Las tres pantallas responden a tres preguntas comunes sobre tu parque de licencias:
- Encuentra una licencia responde al dónde — todo el parque, cualquier grafía del nombre, en una búsqueda.
- Cobertura de Funciones responde al por qué cambia el acceso — el hueco estructural entre servidores de una aplicación que explica algunas denegaciones.
- Historial de Licencias responde al cuándo y por qué cambió — un rastro de auditoría automático y anotado.
Lo que comparten es que ninguna te pide saber ya la respuesta. No aportas un servidor, un puerto ni el mnemónico exacto del fabricante; aportas lo difuso que realmente tienes — un nombre a medio recordar, un usuario confundido, un número que cambió — y LiMon lo resuelve contra el inventario que lleva manteniendo en silencio todo el tiempo. Ese es el cambio de verdad: la gestión de licencias deja de ser un examen de memoria.
Dónde encaja LiMon
LiMon sondea servidores FlexLM, RLM, LM-X, DSLS por toda tu red, mantiene una imagen viva de lo que lleva cada uno y la convierte en las vistas de búsqueda, cobertura e historial de arriba — además de análisis de uso, documentación de defensa ante auditorías y datos reales para tus conversaciones de renovación. Funciona en tu hardware: sin nube, sin agentes en los servidores de licencias, sin llamar a casa. Solicita una evaluación para apuntarlo a tu propio parque, y luego elige Standard o Professional según la escala de servidores y la analítica que necesites. (Todas las features tratadas en este artículo están disponibles en Standard y Professional.)