Alertas de espacio de trabajo
Notificaciones opcionales para autorización de cuenta, disponibilidad del grupo y fallas de generación.
Los administradores del espacio de trabajo pueden configurar alertas desde Configuración del sistema → Alertas del espacio de trabajo. Las notificaciones están desactivadas hasta que un administrador guarda un destino y las habilita. Cada espacio de trabajo tiene su propio destino e historial de incidentes.
Utilice un punto final público HTTPS que acepte JSON solicitudes POST. Se rechazan las direcciones privadas/locales, los redireccionamientos, los nombres de usuario/contraseñas incrustados y los fragmentos de URL. SubLane cifra el destino, muestra solo su host y nunca lo revela automáticamente. Deje la URL en blanco al editarla para conservarla. Eliminar el destino deshabilita las notificaciones y elimina su historial de notificaciones pendientes.
Condiciones
| Evento | Condición |
|---|---|
account_reauthorization | Una suscripción habilitada requiere nueva autorización, o un canal API habilitado requiere cambiar la clave. |
pool_unavailable | Un grupo habilitado no tiene recursos habilitados y verificados, fuera del enfriamiento o recuperación registrados, que permita su política de enrutamiento y respaldo API. Cuentan tanto suscripciones como canales API; los grupos vacíos también activan la alerta. |
request_failures | En los últimos cinco minutos, al menos cinco generaciones terminaron y al menos la mitad terminó en error o respuesta incompleta. Se excluyen las solicitudes canceladas y rechazadas localmente. |
Las comprobaciones utilizan el estado persistente local aproximadamente una vez por minuto; no envían solicitudes de modelos ni credenciales de suscripción de prueba. La alerta del grupo original verifica el estado de la cuenta. Opcionalmente, habilite las alertas del modelo y configure un umbral de cuota utilizada de 1 a 99 (el espacio en blanco lo deshabilita); ambos están desactivados de forma predeterminada. Sólo se evalúan los modelos permitidos, observados previamente y las nuevas cuotas. Las observaciones desconocidas o obsoletas no pueden probar el fracaso o la recuperación; la saturación de concurrencia por sí sola no desencadena una alerta de modelo. Las instantáneas inactivas pueden caducar y las comprobaciones no actualizan los metadatos. Un tiempo de reutilización borrado después de una solicitud exitosa o una acción de recuperación del administrador puede resolver un incidente del grupo.
Entrega y recuperación
Un incidente sin cambios envía una notificación. Una condición que desaparece después de que se aceptó su evento de disparo envía un resolved evento. El estado del incidente sobrevive al reinicio. Los errores de entrega vuelven a intentarlo después de un minuto y luego retroceden hasta 30 minutos; cada pase intenta como máximo diez entregas en la instancia. Las colas grandes pendientes pueden requerir pases adicionales.
El receptor debe devolver un estado 2xx en cinco segundos. Deduplicar usando id, que también se envía en el Idempotency-Key encabezado: una pérdida de acuse de recibo o un reinicio entre la aceptación del receptor y la persistencia local pueden provocar una entrega repetida. Guardar la configuración no envía ninguna prueba. Después de guardar un destino, explícitamente Enviar notificación de prueba, incluso con las notificaciones desactivadas. Es kind y status son test. Se permite una prueba por minuto entre reinicios; los fallos no se reintentan y el estado del incidente no cambia. La página de configuración muestra el error de entrega y la hora de notificación aceptada más reciente; Guardar una URL por sí solo no prueba que funcione.
Evento de ejemplo que utiliza ID sintéticos:
{
"id": "11111111111111111111111111111111",
"workspace_id": 1,
"kind": "pool_unavailable",
"subject": "2",
"status": "firing",
"observed_at": 1900000000
}Uso de eventos modelo model_unavailable, con el ID del grupo y el ID del modelo nativo unidos por dos puntos como asunto. Uso de eventos de cuota quota_low, con un ID de cuenta como asunto.
Solo se envían identificadores (incluido el ID del modelo nativo para eventos del modelo), tipo de condición, estado y tiempo de observación. Se excluyen los nombres de cuentas, las identidades de los miembros, las claves, las URL de webhooks, las indicaciones, las respuestas y los errores sin formato. Este es un formato de webhook genérico; Las aplicaciones de chat pueden requerir un adaptador para su formato de mensaje.
Las copias de seguridad incluyen destinos cifrados e historial de incidentes con la clave de bóveda correspondiente. Restaurar una instantánea anterior puede reproducir incidentes posteriores, por lo que los receptores deben conservar su historial de deduplicación.