Cómo monitorizar el uso de licencias FlexLM

Qué te da lmstat gratis, dónde se queda corto, y cómo pasar de una consulta puntual de estado a dashboards históricos — con Docker, DEB o RPM, en tu propio hardware.

Si gestionas servidores de licencias FlexLM (también conocido como FlexNet Publisher), tarde o temprano alguien te hace una pregunta de uso: ¿quién tiene cogidos todos los tokens de ABAQUS?, ¿usamos de verdad los 40 puestos que renovamos cada año?, ¿por qué fallaron los checkouts ayer por la tarde? Esta guía recorre las respuestas prácticas — empezando por lo que las herramientas del vendor ya te dan gratis, siendo claros sobre dónde se quedan cortas, y montando después monitorización de verdad en unos diez minutos.

Todo lo que sigue aplica a cualquier aplicación licenciada con FlexLM: Ansys, MATLAB, Cadence, Synopsys, Siemens NX, licencias de red de Autodesk y unos cuantos cientos más.

Nivel cero: lmstat

FlexLM incluye lmutil, una herramienta de línea de comandos multipropósito, y su subcomando lmstat es la forma canónica de preguntarle a un servidor de licencias qué está pasando ahora mismo:

lmutil lmstat -a -c 27000@licserver01

El argumento -c acepta el mismo puerto@host que usan las estaciones de trabajo de tus usuarios, y -a pide todo. La salida tiene esta pinta (recortada):

lmgrd is UP, vendor daemon ansyslmd is UP
Users of cfd_solve_level1:  (Total of 25 licenses issued;  Total of 18 licenses in use)

  "cfd_solve_level1" v2024.1, vendor: ansyslmd
  jsmith wks-0214 (v2024.1) (licserver01/27000 1102), start Tue 6/10 8:42
  mgarcia wks-0307 (v2024.1) (licserver01/27000 2240), start Tue 6/10 9:15
  ...

Eso es genuinamente útil. Tienes la salud de los demonios, el recuento de puestos por feature y una línea por usuario para cada checkout activo. Para un rápido “¿está el servidor levantado y quién está acaparando el solver?”, lmstat es la herramienta correcta y nada supera su inmediatez.

Dos notas prácticas desde la trinchera:

  • lmutil es un binario para Linux/Windows que obtienes del portal de soporte del vendor de tu aplicación (o ya está junto a lmgrd en el servidor de licencias). Usa una versión razonablemente actual; las antiguas pueden interpretar mal la salida de servidores más nuevos.
  • En distribuciones Linux modernas, lmutil suele fallar de entrada con No such file or directory porque está enlazado contra el viejo loader LSB. El arreglo estándar es un symlink de una línea: sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3.

Dónde se queda corto lmstat

lmstat responde exactamente una pregunta: qué está en uso ahora mismo. Las preguntas que acaban importando — en la renovación, en una auditoría, en una reunión de presupuesto — son todas preguntas sobre tiempo, y una foto puntual no puede tocarlas:

  • Sin histórico. Una foto a las 11 de la mañana de un martes no dice nada del pico de uso del trimestre pasado. Las decisiones de renovación necesitan uso pico y sostenido a lo largo de meses, no una captura puntual.
  • Sin denegaciones. Cuando el pool está agotado, lmstat muestra 25 de 25 en uso — no muestra a los cuatro ingenieros que se quedaron fuera. Las denegaciones viven en el log de debug, no en el protocolo en vivo.
  • Un servidor cada vez. Doce servidores de licencias son doce invocaciones y juntar los resultados tú mismo — y FlexLM rara vez está solo; la mayoría de los parques también tienen software licenciado bajo RLM, LM-X o DSLS, cada uno con su propia CLI incompatible.
  • Sin nombres que puedas llevar a una reunión. Features como cfd_solve_level1 significan algo para el vendor, no para finanzas. Alguien tiene que mapear features a productos y usuarios a departamentos.

El siguiente paso clásico es un cron que ejecuta lmstat -a cada 15 minutos y parsea la salida hacia una base de datos. Funciona — hasta cierto punto. Ya hemos escrito en detalle sobre cómo acaba la vía del script; la versión corta es que el parsing, el almacenamiento, los dashboards, el mapeo de usuarios y el soporte multivendor parecen pequeños por separado y terminan por sumar un trabajo a media jornada para el que no se contrató a nadie.

