¿Por qué monitorizar el uso de licencias?

Si gestionas más que un puñado de servidores FlexLM, RLM, LM-X o DSLS, monitorizarlos o no no es la cuestión. La cuestión es con qué monitorizarlos — porque las respuestas caen en tres categorías muy distintas, y la mayoría de los equipos no se da cuenta hasta que ya ha elegido una y ha descubierto lo que deja fuera.

Este artículo es un mapa rápido de esas tres opciones: los scripts caseros (cron y shell, quizá Python o Powershell), la suite empresarial de gestión de activos de software y las herramientas diseñadas a propósito que se sitúan entre ambas. Cada una tiene puntos fuertes reales. Cada una tiene aristas que pillan a la gente por sorpresa.

¿Para qué monitorizar?

Pregunta razonable como punto de partida. Los gestores vienen con utilidades como lmstat, rlmutil y la CLI de LM-X. Son gratis, te dicen quién tiene qué en este momento, y un ingeniero senior puede leer la salida más rápido que abriendo una web para consultar un panel. ¿Para qué entonces molestarse con una herramienta?

Tres razones:

• Tendencia en el tiempo. Una consulta a las 11 de la mañana del martes no te dice nada del pico de uso del trimestre pasado. Sin un registro histórico no puedes responder a la única pregunta que importa en la renovación: ¿usamos lo que pagamos, o pagamos lo que no usamos?
• Denegaciones y contención. lmstat te muestra el estado actual. No puede mostrarte que nueve personas intentaron coger ABAQUS ayer por la tarde y tres desistieron y pasaron a otra tarea. Esas denegaciones son la diferencia entre “estamos usando todo lo que tenemos al máximo” y “no tenemos suficiente” — y no aparecen en ningún sitio en la vista en vivo.
• Varios vendors a la vez. Un equipo que tiene aplicaciones licenciadas bajo FlexLM, RLM y LM-X ha de usar tres CLIs distintos, tres formatos de log distintos, tres maneras distintas de hacer la misma pregunta. Las herramientas de monitorización colapsan eso en una sola vista.

Si alguna de esas tres impacta en una decisión que vas a tomar en los próximos doce meses, “ya miraré lmstat cuando lo necesite” deja de ser una respuesta viable.

Opción uno: el script casero

La opción obvia para empezar, y donde la mayoría de los equipos de IT empieza. Un cron que corre lmstat -a cada 15 minutos. Un script de Python que parsea la salida y escribe filas en MySQL. Un panel de Grafana, o quizá solo un CSV que el analista pivota en Excel una vez al trimestre. Una persona del equipo — normalmente uno de los ingenieros más senior, a menudo un manager que antes programaba — se ocupa de ello.

Funciona. Para uno, o incluso unos pocos, servidores de licencias, un vendor y un puñado de funcionalidades, funciona bien. Es gratis, hace exactamente lo que le digas, y no introduce una nueva línea en el presupuesto que tendrás que defender en la próxima revisión de presupuesto.

Las cosas que no se tuvieron en cuenta:

• Cada nuevo vendor duplica el trabajo. FlexLM, RLM, LM-X, DSLS, Sentinel RMS… no tienen nada en común a nivel de protocolo. Añadir un segundo vendor significa un segundo parser, modificar el modelo de datos, un segundo conjunto de casos especiales. Para el tercer vendor, “el script” ya es un proyecto.
• El reporting histórico se convierte en su propio producto. Almacenar los datos es fácil. Construir los informes que de verdad responden a "¿cuál fue el pico de uso de ABAQUS en el Q4 por departamento?" no lo es. Acabas escribiendo SQL a mano, o montando un pequeño frontend, o manteniendo un montón de ficheros de Power BI que se desincronizan entre sí.
• Las peticiones de funcionalidades no paran. Cuando el script básico funciona, empiezan a llegar las peticiones. "¿Puede resolver nombres de usuario desde AD en lugar de los IDs en bruto?" "¿Podemos sacar análisis de patrones sobre quién recibe más denegaciones?" "¿Puede mandar un email a finanzas cuando una funcionalidad lleva una semana al 90%?" Cada petición es pequeña. Ninguna estaba en el plan original. Juntas acaban comiéndose una parte significativa de la semana de alguien — y ese alguien suele ser un ingeniero senior o un manager cuyo coste total hace que la tarifa anual de LiMon parezca un error de redondeo. No hay nadie contratado para lidiar con esto.
• El propietario es un único punto de fallo. Es una historia común: el equipo tenía un sistema estupendo, y luego la persona que lo construyó cambió de empresa, fue promocionada a otro puesto o simplemente se quedó sin tiempo, y el script dejó de mantenerse sin que sonaran las alarmas. Un año después nadie recuerda muy bien cómo funcionaba.

El scripting casero es un buen lugar para empezar. Es un mal lugar para quedarse si el uso de licencias condiciona decisiones de negocio.

Opción dos: la suite empresarial de activos

En el otro extremo: Flexera FlexNet Manager Suite o FNMEA, la edición empresarial de OpenLM, las ofertas de pago de X-Formation y un puñado de herramientas similares del mundo de la gestión de activos de IT. Son productos destacados, vendidos a equipos empresariales de ITAM, y cubren mucho terreno.

