Cómo configurar correctamente Node Exporter: guía práctica para la supervisión de servidores Linux con Prometheus

Configurar correctamente Node Exporter significa: configuro el servicio de tal manera que Prometheus recopile métricas fiables de los servidores Linux con puertos bien definidos, ajustes específicos del colector y una seguridad adecuada. En esta guía práctica, explico la instalación, la configuración de systemd, el ajuste del colector, la seguridad, la integración con Prometheus, consejos para mejorar el rendimiento y comprobaciones útiles para el día a día.

Puntos centrales

• Instalación y el inicio del servicio con su propia unidad de systemd
• Coleccionista seleccionar de forma selectiva, reducir la carga métrica
• Seguridad mediante la apertura de puertos y el uso de un proxy
• Prometeo Scrapes, alertas y conservación
• Actuación a través de intervalos, sharding y limpieza

¿Qué es Node Exporter?

Puse el Nodo Instala el exportador en cada servidor Linux para proporcionar métricas del sistema en formato Prometheus. El demonio proporciona datos sobre la carga de la CPU, la carga del sistema, la memoria RAM, el espacio de intercambio, los sistemas de archivos, la red y, opcionalmente, datos de systemd y de procesos. Accedo al punto final a través de HTTP /métricas y veo series temporales legibles que Prometheus recoge de forma cíclica. Este enfoque se adapta a flotas de servidores heterogéneas y mantiene la transparencia gracias al modelo «pull». Me beneficio de una separación clara: el exportador recopila, Prometheus almacena y analiza.

Descripción general de la arquitectura: así es como se integran Node Exporter y Prometheus

Inicio el exportador en el puerto 9100, controlo los colectores y hago que Prometheus recopile datos periódicamente. El principio «pull» facilita la gestión de los cortafuegos, ya que solo tengo que permitir el acceso de Prometheus al host. A continuación, Grafana u otras soluciones de visualización similares se basan en Prometheus y muestran los valores de forma clara. En entornos de producción, utilizo varios servidores de Prometheus para responsabilidades separadas. De este modo, mantengo las rutas cortas, las funciones claras y la gestión transparente.

Instalación en Linux: limpia y repetible

Descargaré el binario adecuado para linux-amd64 o la arquitectura de destino, y ajústala en función de /usr/local/bin/. A continuación, configuro un usuario del sistema sin nombre de usuario, por ejemplo: node_exporter, y asigno los derechos de propietario al archivo binario. Para que se inicie automáticamente, creo una unidad de systemd en el directorio /etc/systemd/system/ con un simple ExecStart y una política de reinicio. Según systemctl daemon-reload Activo e inicio el servicio, compruebo el estado y llamo a curl http://localhost:9100/metrics . Así puedo comprobar de inmediato si las métricas están disponibles correctamente y si el servicio funciona según lo previsto.

Node Exporter como servicio de systemd: los ajustes clave

En la unidad defino Usuario y «Group» como cuenta dedicada, establece Tipo=simple y un ExecStart bien definido. Una estrategia de reinicio como Reiniciar=al fallar Ayuda a evitar fallos a corto plazo. Para las actualizaciones, edito la unidad o creo un archivo «drop-in», para que los cambios sean fáciles de seguir. Después de cada modificación, realizo un daemon-reload y reinicia el servicio. Me aseguro de que la unidad sea compacta, esté bien documentada y sea reutilizable para todos los tipos de servidores.

Puerto y dirección de lista: coherentes y seguros

Por defecto, escucho en el puerto 9100, aunque cambia el puerto en función del proyecto si hay conflictos. La opción --web.listen-address permite ajustar el host y el puerto, por ejemplo: 127.0.0.1:9200 en el caso de la descarga de proxy local. Un esquema de puertos uniforme reduce la confusión en equipos grandes. Introduzco los cambios de puerto de forma centralizada para que los cortafuegos y las listas de seguridad estén correctos. El puerto se limita a los servidores de Prometheus y no tiene acceso libre a Internet.

Configurar Collector de forma específica: solo lo que realmente importa

