Allarmi raccomandati

Le sezioni seguenti elencano i parametri per i quali suggeriamo di attivare gli allarmi basati sulle best practice. Per ogni parametro, vengono visualizzati anche le dimensioni, lo scopo dell'allarme, la soglia consigliata, la giustificazione della soglia, la durata del periodo e il numero di punti dati.

Alcuni parametri potrebbero apparire due volte nell'elenco. Ciò accade quando allarmi diversi sono raccomandati per combinazioni differenti di dimensioni di tale parametro.

Il valore Punti dati su cui attivare allarmi rappresenta il numero di punti dati che devono essere violati per mettere l'allarme nello stato ALARM. Il valore Periodi di valutazione rappresenta il numero di periodi che vengono presi in considerazione quando viene valutato l'allarme. Se questi due numeri coincidono, l'allarme passa allo stato ALARM solo quando tale numero di periodi consecutivi presenta valori che superano la soglia. Se Punti dati su cui attivare allarmi è inferiore a Periodi di valutazione, l'allarme è del tipo "M su N" e passa allo stato ALARM se almeno un numero di punti dati pari a Punti dati su cui attivare allarmi viene violato all'interno di qualsiasi set di punti dati pari a Periodi di valutazione. Per ulteriori informazioni, consulta Valutazione di un allarme.

Amazon API Gateway

4XXError

Dimensioni:ApiName, Stage

Descrizione dell'allarme: questo allarme rileva un tasso elevato di errori lato client. Ciò può indicare un problema nei parametri di autorizzazione o di richiesta del client. Potrebbe anche significare che una risorsa è stata rimossa o che un client ne sta richiedendo una che non esiste. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4XX. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per risorsa e metodo e restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui questa guida per risolvere il problema.

Scopo: questo allarme può rilevare tassi elevati di errori lato client per le richieste di Gateway API.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4XX. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

5XXError

Dimensioni:ApiName, Stage

Descrizione dell'allarme: questo allarme aiuta a rilevare un tasso elevato di errori lato client. Ciò può indicare un errore nel back-end dell'API, nella rete o nell'integrazione tra il gateway API e l'API di back-end. Questa documentazione può aiutarti a risolvere la causa degli errori 5xx.

Scopo: questo allarme può rilevare tassi elevati di errori lato server per le richieste di Gateway API.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 5XX. Tuttavia, è possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

Conteggio

Dimensioni:ApiName, Stage

Descrizione dell'allarme: questo allarme aiuta a rilevare un basso volume di traffico per la fase della REST API. Questo potrebbe segnalare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Scopo: questo allarme può rilevare un volume di traffico inaspettatamente basso per la fase di REST API. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per metodo e risorsa, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più preciso delle cadute di volume di traffico per ogni risorsa e metodo. Questo allarme non è raccomandato per le API che non prevedono un traffico costante e regolare.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

Conteggio

Dimensioni: faseApiName, risorsa, metodo

Descrizione dell'allarme: questo allarme aiuta a rilevare un basso volume di traffico per la risorsa e il metodo nella fase di REST API. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Scopo: questo allarme può rilevare un volume di traffico inaspettatamente basso per la risorsa e il metodo nella fase di REST API. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Questo allarme non è raccomandato per le API che non prevedono un traffico costante e regolare.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

Conteggio

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme aiuta a rilevare un basso volume di traffico per la fase dell'API HTTP. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Scopo: questo allarme può rilevare un volume di traffico inaspettatamente basso per la fase dell'API HTTP. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per percorso, ti consigliamo di creare allarmi alternativi a questo per avere un monitoraggio più preciso delle cadute di volume di traffico per ogni percorso. Questo allarme non è raccomandato per le API che non prevedono un traffico costante e regolare.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

Conteggio

Dimensioni: faseApiId, risorsa, metodo

Descrizione dell'allarme: questo allarme aiuta a rilevare un basso volume di traffico per la route dell'API HTTP nella fase. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Scopo: questo allarme può rilevare un volume di traffico inaspettatamente basso per la route dell'API HTTP nella fase. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Questo allarme non è raccomandato per le API che non prevedono un traffico costante e regolare.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

IntegrationLatency

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme aiuta a rilevare un'elevata latenza di integrazione per le richieste API in una fase. Puoi stabilire un collegamento tra il valore del parametro IntegrationLatency e il parametro della latenza corrispondente per il back-end, ad esempio il parametro Duration per le integrazioni Lambda. Questo ti aiuta a determinare se il back-end dell'API impiega più tempo a elaborare le richieste dei client a causa di problemi di prestazioni o se sussiste qualche altro sovraccarico dovuto all'inizializzazione o all'avvio a freddo. Inoltre, valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per eventuali errori che potrebbero causare problemi di elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per avere una visione di questa metrica per percorso, per aiutarti a restringere l'origine della latenza di integrazione.

Scopo: questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza di integrazione elevata. Consigliamo questo allarme per le WebSocket API e lo consideriamo facoltativo per le API HTTP, in quanto offrono già raccomandazioni di allarme separate per la metrica di latenza. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti prestazionali di latenza di integrazione diversi per percorso, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più dettagliato della latenza di integrazione per ciascuna route.

Statistica: p90

Soglia raccomandata: 2.000,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, imposta un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Dimensioni:, tappa, percorso ApiId

Descrizione dell'allarme: questo allarme aiuta a rilevare se c'è un'elevata latenza di integrazione per le richieste WebSocket API per un percorso in una fase. Puoi stabilire un collegamento tra il valore del parametro IntegrationLatency e il parametro della latenza corrispondente per il back-end, ad esempio il parametro Duration per le integrazioni Lambda. Questo ti aiuta a determinare se il back-end dell'API impiega più tempo a elaborare le richieste dei client a causa di problemi di prestazioni o se sussiste qualche altro sovraccarico dovuto all'inizializzazione o all'avvio a freddo. Inoltre, valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per eventuali errori che potrebbero causare problemi di alta latenza.

Scopo: questo allarme può rilevare quando le richieste di Gateway API per una route in una fase hanno una latenza di integrazione elevata.

Statistica: p90

Soglia raccomandata: 2.000,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latenza

Dimensioni:, palco ApiName

Descrizione dell'allarme: questo allarme rileva un'elevata latenza in una fase. Trova il valore del parametro IntegrationLatency per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi. Prendi in considerazione anche l'attivazione CloudWatch dei log e il controllo degli errori che potrebbero causare l'elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per risorsa e metodo e restringere la fonte della latenza. Se applicabile, consulta le guide alla risoluzione dei problemi con Lambda o alla risoluzione dei problemi per gli endpoint API ottimizzati per l'edge.

Scopo: questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza elevata. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti di prestazioni di latenza diversi per ogni metodo e risorsa, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più dettagliato della latenza per ogni risorsa e metodo.

Statistica: p90

Soglia raccomandata: 2.500,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latenza

Dimensioni: fase, risorsa, metodo ApiName

Descrizione dell'allarme: questo allarme rileva un'elevata latenza per un metodo e una risorsa in una fase. Trova il valore del parametro IntegrationLatency per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Prendi in considerazione anche l'attivazione CloudWatch dei log e il controllo di eventuali errori che potrebbero causare l'elevata latenza. Se applicabile, puoi anche fare riferimento alle guide alla risoluzione dei problemi con Lambda o alla risoluzione dei problemi per gli endpoint API ottimizzati per l'edge.

Scopo: questo allarme può rilevare quando le richieste di Gateway API per una risorsa e un metodo in una fase hanno una latenza elevata.

Statistica: p90

Soglia raccomandata: 2.500,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latenza

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme rileva un'elevata latenza in una fase. Trova il valore del parametro IntegrationLatency per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Valuta anche la possibilità di abilitare CloudWatch i log e di verificare la presenza di eventuali errori che potrebbero causare l'elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso e restringere la fonte della latenza. Puoi anche fare riferimento alla guida alla risoluzione dei problemi con le integrazioni Lambda, se applicabile.

Scopo: questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza elevata. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti di prestazioni di latenza diversi per percorso, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più dettagliato della latenza per ogni percorso.

Statistica: p90

Soglia raccomandata: 2.500,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, può essere utilizzato come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se in generale è accettabile che l'API abbia una latenza più elevata, puoi impostare un valore di soglia più elevato per renderla meno sensibile. Tuttavia, se all'API è richiesto di fornire risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latenza

Dimensioni:, fase, risorsa, metodo ApiId

Descrizione dell'allarme: questo allarme rileva un'elevata latenza per una route in una fase. Trova il valore del parametro IntegrationLatency per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Prendi in considerazione anche l'abilitazione CloudWatch dei log e il controllo di eventuali errori che potrebbero causare l'elevata latenza. Puoi anche fare riferimento alla guida alla risoluzione dei problemi con le integrazioni Lambda, se applicabile.

Scopo: questo allarme è impiegato per rilevare quando le richieste di Gateway API per una route in una fase hanno una latenza elevata.

Statistica: p90

Soglia raccomandata: 2.500,0

Giustificazione della soglia: il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, può essere utilizzato come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme rileva un tasso elevato di errori lato client. Ciò può indicare un problema nei parametri di autorizzazione o di richiesta del client. Potrebbe anche significare che una route è stata rimossa o che un client sta richiedendo una route che non esiste nell'API. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4xx. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui questa guida per risolvere il problema.

Scopo: questo allarme può rilevare tassi elevati di errori lato client per le richieste di Gateway API.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4xx. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

5xx

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme aiuta a rilevare un tasso elevato di errori lato client. Ciò può indicare un errore nel back-end dell'API, nella rete o nell'integrazione tra il gateway API e l'API di back-end. Questa documentazione può aiutarti a risolvere la causa degli errori 5xx.

Scopo: questo allarme può rilevare tassi elevati di errori lato server per le richieste di Gateway API.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 5xx. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5xx che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

MessageCount

Dimensioni:ApiId, Stage

Descrizione dell'allarme: Questo allarme aiuta a rilevare un basso volume di traffico per la fase WebSocket API. Ciò può indicare un problema quando i client chiamano l'API, ad esempio in caso di utilizzo di endpoint errati o problemi con il back-end che invia messaggi ai client. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Intento: questo allarme può rilevare un volume di traffico inaspettatamente basso per la WebSocket fase API. Suggeriamo di creare questo allarme se l'API riceve e invia un numero prevedibile e regolare di messaggi in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per percorso, è meglio creare allarmi alternativi a questo, in modo da avere un monitoraggio più preciso delle cadute di volume di traffico per ogni percorso. Non suggeriamo questo allarme per le API che non prevedono un traffico regolare e costante.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di messaggi di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

MessageCount

Dimensioni:ApiId, tappa, percorso

Descrizione dell'allarme: questo allarme aiuta a rilevare un basso volume di traffico per il percorso WebSocket API nella fase. Ciò può indicare un problema relativo ai client che chiamano l'API, ad esempio in caso di utilizzo di endpoint errati o problemi con il back-end che invia messaggi ai client. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.

Intento: questo allarme è in grado di rilevare un volume di traffico inaspettatamente basso per il percorso WebSocket API nella fase. Suggeriamo di creare questo allarme se l'API riceve e invia un numero prevedibile e regolare di messaggi in condizioni normali. Non suggeriamo questo allarme per le API che non prevedono un traffico regolare e costante.

Statistica: SampleCount

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base all'analisi dei dati storici per determinare il numero di messaggi di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

ClientError

Dimensioni:ApiId, Stage

Descrizione dell'allarme: questo allarme rileva un tasso elevato di errori dei client. Ciò può indicare un problema nei parametri di autorizzazione o dei messaggi. Potrebbe anche significare che una route è stata rimossa o che un client sta richiedendo una route che non esiste nell'API. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4xx. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui questa guida per risolvere il problema.

Intento: questo allarme è in grado di rilevare tassi elevati di errori del client per i messaggi WebSocket API Gateway.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4xx. È possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ExecutionError

Dimensioni:ApiId, Palco

Descrizione dell'allarme: questo allarme aiuta a rilevare un tasso elevato di errori di esecuzione. Questo potrebbe derivare da errori 5xx generati dall'integrazione, da problemi di autorizzazione o da altri fattori che ostacolano la corretta invocazione dell'integrazione, come la sua rimozione o la limitazione della larghezza di banda della rete associata. Valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per il tipo e la causa degli errori. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per avere una visione di questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Anche questa documentazione può aiutarti a risolvere la causa degli errori di connessione.

Intento: questo allarme può rilevare alti tassi di errori di esecuzione per i messaggi WebSocket API Gateway.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia suggerita rileva quando più del 5% del totale delle richieste presenta errori di esecuzione. È possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. È possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori di esecuzione che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon EC2 Auto Scaling

GroupInServiceCapacity

Dimensioni: AutoScalingGroupName

Descrizione dell'allarme: questo allarme aiuta a rilevare quando la capacità del gruppo è inferiore alla capacità desiderata richiesta per il carico di lavoro. Per risolvere il problema, controlla le attività di dimensionamento per individuare eventuali errori di avvio e verifica che la configurazione della capacità desiderata sia corretta.

Scopo: questo allarme può rilevare una bassa disponibilità nel gruppo con dimensionamento automatico a causa di errori di avvio o avvii sospesi.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore della soglia deve essere la capacità minima richiesta per eseguire il carico di lavoro. Nella maggior parte dei casi, puoi impostarlo in modo che corrisponda alla GroupDesiredCapacity metrica.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

Amazon CloudFront

5 xxErrorRate

Dimensioni:DistributionId, Region=Global

Descrizione dell'allarme: questo allarme monitora la percentuale di 5xx risposte di errore dal server di origine, per aiutarti a rilevare se il CloudFront servizio presenta problemi. Consulta la pagina Troubleshooting error responses from your origin per informazioni su come comprendere i problemi del server. Inoltre, attiva parametri aggiuntivi per ottenere parametri dettagliati sugli errori.

Intento: questo allarme viene utilizzato per rilevare problemi relativi alla gestione delle richieste dal server di origine o problemi di comunicazione tra CloudFront e il server di origine.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dalla tolleranza per le risposte 5xx. È possibile analizzare i dati storici e le tendenze e impostare la soglia di conseguenza. Poiché gli errori 5xx possono essere causati da problemi transitori, consigliamo di impostare la soglia su un valore maggiore di 0 in modo che l'allarme non sia troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

OriginLatency

Dimensioni:DistributionId, Region=Global

Descrizione dell'allarme: l'allarme aiuta a monitorare se il server di origine impiega troppo tempo a rispondere. Se il server impiega troppo tempo a rispondere, potrebbe verificarsi un timeout. Consulta la pagina Find and fix delayed responses from applications on your origin server se riscontri valori di OriginLatency costantemente elevati.

Scopo: questo allarme viene utilizzato per rilevare problemi con un server di origine che impiega troppo tempo a rispondere.

Statistica: p90

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: la soglia va impostata su un valore pari a circa l'80% del valore di timeout di risposta del server di origine. Se questo parametro è costantemente vicino al valore di timeout di risposta del server di origine, potresti iniziare a riscontrare errori di tipo 504.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensioni:DistributionId, Region=Global FunctionName

