El iLO sabe la temperatura, pero no la de ayer: un historial térmico para el rack de mi homelab

🌐 También en: English · Deutsch · Français

Todo empezó con una pregunta sencilla en una tarde perezosa: ¿a qué temperatura están en realidad mis tres servidores? El iLO respondió al instante: aire de entrada entre 22 y 25 °C, ventiladores al ralentí al 6 %, todo en verde. Genial. Luego, la siguiente pregunta: ¿y durante la ola de calor de julio? Silencio. El iLO 5 muestra temperaturas y ventiladores solo en directo. Sin historial, sin gráfica, sin «el martes pasado». Así que me construí uno, y está en GitHub: aptupgrademe/ilo-thermal.

El mismo método de siempre: yo hago las preguntas y tomo las decisiones, mi coadministrador de IA (Claude) lee los iLO a través de Redfish, escribe el código y comprueba dos veces cada número antes de fiarse de él. Esa última parte resultó ser más importante de lo esperado.

🌡️ Primer vistazo: ¿qué sensor significa realmente algo?

Un iLO 5 en un DL20 Gen10 Plus expone una docena de sensores de temperatura. No todos son útiles, y dos de ellos mienten.

¿Tres servidores, cargas distintas y exactamente 40 °C en todos? Aquello olía a valor de relleno, así que comprobamos los discos desde Windows con SMART: de 31 a 35 °C. El iLO simplemente no sabe leer discos que no son de HPE y pone una constante. Primera lección: verifica un sensor antes de montar alertas sobre él.

🗺️ El mapa de sensores: delante es y = 1, detrás la y más alta

La siguiente pregunta era la interesante: ¿me daría cuenta siquiera de una acumulación de calor detrás del rack? Estos modelos no tienen sensor de aire de salida. Pero el Redfish de HPE te dice dónde está cada sensor: Oem.Hpe.LocationXmm y LocationYmm forman una cuadrícula en la que y = 1 es la entrada de aire delantera y la y más alta, el fondo; x es la posición a lo ancho. Pese al «mm» del nombre, son celdas de cuadrícula, no milímetros: los valores solo van de 1 a 14, más o menos, en un servidor de 43 cm de ancho. La profundidad de la cuadrícula depende del modelo: en los DL20 la fila trasera es y = 13–14, en el MicroServer, más compacto, la cuadrícula termina en y = 13. Detrás hay dos tipos de sensores:

• Sensores de chip (BMC, chip de red LOM): dominados por su propio calor, inútiles para el flujo de aire.
• Sensores de zona de aire (BMC Zone, PCI 1 Zone): miden el aire que los rodea, con poco autocalentamiento. BMC Zone marcaba 28 °C en HP2, solo 3 °C por encima de su entrada. Ese es mi sustituto del sensor de salida.

Y aquí está la clave: la temperatura trasera por sí sola no dice nada, porque sigue a la de la habitación. Una tarde calurosa sube la parte delantera y la trasera. Lo que delata una acumulación de calor es la diferencia. Si «detrás menos delante» crece por encima de sus +3 °C habituales mientras la entrada y la carga siguen igual, el aire caliente no está saliendo. El segundo indicador temprano: ventiladores que se aceleran aunque la entrada no esté más caliente.

📍 Ubicación, ubicación, ubicación: cuatro grados de abajo arriba

Las primeras horas de historial ya dejaron algo claro: dónde está un servidor en el rack importa más que qué servidor es. Misma habitación, mismo rack, misma carga en reposo, y aun así el aire de entrada difiere en varios grados, de forma constante, en cada una de las mediciones:

33 mediciones durante las cinco primeras horas de una tarde tranquila; todos los ventiladores en su mínimo del 6–8 %.

