Rilevamento delle anomalie nei registri

È possibile creare un rilevatore di anomalie di registro per ogni gruppo di log. Il rilevatore di anomalie analizza gli eventi di registro inseriti nel gruppo di log e trova le anomalie nei dati di registro. Il rilevamento delle anomalie utilizza l'apprendimento automatico e il riconoscimento dei pattern per stabilire le linee di base dei contenuti tipici dei log.

Dopo aver creato un rilevatore di anomalie per un gruppo di log, questo si allena utilizzando gli eventi di registro delle ultime due settimane nel gruppo di log per l'addestramento. Il periodo di formazione può durare fino a 15 minuti. Una volta completato l'addestramento, inizia ad analizzare i log in entrata per identificare le anomalie e le anomalie vengono visualizzate nella console CloudWatch Logs per essere esaminate dall'utente.

CloudWatch Logs Pattern Recognition estrae i pattern di log identificando i contenuti statici e dinamici nei log. I pattern sono utili per analizzare set di log di grandi dimensioni perché un gran numero di eventi di log può spesso essere compresso in pochi pattern.

Ad esempio, vedete il seguente esempio di tre eventi di registro.

2023-01-01 19:00:01 [INFO] Calling DynamoDB to store for resource id 12342342k124-12345
2023-01-01 19:00:02 [INFO] Calling DynamoDB to store for resource id 324892398123-12345
2023-01-01 19:00:03 [INFO] Calling DynamoDB to store for resource id 3ff231242342-12345

Nell'esempio precedente, tutti e tre gli eventi di registro seguono uno schema:

<*> <*> [INFO] Calling DynamoDB to store for resource id <*>

I campi all'interno di un pattern sono chiamati token. I campi che variano all'interno di uno schema, come l'ID della richiesta o il timestamp, vengono definiti token dinamici. I token dinamici sono rappresentati da <*> quando CloudWatch Logs visualizza il pattern. Ogni valore diverso trovato per un token dinamico viene chiamato valore token.

Esempi comuni di token dinamici includono codici di errore, timestamp e ID di richiesta.

Il rilevamento delle anomalie nei log utilizza questi modelli per trovare anomalie. Dopo il periodo di addestramento del modello di rilevatore di anomalie, i log vengono valutati in base alle tendenze note. Il rilevatore di anomalie segnala le fluttuazioni significative come anomalie.

La creazione di rilevatori di anomalie di registro non comporta costi.

Gravità e priorità delle anomalie e dei modelli

A ogni anomalia rilevata da un rilevatore di anomalie di registro viene assegnata una priorità. A ogni pattern trovato viene assegnata una gravità.

• La priorità viene calcolata automaticamente e si basa sia sul livello di gravità del modello che sulla quantità di deviazione dai valori previsti. Ad esempio, se il valore di un determinato token aumenta improvvisamente del 500%, tale anomalia potrebbe essere designata come HIGH prioritaria anche se la sua gravità lo è. NONE

• La severità si basa solo sulle parole chiave presenti nei modelli come FATALERROR, e. WARN Se non viene trovata nessuna di queste parole chiave, la gravità di un pattern viene contrassegnata comeNONE.

Tempo di visibilità dell'anomalia

Quando si crea un rilevatore di anomalie, si specifica il periodo massimo di visibilità delle anomalie. Questo è il numero di giorni in cui l'anomalia viene visualizzata nella console e viene restituita dall'operazione API. ListAnomalies Trascorso questo periodo di tempo relativo a un'anomalia, se continua a verificarsi, viene automaticamente accettata come comportamento normale e il modello di rilevatore di anomalie smette di contrassegnarla come anomalia.

Se non modifichi il tempo di visibilità quando crei un rilevatore di anomalie, per impostazione predefinita vengono utilizzati 21 giorni.

Soppressione di un'anomalia

Dopo aver rilevato un'anomalia, è possibile scegliere di sopprimerla temporaneamente o permanentemente. La soppressione di un'anomalia fa sì che il rilevatore di anomalie smetta di contrassegnare tale evento come anomalia per il periodo di tempo specificato. Quando si sopprime un'anomalia, è possibile scegliere di sopprimere solo quell'anomalia specifica o di sopprimere tutte le anomalie relative al modello in cui è stata rilevata l'anomalia.

È ancora possibile visualizzare le anomalie soppresse nella console. Puoi anche scegliere di smettere di sopprimerle.

Domande frequenti

AWS Utilizza i miei dati per addestrare algoritmi di apprendimento automatico da AWS utilizzare o per altri clienti?

No. Il modello di rilevamento delle anomalie creato dal corso di formazione si basa sugli eventi di registro in un gruppo di log e viene utilizzato solo all'interno di quel gruppo di log e di quell' AWS account.

Quali tipi di eventi di registro funzionano bene con il rilevamento delle anomalie?

Il rilevamento delle anomalie nei log è ideale per: registri delle applicazioni e altri tipi di log in cui la maggior parte delle voci di registro rientra negli schemi tipici. I gruppi di log con eventi che contengono parole chiave a livello di registro o di gravità come INFO, ERROR e DEBUG sono particolarmente adatti per il rilevamento delle anomalie nei log.

Il rilevamento delle anomalie nei log non è adatto per: Registra eventi con strutture JSON estremamente lunghe, come Logs. CloudTrail L'analisi dei pattern analizza solo fino ai primi 1500 caratteri di una riga di registro, quindi tutti i caratteri oltre tale limite vengono ignorati.

Anche i log di controllo o di accesso, come i log di flusso VPC, avranno meno successo con il rilevamento delle anomalie. Il rilevamento delle anomalie serve a individuare i problemi delle applicazioni, quindi potrebbe non essere adatto per le anomalie di rete o di accesso.

Per aiutarvi a determinare se un rilevatore di anomalie è adatto a un determinato gruppo di log, utilizzate l'analisi del pattern CloudWatch Logs per trovare il numero di pattern negli eventi di registro del gruppo. Se il numero di pattern non è superiore a circa 300, il rilevamento delle anomalie potrebbe funzionare bene. Per ulteriori informazioni sull'analisi dei pattern, vedereAnalisi del modello.

Cosa viene contrassegnato come anomalia?

Le seguenti occorrenze possono far sì che un evento di registro venga contrassegnato come anomalia:

• Un evento di registro con uno schema mai visto prima nel gruppo di log.

• Una variazione significativa rispetto a un modello noto.

• Un nuovo valore per un token dinamico che ha un insieme discreto di valori usuali.

• Una grande variazione nel numero di occorrenze di un valore per un token dinamico.

Sebbene tutti gli elementi precedenti possano essere contrassegnati come anomalie, non tutti significano che l'applicazione stia funzionando male. Ad esempio, higher-than-usual alcuni valori di 200 successo potrebbero essere contrassegnati come anomalia. In casi come questo, potresti prendere in considerazione la possibilità di eliminare queste anomalie che non indicano problemi.

Cosa succede con i dati sensibili che vengono mascherati?

Qualsiasi parte degli eventi di registro mascherata come dati sensibili non viene analizzata per individuare eventuali anomalie. Per ulteriori informazioni sul mascheramento dei dati sensibili, consulta Aiutare a proteggere i dati di registro sensibili con il mascheramento.