Elijo el Coleccionista de forma consciente, para controlar el volumen de datos y el tiempo de cálculo. Los módulos estándar para la CPU, la memoria, los sistemas de archivos y la red suelen permanecer activos. Si es necesario, activo módulos específicos como --collector.systemd o --collector.processes, para supervisar con mayor detalle los servicios y los procesos. Desactivo los módulos no deseados con --no-collector.X, para que Prometheus tenga que procesar menos series temporales. Documentaré la selección realizada para cada rol de servidor, para que el equipo mantenga la coherencia.

Textfile Collector: introducir correctamente las métricas propias

Utilizo el Textfile Collector para individual Indicadores que no proporcionan los módulos estándar. Un directorio como /var/lib/node_exporter/textfile_collector recoge .promArchivos en formato Prometheus. Los scripts escriben de forma atómica, creando archivos temporales y sustituyéndolos al final, para que no aparezcan valores a medio procesar. Así es como introduzco estadísticas empresariales, el estado de los lotes o la longitud de las colas directamente en Prometheus. Sigo las convenciones de nomenclatura para que los análisis y los paneles de control sean legibles.

Seguridad en el entorno de producción: acceso exclusivo para usuarios autorizados

Limito el acceso a los puertos mediante Cortafuegos de forma sistemática a las fuentes de scraping. Un proxy inverso situado en la entrada se encarga, si es necesario, del TLS o mTLS y gestiona la autenticación. Ejecuto el servicio sin derechos de root y asigno permisos mínimos a las rutas de los archivos de registro y de texto. En redes separadas, aplico medidas de seguridad adicionales mediante VPN o subredes privadas. De este modo, la información detallada del sistema permanece protegida y solo es visible para la infraestructura de monitorización.

Integración en Prometheus: scrapes, etiquetas, alertas

Lo pongo en la prometheus.yml un trabajo como nombre_del_puesto: node , establece un scrape_interval (a menudo 15 s) e introduzco objetivos o el descubrimiento de servicios. Las etiquetas uniformes (por ejemplo, entorno, función, ubicación) facilitan los filtros y los paneles de control. Para los análisis frecuentes, defino reglas de registro y, de este modo, aligero la carga de las consultas ad hoc. Las alertas se basan en métricas agregadas, como la carga de la CPU, la RAM, el espacio de intercambio, el uso del disco y los errores de red. Para iniciarse en el análisis de la utilización y los picos de carga, te remito a mi breve Análisis de la CPU y de la carga, que explica de forma práctica los indicadores típicos.

Supervisión del propio Node Exporter: confiar está bien, pero controlar es mejor

Observo al Estado del trabajo en Prometheus y configuro que se activen alertas si un host lleva mucho tiempo sin ser rastreado. Compruebo periódicamente las versiones de los exportadores para aprovechar rápidamente las correcciones de errores y los nuevos módulos. Además, mido el número de series temporales por host para detectar a tiempo si un cambio en el colector aumenta la carga. Los paneles de control reciben notificaciones sobre la última recopilación realizada con éxito. De este modo, detecto rápidamente las incidencias y reacciono sin demora.

Optimización del rendimiento y escalabilidad: mantener la carga bajo control

Controlo el Intervalos Según el tamaño y la finalidad del entorno: 15 s para los sistemas centrales, entre 30 y 60 s para los servidores menos críticos. Mediante una selección selectiva de colectores, reduzco las métricas y los tiempos de consulta. Mantengo mis propias métricas en archivos de texto lo más concisas posible, elimino las antiguas y las nombro de forma coherente. Si la flota crece considerablemente, distribuyo la carga entre varias instancias de Prometheus y separo las responsabilidades. La siguiente tabla muestra los ajustes probados y su efecto en el funcionamiento.

Tema	Configuración	Efecto	Nota
Intervalo de rastreo	15 s / 30 s / 60 s	Reducir el número de rasguños Carga	Tener en cuenta la criticidad por clase de host
Selección «Collector»	solo los módulos necesarios	Reduce las series temporales	Documentar la lista por cada rollo
Recopilador de archivos de texto	Archivos .prom de tamaño reducido	Menos costes de análisis sintáctico	Escribir de forma concisa, nombrar con claridad
Cardinalidad de las etiquetas	Comprobar las etiquetas	Evita Explosión de las series	Evitar los identificadores (ID) y los valores muy variables
Fragmentación	Dividir Prometeo	Amplía el número de raspeos y consultas	Separar las responsabilidades

