Notifications et pages de statut

Les intégrations d’hébergeurs exposent aussi les changements d’alimentation des VM, les échecs d’opérations, la synchronisation et les seuils de solde de compte pris en charge. Les alertes de facturation nécessitent un accès à la facturation et une devise ; une VM en cours d’exécution ne prouve pas que son démon Opfield est en ligne.

Créez des destinations, des modèles et des règles d’alerte pour la santé, la capacité, les certificats, les déploiements, les bases de données, les builds et l’état de la plateforme. Testez chaque destination avant de vous y fier.

Les notifications et les pages de statut s’adressent à des publics différents. Les notifications demandent à un responsable interne d’agir ; une page de statut indique aux clients à quoi ils peuvent s’attendre. Le responsable du service définit l’impact et la priorité, le responsable d’astreinte reçoit et résout les alertes, et le responsable de la communication publie des mises à jour adaptées aux clients. N’envoyez pas la même charge utile technique brute aux deux publics.

Les critères de réussite sont explicites : une condition significative ouvre une seule alerte exploitable, la reprise la ferme ou la résout, l’envoi atteint un canal doté d’un responsable, et un incident visible par les clients contient un impact exact sans exposer de détails d’infrastructure. Une destination configurée qui n’a jamais réussi de test de bout en bout n’est pas prête pour la production.

Les alertes à état doivent s’ouvrir lorsqu’une condition commence et se rétablir lorsqu’elle disparaît. Configurez les seuils et les fenêtres pour éviter les oscillations. Incluez la ressource, l’impact, l’horodatage et l’action de l’opérateur — pas de secrets ni d’erreurs complètes des démons.

Les pages de statut exposent aux clients un état de service sélectionné. Le mode maintenance doit apparaître comme une maintenance planifiée plutôt que comme une panne inexpliquée. Gardez la topologie interne, les noms de nœuds privés et les diagnostics sensibles pour la sécurité hors des pages publiques.

Décider de ce qui mérite d’être communiqué

Classez les événements selon l’impact client et l’action requise. Les tendances de capacité peuvent commencer comme des avertissements internes ; la perte d’un parcours client public peut nécessiter à la fois une alerte urgente et un incident sur la page de statut. Évitez de créer un composant public pour chaque démon ou nœud. Les composants doivent correspondre à des produits ou des fonctionnalités que les clients reconnaissent et avoir un responsable capable de publier des mises à jour.

Convenez de la gravité, du délai d’acquittement, du rythme des mises à jour et des critères de clôture avant le premier incident. Une maintenance planifiée doit indiquer la fonctionnalité concernée, la fenêtre prévue et l’action attendue des clients. Les incidents de sécurité peuvent exiger un processus de communication restreint plutôt qu’une divulgation immédiate des détails de diagnostic.

Configurer les notifications

1. Créez la destination et stockez les identifiants via le chemin de paramètres chiffré.
2. Envoyez une notification de test et vérifiez l’identité de l’expéditeur, la signature, le rendu et le délai d’envoi.
3. Créez une règle d’alerte pour une condition significative sur une ressource.
4. Sélectionnez un seuil, une fenêtre d’évaluation, une fenêtre de rétablissement et une gravité.
5. Dirigez-la vers un canal d’astreinte ou d’exploitation doté d’un responsable.
6. Déclenchez la condition dans un environnement sûr et vérifiez à la fois les messages d’ouverture et de rétablissement.

Évitez les alertes sur lesquelles les opérateurs ne peuvent pas agir. Chaque notification urgente doit identifier la ressource concernée, l’impact client, l’heure de début, l’état actuel et la première action de diagnostic sûre.

La lecture des règles d’alerte nécessite notifications:alerts:view, et leur création, modification ou suppression notifications:alerts:manage. Les webhooks et leur historique d’envoi nécessitent notifications:webhooks:view, et la création, le test, la modification ou la suppression de webhooks nécessitent notifications:webhooks:manage. notifications:webhooks:manage révèle aussi les URL, les en-têtes et les charges utiles d’envoi des webhooks.

Les règles peuvent cibler les nœuds, les conteneurs, les builds Git, les projets Compose, les Routes, Pages, les relais, les certificats, les bases de données, le stockage managé, la journalisation structurée, les synchronisations d’intégrations, les VM et comptes d’hébergeurs, ainsi qu’Opfield lui-même. Une règle de conteneur sur Log Size (MB) repère les conteneurs dont les journaux croissent sans limite.

