Netdata es la forma más rápida de ver, en tiempo real y por segundo, qué le pasa a tu servidor y a cada contenedor, y con Docker lo tienes funcionando sin escribir una sola línea de configuración. En esta guía levantas Netdata con un solo archivo docker-compose.yml, montas las rutas del sistema anfitrión que necesita para verlo todo, entiendes por qué recoge las métricas por segundo y detecta tus servicios de forma automática, configuras alertas y notificaciones, y decides cuándo te conviene Netdata y cuándo la pila Prometheus más Grafana. La misma explicación está disponible en inglés.

Puntos clave

  • Netdata es un sistema de monitorización en tiempo real de código abierto (licencia GPLv3+), creado por Costa Tsaousis y publicado en marzo de 2016; hoy es una de las herramientas de observabilidad self-hosted más instaladas.
  • La versión estable más reciente es Netdata 2.10.4, publicada en julio de 2026; su imagen oficial netdata/netdata está basada en Debian 13.
  • El panel web y la API escuchan en el puerto 19999, y no requieren ninguna configuración inicial: Netdata detecta cientos de servicios y expone sus gráficas nada más arrancar.
  • Recoge métricas con granularidad de un segundo, sin muestreo ni promediado, y las guarda en su motor propio dbengine, que usa hasta cinco niveles de resolución para conservar el histórico ocupando muy poco disco.
  • Cuidado con la etiqueta :latest: en Netdata apunta a las compilaciones nocturnas (nightly). Para un servidor usa netdata/netdata:stable o fija una versión concreta como netdata/netdata:v2.10.4.

¿Qué es Netdata y para qué sirve?

Netdata es un agente de monitorización que se instala en cada máquina y, sin configuración previa, empieza a recoger miles de métricas del sistema operativo (CPU, memoria, disco, red), de los contenedores Docker y de las aplicaciones que encuentra (bases de datos, servidores web, colas). Todo eso lo muestra en un panel web propio, con gráficas que se actualizan en vivo y una resolución de un segundo.

Nació de la frustración de su creador, Costa Tsaousis, que en 2013 no logró diagnosticar por qué fallaban en silencio ciertas transacciones porque las herramientas de la época daban pocas métricas y con poca resolución. La respuesta de Netdata es la contraria: recoger casi todo, por segundo, y enseñarlo al instante. Como resume su documentación oficial, Netdata recoge métricas "por segundo, sin muestreo, promediado ni estimación", con una latencia de recogida a visualización inferior a un milisegundo.

Frente a la clásica pila de Prometheus y Grafana, que hay que montar y configurar pieza a pieza, la propuesta de Netdata es la inmediatez: un contenedor, cero configuración y un panel completo desde el primer segundo. A cambio, cada nodo guarda sus propios datos por defecto, un modelo distinto al de un almacén central que veremos más abajo.

¿Cómo es el docker-compose.yml de Netdata?

Para que Netdata vea el sistema anfitrión de verdad (procesos, discos, temperatura, contenedores) el contenedor necesita compartir el espacio de procesos y la red del anfitrión y montar varias rutas del sistema en modo solo lectura. Esta es la configuración recomendada oficialmente, con volúmenes con nombre para que la configuración, los datos y la caché sobrevivan a los reinicios:

services:
  netdata:
    image: netdata/netdata:v2.10.4
    container_name: netdata
    hostname: mi-servidor
    pid: host
    network_mode: host
    restart: unless-stopped
    cap_add:
      - SYS_PTRACE
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined
    volumes:
      - netdataconfig:/etc/netdata
      - netdatalib:/var/lib/netdata
      - netdatacache:/var/cache/netdata
      - /:/host/root:ro,rslave
      - /etc/passwd:/host/etc/passwd:ro
      - /etc/group:/host/etc/group:ro
      - /etc/os-release:/host/etc/os-release:ro
      - /etc/localtime:/etc/localtime:ro
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /var/log:/host/var/log:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  netdataconfig:
  netdatalib:
  netdatacache:

Merece la pena entender cada bloque. La opción pid: host deja que Netdata vea todos los procesos del anfitrión y no solo los del contenedor, y network_mode: host le da acceso a las interfaces de red reales y publica el panel directamente en el puerto 19999 de la máquina. Las capacidades SYS_PTRACE y SYS_ADMIN, junto con apparmor:unconfined, permiten al agente leer información de procesos y del kernel que de otro modo estaría bloqueada. Los tres volúmenes con nombre (netdataconfig, netdatalib, netdatacache) guardan tu configuración y el histórico de métricas; si quieres repasar la diferencia entre un volumen con nombre y un bind mount, lo explicamos en la guía sobre volúmenes y bind mounts en Docker. El montaje de /var/run/docker.sock en modo lectura es el que permite descubrir y medir cada contenedor por su nombre.

Arranca la pila y sigue el arranque en los logs:

docker compose up -d
docker compose ps
docker compose logs -f netdata

Abre http://localhost:19999 en el navegador y verás el panel con todas las secciones ya pobladas. La imagen oficial incluye su propio HEALTHCHECK interno (consulta /api/v1/info), así que docker compose ps mostrará el contenedor como healthy en cuanto el agente esté listo, sin que tengas que definir nada.

Un aviso de seguridad: con network_mode: host, el puerto 19999 queda expuesto en todas las interfaces de la máquina. Netdata no trae inicio de sesión en su versión de agente, así que no lo dejes accesible en Internet a pelo. Protégelo con el cortafuegos, o publícalo con autenticación y HTTPS tras un proxy inverso como Traefik.

¿Cómo funcionan las métricas por segundo y la detección automática?

La seña de identidad de Netdata es la resolución. Mientras que muchos sistemas recogen datos cada 15, 30 o 60 segundos, Netdata lo hace cada segundo y sin promediar, de modo que un pico de CPU que dura tres segundos se ve como tres puntos reales y no se pierde en una media. Ese detalle marca la diferencia cuando persigues un problema intermitente.

Para conservar tanta resolución sin llenar el disco, Netdata usa su motor de base de datos dbengine, organizado en niveles (tiers): el nivel 0 guarda los datos por segundo, el nivel 1 los agrega por minuto y el nivel 2 por hora, y así hasta cinco niveles. Los datos recientes conservan el máximo detalle y los antiguos se comprimen a menor resolución, ocupando en torno a medio byte por muestra en alta resolución. Puedes decidir cuánto histórico guardar ajustando el tamaño de cada nivel en la configuración.

La detección automática es la otra mitad del truco. Al arrancar, Netdata inspecciona el sistema y activa por su cuenta los colectores que correspondan: si detecta contenedores por el socket de Docker, los monitoriza uno a uno; si encuentra un PostgreSQL, un Nginx o un Redis, empieza a leer sus estadísticas sin que configures nada. Es el mismo tipo de métricas de sistema y de contenedor que en la pila de Prometheus tendrías que exponer a mano con un Node Exporter y un cAdvisor, aquí resueltas de una sola vez.

¿Cómo configurar alertas y notificaciones?

Netdata no solo dibuja gráficas: trae de fábrica cientos de alertas ya definidas sobre las métricas más habituales (uso de disco, memoria disponible, contenedores reiniciándose, saturación de red). Cuando una de esas condiciones se cumple, el agente lanza una alarma que verás marcada en el panel, en la sección de alertas, sin haber tocado nada.

Para que esas alarmas salgan de la máquina y te lleguen, se configura el archivo health_alarm_notify.conf. La forma más limpia de editarlo con esta instalación es usar el script edit-config dentro del contenedor, que copia la plantilla al volumen de configuración:

docker exec -it netdata /usr/sbin/netdata-updater.sh --help
docker exec -it netdata edit-config health_alarm_notify.conf

En ese archivo activas los métodos que quieras: correo, Telegram, Slack, Discord o un servidor de notificaciones push propio. Si prefieres recibir los avisos en el móvil sin depender de terceros, encaja muy bien con ntfy, un servidor de notificaciones push self-hosted, al que Netdata puede enviar mediante una llamada web. También puedes crear o ajustar tus propias alertas en la carpeta health.d, definiendo el umbral y la gravedad de cada una.