Qué requiere de verdad monitorizar FlexLM

Sea cual sea la herramienta — casera o comprada — la monitorización continua de FlexLM es siempre el mismo bucle:

  1. Sondear cada servidor de forma programada con la utilidad del vendor (los mismos datos que muestra lmstat).
  2. Parsear y almacenar las instantáneas en una base de datos, normalizadas entre servidores y vendors.
  3. Agregar hacia las vistas que la gente realmente pide: uso en el tiempo, picos, features ociosas, desgloses por usuario y por departamento.
  4. Vigilar los propios servidores — un demonio de vendor caído genera tickets más rápido que cualquier problema de utilización.
  5. Capturar lo que el sondeo no ve importando los logs del servidor: sesiones cortas y, sobre todo, denegaciones.

El resto de esta guía explica cómo cubrir ese bucle con LiMon, nuestro appliance de monitorización on-premises. Implementa el bucle para FlexLM, RLM, LM-X y DSLS en un solo producto, en tu hardware, sin agentes en los servidores de licencias y sin que nada salga de tu red.

Requisitos previos

  • Un host Linux (una VM vale) con 2 GB de RAM y 20 GB de disco como mínimo.
  • Acceso de red desde ese host a cada servidor de licencias en su puerto de licencias — para FlexLM típicamente el 27000 más el puerto del daemon del vendor. Regla básica: el host de LiMon necesita el mismo acceso que ya tienen las estaciones de tus usuarios.
  • El binario lmutil para FlexLM (y rlmutil, lmxendutil o DSLicSrv si también usas esos vendors). LiMon consulta los servidores con las utilidades oficiales de cada vendor — las mismas en las que ya confías — así que tú aportas el binario de tu vendor, y va en /opt/limon/tools/. No se instala nada en los propios servidores de licencias.
  • Para instalación Docker: Docker Engine 20.10+ y Docker Compose v2. Para paquetes nativos: Python 3.9+ con venv y pip, y una base de datos MariaDB 10+ o MySQL 8.x.

Instalación: Docker, DEB o RPM

Los tres paquetes se entregan a través del portal de clientessolicita una evaluación de 60 días y las instrucciones de descarga llegan por email. Sin tarjeta de crédito, y la evaluación corre con las funciones Professional activadas.

Docker es la vía autocontenida más rápida. El bundle lleva sus imágenes dentro del tarball — el instalador no tira de ningún registro público ni descarga scripts de internet, lo que importa en redes restringidas:

tar -xzf limon-docker-<version>.tgz
cd limon-docker-<version>
./docker-install.sh

Debian/Ubuntu:

sudo apt install ./limon_<version>_amd64.deb
sudo limon-setup

RHEL/Rocky/Alma:

sudo dnf install ./limon-<version>.x86_64.rpm
sudo limon-setup

Los paquetes nativos ejecutan LiMon como servicios systemd normales e incluyen wheels de Python precompilados para Python 3.9, 3.11 y 3.12, de modo que la capa Python se instala sin llegar a conectar con PyPI en esas versiones.

Ambos caminos terminan igual: el instalador imprime la URL del Setup Wizard.

Apúntalo a tus servidores

El asistente recorre base de datos, rutas de herramientas, y después el paso que importa — Servers. Elige FlexLM como tipo, introduce la dirección en el mismo formato puerto@hostname que usan tus ficheros de licencia, y pulsa Test Connection para confirmar que el host llega de verdad al demonio antes de guardar nada:

Paso Servers del Setup Wizard de LiMon mostrando cómo se añade un servidor FlexLM con dirección puerto@hostname y botón Test Connection
Añadiendo un servidor FlexLM en el Setup Wizard: tipo de vendor, puerto@hostname y prueba de conexión antes de guardar nada.

Añade tantos servidores como tengas — FlexLM y los otros tres tipos de vendor, lado a lado. Termina el asistente y LiMon empieza a sondear inmediatamente, cada 10 minutos por defecto (ajustable; el Live View muestra los tiempos reales de cada ciclo para que afines el intervalo con evidencia en lugar de a ojo).

