Monitoraggio DAX

Cache hit ratio: mostra l'efficacia con cui vengono DAX utilizzati i dati memorizzati nella cache, riducendo la necessità di accedere alle tabelle DynamoDB sottostanti. Pochi errori di cache per il cluster indicano una buona efficienza della memorizzazione nella cache. Tuttavia, alcuni accessi alla cache suggeriscono che potrebbe essere necessario rivedere l'TTLimpostazione di memorizzazione nella cache, altrimenti il carico di lavoro non è adatto alla memorizzazione nella cache.

Usa Amazon CloudWatch per calcolare il rapporto di accessi alla cache del tuo DAX cluster. Confronta i QueryCacheMisses parametri ItemCacheHits ItemCacheMissesQueryCacheHits,, e per ottenere questo rapporto. La formula seguente mostra come viene calcolato il rapporto di accessi alla cache. Per calcolare il rapporto utilizzando questa formula, dividi gli accessi alla cache per la somma degli accessi alla cache e degli accessi mancati nella cache.

Cache hit ratio = Cache hits / (Cache hits + Cache misses)

Il rapporto di accessi alla cache è un numero compreso tra 0 e 1, rappresentato in percentuale. Una percentuale più alta indica un migliore utilizzo complessivo della cache.

ErrorRequestCount— Numero di richieste che hanno provocato errori utente segnalati dal nodo o dal cluster. ErrorRequestCountinclude le richieste che sono state limitate dal nodo o dal cluster. Il monitoraggio degli errori degli utenti può aiutarvi a identificare configurazioni errate di scalabilità o modelli di partizioni o elementi chiave nell'applicazione.

Latenze operative: il monitoraggio della latenza delle operazioni di lettura e scrittura da e verso il cluster può aiutarvi a identificare i punti deboli delle DAX prestazioni. L'aumento delle latenze potrebbe indicare problemi relativi alla configurazione del DAX cluster, alla rete o alla necessità di scalare.

Consumo di rete: tieni d'occhio le NetworkBytesOut metriche NetworkBytesIn e per monitorare il traffico di rete del DAX cluster. Un aumento imprevisto del throughput di rete potrebbe significare un maggior numero di richieste da parte dei client o modelli di query inefficienti che causano il trasferimento di una maggiore quantità di dati.

Il monitoraggio del consumo di rete consente di gestire i DAX costi del cluster. Garantisce inoltre che la rete non diventi un collo di bottiglia per le prestazioni del cluster.

Tasso di sfratto: mostra la frequenza con cui gli elementi vengono rimossi dalla cache per fare spazio a nuovi elementi. Se il tasso di eliminazione aumenta nel tempo, è possibile che la cache sia troppo piccola o che la strategia di memorizzazione nella cache non sia efficace.

Monitora la EvictedSize metrica CloudWatch per determinare se la dimensione della cache è adeguata al carico di lavoro. Se la dimensione totale eliminata continua a crescere, potrebbe essere necessario scalare il DAX cluster per ospitare una cache più grande.

CPUutilizzo: si riferisce alla percentuale di CPU utilizzo del nodo o del cluster. Si tratta di una metrica fondamentale da monitorare per qualsiasi database o sistema di memorizzazione nella cache. Un CPU utilizzo elevato potrebbe significare che il DAX cluster potrebbe essere sovraccarico e necessitare di scalabilità per gestire l'aumento della domanda.

Monitora la CPUUtilization metrica per il tuo cluster. DAX Se il tuo CPU utilizzo si avvicina o supera costantemente il 70-80%, prendi in considerazione la possibilità di scalare il DAX cluster come descritto nella sezione seguente.

Se il numero di richieste inviate DAX supera la capacità di un nodo, DAX limita la velocità con cui il nodo accetta richieste aggiuntive. Lo fa restituendo un ThrottlingException. DAXvaluta continuamente l'CPUutilizzo del cluster per determinare il volume di richieste che può elaborare mantenendo uno stato integro del cluster.

Puoi monitorare la ThrottledRequestCount metrica su cui DAX viene pubblicata. CloudWatch Se queste eccezioni vengono visualizzate regolarmente, è consigliabile prendere in considerazione la possibilità di aumentare la dimensione del cluster.

Scalabilità verticale o orizzontale: se il DAX cluster presenta un elevato CPU utilizzo, bassi accessi alla cache (dopo aver ottimizzato la strategia di caching) o latenze operative elevate, è consigliabile scalare il cluster verso l'alto. L'aggiunta di più nodi, chiamata anche scalabilità orizzontale, può aiutare a distribuire il carico in modo più uniforme. Per carichi di lavoro con un aumento delle scritture al secondo, potrebbe essere necessario scegliere nodi più potenti (scalabilità verticale).

Ridimensionamento: se si riscontrano costantemente bassi livelli di CPU utilizzo e latenze operative al di sotto delle soglie stabilite, è possibile che le risorse siano sovradimensionate. In questi casi, riduci i nodi per ridurre i costi. È possibile ridurre il numero di nodi a 1 durante i periodi di utilizzo ridotto, ma non è possibile chiudere completamente il cluster.