Avvisi smart

Le soglie statiche non cambiano dopo la creazione dello Smart Alert. La soglia stessa può essere un valore costante semplice o può tenere conto delle variazioni stagionali che si sono verificate nel passato al momento della creazione della configurazione di Smart Alert. È possibile immaginare la tabella successiva come una tabella di ricerca per ogni momento del giorno o della settimana che viene precalcolato una volta in base ai dati cronologici.

La soglia potrebbe non essere più rilevante dopo che la metrica sottostante è stata modificata in modo significativo. In risposta, la soglia può essere regolata manualmente o ricalcolata in qualsiasi momento. Per ulteriori informazioni, consultare Soglia di avviso.

Le soglie statiche funzionano meglio per blueprint come Chiamate lente o Chiamate errate nelle situazioni seguenti:

• Indipendentemente dalla stagionalità della metrica sottostante. Non è desiderabile che la metrica sia maggiore o minore di un valore costante.
• La metrica sottostante è stagionale e quindi esistono soglie diverse a seconda del momento temporale del giorno o della settimana. Ma queste soglie di per sé non cambiano nel tempo, e le modifiche graduali a queste soglie su lunghi periodi di tempo non sono desiderabili.

Le soglie adattive si evolvono e si regolano continuamente sulla base dei nuovi dati rilevati d Instana Ciò significa che la soglia tiene continuamente conto delle variazioni stagionali della metrica sottostante senza alcun intervento umano. Per ulteriori informazioni, consultare la documentazione relativa alla soglia adattiva.

Le seguenti opzioni consentono di regolare il livello di dettaglio della valutazione degli avvisi e delle notifiche, passando da un livello di dettaglio generico (a livello di applicazione) a uno più dettagliato (a livello di endpoint).

Poiché una prospettiva dell'applicazione generalmente include più di un servizio, è necessario determinare quali chiamate sono nell'ambito di questo Smart Alert.

Scegliere chiamate in entrata per limitare le chiamate solo a questa prospettiva dell'applicazione (dal frontend o da qualsiasi servizio upstream). Le chiamate tra i servizi all'interno di questa prospettiva dell'applicazione sono escluse.

Scegliere tutte le chiamate per includere non solo le chiamate a questa prospettiva dell'applicazione come destinazione (dal frontend o da qualsiasi servizio upstream), ma anche le chiamate tra i servizi all'interno della prospettiva dell'applicazione.

Facoltativamente, è possibile includere chiamate interne o sintetiche. Per impostazione predefinita, entrambe le chiamate sono escluse.

Una chiamata interna è un particolare tipo di chiamata che rappresenta il lavoro eseguito all'interno di un servizio. Può essere creato da fasi intermedie che vengono inviate tramite la traccia personalizzata. Per ulteriori informazioni relative alle chiamate interne, consultare Concetti di traccia.

Le chiamate sintetiche sono quelle con un endpoint sintetico come destinazione, come le chiamate agli endpoint di controllo dell'integrità.

Facoltativamente, utilizzare l'elenco a discesa rispetto al nome della prospettiva dell'applicazione per selezionare o escludere manualmente i singoli servizi a cui questo Smart Alert deve limitare il proprio ambito. All'interno di un servizio selezionato o escluso, l'ambito selezionato può essere ulteriormente definito per ciascuno dei suoi endpoint.

L'abilitazione di Ordina per selezione utente mantiene i servizi e gli endpoint selezionati all'inizio.

Se si utilizza il campo di ricerca, la struttura ad albero di selezione viene ridotta solo a servizi ed endpoint il cui nome corrisponde alla parola chiave di ricerca.

Facoltativamente, utilizzare Aggiungi filtro per requisiti di filtro più avanzati e granulari che utilizzano la logica booleana arbitraria.

Questo passaggio è rilevante quando si seleziona il modello "Slow Calls", in cui è possibile scegliere tra le seguenti opzioni: media aritmetica, minimo e massimo, oltre ai percentili 25°, 50°, 75°, 90°, 95°, 98° e 99°.

In base al blueprint scelto, è possibile scegliere tra <, <=, >, >=.

Qui è possibile scegliere tra i seguenti tipi di soglia statica:

• Soglia statica: assume un valore costante come soglia.
• Stagionalità giornaliera statica : utilizza una soglia che acquisisce i modelli ripetitivi giornalieri della metrica in cui ogni giorno si comporta più o meno allo stesso modo, ma è diverso durante il giorno. Ad esempio, un'applicazione che riceve più chiamate durante il giorno rispetto alla sera.
• Stagionalità settimanale statica : utilizza una soglia che cattura i modelli ripetitivi settimanali della metrica in cui ogni giorno di una settimana si comporta più o meno allo stesso modo, ma è diverso durante la settimana. Ad esempio, un'applicazione che riceve più chiamate nei giorni lavorativi rispetto al fine settimana.

Per la stagionalità giornaliera statica, sono necessari almeno 5 giorni di dati metrici continui, ma sono consigliati 7 giorni di dati. Per la stagionalità settimanale statica, sono richieste almeno 2 settimane di dati metrici cronologici continui. Non è possibile creare lo Smart Alert quando questi requisiti non sono soddisfatti.

Per Soglia adattiva, sono richiesti almeno 14 giorni di dati metrici continui. Se questo requisito non viene soddisfatto, è ancora possibile creare lo Smart Alert. Il rilevamento dei problemi e gli avvisi inizieranno a funzionare non appena il requisito dei dati sarà soddisfatto per inizializzare il modello utilizzato.

Se si seleziona «Soglia statica », « Instana » imposta automaticamente un livello di gravità dell'avviso e fornisce un valore di soglia suggerito. È possibile utilizzare il valore suggerito oppure definire manualmente un valore personalizzato. Per configurare un livello di gravità aggiuntivo, ad esempio "critico", selezionare la casella di controllo "Critico" e specificare un valore di soglia distinto che attivi l'avviso come critico.

Quando si seleziona un livello di sensibilità, Instana assegna automaticamente un livello di gravità dell'avviso. È possibile regolare il livello di sensibilità utilizzando un cursore. Per definire un livello di sensibilità distinto per la gravità "Critica", selezionare la casella di controllo "Critica" e configurare la sensibilità come richiesto.

Aumentando la sensibilità si restringono i limiti superiore e inferiore per il rilevamento delle anomalie, con un conseguente aumento delle notifiche di allerta. Riducendo la sensibilità, questi limiti si ampliano, riducendo il numero di avvisi. Questa impostazione definisce l'intervallo dei valori attesi per la metrica. A seconda dell'operatore di soglia utilizzato, un valore che supera uno dei due limiti viene considerato una violazione e potrebbe attivare un avviso.

Scegliere questa opzione se si desidera ritardare l'invio delle notifiche di avviso fino a quando non viene violato il numero fornito di finestre di valutazione consecutive.

Seguire i passi:

1. Scegliere la finestra di valutazione o la granularità.
2. Scegliere il numero di finestre di valutazione che devono essere violate consecutivamente prima che venga attivata la notifica di avviso.

Scegliere questa opzione se si desidera ritardare l'invio delle notifiche di avviso fino a quando non vengono violate le finestre di valutazione N out of M .

Nell'immagine seguente è riportato un esempio di violazioni rispetto alla configurazione della soglia temporale. Con una granularità di valutazione delle metriche di 5 minuti, viene attivato un avviso quando si verificano almeno 2 violazioni delle metriche negli ultimi 15 minuti.

Seguire i passi:

1. Scegliere la finestra di valutazione o la granularità. I singoli valori metrici vengono aggregati in finestre di questa dimensione.
2. Scegli il numero di finestre di valutazione (M) da monitorare.
3. Imposta il numero minimo di finestre di valutazione monitorate che devono essere violate per inviare la notifica di allerta.

Nell'esempio seguente vengono illustrati due cicli di valutazione distinti con questa configurazione.

I dati vengono aggregati in intervalli di valutazione di 5 minuti. Se vengono superati i limiti in 2 delle ultime 3 finestre di valutazione, viene inviato un avviso.

Scegliere questa opzione se si desidera ritardare l'invio delle notifiche di avviso fino a quando non viene influenzato un determinato numero di tracce .

Seguire i passi:

1. Scegliere la finestra di valutazione o la granularità.
2. Immettere il numero di tracce che violano la soglia nella finestra di valutazione.