¿Netdata o Prometheus más Grafana?

No compiten exactamente en la misma liga, y elegir bien depende de tu escala. Netdata es un todo en uno: recoge, almacena, alerta y visualiza en un único contenedor, por segundo y sin configurar. Es ideal para uno o pocos servidores donde quieres visibilidad total ya, con el mínimo esfuerzo. Su punto débil es que, por defecto, cada agente guarda sus propios datos localmente, así que agregar el histórico de muchos nodos en un mismo sitio no es su fuerte sin recurrir a Netdata Cloud.

La pila de Prometheus con Grafana es lo contrario: más piezas que montar y configurar, un modelo pull con un almacén central de series temporales y tableros que construyes tú, pero a cambio te da un repositorio único para decenas de servidores, un lenguaje de consulta potente (PromQL) y un ecosistema enorme de exportadores y cuadros de mando. Para un homelab que empieza, Netdata te da resultados en un minuto; para una flota grande con retención a largo plazo y consultas a medida, la pila Prometheus más Grafana escala mejor. Nada te impide usar las dos: de hecho, Netdata puede exponer sus métricas en formato Prometheus para que este las recoja. Si buscas algo aún más ligero, compáralo también con Glances como monitor de sistema.

Preguntas frecuentes

¿Por qué no debo usar la etiqueta latest de Netdata?

Porque en Netdata la etiqueta :latest apunta a las compilaciones nocturnas (nightly), pensadas para probar novedades, no para producción. Si escribes netdata/netdata:latest recibirás builds recientes que pueden cambiar de un día para otro. Para un servidor estable usa la etiqueta netdata/netdata:stable, o mejor fija una versión concreta como netdata/netdata:v2.10.4 y decide tú cuándo actualizar recreando el contenedor con una imagen nueva.

¿Cuántos recursos consume Netdata?

Menos de lo que su cantidad de gráficas hace pensar, porque está escrito en C y muy optimizado. En un servidor doméstico el agente suele moverse en unos pocos cientos de MB de RAM y un uso de CPU bajo; el consumo depende sobre todo de cuántas métricas recojas y de cuánto histórico guardes en el dbengine. Si vas justo de memoria, puedes reducir el número de niveles de almacenamiento o la retención de cada uno en la configuración, y bajar así la huella.

¿Netdata guarda el histórico si borro el contenedor?

Sí, siempre que uses los volúmenes con nombre de esta guía. El contenedor es efímero, pero netdatalib y netdatacache conservan la base de datos de métricas y sobreviven a docker compose down; al recrear el servicio, el histórico vuelve a montarse. Solo lo perderías con docker compose down -v, que elimina también los volúmenes. Aun así, por defecto Netdata está pensado para el histórico de cada nodo: para retención centralizada de muchas máquinas se usa Netdata Cloud o se exportan las métricas a un almacén como Prometheus.

Conclusión

Con un único docker-compose.yml y los montajes del anfitrión tienes un Netdata persistente que monitoriza tu servidor y todos sus contenedores por segundo, con detección automática, cientos de alertas de fábrica y un panel completo en el puerto 19999, todo sin apenas configurar. Es la vía más rápida a la observabilidad en un homelab: arráncalo, protégelo tras un proxy inverso, conéctalo a ntfy para las notificaciones y, si tu infraestructura crece, complétalo o sustitúyelo por la pila Prometheus más Grafana. A partir de aquí, cada servicio nuevo aparece solo en tu panel.

Fuentes: [1] Documentación oficial de Netdata (instalación con Docker)[1], [2] Imagen oficial netdata/netdata en Docker Hub[2], [3] Repositorio de Netdata en GitHub[3], [4] Netdata en Wikipedia[4].

Visitas: 0

Fuentes

  1. Documentación oficial de Netdata (instalación con Docker)
  2. Imagen oficial netdata/netdata en Docker Hub
  3. Repositorio de Netdata en GitHub
  4. Netdata en Wikipedia

Ruta: Monitorización y observabilidad con Docker