Descrizione dell'allarme: questo allarme consente di monitorare gli errori di convalida delle CloudFront funzioni in modo da poter adottare le misure necessarie per risolverli. Analizza i registri delle CloudWatch funzioni e guarda il codice della funzione per trovare e risolvere la causa principale del problema. Vedi Restrizioni sulle funzioni edge per comprendere gli errori di configurazione comuni delle funzioni. CloudFront

Intento: questo allarme viene utilizzato per rilevare gli errori di convalida delle funzioni. CloudFront

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: un valore maggiore di 0 indica un errore di convalida. Si consiglia di impostare la soglia su 0 perché gli errori di convalida implicano un problema quando CloudFront le funzioni vengono restituite a. CloudFront Ad esempio, CloudFront necessita dell'intestazione HTTP Host per elaborare una richiesta. Non c'è nulla che impedisca a un utente di eliminare l'intestazione Host nel codice delle funzioni. CloudFront Ma quando CloudFront riceve la risposta e manca l'intestazione Host, CloudFront genera un errore di convalida.

Periodo: 60

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Dimensioni:DistributionId,, Region=Global FunctionName

Descrizione dell'allarme: Questo allarme consente di monitorare gli errori di esecuzione CloudFront delle funzioni in modo da poter adottare le misure necessarie per risolverli. Analizza i log delle CloudWatch funzioni e guarda il codice della funzione per trovare e risolvere la causa principale del problema.

Intento: questo allarme viene utilizzato per rilevare gli errori di esecuzione delle funzioni. CloudFront

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: si consiglia di impostare la soglia su 0 perché un errore di esecuzione indica un problema con il codice che si verifica in fase di runtime.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensioni:DistributionId,, FunctionName Region=Global

Descrizione dell'allarme: Questo allarme ti aiuta a monitorare se la tua CloudFront funzione è limitata. Se la tua funzione è sottoposta a limitazione della larghezza di banda della rete, significa che l'esecuzione sta impiegando troppo tempo. Per evitare limitazioni della larghezza di banda della rete nelle funzioni, valuta la possibilità di ottimizzarne il codice.

Scopo: questo allarme è in grado di rilevare quando la CloudFront funzione è limitata, in modo da consentire all'utente di reagire e risolvere il problema per un'esperienza utente senza intoppi.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: si consiglia di impostare la soglia su 0, per consentire una risoluzione più rapida delle accelerazioni delle funzioni.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon Cognito

SignUpThrottles

Dimensioni:, UserPool UserPoolClient

Descrizione dell'allarme: questo allarme monitora il numero di richieste sottoposte a limitazione della larghezza di banda della rete. Se gli utenti vengono costantemente sottoposti a limitazione della larghezza di banda della rete, è necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina Quotas in Amazon Cognito per informazioni su come richiedere un aumento delle quote. Per intraprendere operazioni in modo proattivo, prendi in considerazione la possibilità di tracciare la quota di utilizzo.

Scopo: questo allarme aiuta a monitorare se si verificano richieste di registrazione sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare qualsiasi deterioramento dell'esperienza di registrazione. Una limitazione prolungata della larghezza di banda della rete per le richieste incide negativamente sull'esperienza di registrazione degli utenti.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: un pool di utenti con provisioning adeguato non dovrebbe subire alcuna limitazione della larghezza di banda della rete su più punti dati. Pertanto, la soglia tipica per un carico di lavoro previsto dovrebbe essere zero. Per un carico di lavoro irregolare con interruzioni frequenti, è possibile analizzare i dati storici per determinare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Per ridurre al minimo l'impatto sull'applicazione, è necessario ritentare una richiesta sottoposta a limitazione della larghezza di banda della rete.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

SignInThrottles

Dimensioni:UserPool, UserPoolClient

Descrizione dell'allarme: questo allarme monitora il numero di richieste di autenticazione utente sottoposte a limitazione della larghezza di banda della rete. Se gli utenti vengono costantemente sottoposti a limitazione della larghezza di banda della rete, potrebbe essere necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina Quotas in Amazon Cognito per informazioni su come richiedere un aumento delle quote. Per intraprendere operazioni in modo proattivo, prendi in considerazione la possibilità di tracciare la quota di utilizzo.

Scopo: questo allarme aiuta a monitorare se si verificano richieste di accesso sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare qualsiasi deterioramento dell'esperienza di accesso. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: un pool di utenti con provisioning adeguato non dovrebbe subire alcuna limitazione della larghezza di banda della rete su più punti dati. Pertanto, la soglia tipica per un carico di lavoro previsto dovrebbe essere zero. Per un carico di lavoro irregolare con interruzioni frequenti, è possibile analizzare i dati storici per determinare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Per ridurre al minimo l'impatto sull'applicazione, è necessario ritentare una richiesta sottoposta a limitazione della larghezza di banda della rete.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Dimensioni:UserPool, UserPoolClient

Descrizione dell'allarme: è possibile impostare il valore di soglia in base al traffico della richiesta e in modo che corrisponda a una limitazione della larghezza di banda della rete accettabile per le richieste di aggiornamento dei token. La limitazione della larghezza di banda della rete viene utilizzata per proteggere il sistema da un numero eccessivo di richieste. Tuttavia, è importante monitorare anche se le risorse di cui si dispone sono insufficienti per il normale traffico. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di allarme in modo che sia superiore al livello di limitazione accettabile. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.

Scopo: questo allarme aiuta a monitorare se si verificano richieste di aggiornamento dei token sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare eventuali problemi, al fine di garantire un'esperienza utente fluida unita all'integrità e all'affidabilità del tuo sistema di autenticazione. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia può essere impostato/regolato anche in base al traffico della richiesta, nonché a una limitazione della larghezza di banda della rete accettabile per le richieste di aggiornamento dei token. La limitazione della larghezza di banda della rete serve a proteggere il sistema da un numero eccessivo di richieste, tuttavia è importante monitorare anche che le risorse per il traffico normale non siano insufficienti e controllare se è proprio questo a causare l'impatto. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

FederationThrottles

Dimensioni:UserPool, UserPoolClient, IdentityProvider

Descrizione dell'allarme: questo allarme monitora il numero di richieste di federazione delle identità sottoposte a limitazione della larghezza di banda della rete. Se si riscontra una continua limitazione della larghezza di banda della rete, potrebbe essere necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina Quotas in Amazon Cognito per informazioni su come richiedere un aumento delle quote.

Scopo: questo allarme aiuta a monitorare se si verificano richieste di federazione delle identità sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a reagire in modo proattivo ai colli di bottiglia in termini di prestazioni o alle configurazioni errate e a garantire un'esperienza di autenticazione fluida per gli utenti. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è possibile impostare la soglia in base al traffico della richiesta e in modo che corrisponda alla limitazione della larghezza di banda della rete accettabile per le richieste di federazione delle identità. La limitazione della larghezza di banda della rete viene utilizzata per proteggere il sistema da un numero eccessivo di richieste. Tuttavia, è importante monitorare anche se le risorse di cui si dispone sono insufficienti per il normale traffico. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare il valore della soglia in modo che sia superiore al livello di limitazione accettabile. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon DynamoDB

AccountProvisionedReadCapacityUtilization

Dimensions: nessuna

Descrizione dell'allarme: questo allarme rileva se la capacità di lettura dell'account sta raggiungendo il limite previsto. In tal caso, è possibile aumentare la quota dell'account per l'utilizzo della capacità di lettura. È possibile visualizzare le quote correnti per le unità di capacità di lettura e richiedere eventuali aumenti utilizzando Service Quotas.

Scopo: l'allarme può rilevare se l'utilizzo della capacità di lettura dell'account si avvicina all'utilizzo della capacità di lettura assegnata. Se l'utilizzo raggiunge il limite massimo, DynamoDB inizia a limitare la larghezza di banda della rete per le richieste di lettura.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: imposta la soglia all'80%, in modo che sia possibile intraprendere operazioni (ad esempio innalzare i limiti dell'account) prima che raggiunga la piena capacità al fine di evitare una limitazione della larghezza di banda della rete.

Periodo: 300

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensions: nessuna

Descrizione dell'allarme: questo allarme rileva se la capacità di scrittura dell'account sta raggiungendo il limite previsto. In tal caso, è possibile aumentare la quota dell'account per l'utilizzo della capacità di scrittura. È possibile visualizzare le quote correnti per le unità di capacità di scrittura e richiedere eventuali aumenti utilizzando Service Quotas.

Scopo: questo allarme può rilevare se l'utilizzo della capacità di scrittura dell'account si avvicina all'utilizzo della capacità di scrittura assegnata. Se l'utilizzo raggiunge il limite massimo, DynamoDB inizia a limitare la larghezza di banda della rete per le richieste di scrittura.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: imposta la soglia all'80%, in modo che sia possibile intraprendere operazioni (ad esempio innalzare i limiti dell'account) prima che raggiunga la piena capacità al fine di evitare una limitazione della larghezza di banda della rete.

Periodo: 300

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Dimensioni:TableName, DelegatedOperation

Descrizione dell'allarme: questo allarme rileva il ritardo nella replica in un flusso di dati Kinesis. In condizioni di funzionamento normale, AgeOfOldestUnreplicatedRecord dovrebbe essere di pochi millisecondi. Questo numero aumenta in base ai tentativi di replica non riusciti causati da scelte di configurazione controllate dal cliente. Gli esempi di configurazioni controllate dal cliente che portano a tentativi di replica non riusciti sono una capacità del flusso di dati Kinesis con provisioning insufficiente, che comporta una limitazione della larghezza di banda della rete eccessiva, o un aggiornamento manuale delle policy di accesso del flusso di dati Kinesis, che impedisce a DynamoDB di aggiungere dati al flusso dei dati. Per mantenere questo parametro il più basso possibile, potrebbe essere necessario garantire il corretto provisioning della capacità del flusso di dati Kinesis e assicurarsi che le autorizzazioni di DynamoDB siano invariate.

Scopo: questo allarme può monitorare i tentativi di replica non riusciti e il conseguente ritardo nella replica nel flusso di dati Kinesis.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al ritardo di replica desiderato misurato in millisecondi. Questo valore dipende dai requisiti del carico di lavoro e dalle prestazioni previste.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Dimensioni:TableName, DelegatedOperation

Descrizione dell'allarme: il numero di record che DynamoDB non è riuscito a replicare nel flusso di dati Kinesis. Alcuni elementi di dimensioni superiori a 34 KB potrebbero espandersi per modificare i record di dati superiori al limite di dimensioni di 1 MB degli elementi di Kinesis Data Streams. Questo aumento delle dimensioni si verifica quando gli elementi più grandi di 34 KB includono un numero elevato di valori booleani o vuoti degli attributi. I valori booleani e vuoti degli attributi vengono archiviati come 1 byte in DynamoDB, ma si espandono fino a 5 byte quando vengono serializzati utilizzando JSON standard per la replica di Kinesis Data Streams. DynamoDB non può replicare tali record di modifica nel flusso dei dati Kinesis. DynamoDB ignora questi record di dati di modifica e continua automaticamente a replicare i record successivi.

Scopo: questo allarme può monitorare il numero di record che DynamoDB non è riuscito a replicare nel flusso di dati Kinesis a causa del limite delle dimensioni degli elementi dei flussi di dati Kinesis.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: imposta la soglia su 0 per rilevare eventuali record che DynamoDB non è riuscito a replicare.

Periodo: 60

Punti dati su cui attivare allarmi: 1

Periodi di valutazione: 1

Operatore di confronto: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensioni: TableName

Descrizione dell'allarme: questo allarme rileva la presenza di un numero elevato di richieste di lettura sottoposte a limitazione della larghezza di banda della rete per la tabella DynamoDB. Per risolvere il problema, consulta la pagina Troubleshooting throttling issues in Amazon DynamoDB.

Scopo: questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di lettura alla tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di lettura può influire negativamente sulle operazioni di lettura del carico di lavoro e ridurre l'efficienza complessiva del sistema.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al traffico di lettura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensioni:TableName, GlobalSecondaryIndexName

Descrizione dell'allarme: questo allarme rileva la presenza di un numero elevato di richieste di lettura sottoposte a limitazione della larghezza di banda della rete per l'indice secondario globale della tabella DynamoDB. Per risolvere il problema, consulta la pagina Troubleshooting throttling issues in Amazon DynamoDB.

Scopo: l'allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di lettura per l'indice secondario globale della tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di lettura può influire negativamente sulle operazioni di lettura del carico di lavoro e ridurre l'efficienza complessiva del sistema.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al traffico di lettura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ReplicationLatency

Dimensioni:TableName, ReceivingRegion

Descrizione dell'allarme: l'allarme rileva se la replica della tabella globale in una regione è in ritardo rispetto alla regione di origine. La latenza può aumentare se una AWS regione si deteriora e in quella regione è presente una tabella di replica. In questo caso, puoi reindirizzare temporaneamente l'attività di lettura e scrittura dell'applicazione verso un'altra regione. AWS Se si utilizza la versione 2017.11.29 (legacy) delle tabelle globali, è necessario verificare che le unità di capacità di scrittura (WCU) siano identiche per ciascuna delle tabelle di replica. Puoi anche assicurarti di seguire le raccomandazioni elencate nella pagina Best practices and requirements for managing capacity.

Scopo: l'allarme può rilevare se la tabella di replica in una regione è in ritardo rispetto alla replica delle modifiche da un'altra regione. Ciò potrebbe far sì che la replica diverga dalle altre repliche. È utile conoscere la latenza di replica di ciascuna AWS regione e avvisare se tale latenza di replica aumenta continuamente. La replica della tabella si applica solo alle tabelle globali.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Solitamente, sono oggetto di indagine le latenze di replica superiori a 3 minuti. Esamina la criticità e i requisiti del ritardo di replica e analizza le tendenze storiche, quindi seleziona la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Dimensioni:, Funzionamento TableName