Instana suggerisce un titolo predefinito in base al tipo di modello utilizzato e alle relative opzioni di configurazione. Tuttavia, è possibile sostituire il titolo predefinito con un testo statico personalizzato oppure utilizzare un titolo dinamico inserendo dei segnaposto.

Ad esempio, quando si scelgono avvisi individuali per ciascun servizio per questa prospettiva dell'applicazione, ${application.name} e ${service.name} sono disponibili, ma non ${endpoint.name}. Questa limitazione è dovuta al fatto che gli avvisi sono limitati ai singoli servizi, consentendo di fare riferimento a una singola prospettiva applicativa e al nome del servizio, ma non a nomi di endpoint specifici, che potrebbero variare da un servizio all'altro.

Inoltre, è possibile inserire ${severity} come segnaposto nel titolo dell'avviso per indicare il livello di gravità.

L'abilitazione di questo interruttore crea inoltre un Incidente a cui si fa riferimento come evento di attivazione e ad altri eventi correlati a questo incidente si fa riferimento come eventi correlati.

Facoltativamente, aggiungere una descrizione all'avviso. Una buona descrizione include un breve riepilogo di questo avviso e le operazioni da eseguire quando viene ricevuto l'avviso. È inoltre possibile creare una descrizione dinamica inserendo dei segnaposto, selezionabili dal menu a tendina "Inserisci segnaposto".

Tuttavia, per aiutarti nella migrazione degli eventi personalizzati esistenti agli avvisi intelligenti, l'interfaccia utente di Instana mette a disposizione alcuni strumenti di migrazione di base. La pagina dei dettagli di un evento personalizzato relativo a un'entità di tipo Applicazione, Servizio o Endpoint mostra due pulsanti relativi alla migrazione degli avvisi intelligenti:

• Contrassegna come migrato: contrassegna un evento personalizzato obsoleto come migrato e lo disabilita. Ciò è utile nel caso in cui questo evento personalizzato sia stato migrato manualmente in uno Smart Alert. Dopo averlo contrassegnato come migrato, sarà comunque possibile visualizzarlo nell'elenco e riesaminarne la configurazione in qualsiasi momento in futuro per riferimento. Non è questo il caso se si elimina questa configurazione. Inoltre, questa funzione consente di tenere traccia dell'avanzamento della migrazione e di garantire che nessun evento personalizzato venga migrato più di una volta.
• Migra a Smart Alert: apre la finestra di dialogo Smart Alert con i valori di rispettivi campi, inclusi nome, descrizione, gravità, incidente, tipo di entità, metrica, granularità di valutazione, aggregazione, operatore e soglia. Sebbene i campi degli «Eventi personalizzati» non possano sempre essere associati a quelli degli «Avvisi intelligenti», « Instana » farà del suo meglio per trasferire tali campi dagli «Eventi personalizzati» agli «Avvisi intelligenti». Inoltre, l'ambito del DFQ o delle applicazioni selezionate viene acquisito selezionando le rispettive entità esplicitamente o utilizzando i filtri di tag del programma di creazione query. Si noti che alcune query di focus dinamico possono essere associate solo parzialmente o non associate affatto alla selezione di entità o ai filtri di tag del programma di creazione query. In questi casi, verrà visualizzato il rispettivo messaggio di avvertenza. Se DFQ non può essere mappato completamente dallo strumento di migrazione, è possibile fare riferimento a Associazione del tipo di entità e selezione dell'ambito per selezionare manualmente l'ambito di Smart Alert. Il salvataggio di tale Smart Alert disabiliterà automaticamente l'evento personalizzato precedente e lo contrassegnerà come migrato.

È possibile migrare manualmente gli eventi personalizzati verso gli avvisi automatici.

1. Abilitare l'indicatore della funzione nel file settings.hcl :

   ...
   feature "smartAlertsLogsBlueprintEnabled" {
       enabled=true
   }
   ...
    

2. Applicare le modifiche tramite il comando instana update .

1. Abilita il flag di funzionalità nel core.yaml file come segue:

   apiVersion: instana.io/v1beta2
   kind: Core
   metadata:
     name: instana-core
     namespace: core
   spec:
     ...
     featureFlags:
       - name:  feature.smart.alerts.logs.blueprint.enabled
         enabled: true
     ...
    

2. Applica le modifiche tramite il kubectl apply -f core.yaml comando.