Monitoreo¶

Disponible solo para: Platform Admin

Hardhat Flow expone comprobaciones de salud, métricas Prometheus y registros estructurados para monitoreo de disponibilidad, paneles y resolución de problemas operativos.

Salud del sistema¶

Endpoint de comprobación de salud¶

GET /healthz

Devuelve HTTP 200 cuando la aplicación puede responder.
No requiere autenticación — pensado para balanceador de carga y monitores de disponibilidad.
Configure la ruta de comprobación de salud de DigitalOcean App Platform en /healthz.

Comprobación profunda — agregue ?deep=1 para diagnósticos a nivel de subsistema:

GET /healthz?deep=1

Devuelve 200 si todos los checks pasan, 503 si alguno falla:

{"status": "healthy|degraded", "checks": {"db": "ok", "redis": "ok", "celery": "ok"}}

No use ?deep=1 para el balanceador de carga. Solo úselo para diagnósticos manuales o monitores externos de baja frecuencia.

Métricas Prometheus¶

GET /metrics

Expone métricas en formato Prometheus vía django-prometheus.
Incluye: conteos de solicitudes HTTP, latencia, distribución de códigos de estado, conteos de consultas a base de datos.
Proteja este endpoint en producción — restrinja por firewall o red interna solamente. No lo exponga públicamente.
Apunte un scraper Prometheus o sistema compatible (Grafana, Datadog, etc.) a esta URL.

Registro estructurado¶

Hardhat Flow usa structlog para todo el registro de la aplicación.

Environment	Format	Destination
Desarrollo	Salida legible en consola	stdout
Producción	JSON (un objeto por línea)	stdout / flujo de registros de DigitalOcean App Platform

Los registros JSON en producción están pensados para ingestión por agregadores como Datadog, Logtail o CloudWatch.

Verbosidad la controla la variable de entorno DJANGO_LOG_LEVEL. Valores válidos: DEBUG, INFO, WARNING, ERROR. Predeterminado: INFO.

Nunca registre secretos, tokens ni payloads JWT completos. Structlog está configurado para redactar campos sensibles, pero las declaraciones de registro personalizadas deben seguir esta regla.

Seguimiento de errores¶

Los errores de aplicación (excepciones no capturadas, respuestas 500) se capturan en Sentry y se etiquetan por inquilino, permitiendo filtrar por slug de empresa en el panel de Sentry.

Panel de Sentry → (inicie sesión con su cuenta Sentry — actualice con la URL del proyecto una vez configurado)

Variable de entorno requerida en producción:

SENTRY_DSN=https://<key>@<org>.ingest.sentry.io/<project-id>

Campos clave en eventos de Sentry y registros estructurados:

level — error o critical
event — descripción del error
exc_info — seguimiento de pila
request_id — correlaciona con la solicitud HTTP de origen
tenant_slug / etiqueta Sentry tenant — inquilino donde ocurrió el error
user_id — usuario autenticado, si lo hay

Referencia de alertas¶

Todas las alertas de producción se envían a [email protected].

Alerta	Fuente	Umbral	Primera respuesta
Pico de errores Sentry	Sentry	>10 nuevos problemas / hora	Revise Sentry; filtre por etiqueta `tenant` para identificar el alcance.
Reinicio de componente	DO App Platform	Cualquier reinicio inesperado	`doctl apps logs <app-id> web --follow`; busque OOM o crash de inicio.
CPU alto en MySQL	DO Managed DB Insights	>80% por 5 min	Identifique queries lentas con `SHOW PROCESSLIST`.
Conexiones altas en MySQL	DO Managed DB Insights	>80% del máximo	Revise fugas de conexión; confirme `CONN_MAX_AGE=0` en DBs de inquilinos.
Cola Celery profunda	Prometheus / Redis	>500 tareas pendientes	Revise logs del worker; escale `instance_count` en `app.yaml` si están saludables.
Tasa de 5xx	django-prometheus	>1% de solicitudes en 5 min	Revise Sentry; correlacione con despliegues recientes.
Spaces 4xx/5xx	DO Spaces metrics	Pico sobre la línea base	Verifique vars `AWS_*` y política del bucket.
`/healthz` caído	DO Uptime	1 fallo	Revise el panel DO App Platform para eventos de reinicio.

Alertas de actividad sospechosa¶

Las siguientes condiciones deben monitorearse y alertarse:

Condition	Signal
Alta tasa de 4xx desde un solo inquilino	Puede indicar scraping o relleno de credenciales
Intentos de inicio de sesión fallidos repetidos	Auth0 maneja el bloqueo, pero se recomiendan alertas del agregador de registros
Entradas inesperadas de ActivityLog `admin_action`	Puede indicar actividad no autorizada de Platform Admin
Pico de 5xx en Prometheus `django_http_responses_total`	Errores de aplicación que requieren investigación

Configure reglas de alerta en su plataforma de monitoreo contra datos del endpoint /metrics y el flujo de registros.

Resolver un problema de inquilino¶

Al investigar un problema reportado por un inquilino, siga esta secuencia:

Revise registros de App Platform — filtre por tenant_slug para aislar el flujo del inquilino.
Revise el ActivityLog** — consulte entity_type, entity_id y performed_by para ver qué cambió y cuándo.
Revise registros del worker Celery — muchos fallos asíncronos (SMS, conversión HEIC, miniaturas) solo aparecen en registros del worker.
Inspeccione métricas Prometheus — busque tasas de error o latencia elevadas en solicitudes del inquilino afectado.
Consulte la base del inquilino directamente si hace falta — pero documente todas las consultas manuales en una entrada ActivityLog admin_action.

El ActivityLog es su herramienta forense principal. Todo cambio significativo queda ahí con marca de tiempo y usuario que lo realizó.