La monitorización de aplicaciones debe ayudar al equipo a reconocer trabajo interrumpido y decidir cómo actuar. Antes de elegir herramientas, identifico un flujo crítico, sus dependencias y quién se responsabiliza de recuperarlo. Los logs centralizados, las métricas y las comprobaciones externas son un punto de partida; su cobertura depende de lo que instrumentes y pruebes.
Empieza por un flujo de negocio y sus posibles fallos
En un sistema de pedidos hipotético, una respuesta HTTP confirma la recepción, pero no demuestra que el almacén haya recibido el pedido. Distingue trabajo aceptado, pendiente, completado y fallido. Acuerda cuánto puede permanecer pendiente y quién investiga cuando supera ese límite. El retraso admisible sale de la operación, no de copiar un umbral de alerta.
Combina comprobaciones externas con señales internas. Una home disponible no acredita que se pueda comprar; un worker activo no acredita que procese correctamente. El capítulo de monitorización de Google SRE explica esta distinción y el papel de latencia, tráfico, errores y saturación.
Elige señales que permitan tomar una decisión
| Flujo | Señal útil | Decisión que preparar |
|---|---|---|
| Aplicación pública | Resultado de la transacción crítica, errores y latencia | Investigar una versión o dependencia e identificar usuarios afectados |
| Trabajo en segundo plano | Edad del pendiente más antiguo, ritmo de finalización y fallos definitivos | Revisar el atasco antes de escalar o reintentar |
| Servidor y almacenamiento | Capacidad disponible, crecimiento y reinicios | Recuperar margen sin borrar evidencia necesaria |
| Recogida de telemetría | Ausencia de muestras esperadas o fallo de entrega | Distinguir pérdida de visibilidad de un servicio sano |
Define la ventana de medición, la actividad esperada y la condición de recuperación de cada señal. La ausencia de tráfico puede ser normal por la noche; la falta de telemetría es otro estado. Conserva los identificadores de petición y job en logs o trazas, en lugar de crear una serie de métricas distinta para cada ejecución.
Los detalles de implementación pertenecen a cada subsistema: colas Laravel en producción, supervisión de procesos y configuración de Nginx para Laravel. Aquí delimito cómo reunir esas piezas en un alcance de monitorización operativa.
Define la alerta y la respuesta a la vez
Separa una interrupción urgente de un ticket que puede esperar al horario de trabajo. Para cada alerta, registra flujo afectado, responsable, horario de cobertura, enlace a evidencia, primera comprobación y escalado si nadie confirma la recepción. Agrupa notificaciones repetidas de una misma incidencia y define cuándo darla por recuperada.
Un runbook es un procedimiento breve de respuesta. En el ejemplo de pedidos, puede pedir que se revisen la edad de la cola y la última entrega correcta, se compruebe el sistema de destino y se decida si pausar la entrada o reanudar el proceso. Reprocesar pedidos exige protección frente a duplicados: monitorizar no convierte un reintento en seguro.
La guía de alertas de Prometheus también recomienda centrarse en síntomas y comprobar el propio recorrido de monitorización. Configurar un canal no demuestra que una persona pueda recibir una alerta real y actuar.
Conserva evidencia útil sin recogerlo todo
Usa eventos estructurados con fecha, entorno, servicio, versión, identificador de correlación y resultado. Conserva evidencia de diagnóstico seleccionada con acceso controlado. Excluye credenciales y contenido innecesario de los payloads; define retención y borrado por categoría. Revisa quién puede leer, exportar y cambiar la configuración junto con los controles de acceso a infraestructura.
El caso de monitorización Adslyfy aporta ejemplos documentados de estados de ejecución, intentos y capturas. Sus imágenes muestran visibilidad operativa, no una reducción medida de incidencias ni una garantía general de nivel de servicio.
Cómo aceptar una implantación de monitorización
Acordaría estas comprobaciones antes de implementar. Son criterios de aceptación propuestos, no pruebas ejecutadas en un sistema de cliente. Usa un entorno controlado o un ejercicio expresamente acordado que no pueda afectar a transacciones reales.
- Flujo interrumpido: simular un job atascado y comprobar que la señal acordada identifica trabajo pendiente aunque la web siga disponible.
- Aviso útil: confirmar recepción por el responsable, acceso a la evidencia y recorrido de escalado dentro del horario acordado.
- Ruido y recuperación: repetir el fallo, comprobar su agrupación y verificar el cierre al recuperarse sin ocultar una incidencia distinta.
- Pérdida de visibilidad: interrumpir la telemetría o su entrega y verificar que la falta de datos aparece como tal, sin mostrarse como servicio sano.
- Evidencia y acceso: seguir un job entre componentes, confirmar permisos restringidos y comprobar que logs y exportaciones no contienen secretos.
- Traspaso operativo: pedir al responsable que siga el runbook y anotar permisos ausentes, pasos ambiguos o recuperaciones que no puede ejecutar.
Registra escenario, resultado esperado, resultado observado, responsable y huecos pendientes. Una dependencia no probada queda fuera de la cobertura demostrada. Superar estas comprobaciones no garantiza detectar todos los fallos futuros.
Separa el coste de implantación del coste de operación
El alcance inicial incluye mapa del flujo, instrumentación, dashboards, rutas de aviso, procedimientos y ejercicio de traspaso. El coste recurrente incluye ingestión de telemetría, almacenamiento, retención, consultas, suscripciones, mantenimiento de reglas y tiempo de respuesta. Más entornos, servicios y volumen añaden trabajo; una instalación existente puede necesitar solo mejores reglas y responsables.
Pide que las propuestas identifiquen flujos incluidos, dependencias excluidas, titularidad de cuentas y responsabilidades de mantenimiento. La lista para comparar presupuestos de software ayuda a separar entrega y soporte recurrente. Instalar monitorización y responder a incidencias son alcances distintos: horarios y compromisos de respuesta deben acordarse expresamente.
Delimita la primera mejora
Si las incidencias siguen llegando por mensajes de clientes, puedo revisar el flujo, las señales y los huecos de respuesta desde mis servicios de CTO e infraestructura. El primer entregable puede ser un alcance priorizado de monitorización con responsables y pruebas de aceptación, seguido de implementación donde haga falta.
Cuéntame tu problema de monitorización con los servicios implicados, una incidencia anonimizada, las herramientas actuales y quién atiende los avisos. Con ese contexto puedo delimitar por dónde empezar y qué requeriría el soporte posterior.