De abajo arriba, la entrada sube en escalones limpios de dos grados: 21,9 → 23,9 → 25,9 °C. Son cuatro grados entre el servidor de abajo y el de arriba, sin nada más que altura entre ellos. La física es sencilla: el aire caliente sube. La salida de todo lo que hay debajo se acumula en lo alto del rack y el servidor de arriba vuelve a aspirar parte de ella, sobre todo si el techo del rack está cerrado o el espacio encima es escaso. Fíjate en que la diferencia entre detrás y delante es la misma, +3–4 °C, en las tres máquinas. Los servidores se comportan de forma idéntica; lo que cambia es el aire que reciben.

Por qué importa:

• El servidor de arriba alcanza todos los límites primero. En una tarde de verano a 30 °C, HP3 seguiría tan tranquilo mientras HP2 ya estaría llamando a la puerta del umbral de aviso. Planifica para el sitio más caliente, no para la media.
• Compara cada servidor consigo mismo. Un valor «normal» fijo para todo el rack marcaría HP2 como sospechoso permanentemente. Por eso las reglas de alerta usan la mediana de 7 días de cada servidor.
• La colocación es un ajuste gratuito. Pon abajo la máquina que más se calienta o la más importante, cierra las unidades de rack sin usar con paneles ciegos para que el aire de salida no se cuele hacia delante, y deja que la parte alta del rack respire.

Confesión: esto lo subestimé. Cuando los servidores entraron en el rack, la estrategia de colocación fue, digamos, «donde quedaba un hueco libre». La física del flujo de aire no tuvo ni voz ni voto. Si alguna vez rediseño el rack, los servidores irán lo más abajo posible, apilados juntos en el fondo, donde el aire está más fresco.

Por cierto, el hueco de arriba ya tiene el inquilino adecuado: el switch. Según su hoja de datos está especificado para funcionar de forma estable a temperaturas ambiente bastante más altas que los servidores, así que soporta el aire caliente de ahí arriba mucho mejor que un ProLiant. La regla que me llevo: el sitio más caliente es para el aparato que mejor tolera el calor, no para el último en llegar.

Inofensivo en septiembre. Pero ahora sé exactamente qué servidor vigilar en agosto, y tengo los números para demostrar si reorganizar el rack sirve de verdad.

🧰 El script: aburrido a propósito

ilo_thermal.py es un único archivo de Python, solo biblioteca estándar. Ni pip, ni requests, ni matplotlib, nada que se pueda romper en la próxima actualización de la distro. Cada 10 minutos lo ejecuta cron:

1. Recoger: un único GET de Redfish de solo lectura por iLO para los datos térmicos. El script se conecta por IP, pero verifica el certificado TLS contra mi propia CA raíz y el nombre del certificado, porque el jump host no usa el DNS del AD. Sí, la PKI del homelab de un artículo anterior vuelve a dar sus frutos.
2. Guardar: todo va a SQLite. Unos 100–150 MB para tres servidores y 400 días, un año completo para comparar.
3. Evaluar: las reglas de alerta de abajo.
4. Informar: un único archivo HTML autónomo con las gráficas.

🚨 ¿Cuándo da la voz de alarma?

«Normal» es siempre la mediana del propio servidor en los últimos siete días, así que el sitio más caliente de HP2, arriba del todo, no cuenta como anomalía. Es lo normal para HP2. Estas reglas de referencia solo se activan tras un día de historial; una instalación recién hecha no te despertará por ruido. Las alertas tienen estado: un correo al empezar, un recordatorio cada 12 horas y un correo de «resuelto» al final. Nada de bombardeos en la bandeja de entrada.

😴 El recolector duerme, el iLO no

Aquí está la pega: mi jump host no está encendido 24/7. La consulta solo funciona mientras está en marcha, y como el iLO no guarda historial de temperaturas, las horas en las que estuvo apagado simplemente se pierden. El informe las muestra honestamente como huecos, en lugar de dibujar una línea recta engañosa a lo largo de la noche.