Lo que aportan:

• Cobertura completa en un solo lugar. Casi cada tipo de servidor de licencias conocido, más descubrimiento de software en los endpoints, más reconciliación contra los derechos de uso que hayas registrado en su base de datos. Para una organización grande que de verdad necesita rastrear cada copia instalada de cada producto, esta es la clase de herramienta que debería investigar.
• Paneles pulidos e informes empaquetados. No necesitas inventar un lenguaje de consulta para responder a “muéstrame funcionalidades por encima del 80% de utilización en los últimos 90 días”.
• Integraciones con el resto del stack ITAM. SCCM, Tanium, ServiceNow, grupos de AD, lo que sea. Si tu organización ya corre ese stack, esto encaja.

Lo que cuesta:

• El precio. Seis cifras es lo normal a cualquier escala mínima. Habitualmente no encontrarás precios públicos. Es “contactar con ventas” o “pida presupuesto” por una razón.
• La implantación. Un proyecto de servicios profesionales de varias semanas es lo estándar. Agentes en los endpoints, conectores con tu base de datos ITAM existente, flujos personalizados para las peculiaridades de tu organización. Para cuando está funcionando, a menudo has gastado más en consultores que en el software.
• El impuesto de la complejidad. Estas herramientas están construidas para equipos ITAM, no para el equipo de R&D que de verdad se preocupa de si ABAQUS está saturado. La persona más cercana a la pregunta a menudo no tiene acceso directo al panel — está mandando una petición al equipo dueño de la plataforma y esperando dos semanas a un informe.
• Los agentes. La mayoría de las suites empresariales despliegan un agente a los endpoints para rastrear instalaciones. Algunos equipos lo necesitan de verdad. Para un equipo que ya sabe exactamente qué servidores de licencias tiene, y solo quiere monitorizarlos, es una complejidad extra que no se pidió.

La suite empresarial es la respuesta adecuada cuando el seguimiento de licencias tiene su propio presupuesto de cumplimiento y un equipo ITAM dedicado que lo gestione — reconciliación contra los derechos de uso, descubrimiento en endpoints, integración con el resto del stack de activos. Rara vez es la respuesta correcta para una empresa de 40 000 empleados que solo quiere saber si está pagando de más por AutoCAD, ni para un equipo con quizá 70 servidores de licencias que se pregunta quién está usando ENOVIA. (Para un cara a cara más detallado, hemos escrito una comparación honesta de LiMon, OpenLM y Flexera.)

Opción tres: el peso medio

Hay un hueco entre el script que un ingeniero mantiene en su tiempo libre y la suite empresarial que gestiona un equipo ITAM de cinco personas. La mayoría de los equipos que gestionan licencias de ingeniería viven en ese hueco. Han pasado el punto en el que un script es suficiente, y están muy lejos de necesitar — o de poder justificar — una plataforma ITAM de seis cifras.

La forma de una herramienta que encaja en ese hueco:

• Multi-vendor de fábrica. FlexLM, RLM, LM-X y DSLS tratados como ciudadanos de primera, no parcheados sobre un core univendedor.
• Se instala en menos de una hora. Docker Compose o un paquete .rpm o .deb para instalar en tu VM Linux. Nada de un proyecto de servicios de cuatro semanas.
• Precios claros y públicos. Standard, Professional y lo que incluye cada plataforma están en la página de precios — nada de “pide un presupuesto”. Puedes contrastarlo con tu presupuesto sin pasar por una conversación comercial.
• On-premises, sin envío de datos. Nada sale de tu red, sin agentes en los servidores de licencias, sin cuenta en la nube que tengas que justificar en la próxima revisión de cumplimiento. Tus datos siguen siendo tuyos.
• Informes que responden directamente a las preguntas de renovación y auditoría. Pico y uso sostenido por funcionalidad, recuentos de denegaciones, resúmenes ejecutivos para esas llamadas de renovación.
• En manos de la persona a la que de verdad le preocupa. Los equipos de R&D o IT que gestiona los servidores de licencias pueden montarlo por sí mismos, mirar los datos por sí mismos, y llevar conclusiones al departamento de compras o finanzas sin involucrar a un equipo aparte o consultores externos.

Este es el hueco para el que LiMon está construido. No es una plataforma de gestión de activos de software — no intenta descubrir instalaciones en los endpoints, reconciliar contra órdenes de compra ni sustituir tu CMDB. Hace lo único que los sistemas de este ámbito realmente necesitan: decirte, con precisión y en un solo sitio, qué están haciendo tus servidores de licencias y qué han hecho desde que lo instalaste.

Si tus necesidades encajan con esta opción, solicita una evaluación de 60 días para ver si LiMon cumple con lo que necesitas. Las plataformas Standard y Professional escalan de 20 servidores a monitorización ilimitada y añaden el reporting y las integraciones que cierran el círculo con finanzas.

Si no — si gestionas una organización que de verdad necesita una suite ITAM completa, o si un par de scripts de shell te están funcionando — eso también está bien. Ninguna herramienta es adecuada para todos. El peor desenlace es pagar de más por una complejidad que no necesitas, o confiar en una simplicidad que dejó de funcionar en silencio el año en que nadie miraba.