Descrizione dell'allarme: questo allarme rileva un'elevata latenza per il funzionamento della tabella DynamoDB (indicata dal valore della dimensione Operationnell'allarme). Consulta questo documento sulla risoluzione dei problemi per risolvere i problemi di latenza in Amazon DynamoDB.

Scopo: questo allarme può rilevare una latenza elevata delle operazioni della tabella DynamoDB. Una latenza delle operazioni più elevata può influire negativamente sull'efficienza complessiva del sistema.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: DynamoDB fornisce una latenza media di un millisecondo per operazioni singleton come, e così via. GetItem PutItem Tuttavia, puoi impostare la soglia in base alla tolleranza accettabile per la latenza, considerando il tipo di operazione e la tabella coinvolta nel carico di lavoro. È possibile analizzare i dati storici di questo parametro per individuare la latenza abituale per l'operazione sulla tabella e quindi impostare la soglia su un numero che rappresenti il ritardo critico per l'operazione.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

SystemErrors

Dimensioni: TableName

Descrizione dell'allarme: questo allarme rileva un numero elevato e prolungato di errori di sistema per le richieste delle tabelle DynamoDB. Se continui a ricevere errori 5xx, apri il Pannello di controllo per lo stato dei servizi AWS per verificare la presenza di problemi operativi con il servizio. Puoi utilizzare questo allarme per ricevere una notifica da DynamoDB in caso di un problema prolungato del servizio interno, aiutandoti a stabilire un collegamento con il problema che l'applicazione client sta riscontrando. Per ulteriori informazioni, consulta la pagina Error handling for DynamoDB.

Scopo: questo allarme può rilevare errori di sistema prolungati nelle richieste della tabella DynamoDB. Gli errori di sistema indicano errori interni del servizio di DynamoDB e contribuiscono a stabilire un collegamento con il problema riscontrato dal client.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al traffico di lettura previsto, tenendo conto di un livello accettabile di errori di sistema. Inoltre, è possibile analizzare i dati storici per determinare il numero di errori accettabili per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Gli errori di sistema devono essere ritentati dall'applicazione/dal servizio poiché sono transitori. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Dimensioni:TableName, DelegatedOperation

Descrizione dell'allarme: questo allarme rileva i record sottoposti a limitazione della larghezza di banda della rete dal flusso di dati Kinesis durante la replica dell'acquisizione dei dati di modifica su Kinesis. Questa limitazione della larghezza di banda della rete si verifica a causa della capacità del flusso di dati Kinesis insufficiente. Se si verifica una limitazione eccessiva e regolare, potrebbe essere necessario aumentare il numero di partizioni del flusso Kinesis proporzionalmente alla velocità di scrittura osservata della tabella. Per ulteriori informazioni su come determinare le dimensioni di un flusso di dati Kinesis, consulta Determinazione delle dimensioni iniziali di un flusso di dati Kinesis.

Scopo: questo allarme può monitorare il numero di record sottoposti a limitazione della larghezza di banda della rete dal flusso di dati Kinesis a causa della capacità insufficiente di Kinesis Data Streams.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è possibile che si verifichino delle limitazioni della larghezza di banda della rete durante i picchi di utilizzo eccezionali, ma i record limitati devono rimanere il più bassi possibile per evitare una maggiore latenza di replica (DynamoDB riprova a inviare i record limitati al flusso di dati Kinesis). Imposta la soglia su un numero che possa aiutarti a rilevare una limitazione della larghezza di banda della rete regolarmente eccessiva. Inoltre, è possibile analizzare i dati storici di questo parametro per individuare i tassi di limitazione della larghezza di banda della rete accettabili per il carico di lavoro dell'applicazione. Regola la soglia su un valore che l'applicazione può tollerare in base al tuo caso d'uso.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

UserErrors

Dimensions: nessuna

Descrizione dell'allarme: questo allarme rileva un numero elevato e prolungato di errori utente per le richieste delle tabelle DynamoDB. È possibile controllare i log delle applicazioni client durante il periodo del problema per vedere perché le richieste non sono valide. Puoi controllare il codice di stato HTTP 400 per vedere il tipo di errore che stai riscontrando e agire di conseguenza. Potrebbe essere necessario correggere la logica dell'applicazione per creare richieste valide.

Scopo: questo allarme può rilevare errori degli utenti prolungati nelle richieste della tabella DynamoDB. Gli errori degli utenti nelle operazioni richieste indicano che il client sta producendo richieste non valide e che l'operazione non va a buon fine.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia su zero per rilevare eventuali errori sul lato client. Oppure impostalo su un valore più alto se vuoi evitare che si attivi l'allarme per un numero molto basso di errori. Decidi in base al tuo caso d'uso e al traffico per le richieste.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensioni: TableName

Descrizione dell'allarme: questo allarme rileva la presenza di un numero elevato di richieste di scrittura sottoposte a limitazione della larghezza di banda della rete per la tabella DynamoDB. Per risolvere il problema, consulta la pagina Troubleshooting throttling issues in Amazon DynamoDB.

Scopo: questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di scrittura alla tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di scrittura può influire negativamente sulle operazioni di scrittura del carico di lavoro e ridurre l'efficienza complessiva del sistema.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al traffico di scrittura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia su un valore superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensioni:TableName, GlobalSecondaryIndexName

Descrizione dell'allarme: questo allarme rileva la presenza di un numero elevato di richieste di scrittura sottoposte a limitazione della larghezza di banda della rete per l'indice secondario globale della tabella DynamoDB. Per risolvere il problema, consulta la pagina Troubleshooting throttling issues in Amazon DynamoDB.

Scopo: questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di scrittura per l'indice secondario globale della tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di scrittura può influire negativamente sulle operazioni di scrittura del carico di lavoro e ridurre l'efficienza complessiva del sistema.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al traffico di scrittura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia su un valore superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, un valore molto basso potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon EBS

VolumeStalledIOCheck

Dimensioni:VolumeId, InstanceId

Descrizione dell'allarme: questo allarme consente di monitorare le prestazioni di I/O dei volumi Amazon EBS. Questo controllo rileva problemi di fondo con l'infrastruttura Amazon EBS, come problemi hardware o software sui sottosistemi di storage alla base dei volumi Amazon EBS, problemi hardware sull'host fisico che influiscono sulla raggiungibilità dei volumi Amazon EBS dall'istanza Amazon EC2, e può rilevare problemi di connettività tra l'istanza e i volumi Amazon EBS. Se lo Stalled IO Check fallisce, puoi AWS attendere la risoluzione del problema oppure puoi intraprendere azioni come sostituire il volume interessato o arrestare e riavviare l'istanza a cui è collegato il volume. Nella maggior parte dei casi, quando questa metrica fallisce, Amazon EBS diagnostica e ripristina automaticamente il volume entro pochi minuti.

Intento: questo allarme è in grado di rilevare lo stato dei volumi Amazon EBS per determinare quando tali volumi sono compromessi e non possono completare le operazioni di I/O.

Statistica: Maximum

Soglia raccomandata: 1,0

Giustificazione della soglia: quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EC2

CPUUtilization

Dimensioni: InstanceId

Descrizione dell'allarme: questo allarme aiuta a monitorare l'utilizzo della CPU di un'istanza EC2. A seconda dell'applicazione, potrebbero essere normali livelli di utilizzo costantemente elevati. Tuttavia, se le prestazioni si deteriorano e l'applicazione non è limitata dall'I/O del disco, dalla memoria o dalle risorse di rete, una CPU al massimo potrebbe indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni. Un utilizzo elevato della CPU potrebbe indicare che è necessario un aggiornamento a un'istanza con un uso più intensivo della CPU. Se è abilitato il monitoraggio dettagliato, è possibile modificare il periodo a 60 secondi anziché 300 secondi. Per ulteriori informazioni, consulta la pagina Enable or turn off detailed monitoring for your instances.

Scopo: questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU.

Statistica: Average

Soglia raccomandata: 80,0

Giustificazione della soglia: in genere, è possibile impostare la soglia per l'utilizzo della CPU al 70-80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcuni sistemi, un utilizzo costantemente elevato della CPU può essere normale e non indicare un problema, mentre per altri può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della CPU per stabilire qual è un valore di utilizzo della CPU accettabile per il sistema e imposta la soglia di conseguenza.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

StatusCheckFailed

Dimensioni: InstanceId

Descrizione dell'allarme: questo allarme aiuta a monitorare sia i controlli dello stato del sistema che i controlli dello stato dell'istanza. Se uno dei due tipi di controllo dello stato fallisce, questo allarme dovrebbe essere nello stato ALARM.

Scopo: questo allarme viene utilizzato per rilevare i problemi sottostanti delle istanze, inclusi gli errori di controllo dello stato del sistema e gli errori di controllo dello stato delle istanze.

Statistica: Maximum

Soglia raccomandata: 1,0

Giustificazione della soglia: quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.

Periodo: 300

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_attachedEBS

Dimensioni: InstanceId

Descrizione dell'allarme: questo allarme consente di monitorare se i volumi Amazon EBS collegati a un'istanza sono raggiungibili e in grado di completare le operazioni di I/O. Questo controllo dello stato rileva problemi di fondo con l'infrastruttura di elaborazione o Amazon EBS, come i seguenti:

• Problemi hardware o software sui sottosistemi di storage alla base dei volumi Amazon EBS

• Problemi hardware sull'host fisico che influiscono sulla raggiungibilità dei volumi Amazon EBS

• Problemi di connettività tra l'istanza e i volumi Amazon EBS

Quando il controllo dello stato EBS allegato fallisce, puoi attendere che Amazon risolva il problema oppure puoi intraprendere un'azione come sostituire i volumi interessati o arrestare e riavviare l'istanza.

Intento: questo allarme viene utilizzato per rilevare volumi Amazon EBS non raggiungibili collegati a un'istanza. Questi possono causare guasti nelle operazioni di I/O.

Statistica: Maximum

Soglia raccomandata: 1,0

Giustificazione della soglia: quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon ElastiCache

CPUUtilization

Dimensioni:, CacheClusterId CacheNodeId

Descrizione dell'allarme: questo allarme aiuta a monitorare l'utilizzo della CPU per l'intera ElastiCache istanza, inclusi i processi del motore di database e altri processi in esecuzione sull'istanza. AWS Elasticache supporta due tipi di motore: Memcached e Redis. Se raggiungi un utilizzo della CPU elevato su un nodo Memcached, dovresti prendere in considerazione la possibilità di aumentare il tipo di istanza o aggiungere nuovi nodi di cache. Per Redis, se il carico di lavoro principale riguarda le richieste di lettura, dovresti prendere in considerazione l'aggiunta di altre repliche di lettura al cluster di cache. Se il tuo carico di lavoro principale è costituito da richieste di scrittura, dovresti prendere in considerazione l'aggiunta di altre partizioni per distribuire il carico di lavoro su più nodi primari (se utilizzi la modalità cluster) o l'aumento del tipo di istanza (se esegui Redis in modalità non cluster).

Intento: questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU da parte degli host. ElastiCache È utile avere una visione generale dell'utilizzo della CPU nell'intera istanza, compresi i processi non legati al motore.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia sulla percentuale che riflette un livello di utilizzo della CPU critico per l'applicazione. Per Memcached, il motore può utilizzare fino a num_threads core. Per Redis, il motore è principalmente a thread singolo, ma potrebbe utilizzare core aggiuntivi, se disponibili, per accelerare l'I/O. Nella maggior parte dei casi, è possibile impostare la soglia su circa il 90% della CPU disponibile. Poiché Redis è a thread singolo, il valore di soglia effettivo deve essere calcolato come una frazione della capacità totale del nodo.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

CurrConnections

Dimensioni:, CacheClusterId CacheNodeId

Descrizione dell'allarme: questo allarme rileva un numero elevato di connessioni, che potrebbe indicare problemi di carico o prestazioni elevati. Un aumento costante di CurrConnections potrebbe portare all'esaurimento delle 65.000 connessioni disponibili. Potrebbe indicare che le connessioni sono state chiuse erroneamente sul lato dell'applicazione e che sul lato server sono rimaste stabilite. È consigliabile utilizzare il pool di connessioni o i timeout di connessione inattivi per limitare il numero di connessioni effettuate al cluster oppure, per Redis, valutare la possibilità di ottimizzare tcp-keepalive sul cluster per rilevare e terminare potenziali peer morti.

Intento: l'allarme consente di identificare un numero elevato di connessioni che potrebbero influire sulle prestazioni e sulla stabilità del ElastiCache cluster.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dall'intervallo di connessioni accettabile per il cluster. Esamina la capacità e il carico di lavoro previsto del ElastiCache cluster e analizza il numero storico delle connessioni durante l'uso regolare per stabilire una linea di base, quindi seleziona una soglia di conseguenza. Ricorda che ogni nodo può supportare fino a 65.000 connessioni simultanee.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Dimensioni: CacheClusterId

Descrizione dell'allarme: questo allarme consente di monitorare l'utilizzo della memoria del cluster. Quando il valore DatabaseMemoryUsagePercentage raggiunge il 100%, viene attivata la policy Redis maxmemory e potrebbero verificarsi espulsioni in base alla policy selezionata. Se nessun oggetto nella cache corrisponde alla policy di espulsione, le operazioni di scrittura hanno esito negativo. Alcuni carichi di lavoro prevedono espulsioni o si basano su di esse, ma in caso contrario sarà necessario aumentare la capacità di memoria del cluster. È possibile dimensionare il cluster aggiungendo altri nodi primari oppure aumentarlo utilizzando un tipo di nodo più grande. Per ulteriori informazioni, consulta Scaling ElastiCache for Redis clusters.

Scopo: questo allarme viene utilizzato per rilevare un elevato utilizzo della memoria del cluster in modo da evitare errori durante la scrittura sul cluster. È utile sapere quando sarà necessario aumentare il cluster se per l'applicazione non sono previste espulsioni.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: a seconda dei requisiti di memoria dell'applicazione e della capacità di memoria del ElastiCache cluster, è necessario impostare la soglia sulla percentuale che riflette il livello critico di utilizzo della memoria del cluster. È possibile utilizzare i dati storici sull'utilizzo della memoria come indicazione per la soglia di utilizzo della memoria accettabile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

EngineCPUUtilization

Dimensioni: CacheClusterId

Descrizione dell'allarme: questo allarme aiuta a monitorare l'utilizzo della CPU di un thread del motore Redis all'interno dell' ElastiCache istanza. I motivi più comuni dell'utilizzo della CPU elevato da parte di un motore sono i comandi a esecuzione prolungata con un utilizzo elevato di CPU, un numero elevato di richieste, l'aumento delle nuove richieste di connessione client in un breve periodo di tempo e un numero elevato di espulsioni quando la cache non dispone di memoria sufficiente per contenere nuovi dati. Dovresti prendere in considerazione la possibilità di scalare ElastiCache i cluster Redis aggiungendo più nodi o aumentando il tipo di istanza.

Scopo: questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU da parte del thread del motore Redis. È utile se si desidera monitorare l'utilizzo della CPU del motore di database stesso.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: imposta la soglia su una percentuale che rifletta il livello di utilizzo della CPU del motore critico per l'applicazione. È possibile eseguire il benchmark del cluster utilizzando l'applicazione e il carico di lavoro previsto per stabilire un collegamento tra EngineCPUUtilization e le prestazioni di riferimento, quindi impostare la soglia di conseguenza. Nella maggior parte dei casi, è possibile impostare la soglia su circa il 90% della CPU disponibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ReplicationLag

Dimensioni: CacheClusterId

Descrizione dell'allarme: questo allarme aiuta a monitorare lo stato della replica del ElastiCache cluster. Un ritardo di replica elevato significa che il nodo primario o la replica non sono in grado di mantenere il ritmo della replica. Se l'attività di scrittura è troppo elevata, valuta la possibilità di dimensionare il cluster aggiungendo altri nodi primari oppure di aumentarlo utilizzando un tipo di nodo più grande. Per i dettagli, consulta Scaling ElastiCache for Redis clusters. Se le repliche di lettura sono sovraccaricate dalla quantità di richieste di lettura, valuta la possibilità di aggiungere altre repliche di lettura.

Scopo: questo allarme viene utilizzato per rilevare un ritardo tra l'aggiornamento dei dati sul nodo primario e la loro sincronizzazione con il nodo di replica. Contribuisce a garantire la coerenza dei dati di un nodo cluster di replica in lettura.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base ai requisiti dell'applicazione e al potenziale impatto del ritardo di replica. È necessario considerare le velocità di scrittura e le condizioni di rete previste dell'applicazione per stabilire un ritardo di replica accettabile.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon EC2 (AWS/ElasticGPUs)

GPU ConnectivityCheckFailed

Dimensioni:InstanceId, ePUID

Descrizione dell'allarme: questo allarme aiuta a rilevare gli errori di connessione tra l'istanza e l'acceleratore Elastic Graphics. Grafica elastica utilizza la rete di istanze per inviare comandi OpenGL a una scheda grafica collegata in remoto. Inoltre, un desktop che esegue un'applicazione OpenGL con un acceleratore Elastic Graphics è in genere accessibile utilizzando una tecnologia di accesso remoto. È importante distinguere tra un problema di prestazioni relativo al rendering di OpenGL e la tecnologia di accesso remoto del desktop. Per ulteriori informazioni sul problema, consulta la pagina Investigate application performance issues.

Scopo: questo allarme viene utilizzato per rilevare i problemi di connettività dall'istanza all'acceleratore Elastic Graphics.

Statistica: Maximum

Soglia raccomandata: 0,0

Giustificazione della soglia: il valore di soglia 1 indica che la connettività ha riscontrato un errore.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

GPU HealthCheckFailed

Dimensioni:InstanceId, ePUID

Descrizione dell'allarme: questo allarme aiuta a sapere quando lo stato dell'acceleratore Elastic Graphics non è integro. Se l'acceleratore non è integro, consulta la procedura di risoluzione dei problemi alla pagina Resolve Unhealthy status issues.

Scopo: questo allarme viene utilizzato per rilevare se l'acceleratore Elastic Graphics non è integro.

Statistica: Maximum

Soglia raccomandata: 0,0

Giustificazione della soglia: il valore della soglia 1 indica che il controllo dello stato non è stato superato.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon ECS

CPUReservation

Dimensioni: ClusterName

Descrizione dell'allarme: questo allarme consente di rilevare un'elevata prenotazione della CPU del cluster ECS. Una prenotazione della CPU elevata potrebbe indicare che il cluster sta esaurendo le CPU registrate per l'attività. Per risolvere il problema, è possibile aggiungere più capacità, dimensionare il cluster o configurare il dimensionamento automatico.

Scopo: l'allarme viene utilizzato per rilevare se le unità di CPU totali riservate dalle attività sul cluster stanno raggiungendo le unità di CPU totali registrate per il cluster. Questo ti aiuta a sapere quando aumentare il cluster. Il raggiungimento del numero totale di unità CPU per il cluster può comportare l'esaurimento della CPU per le attività. Se hai attivato il dimensionamento gestito dai provider di capacità EC2 o hai associato Fargate ai provider di capacità, questo allarme non è consigliato.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: imposta la soglia per la prenotazione della CPU al 90%. In alternativa, è possibile scegliere un valore inferiore in base alle caratteristiche del cluster.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

CPUUtilization

Dimensioni:ClusterName, ServiceName

Descrizione dell'allarme: questo allarme consente di rilevare un elevato utilizzo della CPU del servizio ECS. In assenza di un'implementazione ECS continua, un utilizzo massimo della CPU potrebbe indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni. Per risolvere il problema, è possibile aumentare il limite della CPU.

Scopo: questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU per il servizio ECS. Un utilizzo costantemente elevato della CPU può indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: i parametri di servizio per l'utilizzo della CPU potrebbero superare il 100% di utilizzo. Tuttavia, ti suggeriamo di monitorare il parametro per un elevato utilizzo della CPU per evitare che influisca su altri servizi. Imposta la soglia su circa il 90-95%. Ti suggeriamo di aggiornare le definizioni delle attività in modo che riflettano l'utilizzo effettivo per evitare problemi futuri con altri servizi.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

MemoryReservation

Dimensioni: ClusterName

Descrizione dell'allarme: questo allarme consente di rilevare un'elevata riserva di memoria del cluster ECS. Una prenotazione di memoria elevata potrebbe indicare un collo di bottiglia in termini di risorse del cluster. Per risolvere il problema, analizza le prestazioni dell'attività di servizio per vedere se l'utilizzo della memoria dell'attività può essere ottimizzato. Inoltre, puoi registrare più memoria o impostare il dimensionamento automatico.

Scopo: l'allarme viene utilizzato per rilevare se le unità di memoria totali riservate dalle attività sul cluster stanno raggiungendo le unità di memoria totali registrate per il cluster. Questo può aiutarti a sapere quando aumentare il cluster. Il raggiungimento delle unità di memoria totali per il cluster può impedire al cluster di avviare nuove attività. Se hai attivato il dimensionamento gestito dai provider di capacità EC2 o hai associato Fargate ai provider di capacità, questo allarme non è consigliato.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: imposta la soglia per la prenotazione della memoria al 90%. È possibile regolare questo valore su un valore inferiore in base alle caratteristiche del cluster.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Dimensioni:ClusterName, ServiceName

Descrizione dell'allarme: questo allarme consente di rilevare un elevato numero di errori lato server per il servizio ECS. Ciò può indicare che sono presenti errori che impediscono al server di evadere le richieste. Per risolvere il problema, controlla i log dell'applicazione.

Scopo: questo allarme viene utilizzato per rilevare un elevato numero di errori lato server per il servizio ECS.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: calcola il valore di circa il 5% del traffico medio e utilizza questo valore come punto di partenza per la soglia. Puoi trovare il traffico medio utilizzando il parametro RequestCount. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

TargetResponseTime

Dimensioni:ClusterName, ServiceName

Descrizione dell'allarme: questo allarme consente di rilevare un tempo di risposta previsto elevato per le richieste del servizio ECS. Ciò può indicare che sono presenti problemi che impediscono al servizio di evadere le richieste in tempo. Per risolvere il problema, controlla il parametro di utilizzo della CPU per vedere se il servizio sta esaurendo la CPU oppure verifica l'utilizzo della CPU di altri servizi a valle da cui dipende il tuo servizio.

Scopo: questo allarme viene utilizzato per rilevare un tempo di risposta previsto elevato per le richieste del servizio ECS.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Esamina la criticità e i requisiti del tempo di risposta previsto del servizio e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon ECS con Container Insights

EphemeralStorageUtilized

Dimensioni:ClusterName, ServiceName

Descrizione dell'allarme: questo allarme consente di rilevare un utilizzo elevato dello spazio di archiviazione temporaneo del cluster Fargate. Se è costantemente elevato, puoi controllare l'utilizzo dello spazio di archiviazione temporaneo e aumentarlo.

Intento: questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione temporaneo per il cluster Fargate. L'uso costantemente elevato dello spazio di archiviazione temporaneo può indicare che il disco è pieno e potrebbe causare errori del container.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia al 90% circa della dimensione dello spazio di archiviazione temporaneo. Puoi modificare questo valore in base all'utilizzo accettabile dello spazio di archiviazione temporaneo del cluster Fargate. Per alcuni sistemi, l'uso costantemente elevato dello spazio di archiviazione temporaneo potrebbe essere normale, mentre per altri potrebbe causare un errore del container.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

RunningTaskCount

Dimensioni:ClusterName, ServiceName

Descrizione dell'allarme: questo allarme consente di rilevare un numero basso di processi in esecuzione del servizio ECS. Un numero di processi in esecuzione troppo basso può indicare che l'applicazione non è in grado di gestire il carico del servizio, il che potrebbe causare problemi di prestazioni. Se non è presente alcun processo in esecuzione, il servizio Amazon ECS potrebbe non essere disponibile o potrebbero esserci problemi di implementazione.

Intento: questo allarme viene utilizzato per rilevare se il numero di processi in esecuzione è troppo basso. Un numero costantemente basso di processi in esecuzione può indicare problemi di implementazione o di prestazioni del servizio ECS.

Statistica: Average

Soglia raccomandata: 0,0

Giustificazione della soglia: puoi modificare la soglia in base al numero minimo di processi in esecuzione del servizio ECS. Se il numero di processi in esecuzione è 0, il servizio Amazon ECS non sarà disponibile.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

Dimensioni:InstanceId, ContainerInstanceId, ClusterName

Descrizione dell'allarme: questo allarme consente di rilevare un utilizzo elevato del file system del cluster ECS. Se l'utilizzo del file system è costantemente elevato, controlla l'utilizzo del disco.

Intento: questo allarme rileva un elevato utilizzo del file system per il cluster Amazon ECS. Un utilizzo costantemente elevato del file system può indicare un collo di bottiglia delle risorse o problemi di prestazioni delle applicazioni e impedire l'esecuzione di nuove attività.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: puoi impostare la soglia per l'utilizzo del file system al 90-95% circa. Puoi modificare questo valore in base al livello di capacità accettabile del file system del cluster Amazon ECS. Per alcuni sistemi, un utilizzo costantemente elevato del file system potrebbe essere normale e non indicare alcun problema, mentre per altri potrebbe essere motivo di preoccupazione e causare problemi di prestazioni e impedire l'esecuzione di nuove attività.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon EFS

PercentIOLimit

Dimensioni: FileSystemId

Descrizione dell'allarme: questo allarme aiuta a garantire che il carico di lavoro rimanga entro il limite di I/O disponibile per il file system. Se il parametro raggiunge costantemente il limite di I/O, valuta la possibilità di spostare l'applicazione su un file system che utilizzi le prestazioni di I/O massime come modalità. Per la risoluzione dei problemi, controlla i client connessi al file system e le applicazioni dei client che limitano la larghezza di banda della rete del file system.

Scopo: questo allarme viene utilizzato per rilevare quanto manca a un file system per raggiungere il limite di I/O della modalità prestazioni per uso generico. Una percentuale di I/O costantemente elevata può indicare che il file system non è in grado di dimensionare in misura sufficiente rispetto alle richieste di I/O e pertanto può rappresentare un collo di bottiglia in termini di risorse per le applicazioni che lo utilizzano.

Statistica: Average

Soglia raccomandata: 100,0

Giustificazione della soglia: quando il file system raggiunge il limite di I/O, può rispondere alle richieste di lettura e scrittura più lentamente. Pertanto, si consiglia di monitorare il parametro per evitare di influire sulle applicazioni che utilizzano il file system. La soglia può essere impostata intorno al 100%. Tuttavia, questo valore può essere regolato su un valore inferiore in base alle caratteristiche del file system.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Dimensioni: FileSystemId

Descrizione dell'allarme: questo allarme aiuta a garantire che sia disponibile un saldo di credito di espansione disponibile per l'utilizzo da parte del file system. Quando non è disponibile alcun credito di espansione, l'accesso delle applicazioni al file system sarà limitato a causa della bassa velocità di trasmissione effettiva. Se il parametro scende costantemente a 0, valuta la possibilità di modificare la modalità di velocità di trasmissione effettiva nella modalità di velocità di trasmissione effettiva elastica o assegnata.

Scopo: questo allarme viene utilizzato per rilevare un saldo di credito di espansione basso del file system. Un saldo di credito di espansione costantemente basso può essere un indicatore del rallentamento della velocità di trasmissione effettiva e dell'aumento della latenza di I/O.

Statistica: Average

Soglia raccomandata: 0,0

Giustificazione della soglia: quando il file system esaurisce i crediti burst e anche se la velocità di throughput di base è inferiore, EFS continua a fornire un throughput misurato pari a 1 a tutti i file system. MiBps Tuttavia, si consiglia di monitorare il parametro verificando la presenza di un saldo di credito basso per evitare che il file system costituisca un collo di bottiglia in termini di risorse per le applicazioni. La soglia può essere impostata intorno a 0 byte.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: LESS_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EKS con Container Insights

node_cpu_utilization

Dimensioni: ClusterName

Descrizione dell'allarme: questo allarme aiuta a rilevare un elevato utilizzo della CPU nei nodi worker del cluster EKS. Un utilizzo costantemente elevato potrebbe indicare la necessità di sostituire i nodi worker con istanze con una CPU maggiore o la necessità di eseguire un dimensionamento orizzontale del sistema.

Scopo: questo allarme aiuta a monitorare l'utilizzo della CPU dei nodi worker nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema inizi a vederne l'impatto.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

node_filesystem_utilization

Dimensioni: ClusterName

Descrizione dell'allarme: questo allarme aiuta a rilevare un utilizzo elevato del file system nei nodi worker del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe essere necessario aggiornare i nodi worker per incrementare le dimensioni del volume del disco oppure potrebbe essere necessario sottoporli a un dimensionamento orizzontale.

Scopo: questo allarme aiuta a monitorare l'utilizzo del file system nei nodi worker del cluster EKS. Se l'utilizzo raggiunge il 100%, può causare errori dell'applicazione, colli di bottiglia nell'I/O del disco, l'espulsione del pod o la completa interruzione della risposta del nodo.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: in presenza di una capacità di archiviazione prossima alla saturazione (il disco si sta riempiendo), i nodi vengono segnalati come non integri e i pod vengono espulsi dal nodo. I pod su un nodo con un carico elevato sul disco vengono espulsi quando il file system disponibile è inferiore alle soglie di espulsione impostate sul kubelet. Imposta la soglia di allarme in modo da avere abbastanza tempo per reagire prima che il nodo venga espulso dal cluster.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

node_memory_utilization

Dimensioni: ClusterName

Descrizione dell'allarme: questo allarme aiuta a rilevare un elevato utilizzo della memoria nei nodi worker del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di dimensionare il numero di repliche dei pod o ottimizzare l'applicazione.

Scopo: questo allarme aiuta a monitorare l'utilizzo della memoria dei nodi worker nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Dimensioni:ClusterName, Namespace, Service

Descrizione dell'allarme: questo allarme aiuta a rilevare un elevato utilizzo della CPU nei pod del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di aumentare il limite di CPU per il pod interessato.

Scopo: questo allarme aiuta a monitorare l'utilizzo della CPU dei pod appartenenti a un servizio Kubernetes nel cluster EKS, in modo da poter identificare rapidamente se il pod di un servizio sta utilizzando più CPU del previsto.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensioni:ClusterName, Namespace, Service

Descrizione dell'allarme: questo allarme aiuta a rilevare un elevato utilizzo della memoria nei pod del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di aumentare il limite di memoria per il pod interessato.

Scopo: questo allarme aiuta a monitorare l'utilizzo della memoria dei pod nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.

Statistica: Maximum

Soglia raccomandata: 80,0

Giustificazione della soglia: si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon Kinesis Data Streams

GetRecords.IteratorAgeMilliseconds

Dimensioni: StreamName

Descrizione dell'allarme: questo allarme può rilevare se l'età massima dell'iteratore è troppo alta. Per le applicazioni di elaborazione dei dati in tempo reale, configura la conservazione dei dati in base alla tolleranza del ritardo. Di solito si tratta di pochi minuti. Per le applicazioni che elaborano dati storici, utilizza questo parametro per monitorare la velocità di recupero dell'arretrato. Una soluzione rapida per arrestare la perdita di dati consiste nell'aumentare il periodo di conservazione durante la risoluzione del problema. Inoltre, è possibile aumentare il numero di worker che elaborano i record nella propria applicazione per consumatori. Le ragioni più comuni dell'incremento graduale dell'età dell'iteratore includono la mancanza di risorse fisiche adeguate o una logica di elaborazione dei record che non è stata dimensionata per gestire un aumento della velocità di trasmissione effettiva del flusso. Consulta questo collegamento per ulteriori dettagli.

Scopo: questo allarme viene utilizzato per rilevare se i dati del flusso stanno per scadere perché conservati troppo a lungo o perché l'elaborazione dei record è troppo lenta. Contribuisce a evitare la perdita di dati dopo aver raggiunto il 100% del tempo di conservazione del flusso.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal periodo di conservazione del flusso e dalla tolleranza del ritardo di elaborazione per i record. Esamina i requisiti e analizza le tendenze storiche, quindi imposta la soglia sul numero di millisecondi che rappresenta un ritardo di elaborazione critico. Se l'età di un iteratore supera il 50% del periodo di conservazione (per impostazione predefinita, 24 ore, configurabile fino a 365 giorni), esiste il rischio di una perdita di dati a causa della scadenza del record. Puoi monitorare il parametro per assicurarti che nessuna delle partizioni si avvicini mai a questo limite.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

GetRecords.Successo

Dimensioni: StreamName

Descrizione dell'allarme: questo parametro aumenta ogni volta che i consumatori leggono correttamente i dati dal flusso. GetRecords non restituisce alcun dato quando genera un'eccezione. L'eccezione più comune è ProvisionedThroughputExceededException, dovuta al fatto che il tasso di richiesta del flusso è troppo alto o la velocità di trasmissione effettiva disponibile è già utilizzata per il secondo in questione. Riduci la frequenza o le dimensioni delle richieste. Per ulteriori informazioni, consulta la pagina Limits relativa ai flussi nella Guida per gli sviluppatori di Flusso di dati Amazon Kinesis e la pagina Error Retries and Exponential Backoff in AWS.

Scopo: questo allarme è in grado di rilevare se il recupero dei record dal flusso da parte dei consumatori ha esito negativo. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo eventuali problemi relativi all'utilizzo dei dati, ad esempio un aumento dei tassi di errore o un calo dei recuperi riusciti. Ciò consente di intraprendere operazioni tempestive per risolvere potenziali problemi e preservare la fluidità della pipeline di elaborazione dei dati.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: a seconda dell'importanza del recupero dei record dal flusso, imposta la soglia in base alla tolleranza dell'applicazione per i record non riusciti. La soglia deve essere la percentuale corrispondente di operazioni riuscite. È possibile utilizzare i dati GetRecords metrici storici come riferimento per il tasso di errore accettabile. Inoltre, quando si imposta la soglia, è necessario considerare i nuovi tentativi, poiché i record con errori possono essere ritentati. Ciò consente di evitare che i picchi transitori generino avvisi non necessari.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

PutRecord.Successo

Dimensioni: StreamName

Descrizione dell'allarme: questo allarme rileva quando il numero di operazioni PutRecord non riuscite supera la soglia. Esamina i log del produttore di dati per individuare le cause principali degli errori. Il motivo più comune è la velocità di trasmissione effettiva insufficiente assegnata alla partizione che ha causato l'eccezione ProvisionedThroughputExceededException. Ciò accade perché il tasso delle richieste per il flusso è troppo alto o la velocità di trasmissione effettiva con cui si tenta di importare nella partizione è troppo alto. Riduci la frequenza o le dimensioni delle richieste. Per ulteriori informazioni, consulta Streams Limits and Error Retries e Exponential Backoff in. AWS

Scopo: questo allarme può rilevare se l'importazione dei record nel flusso non riesce. Ti aiuta a identificare i problemi nella scrittura dei dati nel flusso. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo eventuali problemi dei produttori nella pubblicazione dei dati nel flusso, come un aumento dei tassi di errore o una diminuzione dei record pubblicati con successo. Ciò consente di intraprendere operazioni tempestive per risolvere potenziali problemi e preservare l'affidabilità del processo di importazione dei dati.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: a seconda dell'importanza dell'importazione e dell'elaborazione dei dati per il servizio, imposta la soglia in base alla tolleranza dell'applicazione per i record non riusciti. La soglia deve essere la percentuale corrispondente di operazioni riuscite. Puoi utilizzare i dati PutRecord metrici storici come riferimento per il tasso di errore accettabile. Inoltre, quando si imposta la soglia, è necessario considerare i nuovi tentativi, poiché i record con errori possono essere ritentati.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Dimensioni: StreamName

Descrizione dell'allarme: questo allarme rileva quando il numero di errori PutRecords supera la soglia. Flusso di dati Kinesis tenta di elaborare tutti i record in ogni richiesta PutRecords, ma l'errore di un singolo record non interrompe l'elaborazione di quelli successivi. Il motivo principale di questi errori è il superamento della velocità di trasmissione effettiva di un flusso o di una singola partizione. Le cause più comuni sono i picchi di traffico e le latenze di rete che causano l'arrivo dei record al flusso in modo non uniforme. È necessario rilevare i record non elaborati correttamente e ritentarli nella chiamata successiva. Per ulteriori dettagli, fare riferimento a Gestione degli errori durante PutRecords l'utilizzo.

Scopo: questo allarme può rilevare errori costanti quando si utilizza l'operazione in batch per inviare i record al flusso. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo un aumento dei record non riusciti, al fine di intraprendere operazioni tempestive per risolvere i problemi sottostanti e garantire un processo di importazione dei dati fluido e affidabile.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia sul numero di record non riusciti che riflette la tolleranza dell'applicazione per i record non riusciti. È possibile utilizzare i dati storici come indicazione per il valore di errore accettabile. È inoltre necessario considerare i nuovi tentativi quando si imposta la soglia, poiché i record non riusciti possono essere riprovati nelle chiamate successive. PutRecords

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Dimensioni: StreamName

Descrizione dell'allarme: l'allarme tiene traccia del numero di record che determinano una limitazione della larghezza di banda della rete della capacità effettiva di trasmissione in lettura. Se noti che la larghezza di banda della rete viene continuamente limitata, dovresti prendere in considerazione l'aggiunta di altre partizioni al flusso per aumentare la velocità di trasmissione effettiva di lettura assegnata. Se nel flusso è in esecuzione più di un'applicazione consumatore che condivide il limite GetRecords, ti consigliamo di registrare le nuove applicazioni consumatori tramite il fan-out avanzato. Se l'aggiunta di altre partizioni non riduce il numero di limitazioni della larghezza di banda della rete, è possibile che una partizione "calda" riceva più letture rispetto alle altre partizioni. Abilita il monitoraggio avanzato, individua la partizione "calda" e suddividila.

Scopo: questo allarme è in grado di rilevare se la larghezza di banda della rete dei consumatori viene limitata quando i consumatori stessi superano la velocità di trasmissione effettiva di lettura assegnata (determinata dal numero di partizioni di cui disponi). In tal caso, non sarai in grado di leggere dal flusso e potrà essere avviato il backup del flusso.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: in genere le richieste sottoposte a limitazione della larghezza di banda della rete possono essere ritentate, quindi l'impostazione della soglia su zero rende l'allarme troppo sensibile. Tuttavia, la continua limitazione della larghezza di banda della rete può influire sulla lettura dal flusso e far scattare l'allarme. Imposta la soglia su una percentuale in base alle richieste sottoposte a limitazioni della larghezza di banda della rete per l'applicazione e ritenta le configurazioni.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Dimensioni:StreamName, ConsumerName

Descrizione dell'allarme: questo allarme rileva quando il ritardo di elaborazione dei record nell'applicazione supera la soglia. Problemi transitori, come i malfunzionamenti delle API di un'applicazione a valle, possono causare un aumento improvviso del parametro. È necessario indagare se si verificano costantemente. Una causa comune è che il consumatore non elabora i record con una velocità sufficiente a causa delle risorse fisiche insufficienti o della logica di elaborazione dei record che non si è dimensionata all'aumento della velocità di trasmissione effettiva. Il blocco delle chiamate nel percorso critico è spesso causa di rallentamenti nell'elaborazione dei record. È possibile aumentare il parallelismo aumentando il numero di partizioni. Inoltre, è necessario verificare che i nodi di elaborazione sottostanti dispongano di risorse fisiche sufficienti durante i picchi di domanda.

Scopo: questo allarme può rilevare un ritardo nell'abbonamento all'evento di partizione del flusso. Ciò indica un ritardo di elaborazione e può contribuire a identificare potenziali problemi con le prestazioni dell'applicazione consumatore o l'integrità generale del flusso. Quando il ritardo di elaborazione diventa significativo, è necessario analizzare e risolvere eventuali colli di bottiglia o inefficienze delle applicazioni consumatore per garantire l'elaborazione dei dati in tempo reale e ridurre al minimo il backlog dei dati.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal ritardo che l'applicazione è in grado di tollerare. Esamina i requisiti dell'applicazione e analizza le tendenze storiche, quindi seleziona una soglia di conseguenza. Quando la SubscribeToShard chiamata ha esito positivo, l'utente inizia a ricevere SubscribeToShardEvent eventi tramite la connessione persistente per un massimo di 5 minuti, dopodiché è necessario chiamare SubscribeToShard nuovamente per rinnovare l'abbonamento se si desidera continuare a ricevere registrazioni.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Dimensioni: StreamName

Descrizione dell'allarme: questo allarme rileva quando il numero di record con conseguente limitazione della larghezza di banda della rete della capacità effettiva di trasmissione di scrittura ha raggiunto la soglia. Quando superano la velocità di trasmissione effettiva di scrittura assegnata (determinata dal numero di partizioni di cui disponi), i produttori vengono sottoposti a limitazione della larghezza di banda della rete e non sarà possibile inviare record al flusso. Per ovviare alla continua limitazione della larghezza di banda della rete, dovresti prendere in considerazione l'aggiunta di partizioni al flusso. Ciò aumenta la velocità di trasmissione effettiva di scrittura assegnata e previene future limitazioni della larghezza di banda della rete. Inoltre, è necessario prendere in considerazione la scelta della chiave di partizione quando si importano i record. La chiave di partizione casuale è preferita perché distribuisce i record in modo uniforme tra le partizioni del flusso, quando possibile.

Scopo: questo allarme può rilevare se ai produttori viene rifiutata la scrittura dei record a causa della limitazione della larghezza di banda della rete del flusso o della partizione. Se il flusso è in modalità assegnata, l'impostazione di questo allarme consente di intervenire in modo proattivo quando il flusso di dati raggiunge i limiti, ottimizzando la capacità fornita o adottando le operazioni di dimensionamento appropriate per evitare la perdita di dati e garantire un'elaborazione dei dati fluida.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: in genere le richieste sottoposte a limitazione della larghezza di banda della rete possono essere ritentate, quindi l'impostazione della soglia su zero rende l'allarme troppo sensibile. Tuttavia, una continua limitazione della larghezza di banda della rete può influire sulla scrittura nel flusso ed è necessario impostare una soglia di allarme per rilevarla. Imposta la soglia su una percentuale in base alle richieste sottoposte a limitazioni della larghezza di banda della rete per l'applicazione e ritenta le configurazioni.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Lambda

ClaimedAccountConcurrency

Dimensions: nessuna

Descrizione dell'allarme: questo allarme aiuta a monitorare se la concorrenza delle funzioni Lambda si avvicina al limite di concorrenza a livello di regione del tuo account. La larghezza di banda della rete di una funzione inizia a essere limitata se raggiunge il limite di simultaneità. È possibile eseguire le seguenti operazioni per evitare la limitazione della larghezza di banda della rete.

1. Richiedi un aumento simultaneo della concorrenza in questa regione.

2. Identifica e riduci qualsiasi concorrenza riservata o accantonata non utilizzata.

3. Identifica i problemi di prestazioni nelle funzioni per migliorare la velocità di elaborazione e quindi migliorare la produttività.

4. Aumentate la dimensione del batch delle funzioni, in modo che vengano elaborati più messaggi a ogni chiamata di funzione.

Intento: questo allarme può rilevare in modo proattivo se la concorrenza delle funzioni Lambda si avvicina alla quota di concorrenza a livello regionale del tuo account, in modo che tu possa agire di conseguenza. Le funzioni vengono limitate se viene raggiunta la quota di concorrenza a livello regionale dell'account. ClaimedAccountConcurrency Se si utilizza Reserved Concurrency (RC) o Provisioned Concurrency (PC), questo allarme offre una maggiore visibilità sull'utilizzo della concorrenza rispetto a un allarme attivo. ConcurrentExecutions

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare il valore di circa il 90% della quota di concorrenza impostata per l'account nella regione e utilizzare il risultato come valore di soglia. Per impostazione predefinita, l'account ha un limite di simultaneità pari a 1.000 per tutte le funzioni in una regione. Tuttavia, dovresti controllare la quota del tuo account dalla dashboard di Service Quotas.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

Errori

Dimensioni: FunctionName

Descrizione dell'allarme: questo allarme rileva un numero elevato di errori. Gli errori includono eccezioni generate dal codice e eccezioni generate dal runtime Lambda. È possibile controllare i log relativi alla funzione per diagnosticare il problema.

Scopo: l'allarme aiuta a rilevare un numero elevato di errori nelle invocazioni di funzioni.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia su un numero maggiore di zero. Il valore esatto può dipendere dalla tolleranza agli errori nell'applicazione. Comprendi la criticità delle chiamate gestite dalla funzione. Per alcune applicazioni, qualsiasi errore potrebbe essere inaccettabile, mentre altre applicazioni potrebbero consentire un certo margine di errore.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: GREATER_THAN_THRESHOLD

Throttles

Dimensioni: FunctionName

Descrizione dell'allarme: questo allarme rileva un numero elevato di richieste di invocazione sottoposte a limitazione della larghezza di banda della rete. La limitazione della larghezza di banda della rete si verifica quando non è disponibile simultaneità per l'aumento. Esistono diversi approcci per risolvere il problema. 1) Richiedi un aumento simultaneo all' AWS assistenza in questa regione. 2) Identificare i problemi di prestazioni della funzione per migliorare la velocità di elaborazione e di conseguenza la velocità di trasmissione effettiva. 3) Aumentare la dimensione del batch della funzione, in modo che a ogni invocazione della funzione vengano elaborati più messaggi.