En el caso de los sistemas de almacenamiento, presto especial atención a los valores de E/S y a las latencias por dispositivo, así como al sistema de archivos. Mi guía ofrece un buen punto de partida. Supervisar las latencias del disco, que resume las cadenas de síntomas y métricas típicas. Relaciono estos valores con la espera y la carga de la CPU para identificar con precisión los cuellos de botella. Encapsulo las consultas en reglas de grabación para que los paneles se carguen rápidamente. De este modo, el análisis y el funcionamiento se mantienen ágiles y claros.

Visualización con Grafana: ver con claridad, actuar con rapidez

Utilizo paneles de control ya preparados para CPU, RAM, disco, red y systemd, aunque los adapto a mis etiquetas. Un panel de control general muestra el estado, la carga y los hosts que destacan, mientras que las páginas de detalles ofrecen información más detallada. Describo brevemente los paneles para que todo el mundo comprenda el significado de los indicadores. Los selectores de variables agilizan el cambio entre hosts o roles. Quien desee obtener una visión general completa, encontrará en Pila de monitorización con Grafana Consejos para crear una pila de alto rendimiento.

Empaquetado limpio y gestión de versiones: mantener la reproducibilidad

Me aseguro de que las instalaciones sean reproducibles fijando explícitamente las versiones y comprobando las sumas de comprobación. Para las configuraciones de Fleet, empaqueto el Node Exporter como un paquete interno (por ejemplo, DEB/RPM) con una estructura de rutas fija y un usuario del sistema. Implemento las actualizaciones de forma escalonada y documento la versión utilizada en cada entorno. Cuando procede, guardo los parámetros de inicio en un EnvironmentFile, para que los cambios no se realicen directamente en el archivo de la unidad y se mantengan correctamente controlados por versiones. Primero pruebo las nuevas versiones en el entorno de staging antes de distribuirlas de forma generalizada.

Configuración de ejemplo: unidad de systemd y refuerzo de seguridad

Utilizo una unidad sencilla pero eficaz y, cuando es necesario, añado ajustes de endurecimiento:

[Unit]
Description=Prometheus Node Exporter
After=network-online.target
Wants=network-online.target

[Service]
Usuario=node_exporter
Grupo=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=0.0.0.0:9100 \
  --collector.systemd \
  --collector.processes \
  --collector.filesystem.fs-types-exclude='^(tmpfs|devtmpfs|overlay|squashfs)$' \
  --collector.filesystem.mount-points-exclude='^/(sys|proc|dev|run)($|/)'
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

En el caso de los servidores productivos, refuerzo aún más la seguridad del servicio sin limitar sus derechos de lectura a /proc y /sys romper. Lo pongo como «drop-in» (/etc/systemd/system/node_exporter.service.d/hardening.conf) para:

[Service]
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=strict
ProtectHome=true
ProtectControlGroups=true
ProtectKernelTunables=true
ProtectKernelModules=true
LockPersonality=true
MemoryDenyWriteExecute=true
CapabilityBoundingSet=
AmbientCapabilities=
RestrictNamespaces=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
SystemCallFilter=@system-service

Después de cada modificación: systemctl daemon-reload y un reinicio limpio. Para fines de depuración, activo temporalmente un nivel de registro más alto mediante --log.level=debug, para ver los detalles del recopilador y del analizador sintáctico.

Toques finales de Collector para entornos de consulta

Equilibro la visibilidad y la carga con filtros específicos:

• Sistemas de archivos: Excluyo los pseudo-FS y los montajes temporales (--collector.filesystem.fs-types-exclude y --collector.filesystem.mount-points-exclude), para evitar series sin sentido.
• Procesos: --collector.processes Proporciona totales útiles, pero genera series adicionales. Solo lo activo en los hosts en los que el número de procesos proporciona una señal (por ejemplo, nodos de lotes o de trabajo).
• Red: El netstat-Collector puede generar muchas etiquetas, dependiendo del kernel y de las conexiones. Compruebo la cardinalidad en el entorno de prueba y, si no es así, lo desactivo de forma selectiva.
• Presión/PSI: Los kernels modernos proporcionan métricas de presión (--collector.pressure, (a menudo activa por defecto). La utilizo para detectar a tiempo los cuellos de botella en la CPU, las E/S y la memoria.
• NVMe/RAID: colectores específicos (p. ej.,. NVMe) Solo lo activo cuando se dispone del hardware necesario; así, los paneles de control siguen siendo significativos.

Pruebo los colectores de forma selectiva mediante el parámetro de consulta collect[], sin modificar los parámetros de inicio. Un ejemplo: curl 'http://localhost:9100/metrics?collect[]=systemd&collect[]=processes'. Así puedo ver de inmediato qué influencia tiene cada Collector.

Textfile Collector: buenas prácticas en el ámbito operativo

Escribo las métricas de forma atómica: los scripts generan primero .tmp-archivos y, al final, los sustituyes mediante mv. Cada archivo contiene solo un grupo lógico y tiene un tamaño máximo de unos pocos kilobytes. Dejo que Prometheus se encargue de la gestión de las marcas de tiempo; los propios archivos no necesitan marcas de tiempo. Si elimino un .promSi el archivo... desaparece, las series correspondientes se borrarán tras la próxima recopilación. Documento los espacios de nombres (p. ej.,. business_*) y mantengo estables los valores de las etiquetas para controlar la cardinalidad. Cuando los valores oscilan mucho, los suavizo ya en los scripts (por ejemplo, calculando la media), para que los paneles de control funcionen con mayor fluidez.

Seguridad: tipos de cortafuegos y servidores proxy

En primer lugar, apuesto por la segmentación de la red: el exportador solo escucha internamente y el cortafuegos solo permite el acceso a las direcciones IP de Prometheus. Un ejemplo con nftables en un servidor:

table inet filter {
  chain input {
    type filter hook input priority 0;
    ct estado establecido, relacionado aceptar
    si lo aceptar
    tcp dport 9100 ip saddr { 10.0.0.10, 10.0.0.11 } aceptar
    tcp dport 9100 rechazar
  }
}

Cuando es necesario el cifrado, coloco delante un proxy inverso local que se encarga del TLS o mTLS y solo permite el acceso a 127.0.0.1:9100 reenvía. Como alternativa, utilizo —siempre que la versión lo permita— la configuración web nativa del exportador a través de un --archivo web.config, para que la autenticación y los certificados sigan gestionándose de forma centralizada. Por norma general, el servicio se ejecuta sin privilegios, con derechos mínimos sobre su directorio y escribiendo solo donde sea realmente necesario (por ejemplo, en la ruta del archivo de texto).

La integración de Prometheus al detalle: reetiquetado, límites y alertas

Mantengo las tareas concisas y uniformes. Una tarea práctica, con límites y gestión de etiquetas, tiene este aspecto:

scrape_configs:
- job_name: node
  scrape_interval: 30 s
  scrape_timeout: 10 s
  sample_limit: 10 000
  static_configs:
  - targets: ['host1:9100','host2:9100']
    labels:
 env: prod
 role: web
  relabel_configs:
  - source_labels: [__address__]
    target_label: instance
    regex: '([^:]+)(?::\d+)?'
    replacement: '$1'
  metric_relabel_configs:
  - source_labels: [device]
    regex: '^(ram|loop|zram|dm-).*'
    action: drop

Con metric_relabel_configs Reduzco la cardinalidad descartando los dispositivos que aportan poca información. Para las alertas, utilizo reglas sencillas pero sólidas:

grupos:
- nombre: node_basic
  reglas:
  - alerta: NodeDown
    expresión: up{job="node"} == 0
    duración: 5m
    etiquetas: {gravedad: crítica}
  - alerta: HighCPU
    expresión: 1 - promedio por (instancia) (tasa(node_cpu_seconds_total{modo="inactivo"}[5m])) > 0,9
    duración: 10m
    etiquetas: {gravedad: advertencia}

Para supervisar la carga utilizo scrape_duration_seconds y muestras_recogidas_raspadas por objetivo. Así puedo detectar si un colector activado adicionalmente aumenta de forma desproporcionada el tiempo de recogida o el número de serie.

Funcionamiento en contenedores y Kubernetes

Instalo Node Exporter en contenedores cerca del servidor, para que /proc y /sys sigan siendo visibles desde el host. Para ello, monto estas rutas en modo de solo lectura en el contenedor y utilizo hostNetwork para garantizar la coherencia de los puertos. En Kubernetes, ejecuto el exportador como un DaemonSet por cada nodo y mantengo los contextos de seguridad de forma restrictiva (sin privilegios innecesarios). A la hora de elegir el colector, tengo en cuenta los entornos Cgroup v2; colectores importantes como meminfo, presión, sistema de archivos y CPU siguen siendo la base. Compruebo, tras las implementaciones, con un enlace directo rizo comprobar en el Pod si realmente se leen las rutas de métricas del host esperadas.

Resolución de problemas y garantía de calidad

• Conectividad: Lo compruebo curl -s http://localhost:9100/metrics | head en el servidor de destino y, desde el punto de vista de Prometheus, la accesibilidad a través del puerto abierto.
• Prueba para coleccionistas: Acerca de collect[] Probé cada colector por separado, sin modificar la configuración global.
• Registros: Aumento temporalmente el nivel de registro (--log.level=debug), para solucionar errores de análisis sintáctico o problemas de permisos en /proc//sys visible.
• Control de versiones: Con node_exporter_build_info Comparo versiones y planifico las actualizaciones de forma específica.
• Resumen de las series: la métrica scrape_samples_scraped{job="node"} Lo utilizo como valor aproximado para el número de series por host. Un repunte indica la aparición de nuevos colectores o una explosión de etiquetas.
• Tiempos muertos: Yo creo que... scrape_timeout por debajo de scrape_interval y observo scrape_timeout_seconds, para detectar a tiempo los cuellos de botella.

Capacidad y almacenamiento: planificar en lugar de dejarse sorprender

Configuré el almacenamiento de datos en Prometheus según el caso de uso: intervalos cortos para los sistemas principales y un almacenamiento más prolongado para las tendencias. A medida que crece la flota, escalo horizontalmente mediante sharding (por ejemplo, por ubicación o equipo) y desacoplo la carga de consultas de la de ingesta. Si es necesario, también escribo métricas en un componente de almacenamiento a largo plazo mediante escritura remota. Vigilo activamente la cardinalidad y elimino de forma sistemática las métricas o etiquetas que no se utilizan, especialmente en el caso de las métricas de archivos de texto, que pueden crecer rápidamente.

Consejos prácticos para flotas heterogéneas

• Hosts que solo admiten IPv6: Yo también me apunto [::]:9100 y asegúrate de que las reglas del cortafuegos sean las adecuadas.
• Hardware específico: solo activo los colectores específicos de hardware cuando tiene sentido hacerlo, y documento las diferencias en los perfiles de roles.
• Actualizaciones por fases: actualizo por lotes y voy supervisando el proceso arriba, scrape_duration_seconds y muestras_recogidas_raspadas, para detectar inmediatamente cualquier retroceso.
• Documentación: Anoto los parámetros de inicio efectivos para cada rol. Esto evita discusiones y facilita el análisis de errores.

En resumen: mi horario de la consulta

Voy a instalar el Nodo Configuraré el exportador como un servicio propio de systemd, estableceré el puerto y la dirección de escucha, y aplicaré un control de acceso estricto. Elijo los colectores de forma deliberada, introduzco los valores necesarios a través del colector de archivos de texto y mantengo reducido el número de métricas. En Prometheus establezco intervalos adecuados, mantengo las etiquetas, defino reglas de registro y alarmas para la CPU, la RAM, los discos y la red. Superviso yo mismo el exportador, planifico las actualizaciones y compruebo periódicamente el número de series por host. Gracias a una visualización clara, reacciono más rápido, detecto tendencias de forma temprana y mantengo la solidez de la supervisión de mis servidores Linux en el día a día.