Origen del IBM AS400

Es posible que algunos de vosotros no hayáis oído hablar de los “AS/400”, también conocido como iSeries o Power Systems, en sus versiones más modernas. Otros puede que llevéis años trabajando con ellos, ya que están en las empresas desde 1988. Más de 30 años en los que un sistema caro y robusto sigue gobernando muchos procesos en muchas empresas: ¿por qué? Principalmente porque todavía sigue siendo posible ejecutar un programa de 1988 en la última versión del sistema, con pocos o ningún cambio. Esta garantía de compatibilidad continua permite a las empresas renovar los sistemas y crecer sin tener que estar continuamente reescribiendo su software. Es decir, imagínate el potencial de hacer una aplicación Javascript por ejemplo en un framework que supieras que en su versión de dentro de 30 años va a seguir funcionando; ¿suena imposible verdad? Pues por ello son máquinas tan apreciadas y se siguen vendiendo.

Con el tiempo, IBM no ha conseguido que la gente deje de llamarlos AS/400 y por tanto que suene a viejo e intocable, sobre todo cuando vemos su consola (fijaos en los aeropuertos cuando vayáis a embarcar, en muchos veréis ESA consola leyendo un QR de vuestros móviles). Pero la realidad es que han ido evolucionando e incluyendo tecnologías modernas, por lo que no es raro que se usen para servidores de aplicaciones Java o Python o servidores web Apache con PHP y MySQL.

Por su coste, no es habitual encontrar muchos en las empresas, pero sí corriendo sistemas críticos de negocio 24/7, como ERPs o sistemas logísticos. Por tanto, y aunque sean unas máquinas muy robustas no deben escapar a nuestro sistema de monitorización.

La solución más habitual para monitorizar estos equipos ha sido históricamente usar SNMP. Es necesario activarlo en el AS400 y normalmente se trata de la versión V1 del protocolo. Cabe decir que, en general, funciona bastante bien y cubre los aspectos básicos:

• Datos básicos de inventario: modelo, nombre del equipo
• Uptime
• CPU
• Memoria
• Número de procesos
• Número de usuarios
• Uso de red

En general esta parte de la monitorización nos servirá para darnos cuenta de si alguien ha reiniciado el equipo o si nuestras aplicaciones están consumiendo demasiada memoria. De hecho, es muy habitual que haya programados “reinicios” periódicos en estos equipos para recuperar la memoria (cuando, en realidad es un problema software).

Pero hay una parte fundamental que no cubre: estado y uso de discos, así como el control de procesos o trabajos, subsistemas y colas de mensajes. Esto era un problema y se planteaban varias soluciones, incluso hubo que gente que llegó a intentar compilar el agente para el AS/400, hasta que a Constantin Oshmyan se le ocurrió utilizar las API de Java (IBM Toolbox) que trae el AS/400 y hacer un software en Java que emulase a un agente de Zabbix.

Con esto, consiguió algo muy potente, ya que este emulador se puede instalar tanto en el servidor de IBM como en una máquina externa, por ejemplo, nuestro proxy o servidor de Zabbix. La única condición es ejecutar la JRE de Java en una versión superior a la 1.7, con un par de dependencias pequeñas. Podéis ver la explicación completa en la Zabbix Conference de 2017.

Hay que destacar que hay algunas limitaciones, pero no representan realmente un problema: no es compatible con IPv6, no hay encriptación y no todas las métricas de un agente normal de Zabbix están implementadas, como puede ser la ejecución remota de comandos o los famosos UserParameters.

Una vez instalado y configurado adecuadamente, podemos empezar a monitorizar el estado de aquellos trabajos (jobs) que nos interese mantener monitorizados, incluso conociendo su consumo concreto de CPU y memoria, y que nos mande una alarma en caso de que alguno caiga. También nos puede avisar de cuando hay algún trabajo parado a la espera de la acción de un operador (fallos al imprimir, etc).

Además de estas métricas el agente permite cosas muy interesantes como descubrimiento de trabajos en función de su consumo de CPU, para hacer un listado de los que más consumen en general, o el detalle de fallo de cualquier disco, así como el estado de los servicios por defecto de los iSeries: base de datos, ficheros, impresoras, etc.

Con estos pasos y combinando ambas monitorizaciones podemos tener muy controlados los AS400 de nuestra empresa desde una única herramienta a la que puedes añadir tus servidores de Amazon o Azure o tus microservicios Docker. La realidad de las empresas es que se termina teniendo una amalgama de tecnologías y esto no debe implicar tener la monitorización esparcida en múltiples aplicaciones que nos compliquen en localizar la causa raíz o correlacionar eventos cuando sucedan los problemas.

Si quieres que desde Muutech te ayudemos con la monitorización de tus IBM AS/400 o iSeries o PowerSystems, o como los llames, no dejes de contactarnos.