Durante mucho tiempo mi stack de monitorización fue Grafana más Prometheus más node_exporter más varios exporters específicos. Funciona bien, da dashboards muy potentes, y lo recomiendo. También tarda horas en configurar correctamente, tiene un consumo de recursos no despreciable, y cualquier nueva métrica que quieras monitorizar requiere buscar el exporter adecuado, configurarlo, añadir el scrape job en Prometheus, crear el panel en Grafana.
Netdata tiene una filosofía diferente. Instalas el agente y en dos minutos tienes datos de todo: CPU, memoria, disco, red, procesos, temperatura, Docker, y decenas de integraciones que se detectan automáticamente. Sin tocar ningún archivo de configuración en la instalación básica.
Llevo usando los dos en mi homelab en paralelo. Te cuento para qué sirve cada uno en la práctica.
Qué es Netdata y cómo funciona#
Netdata es una herramienta de monitorización open source enfocada en datos en tiempo real. La diferencia fundamental con Prometheus es la resolución: Prometheus por defecto hace scrape cada 15-60 segundos. Netdata recolecta métricas cada segundo.
Para muchos casos, la diferencia no importa. Para detectar picos de CPU que duran 3 segundos o para entender exactamente qué proceso consumió memoria en un momento concreto, la diferencia es enorme.
El agente de Netdata se instala en cada servidor que quieres monitorizar. Cada agente tiene su propia interfaz web con dashboards completos. Opcionalmente, puedes conectar varios nodos a Netdata Cloud (la versión hosted gratuita con limitaciones) o desplegar tu propio Netdata Parent para centralizar datos localmente.
El consumo del agente en un servidor inactivo es de unos 40-70 MB de RAM. Con todas las integraciones activas y alta carga, puede llegar a 150-200 MB. Mucho menos que un stack Prometheus completo.
Instalación#
La forma más rápida de instalar el agente:
| |
El flag --disable-telemetry deshabilita el envío de estadísticas anónimas de uso. Lo recomiendo para instalaciones de homelab aunque los datos que envían son genéricos.
Si prefieres Docker, hay imagen oficial:
| |
El contenedor necesita acceso al sistema host para recopilar métricas reales, de ahí los volúmenes de /proc, /sys, etc. y el modo de red host. Sin esos accesos, las métricas que obtiene son las del contenedor, no las del servidor subyacente.
Después de instalar, accede a http://tu-servidor:19999 y ya tienes la interfaz con datos en tiempo real.
Lo que detecta automáticamente#
Aquí es donde Netdata sorprende si vienes de Prometheus. Sin tocar ningún archivo de configuración, detecta y empieza a monitorizar automáticamente:
Sistema base: CPU por core y por modo (user, system, iowait, irq, softirq), memoria RAM y swap con detalle de buffers y caché, disco por dispositivo con IOPS y latencia, red por interfaz con detalle de paquetes y errores.
Procesos: los top procesos por CPU y memoria con actualización por segundo. Puedes ver exactamente qué proceso está consumiendo qué en este momento, no el promedio de los últimos 15 segundos.
Docker: si el socket de Docker está accesible, detecta todos los contenedores y muestra métricas por contenedor automáticamente. CPU, memoria, red y disco de cada contenedor sin configurar nada adicional.
Servicios comunes: si tienes nginx, Apache, MySQL, PostgreSQL, Redis, o decenas de otros servicios corriendo, Netdata los detecta e intenta recopilar métricas específicas del servicio. Para PostgreSQL, por ejemplo, muestra número de conexiones, queries por segundo, tamaño de caché. Algunos requieren que le des credenciales de solo lectura, pero la detección automática te dice qué configurar.
Temperatura: en servidores con sensores de temperatura expuestos vía lm_sensors, Netdata los muestra automáticamente. En mis Mini PCs tengo temperatura de CPU y de la placa sin configuración adicional.
La interfaz web#
La interfaz de Netdata tiene un diseño distinto a Grafana. No creas dashboards desde cero, la interfaz viene preconfigurada con decenas de secciones organizadas por categoría. CPU, memoria, disco, red, Docker, y todos los servicios detectados tienen sus secciones con los gráficos relevantes.
Lo que más uso: la sección de “Overview” cuando algo va raro. En 30 segundos puedo ver si el problema es CPU, memoria, disco o red, y en cuál de los procesos está el origen. Con Grafana y Prometheus también puedo hacer esto, pero requiere saber dónde está el panel relevante o construirlo previamente.
La línea de tiempo en la parte superior del dashboard permite navegar por el historial. Haces clic en un punto del pasado y todos los gráficos se sincronizan a ese momento. Para investigar un incidente que ocurrió a las 3 de la mañana, esto es muy útil.
El historial que guarda por defecto: una hora de datos al segundo, luego resolución reducida para histórico más largo. Para retención de datos larga con alta resolución necesitas configurar persistencia adicional, que veremos después.
Alertas automáticas#
Netdata viene con cientos de alertas predefinidas que se activan automáticamente cuando el agente detecta condiciones anómalas. No necesitas crear reglas desde cero.
Alertas que se activan sin configuración:
- CPU con uso sostenido alto durante varios minutos
- Memoria libre por debajo de ciertos umbrales
- Swap en uso (señal de presión de memoria)
- Espacio en disco bajo
- IOPS de disco excesivos
- Temperatura de CPU alta
- Errores en interfaces de red
Para configurar los canales de notificación, editas /etc/netdata/health_alarm_notify.conf. Hay soporte para Telegram, Slack, Discord, email, PagerDuty, y bastantes más.
La configuración de Telegram es la más rápida:
| |
Con esto, cualquier alerta que dispare Netdata llega a Telegram. El mensaje incluye el nombre del servidor, la métrica que activó la alerta, el valor actual, y un enlace directo al dashboard del servidor en ese momento.
Hay también alertas silenciadas o con criticidad reducida que puedes ajustar. Si tienes un servicio que normalmente usa mucha CPU pero es esperado, puedes editar la alerta correspondiente para subir el umbral o desactivarla para ese servidor específico.
Centralizar múltiples nodos: Netdata Parent#
Cuando tienes varios servidores, acceder a cada uno por su IP es incómodo. Netdata Parent permite centralizar los datos de varios agentes en un nodo central.
La arquitectura es simple: los agentes envían sus datos por streaming al Parent, que los almacena y los sirve todos desde una sola interfaz. Puedes ver todos tus servidores desde una URL.
Para configurar el agente como hijo que envía datos al Parent, en el archivo /etc/netdata/stream.conf del agente:
| |
En el Parent, en el mismo archivo stream.conf, configuras los UUIDs aceptados:
| |
Con esta configuración, el Parent recibe los datos de todos los agentes. La interfaz web del Parent muestra todos los nodos con un selector, y puedes cambiar entre ellos manteniendo el mismo dashboard.
El Parent necesita algo más de RAM que los agentes individuales porque almacena los datos de todos. Para 5-10 nodos con histórico de una semana, 2-4 GB de RAM es suficiente.
Retención de datos: dbengine#
Por defecto, Netdata guarda los datos en memoria con retención limitada. Para histórico largo, usa dbengine, que escribe los datos a disco.
En /etc/netdata/netdata.conf:
| |
Con esta configuración tienes datos al segundo para el histórico reciente, y datos comprimidos para análisis a largo plazo. El espacio total con esos valores es menos de 2 GB para un servidor típico.
Netdata vs Grafana+Prometheus: cuándo usar cada uno#
Después de usar los dos en producción, mi conclusión:
Uso Netdata para:
- Monitorización en tiempo real cuando hay un problema activo
- Servidores que no forman parte de mi stack principal de Kubernetes (SBCs, mini PCs secundarios, VMs de prueba)
- Detección rápida de anomalías sin tiempo de configuración
- Servidores nuevos que quiero monitorizar en minutos
Uso Grafana + Prometheus para:
- Dashboards personalizados con métricas de negocio o métricas específicas de mis aplicaciones
- Correlación de métricas de múltiples fuentes en un solo dashboard
- Alertas con reglas complejas que dependen de múltiples condiciones
- Mi cluster K3s, donde las integraciones con Kubernetes son más maduras en Prometheus
En un homelab mediano, los dos tienen su lugar. No son mutuamente excluyentes. De hecho, Netdata puede exportar métricas en formato Prometheus, así que si ya tienes Prometheus, puedes añadir Netdata como fuente de datos sin abandonar tu stack actual.
Algunas limitaciones reales#
El modo de visualización de Netdata no tiene la flexibilidad de Grafana. Si necesitas un dashboard con métricas muy específicas o cruzadas entre diferentes sistemas, Grafana es mejor. La interfaz de Netdata está preconfigurada y aunque se puede personalizar con dashboards personalizados, es más rígida.
Las alertas de Netdata son más simples que las de Alertmanager (el componente de Prometheus para alertas). Para alertas complejas con agrupación, silencios programados, y escalado a diferentes canales según severidad, el stack de Prometheus es más potente.
La versión cloud de Netdata tiene limitaciones en el plan gratuito (retención de datos, número de nodos). El setup con Parent propio evita estas limitaciones pero requiere más configuración inicial.
Conclusión#
Netdata ocupa un lugar específico en el toolkit de homelab. No reemplaza a Grafana+Prometheus para todo, pero para monitorización rápida sin configuración, detección en tiempo real, y servidores secundarios que no justifican el overhead de un stack completo de Prometheus, es difícil de superar.
Si tienes servidores en tu homelab sin ninguna monitorización porque montar Grafana te da pereza, Netdata puede ser el punto de partida. Diez minutos de instalación y ya tienes datos que tardarías horas en ver con otros stacks.