Monitoreo API Django con Vigilmon: guía 2026 en español
Si tenés una API Django REST en producción y tu estrategia de monitoreo es “esperar a que un usuario se queje”, estamos mal. Vigilmon lanzó una guía detallada para cerrar ese gap: health checks que no mienten, heartbeats para workers y alertas que llegan antes que la puteada del cliente. Lo interesante es que el servicio es gratuito para empezar, sin tarjeta de crédito, y se integra con DRF en menos de 15 minutos (sí, en serio).
En 30 segundos
- Vigilmon es un servicio gratuito de monitoreo que ofrece HTTP checks, heartbeats y alertas multicanal, lanzado con guía oficial para Django REST Framework.
- El health check endpoint valida base de datos, caché y Redis devolviendo un JSON con status healthy/unhealthy, sin tocar tus serializers existentes.
- Los heartbeats de Celery se implementan con una tarea Beat que hace un GET a la URL de heartbeat de Vigilmon cada 5 minutos para detectar workers muertos.
- Las alertas se configuran en Slack y email desde Settings > Integrations y se disparan cuando un HTTP check no devuelve 2xx o un heartbeat falta.
¿Qué es Vigilmon y cómo funciona para monitorear APIs Django?
Vigilmon es un servicio de monitoreo de sitios y APIs que verificá tus endpoints desde múltiples regiones, te avisa cuando algo falla y encima es gratuito para empezar. Lo presentaron con soporte para Node.js, pero ahora la cosa se puso seria: la guía oficial detalla cómo instrumentar una app Django REST Framework de punta a punta.
El servicio cubre tres patas que cualquier dev con experiencia sabe que son críticas: uptime de los endpoints HTTP, heartbeats para procesos en segundo plano como Celery, y enrutamiento de alertas a Slack o email. ¿Lo mejor? No tenés que poner tarjeta de crédito para probarlo. El plan gratuito incluye chequeos periódicos y umbrales de alerta configurables (como tiempo de respuesta o status no 2xx).
¿Cómo crear un health check endpoint en Django REST Framework?
Un 200 OK de Django no te dice nada sobre la salud real de tu app. La base de datos puede estar saturada, Redis desconectado o los workers de Celery muertos, y Django te va a seguir devolviendo respuestas como si nada. Por eso el health check posta tiene que validar dependencias.
La guía propone dos caminos, y los dos son válidos. El primero usa el paquete django-health-check, que ya trae checks para base de datos, caché y cola (Celery, si lo tenés configurado). Lo instalás con pip, agregás health_check y sus subpaquetes a INSTALLED_APPS, y exponés la URL. Cuando todo funciona, devuelve un 200 con un JSON; cuando algo falla, un 500. Complementá con nuestra comparativa de pipelines CI/CD.
El segundo camino es un endpoint manual con DRF puro, sin dependencias extra. La fuente muestra una vista que usa api_view y verifica la conexión a la base con connection.ensure_connection(), al caché con cache.set()/cache.get(), y a Redis con un ping. Si alguna pata falla, la respuesta incluye qué componente específico está caído, no solo un status genérico. Esto para debuggear en producción es un golazo.
¿Cómo configurar un monitor HTTP en Vigilmon para tu API?
Una vez que tenés el endpoint /api/health/ andando, el paso siguiente es que alguien lo golpee regularmente desde afuera. Vigilmon hace eso desde múltiples regiones, así que detecta si tu API es accesible desde Brasil pero no desde Argentina, ponele.
El proceso es straightforward: creás una cuenta, agregás un HTTP check apuntando a la URL de health, configurás el intervalo de chequeo, establecés los umbrales de alerta (por ejemplo, si el tiempo de respuesta excede un límite o no devuelve 2xx) y listo. El servicio empieza a monitorear en unos segundos.
Ojo con algo que la guía no dice explícitamente pero que es clave: no expongas este endpoint sin rate limiting. Si tu health check valida base de datos y caché, cada request consume recursos. Un atacante podría usarlo para saturarte. Un throttle de DRF con 10 requests por minuto por IP alcanza y sobra para el monitoreo. Relacionado: al elegir entre Jenkins y GitHub Actions.
¿Cómo monitorear workers de Celery con heartbeats en Vigilmon?
Acá es donde la mayoría de los setups de monitoreo hacen agua. Los workers de Celery pueden fallar silenciosamente: el proceso sigue corriendo pero no procesa tareas, o directamente se murió y nadie se enteró. Tu API sigue devolviendo 200, las tareas se acumulan en Redis, y vos te enterás cuando el cliente pregunta por qué su reporte no se generó hace tres horas.
La solución que documenta Vigilmon es elegante: crear una tarea periódica con Celery Beat que le pegue a una URL de heartbeat específica. En el código de la fuente, la tarea hace un GET a la URL de heartbeat de Vigilmon (algo como https://vigilmon.com/heartbeat/<tu-id>) cada 5 minutos. Si Vigilmon no recibe ese GET dentro del intervalo configurado, dispara la alerta. Cero sobrecarga, cero infraestructura nueva.
El patrón de management command para heartbeats que también mencionan es útil si no usás Celery pero tenés cron jobs o procesos similares: un comando de Django que envía el heartbeat y que podés programar con el scheduler que prefieras.
¿Cómo configurar alertas por email y Slack en Vigilmon?
Las alertas que no llegan no existen. La integración con Slack y email se configura desde Settings > Integrations en el dashboard de Vigilmon. Para Slack, pegás la URL del webhook entrante (que habrás creado en tu workspace) y seleccionás qué tipo de eventos querés recibir: caída de endpoint, heartbeat perdido, restauración del servicio. Sobre eso hablamos en la guía de hreflang para SEO multilingüe.
Cuando un monitor falla, el mensaje de alerta incluye el nombre del monitor, el tipo de falla (timeout, status 5xx, heartbeat no recibido), timestamp y un enlace directo al incidente. Esto parece una boludez, pero en un contexto de incident response donde estás mirando cinco pestañas a las 3 AM, tener el dato exacto y sin tener que navegar paneles te ahorra minutos importantes.
Un detalle que me gusta del enfoque de la guía: las alertas se configuran por canal y por monitor, no son “todo o nada”. Podés tener alertas de Slack para los endpoints críticos y alertas por email para los heartbeats de workers no críticos. Esto evita la fatiga de alertas, que es el problema #1 por el que la gente termina ignorando las notificaciones.
¿Qué más monitorear en una API Django REST en producción?
El health endpoint y los heartbeats de Celery son el piso, no el techo. Según la fuente complementaria de Webalert sobre monitoreo en producción, hay al menos tres checks adicionales que deberías considerar.
Primero, monitoreo de certificados SSL. Vigilmon te avisa 30, 14 y 7 días antes del vencimiento. Si alguna vez se te venció un certificado en producción sin darte cuenta (a mí sí, y fue un papelón), sabés que esto vale oro.
Segundo, verificación de contenido en los endpoints, no solo status code. Un endpoint puede devolver 200 con un body que dice “error” porque algo se rompió aguas abajo. Configurar un check que busque una cadena específica en la respuesta (por ejemplo, "status": "ok") te protege de ese tipo de falsos negativos. Para más detalles técnicos, mirá ejecutar agentes locales sin API con OpenClaw.
Tercero, endpoints críticos con alta carga. No es lo mismo monitorear /api/health/ (que apenas toca la base) que /api/login/ o una ruta que dispara consultas pesadas. Si tu health check está verde pero el login tarda 8 segundos, hay un problema que no estás viendo. La guía recomienda crear monitores HTTP separados para las rutas principales de negocio, con umbrales de tiempo de respuesta distintos según la complejidad esperada de cada endpoint.
| Enfoque | Dependencia extra | Qué verifica | Configuración |
|---|---|---|---|
| django-health-check | Sí (paquete pip) | DB, caché, Celery, storage | Añadir a INSTALLED_APPS + URL |
| Endpoint manual DRF | No | Lo que programes (DB, Redis, etc.) | Vista con api_view + urlpattern |
| HTTP Monitor Vigilmon | No (servicio externo) | Status 2xx, tiempo respuesta | Dashboard: apuntar a URL de health |
| Celery Beat heartbeat | Celery + scheduler | Workers procesando tareas | Tarea GET cada 5 min a URL heartbeat |
Errores comunes al monitorear APIs Django REST
- Asumir que 200 OK significa “todo bien”. Es el error más frecuente. Un health check que solo responde con
{"status": "ok"}sin validar dependencias es papel mojado. Si la base de datos está caída y tu health check no la toca, ese 200 te está mintiendo. - No configurar alertas por tiempo de respuesta. Un endpoint que responde en 8 segundos no está caído, pero para el usuario es lo mismo. Un umbral de tiempo de respuesta configurable es un buen punto de partida; ajustalo según la complejidad de tu endpoint.
- Olvidarse del health check en el deploy. Subís una migración que rompe un serializer, el health check no lo detecta porque no pasa por esa vista, y te enterás por el cliente. La guía de Vigilmon no lo menciona, pero un smoke test post-deploy que pegue a los endpoints principales te salva de este escenario.
- Ignorar los heartbeats en workers asíncronos. Si tu app usa Celery para tareas críticas (envíos de email, generación de PDFs, procesamiento de pagos) y no monitoreás que el worker esté vivo, la mitad de tu funcionalidad puede estar muerta sin que lo sepas.
Preguntas Frecuentes
¿Cómo crear un health check endpoint en Django REST?
Tenés dos opciones: usar el paquete django-health-check (que agrega checks para DB, caché y Celery con solo configurar INSTALLED_APPS) o crear una vista manual con api_view que verifique connection.ensure_connection(), cache.set()/cache.get() y un ping a Redis, devolviendo un JSON con el estado de cada componente y un 200 o 500 según corresponda.
¿Qué es Vigilmon y cómo se usa para monitorear APIs?
Vigilmon es un servicio de monitoreo que verifica endpoints HTTP desde múltiples regiones, recibe heartbeats de procesos en segundo plano y dispara alertas por Slack y email cuando algo falla. Se configura apuntando un HTTP check a tu endpoint de health, definiendo el intervalo de chequeo y los umbrales de alerta desde un dashboard web.
¿Cómo monitorear workers de Celery en producción?
La forma más directa es crear una tarea periódica con Celery Beat que haga un GET a la URL de heartbeat de Vigilmon cada 5 minutos. Si el worker está caído y el heartbeat no llega, Vigilmon dispara una alerta. La alternativa sin Celery es usar un management command de Django que envíe el heartbeat, programado con cron o el scheduler del sistema.
¿Cómo configurar alertas por Slack en Django?
La configuración no se hace en Django sino en el dashboard de Vigilmon: vas a Settings > Integrations, pegás la URL del webhook de Slack y seleccionás qué eventos disparan alerta (caída, timeout, heartbeat perdido, restauración). El mensaje incluye nombre del monitor, tipo de falla, timestamp y enlace al incidente.
¿Qué monitorear en una API Django REST en producción?
Como mínimo: el health endpoint que valide DB, caché y Redis; heartbeats de workers de Celery; monitoreo de SSL para que no se te venza el certificado; verificación de contenido en endpoints críticos (no solo status code); y monitores separados para rutas de negocio clave como login o endpoints con consultas pesadas, cada uno con su propio umbral de tiempo de respuesta.
Conclusión
La guía de Vigilmon no inventa la rueda, pero junta en un solo lugar las prácticas que cualquier dev con experiencia en producción ya debería estar aplicando. El mérito es que baja la barrera de entrada: en 15 minutos tenés health checks que no mienten, heartbeats que vigilan tus workers y alertas que te llegan antes del desastre.
Si ya estás corriendo Django REST Framework en producción y tu plan de monitoreo es rezar, este es el momento de cambiar eso. Si estás por deployar algo nuevo y pensás que monitoreo “se hace después”, la experiencia dice que “después” suele ser “cuando se rompió y el cliente está llamando”. La API va a estar expuesta a Internet de todos modos; más vale que sepas cuando deja de responder.
Si estás buscando dónde hostear esa API Django en infraestructura pensada para el tráfico de Latinoamérica, en donweb.com tienen VPS y cloud con data centers en la región que te dan latencia baja para tus usuarios locales y el control que necesitás para configurar monitoreo como el que describimos acá.
Fuentes
- Monitoring Your Django REST API with Vigilmon: Health Checks, Workers & Alerts — Guía oficial de Vigilmon.
- Django Monitoring: Production Celery Uptime Checks — Artículo complementario sobre monitoreo de workers y endpoints en producción.
- Free Uptime Monitoring for Your Node.js App with Vigilmon — Lanzamiento original del servicio con detalles del plan gratuito y chequeos desde múltiples regiones.