Scopo: l'allarme aiuta a rilevare un numero elevato di richieste di invocazione con limitazione della larghezza di banda della rete per una funzione Lambda. È importante sapere se le richieste vengono costantemente rifiutate a causa della limitazione della larghezza di banda della rete e se è necessario migliorare le prestazioni della funzione Lambda o aumentare la capacità di simultaneità per evitare la limitazione costante.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia su un numero maggiore di zero. Il valore esatto della soglia può dipendere dalla tolleranza dell'applicazione. Imposta la soglia in base all'utilizzo e ai requisiti di dimensionamento della funzione.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Duration (Durata)

Dimensioni: FunctionName

Descrizione dell'allarme: questo allarme rileva tempi di elaborazione di un evento prolungati da parte di una funzione Lambda. Durate significative potrebbero essere dovute a modifiche nel codice della funzione che rendono più lunga l'esecuzione della funzione o delle rispettive dipendenze.

Scopo: questo allarme può rilevare una lunga durata di esecuzione di una funzione Lambda. Un'elevata durata di runtime indica che una funzione impiega più tempo per l'invocazione e può anche influire sulla capacità di chiamata simultanea nel caso in cui Lambda stia gestendo un numero maggiore di eventi. È fondamentale sapere se la funzione Lambda richiede costantemente tempi di esecuzione più lunghi del previsto.