Opfield déclenche aussi des alertes d’expiration intégrées, en nommant la ressource propriétaire : certificats SSL et de PKI interne aux seuils d’avertissement et de criticité PKI, CA bien avant leur expiration, certificats de nœuds dont le renouvellement échoue, et jetons d’intégration Git à 30 et 7 jours. Chaque seuil n’alerte qu’une fois, et un certificat renouvelé alerte à nouveau au cours de sa nouvelle durée de vie. Pour le stockage managé et les bases de données managées, créez une règle d’alerte pour l’événement de certificat Managed Service Certificate Renewal Failed, qui s’ouvre tant que le renouvellement automatique continue d’échouer et se rétablit après un renouvellement réussi.

Les modèles de notification utilisent un contexte imbriqué canonique. Gardez les modèles courts et testez le rendu exact sur la destination ; les anciens noms de variables plats ne sont pas des alias et peuvent s’afficher vides. Traitez les modifications de modèles comme des changements d’exploitation, car un message cassé peut masquer la ressource, la gravité ou l’état de rétablissement même lorsque le transport réussit.

Réduire le bruit

• Utilisez des fenêtres de durée soutenue pour les seuils de CPU, de mémoire, de disque, de latence et de taux d’erreur.
• Déclenchez une alerte sur une transition d’état plutôt que de répéter le même état inchangé.
• Séparez les avertissements de capacité de l’impact client critique.
• Suspendez ou annotez les alertes pendant une maintenance explicite plutôt que de supprimer la règle.
• Examinez régulièrement les règles obsolètes, désactivées en permanence ou sans responsable.

Exploiter les pages de statut

Créez des composants qui correspondent aux services visibles par les clients, et non à la topologie interne des démons. Associez les incidents aux composants concernés, publiez des mises à jour concises et distinguez les états investigating, identified, monitoring et resolved selon le processus de communication.

Le mode maintenance d’une Route gérée peut apparaître comme une maintenance planifiée. Vérifiez que la vue publique du statut n’expose ni noms de nœuds, ni adresses privées, ni traces d’appels, ni identifiants de ressources, ni détails de sécurité.

Pendant l’indisponibilité d’Opfield

Opfield sert la page de statut publique via un nœud Ingress, et ce nœud conserve la dernière copie valide de la page, de ses ressources et des données de statut que la page interroge. Pendant qu’Opfield redémarre, est mis à jour ou est injoignable, les visiteurs reçoivent cette copie, la dernière récupérée lorsqu’Opfield répondait ; elle montre donc l’état juste avant l’interruption. Une page jamais chargée auparavant affiche une courte page « Back in a moment » qui se recharge d’elle-même. Les navigateurs ne stockent jamais la page ; les données en direct reviennent donc dès qu’Opfield répond ; tant qu’il répond, les données que voit un visiteur ont au plus 5 secondes. Par défaut, la page de statut utilise un upstream que le nœud Ingress peut joindre. Dans les paramètres de la page de statut, vous pouvez aussi choisir un groupe d’ingress sous Ingress groups (served by every member), afin que chaque membre serve la page.

Les nœuds Ingress adoptent ce comportement lorsqu’ils se reconnectent à une installation Opfield mise à jour. La première mise à jour d’Opfield vers une version dotée de ce comportement interrompt encore la page, car le cache est vide lorsque l’ancienne version d’Opfield s’arrête ; chaque mise à jour ultérieure est couverte.

Ne clôturez un incident qu’après avoir vérifié le parcours client, et pas simplement lorsqu’une alerte interne repasse au vert. Publiez un résumé final adapté au public et conservez les constats techniques détaillés dans l’enregistrement interne de l’incident.

Détails pour l’opérateur : échec d’envoi et reprise

Si l’envoi échoue, examinez la santé de la destination, l’authentification, la validation TLS, le code de réponse, l’historique des nouvelles tentatives et l’âge de la file. Ne faites pas tourner un identifiant sans mettre à jour chaque destination dépendante. Après la réparation, envoyez un nouveau test et confirmez le comportement des envois en file d’attente avant de déclarer le canal opérationnel.

Maintenez un chemin de contact de secours en cas d’échec de la destination principale. Pendant les tests, vérifiez les messages d’ouverture et de rétablissement, la déduplication, le rendu, les liens et les horodatages. Pendant une vraie panne, ne recréez pas à répétition les destinations ou les règles : conservez l’historique des envois, réparez l’échec précis et vérifiez si les messages en file doivent encore être envoyés ou sont devenus obsolètes.