← Volver al listado de tecnologías ← Índice de Dokploy

Monitoring

Por: Artiko
dokploymonitoringmetricasrecursos

Monitoring

Dokploy incluye un sistema de monitoreo integrado que muestra metricas de recursos en tiempo real. No necesitas instalar herramientas externas para tener visibilidad basica del estado de tus aplicaciones y servidor.

Dashboard de monitoreo

El dashboard de monitoreo esta disponible en dos niveles:

Monitoreo del servidor

Accede desde Settings > Server > Monitoring. Muestra metricas globales del servidor host:

Monitoreo por aplicacion

Cada aplicacion tiene su propia pestana Monitoring que muestra el consumo de recursos de ese contenedor especifico.

Para acceder:

  1. Abre el proyecto
  2. Selecciona la aplicacion
  3. Ve a la pestana Monitoring

Metricas por aplicacion

CPU

La grafica de CPU muestra el porcentaje de uso del contenedor respecto a los recursos asignados:

CPU Usage: 23.5%
Limit: 2 cores
Current: 0.47 cores

Valores a observar:

Memoria

Muestra el consumo de RAM del contenedor:

Memory Usage: 256 MB / 512 MB (50%)
RSS: 245 MB
Cache: 11 MB

Si una aplicacion alcanza su limite de memoria, Docker la mata con un error OOM (Out of Memory). Veras esto en los logs como:

Container killed: OOMKilled=true

Disco

El uso de disco del contenedor incluye:

Disk Read: 12.3 MB/s
Disk Write: 4.7 MB/s

Red

Trafico de red del contenedor:

Network RX: 1.2 MB/s (entrante)
Network TX: 3.4 MB/s (saliente)

Picos en trafico de red pueden indicar:

Metricas del servidor host

Las metricas del servidor dan una vision general de la salud del VPS completo.

Vista general

En Settings > Server > Monitoring ves un resumen:

Server: mi-vps.com
OS: Ubuntu 24.04
Uptime: 45 days
Load Average: 0.82, 0.94, 1.12

CPU:     [========--------] 47%  (4 cores)
Memory:  [===========-----] 68%  (5.4 GB / 8 GB)
Disk:    [======----------] 35%  (28 GB / 80 GB)
Swap:    [=---------------]  8%  (0.16 GB / 2 GB)

Interpretar Load Average

El Load Average muestra la carga del sistema en los ultimos 1, 5 y 15 minutos:

Load Average: 0.82, 0.94, 1.12
               1min  5min  15min

La regla general: si el Load Average supera el numero de nucleos de CPU, el servidor esta sobrecargado.

4 nucleos:
  Load 2.0 -> OK (50% de capacidad)
  Load 4.0 -> Limite (100% de capacidad)
  Load 6.0 -> Sobrecargado (150%, hay procesos en cola)

Uso de swap

Si el swap esta en uso significativo, significa que la RAM no es suficiente:

Swap: 0% -> Ideal, toda la carga cabe en RAM
Swap: 5-10% -> Aceptable, monitorear
Swap: >20% -> Problema, agregar RAM o reducir servicios

Interpretar graficos de uso

Los graficos de Dokploy muestran datos historicos con diferentes rangos temporales.

Patrones normales

Aplicacion web tipica:

CPU:  Picos durante horas pico, bajo en madrugada
      ___    ___
     /   \  /   \
____/     \/     \____

Memoria: Relativamente estable con crecimiento gradual
     ___________________
    /
___/

Base de datos:

CPU: Picos en queries pesados
     |  |    |
     |  |    |
_____|__|____|_________

Memoria: Alta y estable (cache de datos)
_________________________

Patrones problematicos

Memory leak (fuga de memoria):

Memoria crece sin parar hasta OOM:
                      / OOM Kill
                    /
                  /
                /
              /
            /
__________/

Si ves este patron, revisa tu aplicacion. Reiniciar el contenedor es un parche temporal.

CPU spike constante:

CPU al 100% permanente:
________________________

Puede indicar un loop infinito, un proceso zombie o que el servicio necesita mas recursos.

Alertas cuando los recursos estan altos

Dokploy no tiene un sistema de alertas nativo con umbrales configurables, pero puedes implementarlo de varias formas.

Notificaciones integradas

Configura notificaciones en Settings > Notifications para recibir alertas cuando un deploy falla o un contenedor se reinicia:

Canales disponibles:
- Slack
- Discord
- Telegram
- Email (SMTP)
- Webhook personalizado

Monitoreo externo con webhook

Crea un script que consulte las metricas y envie alertas:

#!/bin/bash
# check-resources.sh
THRESHOLD_CPU=80
THRESHOLD_MEM=85

CPU_USAGE=$(docker stats --no-stream --format "{{.CPUPerc}}" mi-app | tr -d '%')
MEM_USAGE=$(docker stats --no-stream --format "{{.MemPerc}}" mi-app | tr -d '%')

if (( $(echo "$CPU_USAGE > $THRESHOLD_CPU" | bc -l) )); then
  curl -X POST https://hooks.slack.com/services/XXX \
    -d "{\"text\": \"ALERTA: CPU de mi-app al ${CPU_USAGE}%\"}"
fi

if (( $(echo "$MEM_USAGE > $THRESHOLD_MEM" | bc -l) )); then
  curl -X POST https://hooks.slack.com/services/XXX \
    -d "{\"text\": \"ALERTA: Memoria de mi-app al ${MEM_USAGE}%\"}"
fi

Ejecutalo con cron cada 5 minutos:

crontab -e
# Agregar:
*/5 * * * * /root/check-resources.sh

Limitar recursos por contenedor

Desde la pestana Resources de cada aplicacion, configura limites:

CPU Limit: 2 (cores)
Memory Limit: 512m
Memory Reservation: 256m

Esto evita que un contenedor consuma todos los recursos del servidor y afecte a los demas.

Health check hooks (v0.27+)

A partir de la version 0.27, Dokploy soporta health checks configurables que verifican si tu aplicacion esta respondiendo correctamente.

Configurar health check

En la pestana Advanced de tu aplicacion, seccion Health Check:

Health Check Path: /health
Health Check Port: 3000
Health Check Interval: 30s
Health Check Timeout: 10s
Health Check Retries: 3

Endpoint de health check

Tu aplicacion debe exponer un endpoint que responda con estado 200:

// Express.js
app.get("/health", (req, res) => {
  res.status(200).json({
    status: "ok",
    uptime: process.uptime(),
    timestamp: Date.now(),
  });
});
// Go
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status":"ok"}`))
})
# FastAPI
@app.get("/health")
def health():
    return {"status": "ok"}

Health check avanzado

Un health check mas completo verifica dependencias:

app.get("/health", async (req, res) => {
  try {
    await db.query("SELECT 1");
    await redis.ping();
    res.status(200).json({
      status: "ok",
      db: "connected",
      cache: "connected",
    });
  } catch (error) {
    res.status(503).json({
      status: "degraded",
      error: error.message,
    });
  }
});

Comportamiento en fallo

Si el health check falla despues del numero de reintentos configurado:

  1. Dokploy marca el contenedor como unhealthy
  2. Si tienes configurado restart policy, Docker reinicia el contenedor
  3. Las notificaciones configuradas se disparan

Anterior: Capitulo 18: 2FA, SSO y Hardening | Siguiente: Capitulo 20: Logs y Terminal —>

← Volver al listado de tecnologías ← Índice de Dokploy