Statistica: p90

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: la soglia per la durata dipende dall'applicazione e dai carichi di lavoro e dai requisiti di prestazioni. Per requisiti di prestazione elevati, imposta la soglia su un periodo di tempo più breve per verificare se la funzione soddisfa le aspettative. Puoi anche analizzare i dati storici dei parametri di durata per vedere se il tempo impiegato corrisponde alle aspettative di prestazioni della funzione e impostare la soglia su un periodo più lungo rispetto alla media storica. Assicurati di impostare la soglia al di sotto del timeout della funzione configurata.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

ConcurrentExecutions

Dimensioni: FunctionName

Descrizione dell'allarme: questo allarme aiuta a monitorare se la simultaneità della funzione si avvicina al limite di simultaneità a livello regionale dell'account. La larghezza di banda della rete di una funzione inizia a essere limitata se raggiunge il limite di simultaneità. È possibile eseguire le seguenti operazioni per evitare la limitazione della larghezza di banda della rete.

1. Richiedi un aumento concomitante in questa regione.

2. Identifica i problemi di prestazioni nelle funzioni per migliorare la velocità di elaborazione e quindi migliorare la produttività.

3. Aumentate la dimensione del batch delle funzioni, in modo che vengano elaborati più messaggi a ogni chiamata di funzione.

