Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
È possibile monitorare le metriche chiave, ad esempio il rapporto di accesso alla cache, per garantire prestazioni ottimali del cluster DAX, diagnosticare i problemi e determinare quando è necessario scalare il cluster. Il controllo regolare delle metriche chiave aiuta a mantenere prestazioni, stabilità ed efficienza in termini di costi scalando il cluster in base ai requisiti del carico di lavoro. Per ulteriori informazioni sul monitoraggio di DAX, vedere. Monitoraggio della produzione
L'elenco seguente presenta alcune delle metriche chiave da monitorare:
-
Cache hit ratio: mostra l'efficacia con cui DAX serve 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'impostazione TTL 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 cluster DAX. Confronta i
QueryCacheMisses
parametriItemCacheHits
ItemCacheMisses
QueryCacheHits
,, 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 per gli utenti segnalate dal nodo o dal cluster.
ErrorRequestCount
include 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 DAX può aiutarvi a identificare i punti deboli delle prestazioni. L'aumento delle latenze potrebbe indicare problemi relativi alla configurazione del cluster DAX, alla rete o alla necessità di scalare.
-
Consumo di rete: tieni d'occhio le
NetworkBytesOut
metricheNetworkBytesIn
e per monitorare il traffico di rete del cluster DAX. 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 costi del cluster DAX. Garantisce inoltre che la rete non diventi un ostacolo alle 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 cluster DAX per ospitare una cache più grande. -
Utilizzo della CPU: si riferisce alla percentuale di utilizzo della CPU del nodo o del cluster. Si tratta di una metrica fondamentale da monitorare per qualsiasi database o sistema di memorizzazione nella cache. L'elevato utilizzo della CPU può comportare un sovraccarico del cluster DAX e la necessità di scalabilità per gestire l'aumento della domanda.
Monitora la
CPUUtilization
metrica per il tuo cluster DAX. Se l'utilizzo della CPU si avvicina o supera costantemente il 70-80%, prendete in considerazione la possibilità di aumentare il cluster DAX come descritto nella sezione seguente.Se il numero di richieste inviate a DAX supera la capacità di un nodo, DAX limita la velocità con cui accetta richieste aggiuntive. Lo fa restituendo un. ThrottlingException DAX valuta continuamente l'utilizzo della CPU del cluster per determinare il volume di richieste che può elaborare mantenendo uno stato integro del cluster.
È possibile monitorare la
ThrottledRequestCount
metrica su cui DAX pubblica. CloudWatch Se queste eccezioni vengono visualizzate regolarmente, è consigliabile prendere in considerazione la possibilità di aumentare la dimensione del cluster.
Scalabilità del cluster DAX utilizzando i dati di monitoraggio
È possibile determinare se è necessario aumentare o diminuire il cluster DAX monitorandone le metriche delle prestazioni.
-
Scalabilità verso l'alto o verso l'alto: se il cluster DAX presenta un elevato utilizzo della CPU, bassi accessi alla cache (dopo l'ottimizzazione della strategia di caching) o latenze operative elevate, è necessario 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 utilizzo della CPU e latenze operative inferiori alle 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.