Notificaciones y páginas de estado

Las integraciones de hosting también exponen los cambios de encendido de las VM, los fallos de operaciones, la sincronización y los umbrales de saldo de la cuenta compatibles. Las alertas de facturación requieren acceso a la facturación y una moneda; que una VM esté en ejecución no demuestra que su daemon de Opfield esté en línea.

Crea destinos, plantillas y reglas de alerta para el estado, la capacidad, los certificados, los despliegues, las bases de datos, los builds y el estado de la plataforma. Prueba cada destino antes de depender de él.

Las notificaciones y las páginas de estado sirven a públicos distintos. Las notificaciones piden a un responsable interno que actúe; una página de estado dice a los clientes qué pueden esperar. El responsable del servicio define el impacto y la prioridad, el responsable de guardia recibe y resuelve las alertas, y el responsable de comunicación publica actualizaciones aptas para los clientes. No envíes el mismo payload técnico en bruto a ambos públicos.

Los criterios de éxito son explícitos: una condición significativa abre una alerta que requiere acción, la recuperación la cierra o la resuelve, la entrega llega a un canal con responsable y un incidente de cara a los clientes contiene un impacto exacto sin exponer detalles de la infraestructura. Un destino configurado que nunca ha superado una prueba de principio a fin no está listo para producción.

Las alertas con estado deben abrirse cuando empieza una condición y recuperarse cuando desaparece. Configura los umbrales y las ventanas para evitar oscilaciones. Incluye el recurso, el impacto, la marca de tiempo y la acción del operador, no secretos ni errores completos del daemon.

Las páginas de estado exponen a los clientes el estado de los servicios seleccionados. El modo de mantenimiento debe aparecer como mantenimiento planificado y no como una caída sin explicación. Mantén fuera de las páginas públicas la topología interna, los nombres privados de los nodos y los diagnósticos sensibles para la seguridad.

Decide qué merece comunicarse

Clasifica los eventos por su impacto en los clientes y la acción necesaria. Las tendencias de capacidad pueden empezar como advertencias internas; la pérdida de un recorrido público de los clientes puede requerir tanto una alerta urgente como un incidente en la página de estado. Evita crear un componente público para cada daemon o nodo. Los componentes deben corresponderse con productos o capacidades que los clientes reconozcan y tener un responsable que pueda publicar actualizaciones.

Acuerda la severidad, el tiempo de reconocimiento, la cadencia de actualizaciones y los criterios de cierre antes del primer incidente. El mantenimiento planificado debe indicar la capacidad afectada, la ventana prevista y la acción del cliente. Los incidentes de seguridad pueden requerir un proceso de comunicación restringido en lugar de divulgar de inmediato los detalles del diagnóstico.

Configura las notificaciones

1. Crea el destino y guarda las credenciales a través de la vía de ajustes cifrada.
2. Envía una notificación de prueba y verifica la identidad del remitente, la firma, el formato y la latencia de entrega.
3. Crea una regla de alerta para una condición significativa de un recurso.
4. Selecciona un umbral, una ventana de evaluación, una ventana de recuperación y una severidad.
5. Dirígela a un canal de guardia u operativo con responsable.
6. Provoca la condición en un entorno seguro y verifica tanto el mensaje de apertura como el de recuperación.

Evita las alertas sobre las que los operadores no pueden actuar. Cada notificación urgente debe identificar el recurso afectado, el impacto en los clientes, la hora de inicio, el estado actual y la primera acción de diagnóstico segura.

Las reglas de alerta requieren notifications:alerts:view para leerlas y notifications:alerts:manage para crearlas, cambiarlas o eliminarlas. Los webhooks y su historial de entregas requieren notifications:webhooks:view, y crear, probar, cambiar o eliminar webhooks requiere notifications:webhooks:manage. notifications:webhooks:manage también revela las URL, las cabeceras y los payloads de entrega de los webhooks.

Las reglas pueden tener como objetivo nodos, contenedores, builds de Git, Compose Projects, Routes, Pages, Relays, certificados, bases de datos, almacenamiento gestionado, logging estructurado, sincronizaciones de integraciones, VM y cuentas de hosting y el propio Opfield. Una regla de contenedor sobre Log Size (MB) encuentra los contenedores cuyos logs crecen sin límite.

