

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Quais métricas devo monitorar?
<a name="metrics.whichshouldimonitor"></a>

As seguintes métricas do CloudWatch oferecem uma boa visão do desempenho do MemoryDB. Na maioria dos casos, recomendamos que você defina alarmes do CloudWatch para essas métricas para poder tomar medidas corretivas antes que problemas de performance ocorram.

**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memória](#metrics-memory)
+ [Rede](#metrics-network)
+ [Latência](#metrics-latency)
+ [Replicação](#metrics-replication)

## CPUUtilization
<a name="metrics-cpu-utilization"></a>

Essa é uma métrica em nível de host relatada como uma porcentagem. Para obter mais informações, consulte [Métricas em nível de host](metrics.HostLevel.md).

 Para tipos de nós menores com 2 vCPUs ou menos, use a métrica `CPUUtilization ` para monitorar a workload.

De modo geral, sugerimos que você defina o limite para 90% da CPU disponível. Como o Valkey e o Redis OSS têm thread único, o valor efetivo do limite deve ser calculado como uma fração da capacidade total do nó. Por exemplo, suponha que você esteja usando um tipo de nó com dois núcleos. Nesse caso, o limite para CPUUtilization seria 90/2 ou 45%. Para saber o número de núcleos (vCPUs) que seu tipo de nó possui, consulte [Precificação do MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).

Você precisará determinar seu próprio limite, com base no número de núcleos no nó que está usando. Se você exceder esse limite e sua workload principal for de solicitações de leitura, escale seu cluster adicionando réplicas de leitura. Se a workload principal for proveniente de solicitações de gravação, recomendamos que você adicione mais fragmentos para distribuir a workload de gravação em mais nós primários.

**dica**  
Em vez de usar a métrica ao nível do host `CPUUtilization`, talvez você possa usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

Para tipos de nós maiores com 4 vCPUs ou mais, talvez você queira usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

## EngineCPUUtilization
<a name="metrics-engine-cpu-utilization"></a>

Para tipos de nós maiores com 4 vCPUs ou mais, talvez você queira usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

## SwapUsage
<a name="metrics-swap-usage"></a>

Esta é uma métrica em nível de host relatada em bytes. Para obter mais informações, consulte [Métricas em nível de host](metrics.HostLevel.md).

Se a métrica `FreeableMemory` do CloudWatch estiver próxima de 0 (ou seja, abaixo de 100 MB), ou se a métrica `SwapUsage` for maior que a métrica `FreeableMemory`, isso poderá indicar que há um nó sob uso intenso da memória.

## Evictions
<a name="metrics-evictions"></a>

Essa é uma métrica de mecanismo. Recomendamos que você determine seu próprio limite de alarme para essa métrica com base nas necessidades do seu aplicativo.

## CurrConnections
<a name="metrics-curr-connections"></a>

Essa é uma métrica de mecanismo. Recomendamos que você determine seu próprio limite de alarme para essa métrica com base nas necessidades do seu aplicativo.

Um número crescente de *CurrConnections* pode indicar um problema em seu aplicativo; você precisará investigar o comportamento do aplicativo para resolver esse problema. 

## Memória
<a name="metrics-memory"></a>

A memória é um aspecto central do Valkey e do Redis OSS. Compreender a utilização da memória do seu cluster é necessário para evitar a perda de dados e acomodar o crescimento futuro do seu conjunto de dados. Estatísticas sobre a utilização de memória de um nó estão disponíveis na seção de memória do comando [INFO](https://valkey.io/commands/info).

## Rede
<a name="metrics-network"></a>

Um dos fatores determinantes para a capacidade de largura de banda da rede do cluster é o tipo de nó selecionado. Para obter mais informações sobre a capacidade de rede de seu nó, consulte [Precificação do Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).

## Latência
<a name="metrics-latency"></a>

As métricas de latência `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` medem o tempo total que o mecanismo do MemoryDB para Valkey leva para responder a uma solicitação.

**nota**  
Valores inflados para as métricas `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` podem ocorrer ao usar o pipeline do Valkey com CLIENT REPLY habilitado no cliente do Valkey. A criação de pipeline do Valkey é uma técnica para melhorar o desempenho emitindo vários comandos ao mesmo tempo, sem esperar pela resposta de cada comando individual. Para evitar valores inflados, recomendamos configurar seu cliente do Redis para gerar comandos do pipeline com [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/).

## Replicação
<a name="metrics-replication"></a>

O volume de dados que está sendo replicado é visível através da métrica `ReplicationBytes`. Você pode monitorar o `MaxReplicationThroughput` em relação ao throughput da capacidade de replicação. Recomenda-se adicionar mais fragmentos ao atingir o throughput máximo da capacidade de replicação.

`ReplicationDelayedWriteCommands` também pode indicar se a workload está excedendo o throughput da capacidade máxima de replicação. Para obter mais informações sobre a replicação no MemoryDB, consulte [Entendendo a replicação do MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)