Per ottenere una migliore visibilità sulla concorrenza riservata e sull'utilizzo della concorrenza fornita, imposta invece un allarme sulla nuova metrica. ClaimedAccountConcurrency

Scopo: questo allarme può rilevare in modo proattivo se la simultaneità della funzione si avvicina alla quota di simultaneità a livello di regione per l'account, in modo che tu possa agire di conseguenza. La larghezza di banda della rete di una funzione viene limitata se raggiunge la quota di simultaneità a livello di regione per l'account.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia su circa il 90% della quota di simultaneità impostata per l'account nella regione. Per impostazione predefinita, l'account ha un limite di simultaneità pari a 1.000 per tutte le funzioni in una regione. Tuttavia, puoi verificare la quota del tuo account, in quanto può essere aumentata contattando l'assistenza. AWS

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

Lambda Insights

Come best practice, consigliamo di attivare allarmi basati sui seguenti parametri di Lambda Insights.

memory_utilization

Dimensioni: function_name

Descrizione dell'allarme: questo allarme viene utilizzato per rilevare se l'utilizzo della memoria di una funzione Lambda si avvicina al limite configurato. Per risolvere il problema, puoi provare a: 1) Ottimizzare il codice. 2) Dimensionare correttamente l'allocazione di memoria stimando accuratamente i requisiti di memoria. A tale scopo, puoi fare riferimento a Lambda Power Tuning. 3) Utilizzare il pooling delle connessioni. Per il pooling delle connessioni per i database RDS, consulta la pagina Using Amazon RDS Proxy with Lambda. 4) Puoi anche prendere in considerazione la possibilità di progettare le tue funzioni per evitare di archiviare grandi quantità di dati in memoria tra un'invocazione e l'altra.

Scopo: questo allarme viene utilizzato per rilevare se l'utilizzo della memoria per la funzione Lambda si avvicina al limite configurato.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: imposta la soglia al 90% per ricevere un avviso quando l'utilizzo della memoria supera il 90% della memoria allocata. Se l'utilizzo della memoria da parte del carico di lavoro rappresenta un fattore critico, è possibile impostarla su un valore inferiore. È inoltre possibile controllare i dati storici per questo parametro e impostare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

ComparisonOperator: GREATER_THAN_THRESHOLD

Amazon VPC (AWS/NATGateway)

ErrorPortAllocation

Dimensioni: NatGatewayId

Descrizione dell'allarme: questo allarme aiuta a rilevare quando il gateway NAT non è in grado di allocare le porte a nuove connessioni. Per risolvere questo problema, consulta la pagina Resolve port allocation errors on NAT Gateway.

Scopo: questo allarme viene utilizzato per rilevare se il gateway NAT non è in grado di allocare una porta di origine.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: se il valore di ErrorPortAllocation è maggiore di zero, significa che tramite NatGateway sono aperte troppe connessioni simultanee verso una singola destinazione popolare.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

PacketsDropCount

Dimensioni: NatGatewayId

Descrizione dell'allarme: questo allarme aiuta a rilevare quando i pacchetti vengono eliminati dal Gateway NAT. Ciò potrebbe accadere a causa di un problema con NAT Gateway, quindi controllate lo stato di AWS NAT Gateway nella vostra regione nel pannello di controllo dello stato del AWS servizio. Questo può aiutarti a stabilire un collegamento con il problema di rete relativo al traffico che utilizza il gateway NAT.

Scopo: questo allarme viene utilizzato per rilevare se i pacchetti vengono eliminati dal gateway NAT.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare il valore dello 0,01% del traffico totale sul gateway NAT e utilizzare tale risultato come valore di soglia. Utilizza i dati storici del traffico sul gateway NAT per stabilire la soglia.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

AWS Link privato () AWS/PrivateLinkEndpoints

PacketsDropped

Dimensioni: ID VPC, ID endpoint VPC, tipo di endpoint, ID sottorete, nome del servizio

Descrizione dell'allarme: questo allarme aiuta a rilevare se l'endpoint o il servizio endpoint non è integro monitorando il numero di pacchetti rilasciati dall'endpoint. I pacchetti con dimensioni superiori a 8.500 byte che arrivano all'endpoint VPC vengono eliminati. Per la risoluzione dei problemi, consulta la pagina Connectivity problems between an interface VPC endpoint and an endpoint service.

Scopo: questo allarme viene utilizzato per rilevare se l'endpoint o il servizio endpoint non è integro.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base al caso d'uso. Per essere consapevole dello stato di non integrità dell'endpoint o del servizio endpoint, dovresti impostare la soglia su un valore basso in modo da avere la possibilità di risolvere il problema prima che si verifichi un'enorme perdita di dati. È possibile utilizzare i dati storici per comprendere la tolleranza in caso di perdita di pacchetti e impostare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

AWS Link privato (AWS/PrivateLinkServices)

RstPacketsSent

Dimensioni: ID servizio, ARN sistema di bilanciamento del carico, AZ

Descrizione dell'allarme: questo allarme consente di rilevare gli obiettivi non integri di un servizio endpoint in base al numero di pacchetti di ripristino inviati agli endpoint. Quando esegui il debug degli errori di connessione con un utente del tuo servizio, puoi verificare se il servizio sta ripristinando le connessioni con la RstPacketsSent metrica o se qualcos'altro non funziona sul percorso di rete.

Scopo: questo allarme viene utilizzato per rilevare gli obiettivi non integri di un servizio endpoint.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: a soglia dipende dal caso d'uso. Se il tuo caso d'uso può tollerare obiettivi non integri, puoi impostare la soglia su un valore alto. Se il caso d'uso non è in grado di tollerare obiettivi non integri, puoi impostare la soglia su un valore molto basso.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon RDS

CPUUtilization

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare un utilizzo costantemente elevato della CPU. L'utilizzo della CPU misura il tempo di non inattività. Prendi in considerazione l'utilizzo di Enhanced Monitoring o Performance Insights per verificare quale tempo di attesa consuma la maggior parte del tempo della CPU (guest, irq, wait, nice e così via) per MariaDB, MySQL, Oracle e PostgreSQL. Quindi valuta quali query consumano la maggiore quantità di CPU. Se non riesci a ottimizzare il carico di lavoro, valuta la possibilità di passare a una classe di istanze database più ampia.

Intento: questo allarme viene utilizzato per rilevare un utilizzo elevato e costante della CPU al fine di evitare tempi di risposta e timeout molto elevati. Se si desidera verificare il micro-bursting dell'utilizzo della CPU, è possibile impostare un tempo inferiore di valutazione degli allarmi.

Statistica: Average

Soglia raccomandata: 90,0

Giustificazione della soglia: i picchi casuali nel consumo di CPU potrebbero non influire sulle prestazioni del database, ma un utilizzo elevato e prolungato della CPU può ostacolare le richieste del database in arrivo. A seconda del carico di lavoro complessivo del database, una CPU elevata sull'istanza RDS/Aurora può ridurre le prestazioni complessive.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

DatabaseConnections

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme rileva un numero elevato di connessioni. Controlla le connessioni esistenti e interrompi quelle che sono in stato di “sospensione” o che non sono chiuse correttamente. Prendi in considerazione l'uso del pool di connessioni per limitare il numero di nuove connessioni. In alternativa, aumenta la dimensione dell'istanza database per utilizzare una classe con più memoria e quindi un valore predefinito più alto per “max_connections” oppure aumenta il valore “max_connections” in RDS e Aurora MySQL e PostgreSQL per la classe corrente se può supportare il tuo carico di lavoro.

Intento: questo allarme viene utilizzato per prevenire il rifiuto delle connessioni quando viene raggiunto il numero massimo di connessioni DB. Questo allarme non è consigliato nel caso in cui si cambi frequentemente la classe dell'istanza database, poiché così facendo si modificano la memoria e il numero massimo predefinito di connessioni.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il numero di connessioni consentite dipende dalla dimensione della classe dell'istanza database e dai parametri specifici del motore di database relativi a processi/connessioni. È necessario calcolare un valore compreso tra il 90 e il 95% del numero massimo di connessioni per il database e utilizzare tale risultato come valore di soglia.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

EBS% ByteBalance

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una bassa percentuale di crediti della velocità di trasmissione effettiva rimanenti. Per la risoluzione dei problemi, controlla i problemi di latenza in RDS.

Intento: questo allarme è utilizzato per rilevare una bassa percentuale di crediti della velocità di trasmissione effettiva rimanenti nel burst bucket. Una bassa percentuale di saldo byte può causare problemi di velocità di trasmissione effettiva. Questo allarme non è consigliato per le istanze Aurora PostgreSQL.

Statistica: Average

Soglia raccomandata: 10,0

Giustificazione della soglia: un saldo a credito della velocità di trasmissione effettiva inferiore al 10% è considerato insufficiente ed è necessario impostare la soglia di conseguenza. È anche possibile impostare una soglia inferiore se l'applicazione è in grado di tollerare una velocità di trasmissione effettiva inferiore per il carico di lavoro.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: LESS_THAN_THRESHOLD

EBSIOBalance%

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una bassa percentuale di crediti IOPS rimanenti. Per la risoluzione dei problemi, consulta i problemi di latenza in RDS.

Intento: questo allarme è utilizzato per rilevare una bassa percentuale di crediti I/O rimanenti nel burst bucket. Una bassa percentuale di saldo IOPS può causare problemi di colli di bottiglia. Questo allarme non è consigliato per le istanze Aurora.

Statistica: Average

Soglia raccomandata: 10,0

Giustificazione della soglia: un saldo a credito IOPS inferiore al 10% è considerato insufficiente ed è possibile impostare la soglia di conseguenza. È anche possibile impostare una soglia inferiore, se l'applicazione è in grado di tollerare IOPS inferiore per il carico di lavoro.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: LESS_THAN_THRESHOLD

