Alertes d'espace de travail

Notifications facultatives pour l'autorisation de compte, la disponibilité de la réserve et les défaillances de génération.

Les administrateurs d'espace de travail peuvent configurer les alertes à partir Paramètres du système → Alertes d'espace de travail. Les notifications sont désactivées jusqu'à ce qu'un administrateur enregistre une destination et les autorise. Chaque espace de travail a sa propre destination et l'historique des incidents.

Utiliser un public HTTPS fin de série acceptée JSON Les adresses privées/locales, les redirections, les noms d'utilisateur/mots de passe intégrés et les fragments d'URL sont rejetés. SubLane crypte la destination, n'affiche que son hôte, et ne la révèle jamais automatiquement. Laissez l'URL vide lors de l'édition pour la garder. Enlever la destination désactive les notifications et supprime son historique de notification en attente.

Conditions générales

Événement	État
`account_reauthorization`	Un abonnement activé nécessite une nouvelle autorisation, ou un canal API activé nécessite le remplacement de sa clé.
`pool_unavailable`	Un groupe activé ne dispose d’aucune ressource activée et vérifiée, hors récupération ou délai enregistré, autorisée par son routage et son repli API. Abonnements et canaux API sont pris en compte ; un groupe vide déclenche aussi l’alerte.
`request_failures`	Au cours des cinq dernières minutes, au moins cinq générations se sont terminées et au moins la moitié se sont terminées par une erreur ou une réponse incomplète. Les demandes annulées et rejetées localement sont exclues.

Les vérifications utilisent l'état local persistant environ une fois par minute; elles n'envoient pas de demandes de modèle ou d'identifiants d'abonnement. L'alerte initiale du pool vérifie la santé du compte. En option, activez les alertes du modèle et configurez un seuil de quota usagé de 1 à 99 (le blanc le désactive); les deux sont désactivés par défaut. Seuls les modèles précédemment observés et les nouveaux quotas sont évalués. Les observations inconnues ou inexistantes ne peuvent pas prouver une défaillance ou une récupération; la saturation de la concordance ne déclenche pas à elle seule une alerte du modèle.

Livraison et recouvrement

Un incident inchangé envoie une notification. Une condition qui s'éclaircit après que son tir a été accepté envoie une resolved event. L'état de l'incident survit au redémarrage. Les échecs de livraison réessayent après une minute, puis reculent jusqu'à 30 minutes; chaque passe tente au plus dix livraisons dans l'instance.

Le récepteur doit retourner un état 2xx dans un délai de cinq secondes. id, qui est également envoyé dans le Idempotency-Key header: un accusé de réception perdu ou un redémarrage entre l'acceptation du récepteur et la persistance locale peut provoquer une livraison répétée. Envoyer une notification d'essai, même avec des notifications éteintes. kind et status sont test. Un test par minute est autorisé à travers les redémarrages; les pannes ne sont pas réévaluées et l'état de l'incident est inchangé. La page de paramètres affiche la défaillance de livraison et le plus récent temps de notification accepté; enregistrer une URL seule ne prouve pas qu'elle fonctionne.

Exemple d'événement utilisant des identifiants synthétiques:

{
  "id": "11111111111111111111111111111111",
  "workspace_id": 1,
  "kind": "pool_unavailable",
  "subject": "2",
  "status": "firing",
  "observed_at": 1900000000
}

Utilisation d'événements modèles model_unavailable, avec l'ID de le pool et l'ID modèle natif rejoint par un colon comme leur sujet. quota_low, avec un identifiant de compte comme sujet.

Seuls les identifiants (y compris l'ID du modèle natif pour les événements du modèle), le type de condition, l'état et le temps d'observation sont envoyés. Les noms de compte, les identités des membres, les clés, les URLs webhook, les invites, les réponses et les erreurs brutes sont exclus.

Les sauvegardes comprennent les destinations cryptées et l'historique des incidents avec la clé de voûte correspondante. La restauration d'un ancien instantané peut rejouer les incidents suivants, de sorte que les récepteurs devraient garder leur historique de déduplication.