Lo que obtienes a cambio

En unos pocos ciclos de sondeo el dashboard está vivo: salud de servidores y demonios, checkouts actuales, utilización por feature — y a partir de ahí, cada ciclo se convierte en histórico:

Dashboard de LiMon mostrando salud de servidores de licencias, utilización por feature y tendencias de uso entre varios tipos de vendor
El parque de un vistazo: salud de servidores, features más ocupadas, tendencias de utilización — cada servidor FlexLM, RLM, LM-X y DSLS en una sola vista.

Los datos se acumulan en las vistas que responden a las preguntas que lmstat no podía:

  • Uso en el tiempo por feature, servidor, usuario y departamento — picos, carga sostenida y features ociosas que cuestan dinero real, en silencio, en cada renovación.
  • Mapeo de features a aplicaciones, para que los informes hablen en nombres de producto y no en mnemónicos del demonio, e integración AD/LDAP para convertir usernames crudos en personas y departamentos.
  • Vistas de búsqueda e inventario sobre todo el parque, más un rastro de auditoría automático de cada cambio de licencia.
  • Informes Intelligence — estate, application, site, ahorro, defensa de auditoría — como vistas web interactivas y exportaciones PDF/CSV, pensados para la llamada de renovación y la respuesta a la auditoría, no solo para la sala de operaciones.
  • Alertas por email (y webhooks de Slack/Teams en Professional) cuando un servidor se cae o una feature cruza un umbral.

Una advertencia honesta, porque es la misma que señalamos en cualquier herramienta basada en sondeo, incluida la nuestra: el sondeo muestrea el presente. Los checkouts que empiezan y terminan entre dos sondeos le resultan invisibles, y las denegaciones jamás aparecen en el protocolo en vivo. Para eso está la importación de logs — dale a LiMon los logs de debug de FlexLM y rellena hacia atrás las sesiones cortas y los eventos de denegación en la misma base de datos. Tenemos una guía completa de importación de logs, incluidas las trampas específicas de FlexLM (arranca lmgrd con -l +ruta o la rotación se comerá tu histórico).

Notas para entornos restringidos

Muchos parques FlexLM viven en sitios donde “mándalo a nuestra nube” no es una respuesta: contratistas de defensa y cualquier entorno de ingeniería o desarrollo donde la política de seguridad exige que los datos no salgan de la red. LiMon está construido para ese caso, no adaptado a él:

  • Corre íntegramente on-premises; nada llama a casa. Las únicas llamadas salientes opcionales son los webhooks de Slack/Teams si los configuras.
  • Sin agentes en servidores de licencias ni estaciones de trabajo — el poller consulta por red con las utilidades del propio vendor.
  • Apto para air-gap: las imágenes Docker van dentro del bundle, los paquetes nativos llevan wheels de Python offline, y tras la descarga inicial no se necesita acceso a internet.
  • El motor de sondeo y la API son de código consultable (BUSL-1.1), de modo que una revisión de seguridad puede leer qué hace el software realmente.

Diez minutos, con honestidad

“Dashboard en diez minutos” es aritmética de marketing en la mayoría de los vendors, así que seamos precisos con la nuestra: los diez minutos son el instalador más el asistente, asumiendo que el host existe, Docker (o la base de datos) está en su sitio y la ruta de red hacia tus servidores de licencias está abierta. La parte que LiMon no puede acelerar es tu burocracia de IT interna. Todo lo que viene después del asistente — el histórico, las tendencias, los informes — se acumula solo.

Si prefieres verificarlo contra tu propio parque antes que fiarte de nuestra palabra: solicita una evaluación de 60 días, apúntala a un par de servidores FlexLM y mira los datos. Las plataformas Standard y Professional — 20 servidores e ilimitados, respectivamente — tienen el precio en la página, de pago único y perpetuo, para que puedas hacer las cuentas sin una llamada comercial.

¿Listo para Encontrar tus Licencias Sin Usar?

Despliega LiMon en 10 minutos. Sin agentes, sin nube, sin aprobaciones de proveedor.