FreeableMemory

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una scarsa memoria liberabile, il che può indicare un picco nelle connessioni al database o che l'istanza potrebbe essere sottoposta a un'elevata pressione di memoria. Controlla la pressione della memoria monitorando le CloudWatch metriche relative SwapUsage a `in aggiunta a. FreeableMemory Se il consumo di memoria dell'istanza è spesso troppo elevato, è necessario controllare il carico di lavoro o aggiornare la classe di istanza. Per un'istanza database di lettura Aurora, valuta la possibilità di aggiungere più istanze database di lettura al cluster. Per ulteriori informazioni sulla risoluzione dei problemi di Aurora, consulta i problemi di memoria liberabile.

Intento: questo allarme viene utilizzato per evitare l'esaurimento della memoria, che può causare il rifiuto delle connessioni.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: a seconda del carico di lavoro e della classe di istanza, possono essere appropriati diversi valori per la soglia. Idealmente, la memoria disponibile non dovrebbe scendere al di sotto del 25% della memoria totale per periodi prolungati. Per Aurora, puoi impostare la soglia vicino al 5%, poiché un parametro vicino a 0 indica che l'istanza database ha eseguito il dimensionamento al valore massimo possibile. È possibile analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: LESS_THAN_THRESHOLD

FreeLocalStorage

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare uno scarso spazio di archiviazione locale. Aurora edizione compatibile con PostgreSQL utilizza l'archiviazione locale per memorizzare i log degli errori e i file temporanei. Aurora MySQL utilizza l'archiviazione locale per archiviare i log degli errori, i log generali, i log delle query lente, i log di audit e le tabelle temporanee non InnoDB. Questi volumi di archiviazione locale sono supportati da Amazon EBS Store e possono essere estesi utilizzando una classe di istanza database più grande. Per la risoluzione dei problemi, verifica Aurora edizione compatibile con PostgreSQL ed edizione compatibile con MySQL.

Intento: questo allarme viene utilizzato per rilevare quanto manca all'istanza di database Aurora per raggiungere il limite di archiviazione locale, se non si usa Aurora Serverless v2 o versione successiva. L'archiviazione locale può raggiungere il limite di capacità quando si archiviano dati non persistenti, come tabelle e file di log temporanei, nella memoria locale. Questo allarme può prevenire un out-of-space errore che si verifica quando l'istanza DB esaurisce lo spazio di archiviazione locale.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare circa il 10%-20% dello spazio di archiviazione disponibile in base alla velocità e all'andamento dell'utilizzo del volume, quindi utilizzare tale risultato come valore di soglia per intervenire in modo proattivo prima che il volume raggiunga il limite.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

FreeStorageSpace

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme rileva una scarsa quantità di spazio di archiviazione disponibile. Se ti avvicini spesso ai limiti di capacità di archiviazione, prendi in considerazione la possibilità di aumentare lo spazio di archiviazione del database. Includi un buffer di memoria per soddisfare gli aumenti imprevisti della domanda delle tue applicazioni. In alternativa, valuta la possibilità di abilitare il dimensionamento automatico dell'archiviazione RDS. Puoi anche valutare la possibilità di liberare più spazio eliminando dati e log obsoleti o inutilizzati. Per ulteriori informazioni, consulta il documento sulla mancanza di spazio per RDS e il documento sui problemi di archiviazione di PostgreSQL.

Intento: questo allarme aiuta a prevenire problemi di esaurimento dell'archiviazione. Può aiutare a prevenire il tempo di inattività che si verifica quando l'istanza di database esaurisce lo spazio di archiviazione. Si sconsiglia di utilizzare questo allarme se è abilitato il dimensionamento automatico dell'archiviazione o se si modifica frequentemente la capacità di archiviazione dell'istanza di database.

Statistica: Minimum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore della soglia dipenderà dallo spazio di archiviazione attualmente allocato. In genere, è necessario calcolare il 10% dello spazio di archiviazione allocato e utilizzare tale risultato come valore di soglia.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

MaximumUsedTransactionID

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a impedire il wraparound dell'ID delle transazioni per PostgreSQL. Fai riferimento alla procedura di risoluzione dei problemi in questo blog per esaminare e risolvere il problema. Puoi anche fare riferimento a questo blog per acquisire maggiore familiarità con i concetti relativi all'autovacuum, i problemi più comuni e le best practice.

Intento: questo allarme viene utilizzato per impedire il wraparound dell'ID delle transazioni per PostgreSQL.

Statistica: Average

Soglia raccomandata: 1,0E9

Giustificazione della soglia: l'impostazione di questa soglia a 1 miliardo dovrebbe darti il tempo di esaminare il problema. Il valore predefinito di autovacuum_freeze_max_age è 200 milioni. Se l'età della transazione più vecchia è 1 miliardo, l'autovacuum ha problemi a mantenere questa soglia al di sotto dell'obiettivo di 200 milioni di ID di transazione.

Periodo: 60

Punti dati su cui attivare allarmi: 1

Periodi di valutazione: 1

Operatore di confronto: GREATER_THAN_THRESHOLD

ReadLatency

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una latenza di lettura elevata. Se la latenza dell'archiviazione è elevata, il carico di lavoro supera i limiti delle risorse. È possibile esaminare l'utilizzo dell'I/O in relazione alla configurazione dell'istanza e dell'archiviazione allocata. Fai riferimento alla risoluzione dei problemi di latenza dei volumi Amazon EBS causata da un collo di bottiglia IOPS. Per Aurora, puoi passare a una classe di istanza con una configurazione di archiviazione con ottimizzazione per I/O. Per informazioni, consulta Pianificazione dell'I/O in Aurora.

Intento: questo allarme viene utilizzato per rilevare una latenza di lettura elevata. I dischi del database hanno normalmente una bassa latenza di lettura/scrittura, ma possono presentare problemi che causano operazioni a latenza elevata.

Statistica: p90

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Le latenze di lettura superiori a 20 millisecondi richiedono probabilmente un'analisi. È inoltre possibile impostare una soglia più alta se l'applicazione può avere una latenza più elevata per le operazioni di lettura. Esamina la criticità e i requisiti della latenza di lettura e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

ReplicaLag

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme ti aiuta a capire il numero di secondi di ritardo di una replica di lettura rispetto all'istanza principale. Una replica di lettura PostgreSQL segnala un ritardo di replica fino a cinque minuti se non ci sono transazioni di utenti sull'istanza database di origine. Quando la ReplicaLag metrica raggiunge 0, la replica ha raggiunto l'istanza DB principale. Se la ReplicaLag metrica restituisce -1, la replica non è attualmente attiva. Per indicazioni relative a RDS PostgreSQL, consulta le migliori pratiche di replica e per ReplicaLag la risoluzione dei problemi e gli errori correlati, consulta Risoluzione dei problemi. ReplicaLag

Intento: questo allarme è in grado di rilevare il ritardo di replica che riflette la perdita di dati che potrebbe verificarsi in caso di errore dell'istanza principale. Se la replica è troppo indietro rispetto alla principale e la principale riscontra errori, alla replica mancheranno i dati presenti nell'istanza principale.

Statistica: Maximum

Soglia raccomandata: 60,0

Giustificazione della soglia: in genere, il ritardo accettabile dipende dall'applicazione. Si consiglia di non superare i 60 secondi.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: GREATER_THAN_THRESHOLD

WriteLatency

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una latenza di scrittura elevata. Se la latenza dell'archiviazione è elevata, il carico di lavoro supera i limiti delle risorse. È possibile esaminare l'utilizzo dell'I/O in relazione alla configurazione dell'istanza e dell'archiviazione allocata. Fai riferimento alla risoluzione dei problemi di latenza dei volumi Amazon EBS causata da un collo di bottiglia IOPS. Per Aurora, puoi passare a una classe di istanza con una configurazione di archiviazione con ottimizzazione per I/O. Per informazioni, consulta Pianificazione dell'I/O in Aurora.

Intento: questo allarme viene utilizzato per rilevare una latenza di scrittura elevata. Sebbene i dischi del database abbiano in genere una bassa latenza di lettura/scrittura, possono presentare problemi che causano operazioni a latenza elevata. Il monitoraggio della latenza di scrittura garantirà che la latenza del disco sia bassa come previsto.

Statistica: p90

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Le latenze di scrittura superiori a 20 millisecondi richiedono probabilmente un'analisi. È inoltre possibile impostare una soglia più alta se l'applicazione può avere una latenza più elevata per le operazioni di scrittura. Esamina la criticità e i requisiti della latenza di scrittura e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

DBLoad

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare un carico del database elevato. Se il numero di processi supera il numero di vCPUs, i processi vengono messi in coda. Quando la coda aumenta, le prestazioni diminuiscono. Se il carico è spesso sopra la vCPU massima e lo stato di attesa primario è CPU, la CPU è sovraccarica. In questo caso, puoi monitorare CPUUtilization, DBLoadCPU e attività in coda in Performance Insights/Enhanced Monitoring. Si potrebbero limitare le connessioni all'istanza, ottimizzare le eventuali query SQL con un elevato carico CPU o valutare la possibilità di una classe istanza di maggiori dimensioni. Istanze elevate e costanti di qualsiasi stato di attesa indicano che possono verificarsi colli di bottiglia o problemi di conflitto delle risorse da risolvere.

Scopo: questo allarme viene utilizzato per rilevare un elevato carico del database. Un carico del database elevato può causare problemi di prestazioni nell'istanza di database. Questo allarme non è applicabile alle istanze di database serverless.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore vCPU massimo è determinato dal numero di core vCPU (CPU virtuale) per l'istanza database. A seconda della vCPU massima, possono essere appropriati valori diversi per la soglia. Idealmente, il carico del database non dovrebbe superare la linea vCPU.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Dimensioni: DB ClusterIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare uno scarso livello di volume totale residuo. Quando il volume totale rimasto raggiunge il limite di dimensione, il cluster segnala un out-of-space errore. L'archiviazione di Aurora viene automaticamente dimensionata con i dati del volume cluster e si espande fino a 128 TiB o 64 TiB a seconda della versione del motore del database. Valuta la possibilità di eliminare le tabelle e i database che non sono più necessari. Per ulteriori informazioni, controlla il dimensionamento dell'archiviazione.

Intento: questo allarme viene utilizzato per rilevare quanto manca al cluster Aurora per raggiungere il limite delle dimensioni del volume. Questo allarme può prevenire un out-of-space errore che si verifica quando lo spazio del cluster si esaurisce. Questo allarme è consigliato solo per Aurora MySQL.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare il 10%-20% del limite delle dimensioni corrente in base alla velocità e all'andamento dell'aumento dell'utilizzo del volume, quindi usare tale risultato come valore di soglia per intervenire in modo proattivo prima che il volume raggiunga il limite.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensioni: DBClusterIdentifier, role=Writer

Descrizione dell'allarme: questo allarme aiuta a monitorare lo stato di errore della replica dell'istanza di scrittura di Aurora. Per ulteriori informazioni, consulta Replica dei cluster DB Aurora MySQL tra le regioni. AWS Per la risoluzione dei problemi, consulta i roblemi di replica di Aurora MySQL.

Intento: questo allarme viene utilizzato per rilevare se l'istanza di scrittura è in uno stato di errore e non è in grado di replicare l'origine. Questo allarme è consigliato solo per Aurora MySQL.

Statistica: Average

Soglia raccomandata: -1,0

Giustificazione della soglia: si consiglia di utilizzare -1 come valore di soglia perché Aurora MySQL pubblica questo valore se la replica è in uno stato di errore.

Periodo: 60

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare un elevato numero di transazioni bloccate in un'istanza di database Aurora. Le transazioni bloccate possono terminare con un rollback o un commit. L'elevata simultaneità, le transazioni inattive o le transazioni di lunga durata possono portare al blocco delle transazioni. Per la risoluzione dei problemi, consulta la documentazione di Aurora MySQL.

Intento: questo allarme viene utilizzato per rilevare un numero elevato di transazioni bloccate in un'istanza di database Aurora al fine di prevenire i rollback delle transazioni e il peggioramento delle prestazioni.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare il 5% di tutte le transazioni dell'istanza utilizzando il parametro ActiveTransactions e utilizzare tale risultato come valore di soglia. Puoi anche esaminare la criticità e i requisiti delle transazioni bloccate e analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme consente di monitorare un rapporto di riscontri nella cache costantemente basso del cluster Aurora. Una percentuale di riscontri bassa indica che le query su questa istanza database vengono spesso trasferite su disco. Per la risoluzione del problemi, esamina il carico di lavoro per vedere quali query causano questo comportamento e controlla il documento Suggerimenti relativi alla RAM per un'istanza di database.

Intento: questo allarme viene utilizzato per rilevare un rapporto di riscontri nella cache costantemente basso al fine di prevenire una riduzione sostenuta delle prestazioni nell'istanza Aurora.

Statistica: Average

Soglia raccomandata: 80,0

Giustificazione della soglia: è possibile impostare la soglia per la percentuale di riscontri nella cache del buffer all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili.

Periodo: 60

Punti dati su cui attivare allarmi: 10

Periodi di valutazione: 10

Operatore di confronto: LESS_THAN_THRESHOLD

EngineUptime

Dimensioni: DBClusterIdentifier, Role=Writer

Descrizione dell'allarme: questo allarme aiuta a monitorare tempi di inattività ridotti dell'istanza database di scrittura. L'istanza database di scrittura può interrompersi a causa di un riavvio, una manutenzione, un aggiornamento o un failover. Se l'uptime raggiunge 0 a causa di un failover nel cluster e il cluster ha una o più repliche Aurora, una replica Aurora Replica viene promossa all'istanza di scrittura principale durante un evento di errore. Per aumentare la disponibilità del cluster database, valuta la possibilità di creare almeno una o più repliche Aurora in due o più due zone di disponibilità. Per ulteriori informazioni, controlla i fattori che influenzano i tempi di inattività di Aurora.

Intento: questo allarme viene utilizzato per rilevare se l'istanza database di scrittura di Aurora è in fase di inattività. In questo modo è possibile evitare errori di lunga durata nell'istanza di scrittura dovuti a un arresto anomalo o a un failover.

Statistica: Average

Soglia raccomandata: 0,0

Giustificazione della soglia: un evento di errore ha come conseguenza una breve interruzione, durante la quale le operazioni di lettura e scrittura falliscono con un'eccezione. Tuttavia, il servizio viene in genere ripristinato in meno di 60 secondi e spesso in meno di 30 secondi.

Periodo: 60

Punti dati su cui attivare allarmi: 2

Periodi di valutazione: 2

Operatore di confronto: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Dimensioni: DB InstanceIdentifier

Descrizione dell'allarme: questo allarme aiuta a monitorare una costante elevata lunghezza della cronologia dei segmenti di rollback di un'istanza Aurora. Una lunghezza dell'elenco della cronologia di InnoDB elevata indica che un grande numero di precedenti versioni di riga, la chiusura delle query e l'arresto del database sono diventati più lenti. Per ulteriori informazioni e risoluzione dei problemi, consulta la documentazione relativa all'aumento significativo della lunghezza dell'elenco della cronologia di InnoDB.

Intento: questo allarme viene utilizzato per rilevare una costante elevata lunghezza della cronologia dei segmenti di rollback. Può aiutarti a impedire un peggioramento sostenuto delle prestazioni e un elevato utilizzo della CPU nell'istanza Aurora. Questo allarme è consigliato solo per Aurora MySQL.

Statistica: Average

Soglia raccomandata: 1000000,0

Giustificazione della soglia: l'impostazione di questa soglia a 1 milione dovrebbe darti il tempo di esaminare il problema. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Dimensioni: DBClusterIdentifier, Role=Writer

Descrizione dell'allarme: questo allarme aiuta a monitorare l'elevata velocità di trasmissione effettiva della rete di archiviazione. Se la velocità di trasmissione effettiva della rete di archiviazione supera la larghezza di banda di rete totale dell'istanza EC2, la latenza di lettura e scrittura può essere elevata e causare un peggioramento delle prestazioni. Puoi controllare il tipo di istanza EC2 dalla Console. AWS Per la risoluzione dei problemi, controlla eventuali modifiche alle latenze di scrittura/lettura e valuta se hai attivato un allarme anche per questo parametro. In tal caso, esamina lo schema del carico di lavoro durante i momenti in cui è stato attivato l'allarme. Questo può aiutarti a capire se puoi ottimizzare il tuo carico di lavoro per ridurre la quantità totale di traffico di rete. Se ciò non è possibile, potresti dover valutare la possibilità di ridimensionare l'istanza.

Intento: questo allarme viene utilizzato per rilevare un'elevata velocità di trasmissione effettiva della rete di archiviazione. Il rilevamento di una elevata velocità di trasmissione effettiva può prevenire perdite di pacchetti di rete e un peggioramento delle prestazioni.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: è necessario calcolare circa l'80%-90% della larghezza di banda della rete totale del tipo di istanza EC2 e quindi utilizzare tale risultato come valore di soglia, in modo da agire proattivamente prima che i pacchetti di rete siano coinvolti. Puoi anche esaminare la criticità e i requisiti della velocità di trasmissione effettiva della rete di archiviazione e analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon Route 53 Public Data Plane

HealthCheckStatus

Dimensioni: HealthCheckId

Descrizione dell'allarme: questo allarme aiuta a rilevare gli endpoint non integri secondo gli strumenti di controllo dello stato. Per comprendere il motivo di un errore che causa uno stato di malfunzionamento, utilizza la scheda Strumenti di controllo dell'integrità nella Console di controllo dell'integrità di Route 53 per visualizzare lo stato di ciascuna regione e l'ultimo errore del controllo dell'integrità. La scheda di stato mostra anche il motivo per cui l'endpoint viene segnalato come non integro. Consulta la procedura per la risoluzione dei problemi.

Scopo: questo allarme utilizza gli strumenti di controllo dell'integrità di Route53 per rilevare endpoint non integri.

Statistica: Average

Soglia raccomandata: 1,0

Giustificazione della soglia: lo stato dell'endpoint è riportato come 1 quando è integro. Tutti i valori inferiori a 1 equivalgono a non integro.

Periodo: 60

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: LESS_THAN_THRESHOLD

Amazon S3

4xxErrors

Dimensioni:BucketName, FilterId

Descrizione dell'allarme: questo allarme contribuisce a segnalare il numero totale di codici di stato di errore 4xx creati in risposta alle richieste dei client. I codici di errore 403 possono indicare una policy IAM errata, mentre i codici di errore 404 possono segnalare, ad esempio, un comportamento errato dell'applicazione client. L'abilitazione temporanea della registrazione degli accessi al server S3 ti aiuterà a individuare l'origine del problema utilizzando i campi Stato HTTP e Codice errore. Per ulteriori informazioni sul codice di errore, consulta la pagina Error Responses.

Scopo: questo allarme viene utilizzato per creare un valore di base per i tassi di errore 4xx tipici, in modo da poter esaminare eventuali anomalie che potrebbero indicare un problema di configurazione.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: la soglia raccomandata consiste nel rilevare se più del 5% del totale delle richieste presenta errori 4XX. È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

5xxErrors

Dimensioni:BucketName, FilterId

Descrizione dell'allarme: questo allarme aiuta a rilevare un numero elevato di errori lato server. Questi errori indicano che un client ha effettuato una richiesta che il server non è riuscito a completare. Questo può aiutarti a stabilire un collegamento con il problema che la tua applicazione sta riscontrando a causa di S3. Per ulteriori informazioni su come gestire o ridurre in modo efficiente gli errori, consulta la pagina Optimizing performance design patterns. Gli errori potrebbero essere causati anche da un problema con S3; controlla lo stato di Amazon S3 nella tua regione nel Pannello di controllo per lo stato dei servizi AWS.

Scopo: questo allarme può aiutare a rilevare se l'applicazione presenta problemi dovuti a errori 5xx.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve 5XXError. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

OperationsFailedReplication

Dimensioni:SourceBucket, DestinationBucket, RuleId

Descrizione dell'allarme: questo allarme aiuta a comprendere un errore di replica. Questo parametro tiene traccia dello stato dei nuovi oggetti replicati utilizzando S3 CRR o S3 SRR così come degli oggetti esistenti replicati utilizzando la replica in batch S3. Per ulteriori dettagli, consulta la sezione Replication troubleshooting.

Scopo: questo allarme viene utilizzato per rilevare se è presente un'operazione di replica non riuscita.

Statistica: Maximum

Soglia raccomandata: 0,0

Giustificazione della soglia: questo parametro emette un valore pari a 0 per le operazioni riuscite e nulla quando non vengono eseguite operazioni di replica per un minuto. Quando il parametro emette un valore maggiore di 0, l'operazione di replica non ha avuto esito positivo.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

S3ObjectLambda

4xxErrors

Dimensioni:AccessPointName, DataSource ARN

Descrizione dell'allarme: questo allarme aiuta a segnalare il numero totale di codici di stato di errore 4xx creati in risposta alle richieste dei client. L'abilitazione temporanea della registrazione degli accessi al server S3 ti aiuterà a individuare l'origine del problema utilizzando i campi Stato HTTP e Codice errore.

Scopo: questo allarme viene utilizzato per creare un valore di base per i tassi di errore 4xx tipici, in modo da poter esaminare eventuali anomalie che potrebbero indicare un problema di configurazione.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve 4XXError. È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

5xxErrors

Dimensioni:AccessPointName, DataSource ARN

Descrizione dell'allarme: questo allarme aiuta a rilevare un numero elevato di errori lato client. Questi errori indicano che un client ha effettuato una richiesta che il server non è riuscito a completare. Questi errori potrebbero essere causati anche da un problema con S3; controlla lo stato di Amazon S3 nella tua regione nel Pannello di controllo per lo stato dei servizi AWS. Questo può aiutarti a stabilire un collegamento con il problema che la tua applicazione sta riscontrando a causa di S3. Per informazioni su come gestire o ridurre in modo efficiente questi errori, consulta la pagina Optimizing performance design patterns.

Scopo: questo allarme può aiutare a rilevare se l'applicazione presenta problemi dovuti a errori 5xx.

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve errori 5XX. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

LambdaResponse4xx

Dimensioni:AccessPointName, DataSource ARN

Descrizione dell'allarme: questo allarme consente di rilevare e diagnosticare gli errori (500) nelle chiamate a S3 Object Lambda. Questi errori possono essere causati da errori o configurazioni errate nella funzione Lambda responsabile della risposta alle richieste. L'analisi dei flussi di CloudWatch log della funzione Lambda associata all'access point Object Lambda può aiutarti a individuare l'origine del problema in base alla risposta di S3 Object Lambda.

Intento: questo allarme viene utilizzato per rilevare gli errori del client 4xx per le chiamate. WriteGetObjectResponse

Statistica: Average

Soglia raccomandata: 0,05

Giustificazione della soglia: consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve 4XXError. È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon SNS

NumberOfMessagesPublished

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme può rilevare quando il numero di messaggi SNS pubblicati è troppo basso. Per la risoluzione dei problemi, controlla perché gli editori inviano una quantità minore di traffico.

Scopo: questo allarme aiuta a monitorare e rilevare in modo proattivo cali significativi nella pubblicazione delle notifiche. Ciò consente di identificare potenziali problemi con l'applicazione o i processi aziendali, in modo da intraprendere le operazioni appropriate per mantenere il flusso di notifiche previsto. È necessario creare questo allarme se si prevede che il sistema debba servire un traffico minimo.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il numero di messaggi pubblicati deve essere in linea con il numero previsto di messaggi pubblicati per l'applicazione. Inoltre, è possibile analizzare i dati storici, le tendenze e il traffico per individuare la soglia giusta.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme può rilevare quando il numero di messaggi SNS consegnati è troppo basso. Ciò potrebbe essere dovuto all'annullamento involontario dell'abbonamento di un endpoint o a un evento SNS che causa un ritardo nei messaggi.

Scopo: questo allarme consente di rilevare un calo del volume dei messaggi consegnati. È necessario creare questo allarme se si prevede che il sistema debba servire un traffico minimo.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il numero di messaggi consegnati deve essere in linea con il numero previsto di messaggi prodotti e il numero di consumatori. Inoltre, è possibile analizzare i dati storici, le tendenze e il traffico per individuare la soglia giusta.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme può rilevare quando il numero di messaggi SNS consegnati è troppo alto. Per risolvere i problemi relativi alle notifiche non riuscite, abilita la registrazione nei registri. CloudWatch L'esame dei log può aiutarti a scoprire quali abbonati non funzionano e i codici di stato che restituiscono.

Scopo: questo allarme ti aiuta a individuare in modo proattivo i problemi relativi alla consegna delle notifiche e a prendere le misure necessarie per risolverli.

Statistica: Sum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dall'impatto delle notifiche non riuscite. Esamina gli SLA forniti agli utenti finali, la tolleranza agli errori e la criticità delle notifiche, analizza i dati storici e seleziona una soglia di conseguenza. Il numero di notifiche non riuscite dovrebbe essere 0 per gli argomenti che hanno solo abbonamenti SQS, Lambda o Firehose.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme aiuta a monitorare e risolvere potenziali problemi con l'editore o gli abbonati. Controlla se un editore pubblica messaggi con attributi non validi o se a un abbonato viene applicato un filtro inappropriato. Puoi anche analizzare CloudWatch i log per individuare la causa principale del problema.

Scopo: l'allarme viene utilizzato per rilevare se i messaggi pubblicati non sono validi o se a un abbonato sono stati applicati filtri inappropriati.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: gli attributi non validi sono quasi sempre un errore dell'editore. Si consiglia di impostare la soglia su 0 perché in un sistema integro non sono previsti attributi non validi.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme aiuta a monitorare e risolvere potenziali problemi con l'editore o gli abbonati. Controlla se un editore pubblica messaggi con corpi dei messaggi non validi o se a un abbonato viene applicato un filtro inappropriato. Puoi anche analizzare CloudWatch i log per individuare la causa principale del problema.

Scopo: l'allarme viene utilizzato per rilevare se i messaggi pubblicati non sono validi o se a un abbonato sono stati applicati filtri inappropriati.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: i corpi dei messaggi non validi sono quasi sempre un errore dell'editore. Si consiglia di impostare la soglia su 0 perché in un sistema integro non sono previsti messaggi non validi.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme aiuta a monitorare il numero di messaggi che vengono spostati in una coda DLQ.

Scopo: l'allarme viene utilizzato per rilevare i messaggi che vengono spostati in una coda DLQ. Ti consigliamo di creare questo allarme quando SNS è abbinato a SQS, Lambda o Firehose.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: in un sistema integro, indipendentemente dal tipo di abbonato, i messaggi non devono essere spostati nella coda DLQ. Ti consigliamo di ricevere una notifica se qualche messaggio finisce nella coda, in modo da poter identificare e risolvere la causa principale e, potenzialmente, reindirizzare i messaggi nella coda DLQ per evitare la perdita di dati.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme aiuta a monitorare i messaggi che non possono essere spostati in una coda DLQ. Controlla se la tua coda DLQ esiste e che sia configurata correttamente. Inoltre, verifica che SNS disponga delle autorizzazioni per accedere alla coda DLQ. Per ulteriori informazioni, consulta la documentazione sulle code DLQ.

Scopo: l'allarme viene utilizzato per rilevare i messaggi che non possono essere spostati in una coda DLQ.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: è quasi sempre un errore se i messaggi non possono essere spostati nella coda DLQ. La soglia raccomandata è 0, il che significa che tutti i messaggi che non vengono elaborati devono essere in grado di raggiungere la coda DLQ quando la coda è stata configurata.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

SMS MonthToDateSpent USD

Dimensioni: TopicName

Descrizione dell'allarme: l'allarme aiuta a controllare se nell'account è disponibile una quota sufficiente per consentire a SNS di consegnare i messaggi. Se raggiungi la quota, SNS non sarà in grado di consegnare messaggi SMS. Per informazioni sull'impostazione della quota di spesa mensile per gli SMS o per informazioni sulla richiesta di un aumento della quota di spesa con AWS, consulta Impostazione delle preferenze per i messaggi SMS.

Scopo: questo allarme viene utilizzato per rilevare se la quota dell'account è sufficiente per garantire la corretta consegna dei tuoi messaggi SMS.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia in base alla quota (limite di spesa dell'account) per l'account. Scegli una soglia che ti informi con sufficiente anticipo del raggiungimento del limite di quota, in modo da avere il tempo di richiedere un aumento.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

SMS SuccessRate

Dimensioni: TopicName

Descrizione dell'allarme: questo allarme aiuta a monitorare il tasso di mancata consegna dei messaggi SMS. Puoi configurare File di log CloudWatch per comprendere la natura dell'errore e agire di conseguenza.

Scopo: questo allarme viene utilizzato per rilevare le mancate consegne di messaggi SMS.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: imposta la soglia per l'allarme in base alla tua tolleranza in caso di mancata consegna dei messaggi SMS.

Periodo: 60

Punti dati su cui attivare allarmi: 5

Periodi di valutazione: 5

Operatore di confronto: GREATER_THAN_THRESHOLD

Amazon SQS

ApproximateAgeOfOldestMessage

Dimensioni: QueueName

Descrizione dell'allarme: questo allarme rileva l'età del messaggio più vecchio nella coda. È possibile utilizzare questo allarme per verificare se i consumatori elaborano i messaggi SQS alla velocità desiderata. Valuta la possibilità di aumentare il numero di consumatori o la velocità di trasmissione effettiva degli stessi per ridurre l'età dei messaggi. Questo parametro può essere utilizzato in combinazione con ApproximateNumberOfMessagesVisible per determinare l'entità del backlog della coda e la velocità di elaborazione dei messaggi. Per evitare che i messaggi vengano eliminati prima dell'elaborazione, prendi in considerazione la possibilità di configurare la coda DLQ in modo da mettere da parte i potenziali messaggi avvelenati.

Intento: questo allarme viene utilizzato per rilevare se l'età del messaggio più vecchio nella QueueName coda è troppo alta. L'età elevata può indicare che i messaggi non vengono elaborati abbastanza velocemente o che alcuni messaggi avvelenanti sono bloccati in coda e non possono essere elaborati.

Statistica: Maximum

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal tempo previsto per l'elaborazione del messaggio. È possibile utilizzare i dati storici per calcolare il tempo medio di elaborazione dei messaggi e quindi impostare la soglia su un valore del 50% superiore al tempo massimo di elaborazione dei messaggi SQS previsto dai consumatori in coda.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Dimensioni: QueueName

Descrizione dell'allarme: questo allarme aiuta a rilevare un numero elevato di messaggi in transito relativamente a QueueName. Per la risoluzione dei problemi, consulta la sezione sulla riduzione del backlog dei messaggi.

Scopo: questo allarme viene utilizzato per rilevare un numero elevato di messaggi in transito nella coda. Se i consumatori non eliminano i messaggi entro il periodo di timeout di visibilità, quando avviene il polling della coda, i messaggi riappaiono nella coda. Per le code FIFO, possono esserci al massimo 20.000 messaggi in transito. Se raggiungi questa quota, SQS non restituisce alcun messaggio di errore. Una coda FIFO esamina i primi 20.000 messaggi per determinare i gruppi di messaggi disponibili. Ciò significa che se in un singolo gruppo di messaggi è presente un backlog, non è possibile utilizzare i messaggi provenienti da altri gruppi di messaggi inviati successivamente alla coda fino a quando non si gestisce correttamente il backlog.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: il valore di soglia raccomandato per questo allarme dipende in larga misura dal numero previsto di messaggi in transito. È possibile utilizzare i dati storici per calcolare il numero massimo previsto di messaggi in transito e impostare una soglia del 50% superiore a questo valore. Se i consumatori della coda elaborano i messaggi della coda ma non li eliminano, questo numero aumenterà improvvisamente.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Dimensioni: QueueName

Descrizione dell'allarme: questo allarme rileva se il backlog della coda di messaggi è maggiore del previsto, indicando che i consumatori sono troppo lenti o che il loro numero è insufficiente. Se l'allarme entra nello stato ALARM, valuta la possibilità di aumentare il numero di consumatori o di velocizzarli.

Scopo: questo allarme viene utilizzato per rilevare se il numero di messaggi della coda attiva è troppo elevato e i consumatori sono lenti nell'elaborazione dei messaggi o se non sono sufficienti per la loro elaborazione.

Statistica: Average

Soglia raccomandata: dipende dalla situazione

Giustificazione della soglia: un numero inaspettatamente elevato di messaggi visibili indica che i messaggi non vengono elaborati da un consumatore alla velocità prevista. È consigliabile analizzare i dati storici per impostare questa soglia.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Dimensioni: QueueName

Descrizione dell'allarme: questo allarme aiuta a rilevare se non ci sono messaggi inviati da un produttore in merito a QueueName. Per la risoluzione dei problemi, controlla il motivo per cui il produttore non invia messaggi.

Scopo: questo allarme viene utilizzato per rilevare quando un produttore interrompe l'invio di messaggi.

Statistica: Sum

Soglia raccomandata: 0,0

Giustificazione della soglia: se il numero di messaggi inviati è 0, il produttore non invia alcun messaggio. Se questa coda ha un TPS basso, aumenta il numero di EvaluationPeriods conseguenza.

Periodo: 60

Punti dati su cui attivare allarmi: 15

Periodi di valutazione: 15

Operatore di confronto: LESS_THAN_OR_EQUAL_TO_THRESHOLD

AWS VPN

TunnelState

Dimensioni: VpnId

Descrizione dell'allarme: questo allarme permette di capire se lo stato di uno o più tunnel è DOWN. Per la risoluzione dei problemi, consulta la pagina VPN tunnel troubleshooting.

Scopo: questo allarme viene utilizzato per rilevare se almeno un tunnel è in stato DOWN per questa VPN, in modo da poter risolvere i problemi relativi alla VPN interessata. Questo allarme sarà sempre nello stato ALARM per le reti in cui è configurato un solo tunnel.

Statistica: Minimum

Soglia raccomandata: 1,0

Giustificazione della soglia: un valore inferiore a 1 indica che almeno un tunnel è in stato DOWN.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: LESS_THAN_THRESHOLD

TunnelState

Dimensioni: TunnelIpAddress

Descrizione dell'allarme: questo allarme permette di capire se lo stato di questo tunnel è DOWN. Per la risoluzione dei problemi, consulta la pagina VPN tunnel troubleshooting.

Scopo: questo allarme viene utilizzato per rilevare se il tunnel è in stato DOWN, in modo da poter risolvere i problemi relativi alla VPN interessata. Questo allarme sarà sempre nello stato ALARM per le reti in cui è configurato un solo tunnel.

Statistica: Minimum

Soglia raccomandata: 1,0

Giustificazione della soglia: un valore inferiore a 1 indica che il tunnel è in stato DOWN.

Periodo: 300

Punti dati su cui attivare allarmi: 3

Periodi di valutazione: 3

Operatore di confronto: LESS_THAN_THRESHOLD