Esempi funzionanti per IncidentRelay v2.3.1, verificati il . I nomi, gli identificatori e i tempi riportati di seguito sono illustrativi; convalidarli in una distribuzione di prova prima di utilizzare le credenziali di produzione.
Esempio aziendale · Configurazione · Esempio pratico · Controlli di accettazione · Limiti e modalità di errore
Esempio aziendale: tre sistemi client, una chat di supporto rumorosa
Scenario illustrativo, non case study del cliente. Le metriche riportate di seguito sono suggerimenti per il tuo progetto pilota, non risparmi misurati o un'affermazione secondo cui l'IR include ogni dashboard di reporting.
Situazione e rischio. Un fornitore di servizi supporta tre clienti, ciascuno con avvisi sull'applicazione e sull'infrastruttura. Tutto finisce in una chat. Gli ingegneri inoltrano messaggi ad altri team mentre ripetuti avvisi seppelliscono il rapporto originale. Il rischio aziendale è rappresentato da un ritardo nella proprietà e da sforzi di supporto evitabili, anche quando il monitoraggio ha rilevato tempestivamente il fallimento.
Flusso di lavoro con IR. Associa ciascun servizio cliente al relativo team responsabile e utilizza il token di percorso previsto per ciascun mittente. Abbina le etichette dell'ambiente e del servizio, scegli il target di guardia e raggruppa le ripetizioni solo entro i limiti di proprietà previsti. Prova il servizio di fatturazione della produzione di un cliente utilizzando il corrispondente di seguito prima di estendere il modello.
Vantaggio operativo derivante dalla convalida. Sostituisci l'inoltro di messaggi di routine con un routing esplicito. Mantieni la prima risposta con il team che può agire, preservando al tempo stesso avvisi secondari separati quando più host segnalano lo stesso problema.
Che cosa misurare. Conta gli avvisi riassegnati dopo la prima decisione di routing, i gruppi senza proprietario e le notifiche per errore sottostante per ciascun client. Esamina anche gli eventi di test rifiutati o senza corrispondenza: meno pagine non è un successo se l'interruzione di un client diventa invisibile.
Confine. La corrispondenza delle etichette non è l'isolamento dei dati dei clienti. Esamina separatamente le autorizzazioni di accesso, le credenziali e i limiti di distribuzione. Etichette incoerenti o raggruppamenti eccessivamente ampi possono comunque inviare il lavoro al team sbagliato o combinare sintomi non correlati; convalidare tali casi prima dell'onboarding di un altro cliente.
Assunzione, proprietà e consegna separate
Un servizio di fatturazione di produzione e una copia di staging non dovrebbero svegliare le stesse persone per sbaglio. Per il primo progetto pilota, crea un percorso Webhook per il team di fatturazione di produzione, seleziona il servizio predefinito, la rotazione o la policy e collega i canali. Il suo token di assunzione seleziona il percorso; le etichette corrispondenti da sole non autenticano un mittente né selezionano un percorso arbitrario.
Un matcher di percorso stretto e una chiave di raggruppamento esplicita
Incollalo nell'editor del matcher del percorso. È un oggetto matcher, non il corpo del webhook in entrata. Tutte le condizioni utilizzano la semantica AND. La richiesta di etichette di produzione e di servizio mantiene la messa in scena e gli eventi senza etichetta fuori da questo percorso.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}Per questo esempio, imposta il campo group_by del percorso su:
["alertname", "severity", "labels.cluster"]Due host che segnalano lo stesso avviso nello stesso cluster possono quindi condividere un AlertGroup, mantenendo identità secondarie separate. Per un webhook generico, utilizza impronte digitali stabili come billing:node-1:health e billing:node-2:health. Includere le etichette previste per gli errori e i ripristini e non utilizzare mai un nuovo timestamp come identità di ogni nuovo tentativo.
La deduplicazione e il raggruppamento sono diversi: la stessa impronta digitale aggiorna un bambino; impronte digitali diverse con la stessa chiave di gruppo creano figli separati in un unico gruppo. Anche il percorso, il team, l'origine e il servizio sono raggruppati in ambiti. Aggiungi instance ai campi di raggruppamento solo se ciascun host deve essere un gruppo separato.
Quando un mittente serve davvero più team
Utilizza l'orchestrazione globale quando la proprietà deve essere scelta dal contenuto dell'evento. Nel Builder, inizia con le condizioni labels.environment equals production e labels.service equals billing-api, quindi seleziona team, percorso e oggetti di servizio validi dallo stesso gruppo. Non copiare ID oggetto numerici tra installazioni.
Convalida e simula sia le corrispondenze che le non corrispondenze, pubblica, quindi utilizza shadow con compatibilità hybrid. Rivedi le esecuzioni reali prima di passare a active. Shadow registra le decisioni senza modificare il comportamento produttivo; il simulatore non dimostra la consegna end-to-end.
Utilizzare una piccola matrice di test di routing
| Ingresso | Risultato previsto per questo esempio |
|---|---|
| Evento di fatturazione della produzione | Il matcher passa; il servizio, l'assegnatario e i canali selezionati corrispondono alla proprietà pianificata. |
| Etichetta di servizio temporanea o mancante | Il matcher non passa. Confermare il percorso alternativo previsto dal mittente; questo esempio non crea un percorso generale. |
| Impronta digitale duplicata | Lo stesso bambino viene aggiornato. Un'impronta digitale host diversa crea un secondo figlio nello stesso gruppo quando le etichette di raggruppamento corrispondono. |
| Recupero di uno solo dei due figli | Quel bambino risolve; il gruppo continua a sparare finché tutti i bambini che sparano non si riprendono. Un ripristino orfano non crea alcun nuovo gruppo. |
Evita regole che cancellano silenziosamente le prove
Un corrispondente vuoto corrisponde a tutto. Un'etichetta denominata severity non è automaticamente lo stesso campo della gravità evento normalizzata; utilizzare il percorso del campo documentato e ispezionare un evento reale normalizzato. Non richiedere status=firing su un percorso di aspirazione che deve accettare anche il recupero.
active + legacy non applica le decisioni di orchestrazione. In hybrid, le combinazioni di entità non valide possono ricadere nel percorso legacy; la modalità autorevole orchestration blocca invece l'elaborazione in caso di errori di valutazione o di convalida dell'entità. Scegli intenzionalmente il comportamento di fallimento.
Inizia senza regole generali drop o suppress. La soppressione e il raggruppamento possono ridurre le notifiche, ma non rendono utile un segnale di monitoraggio errato. Conserva una versione precedente testata ed esamina le mancate corrispondenze impreviste prima di espandere l'implementazione.