Exemples concrets pour IncidentRelay v2.3.1, vérifiés le . Les noms, identifiants et horaires ci-dessous sont donnés à titre indicatif ; validez-les dans un déploiement de test avant d’utiliser les informations d’identification de production.
Exemple commercial · Configuration · Exemple pratique · Contrôles d'acceptation · Limites et modes de défaillance
Exemple commercial : trois systèmes clients, un chat d'assistance bruyant
Scénario illustratif, pas une étude de cas client. Les mesures ci-dessous sont des suggestions pour votre projet pilote, et non des économies mesurées ou une affirmation selon laquelle IR inclut chaque tableau de bord de reporting.
Situation et risque. Un fournisseur de services prend en charge trois clients, chacun avec des alertes d'application et d'infrastructure. Tout atterrit dans une seule discussion. Les ingénieurs transmettent des messages à d'autres équipes tandis que les alertes répétées enterrent le rapport original. Le risque commercial est un retard dans l'appropriation et un effort de support évitable, même lorsque la surveillance a détecté la panne rapidement.
Workflow avec IR. Mappez chaque service client à son équipe responsable et utilisez le jeton de route prévu pour chaque expéditeur. Faites correspondre les étiquettes d'environnement et de service, choisissez la cible d'astreinte et regroupez les répétitions uniquement dans la limite de propriété prévue. Pilotez le service de facturation de production d'un client à l'aide du comparateur ci-dessous avant d'étendre le modèle.
Avantage opérationnel à valider. Remplacez le transfert de messages de routine par un routage explicite. Conservez la première réponse à l'équipe qui peut agir, tout en préservant des alertes enfants distinctes lorsque plusieurs hébergeurs signalent le même problème.
Ce qu'il faut mesurer. Compte des alertes réaffectées après la première décision de routage, des groupes sans propriétaire et des notifications par erreur sous-jacente pour chaque client. Examinez également les événements de test rejetés ou sans correspondance : moins de pages n'est pas un succès si la panne d'un client devient invisible.
Limite. La correspondance d'étiquettes ne constitue pas une isolation des données client. Examinez séparément les autorisations d’accès, les informations d’identification et les limites de déploiement. Des étiquettes incohérentes ou un regroupement trop large peuvent toujours envoyer le travail à la mauvaise équipe ou combiner des symptômes sans rapport ; validez ces cas avant d’intégrer un autre client.
Réception, propriété et livraison séparées
Un service de facturation de production et une copie intermédiaire ne devraient pas réveiller les mêmes personnes par accident. Pour le premier pilote, créez un itinéraire Webhook pour l'équipe de facturation de production, sélectionnez son service et sa rotation ou sa politique par défaut, et attachez les canaux. Son jeton d'admission sélectionne l'itinéraire ; Les étiquettes correspondantes à elles seules n'authentifient pas un expéditeur ni ne sélectionnent un itinéraire arbitraire.
Un comparateur d'itinéraire étroit et une clé de regroupement explicite
Collez-le dans l'éditeur de correspondance de l'itinéraire. Il s'agit d'un objet correspondant, et non du corps du webhook entrant. Toutes les conditions utilisent la sémantique AND. Exiger des étiquettes de production et de service empêche la mise en scène et les événements non étiquetés de cette voie.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}Pour cet exemple, définissez le champ group_by de l'itinéraire sur :
["alertname", "severity", "labels.cluster"]Deux hôtes signalant la même alerte dans le même cluster peuvent alors partager un AlertGroup, tout en conservant des identités enfants distinctes. Pour un webhook générique, utilisez des empreintes digitales stables telles que billing:node-1:health et billing:node-2:health. Incluez les étiquettes attendues en cas d'échec et de récupération, et n'utilisez jamais un nouvel horodatage comme identité à chaque nouvelle tentative.
La déduplication et le regroupement sont différents : la même empreinte digitale met à jour un enfant ; différentes empreintes digitales avec la même clé de groupe créent des enfants séparés dans un groupe. L'itinéraire, l'équipe, la source et le service regroupent également la portée. Ajoutez instance aux champs de regroupement uniquement si chaque hôte doit être un groupe distinct.
Quand un expéditeur sert réellement plusieurs équipes
Utilisez l'orchestration globale lorsque la propriété doit être choisie à partir du contenu de l'événement. Dans le générateur, commencez par les conditions labels.environment equals production et labels.service equals billing-api, puis sélectionnez les objets d'équipe, d'itinéraire et de service valides du même groupe. Ne copiez pas les ID d’objet numériques entre les installations.
Validez et simulez les correspondances et les non-correspondances, publiez, puis utilisez shadow avec la compatibilité hybrid. Examinez les exécutions réelles avant de passer à active. Des enregistrements fantômes des décisions sans modifier le comportement de production ; le Simulateur ne prouve pas une livraison de bout en bout.
Utiliser une petite matrice de test de routage
| Saisir | Résultat attendu pour cet exemple |
|---|---|
| Événement de facturation de production | Matcher passe ; le service, le cessionnaire et les canaux sélectionnés correspondent à la propriété prévue. |
| Étiquette de service intermédiaire ou manquante | Matcher ne passe pas. Confirmez le chemin alternatif prévu par l'expéditeur ; cet exemple ne crée pas de route fourre-tout. |
| Empreinte digitale en double | Le même enfant est mis à jour. Une empreinte digitale d'hôte différente crée un deuxième enfant dans le même groupe lorsque les étiquettes de regroupement correspondent. |
| Récupération pour un seul enfant sur deux | Cet enfant se résout ; le groupe continue de tirer jusqu'à ce que tous les enfants qui tirent se rétablissent. Une récupération orpheline ne crée aucun nouveau groupe. |
Évitez les règles qui effacent silencieusement les preuves
Un matcher vide correspond à tout. Une étiquette nommée severity n'est pas automatiquement le même champ que la gravité d'événement normalisée ; utilisez le chemin de champ documenté et inspectez un événement normalisé réel. N'exigez pas status=firing sur un chemin d'admission qui doit également accepter la récupération.
active + legacy n'applique pas les décisions d'orchestration. Dans hybrid, les combinaisons d'entités non valides peuvent revenir au chemin hérité ; Le mode faisant autorité orchestration bloque à la place le traitement en cas d'échecs d'évaluation ou de validation d'entité. Choisissez intentionnellement le comportement d’échec.
Commencez sans règles générales drop ou suppress. La suppression et le regroupement peuvent réduire les notifications, mais aucun d’eux ne rend utile un mauvais signal de surveillance. Conservez une version précédente testée et examinez les non-correspondances inattendues avant d’étendre le déploiement.