Pero el iLO sí guarda algo: el Integrated Management Log. Cada evento de hardware (sobrecalentamiento, fallo de ventilador, corte de corriente, errores de memoria o PCIe) se registra allí con marca de tiempo, lo esté mirando alguien o no. Así que el script recuerda el EventNumber más alto que ha visto por cada iLO, y una línea de cron @reboot lo ejecuta dos minutos después del arranque. Todo lo que sea más reciente se notifica con su marca de tiempo original.

Para probarlo, rebobinamos el cursor de HP2. El script desenterró enseguida un Uncorrectable PCI Express Error del 23 de julio que nadie había notado nunca:

IML HP2 CRIT: iLO log 2026-07-23 20:29:31 UTC [PCI Bus]: Uncorrectable PCI Express Error Detected.
              (Segment 0x0, Bus 0x1, Device 0x0, Function 0x2)

Un caso aislado, que no se repitió, pero justo el tipo de cosa que quieres saber. Dos detalles mantienen todo esto en su sitio: la primera ejecución solo coloca el cursor, para que no recibas la biografía completa de tus servidores en el primer correo. Y la clase Network del IML se ignora por defecto, porque HPE registra cada caída de enlace como «Critical», y eso pasa en cada reinicio por parches. (Mientras escarbaba, el IML también reveló que los tres servidores perdieron el enlace de red en el mismo segundo exacto el 26 de septiembre durante 90 segundos. No son tres servidores fallando, es un switch reiniciándose.)

📈 El informe

• Tres gráficas: aire de entrada (con la línea de aviso), diferencia detrás menos delante, ventiladores. Una magnitud por gráfica, sin crímenes de doble eje.
• Rangos de 24 h / 7 / 30 / 90 días, tooltips al pasar el ratón con todos los servidores en ese momento, huecos donde el recolector estaba apagado.
• Recuadros de estado, un banner de alerta y el historial de alertas, incluidos los eventos del IML recuperados.
• Modo claro y oscuro, un único archivo HTML, sin dependencias externas. Ábrelo en local o déjalo en una carpeta compartida.

📦 Descárgalo

Todo está en el repositorio: github.com/aptupgrademe/ilo-thermal. Documentación completa en inglés, alemán, francés y español: instalación, una cuenta de iLO de solo lectura (le basta con el privilegio Login), cada clave de configuración, cada regla de alerta, resolución de problemas y cómo adaptar los dos patrones de nombres de sensores a otros modelos ProLiant. El informe y las alertas hablan inglés o alemán.

git clone https://github.com/aptupgrademe/ilo-thermal.git ~/ilo-thermal
cd ~/ilo-thermal
cp ilo_thermal.conf.example ilo_thermal.conf && chmod 600 ilo_thermal.conf
# edit: iLO account, CA file, hosts, optional SMTP
./ilo_thermal.py collect && ./ilo_thermal.py report

# crontab
*/10 * * * * $HOME/ilo-thermal/run.sh
@reboot      sleep 120; $HOME/ilo-thermal/run.sh

⚠️ Descargo de responsabilidad

Esto es un proyecto personal, publicado tal cual bajo la licencia MIT. No acepto ninguna responsabilidad por su correcto funcionamiento, por alertas perdidas o falsas, ni por daños al hardware, a los datos o a cualquier otra cosa derivados de su uso. No sustituye la protección térmica propia de tus servidores ni un sistema de monitorización profesional. Comprueba siempre los valores en el iLO antes de actuar. Probado en iLO 5 con DL20 Gen10 Plus y MicroServer Gen10 Plus v2; lo demás corre de tu cuenta.

🎯 Conclusión

El iLO es una instantánea fantástica y una memoria pésima. Media tarde bastó para convertir la instantánea en historial y, de paso, me enseñó que dos de mis sensores cuentan ficción, que lo alto del rack siempre es el sitio caliente (cuatro grados más, en mi caso) y que el verdadero indicador del aire de salida es una diferencia, no una temperatura. Ahora es otoño y todo está aburrido y en verde. El próximo verano tendré un año de datos para comparar. De eso se trata. 🌡️📉