Opfield también genera alertas de caducidad integradas, que indican el recurso propietario: certificados SSL y de la PKI interna en los umbrales de advertencia y críticos de la PKI, CA con mucha antelación a su caducidad, certificados de nodos cuya renovación está fallando y tokens de integraciones de Git a 30 y 7 días. Cada umbral avisa una vez, y un certificado renovado vuelve a avisar en su nuevo periodo de vida. Para el almacenamiento y las bases de datos gestionados, crea una regla de alerta para el evento de certificado Managed Service Certificate Renewal Failed, que se abre mientras la renovación automática sigue fallando y se recupera tras una renovación correcta.

Las plantillas de notificación usan un contexto anidado canónico. Mantén las plantillas pequeñas y prueba el formato exacto en el destino; los nombres de variables planos antiguos no son alias y pueden quedar vacíos. Trata los cambios de plantillas como cambios operativos, porque un mensaje roto puede ocultar el recurso, la severidad o el estado de recuperación aunque el transporte funcione.

Reduce el ruido

• Usa ventanas sostenidas para los umbrales de CPU, memoria, disco, latencia y tasa de errores.
• Avisa ante un cambio de estado en lugar de repetir el mismo estado sin cambios.
• Separa las advertencias de capacidad del impacto crítico en los clientes.
• Silencia o anota las alertas durante un mantenimiento explícito en lugar de eliminar la regla.
• Revisa con regularidad las reglas obsoletas, silenciadas permanentemente o sin responsable.

Opera las páginas de estado

Crea componentes que se correspondan con los servicios visibles para los clientes, no con la topología interna de los daemons. Asocia los incidentes a los componentes afectados, publica actualizaciones concisas y distingue los estados de investigación, identificado, en observación y resuelto según el proceso de comunicación.

El modo de mantenimiento de una Route gestionada puede aparecer como mantenimiento planificado. Confirma que la vista pública de estado no expone nombres de nodos, direcciones privadas, trazas de pila, ID de recursos ni detalles de seguridad.

Mientras Opfield no está disponible

Opfield sirve la página de estado pública a través de un nodo Ingress, y ese nodo conserva la última copia correcta de la página, sus recursos y los datos de estado que consulta la página. Mientras Opfield se reinicia, se actualiza o no es accesible, los visitantes reciben esa copia, la última obtenida mientras Opfield respondía, de modo que muestra el estado de justo antes de la interrupción. Una página que nunca se había cargado antes muestra una breve página “Back in a moment” que se recarga sola. Los navegadores nunca guardan la página, así que los datos en vivo vuelven en cuanto Opfield responde; mientras responde, los datos que ve un visitante tienen como mucho 5 segundos de antigüedad. Por defecto, la página de estado usa un upstream al que puede llegar el nodo Ingress. En los ajustes de la página de estado también puedes elegir un grupo de ingress en Ingress groups (served by every member), para que todos los miembros sirvan la página.

Los nodos Ingress adoptan este comportamiento cuando se vuelven a conectar a una instalación de Opfield actualizada. La primera actualización de Opfield a una versión con este comportamiento todavía interrumpe la página, porque la caché está vacía cuando se detiene la versión antigua de Opfield; todas las actualizaciones posteriores quedan cubiertas.

Cierra un incidente solo cuando se haya verificado el recorrido del cliente, no simplemente cuando una alerta interna se ponga en verde. Publica un resumen final adecuado para el público y conserva los hallazgos técnicos detallados en el registro interno del incidente.

Detalles para operadores: fallos de entrega y recuperación

Si la entrega falla, inspecciona el estado del destino, la autenticación, la validación TLS, el código de respuesta, el historial de reintentos y la antigüedad de la cola. No rotes una credencial sin actualizar todos los destinos que dependen de ella. Tras la reparación, envía una prueba nueva y confirma el comportamiento de la entrega en cola antes de declarar operativo el canal.

Mantén una vía de contacto alternativa para cuando falle el destino principal. Durante las pruebas, verifica los mensajes de apertura y de recuperación, la eliminación de duplicados, el formato, los enlaces y las marcas de tiempo. Durante una caída real, no vuelvas a crear repetidamente destinos ni reglas: conserva el historial de entregas, repara el fallo concreto y confirma si los mensajes en cola deben entregarse todavía o se han quedado obsoletos.