Referência de dados de monitoramento do Redis Gerenciado do Azure

Este artigo contém todas as informações de referência de monitoramento para este serviço.

Métricas

Esta seção lista todas as métricas da plataforma coletadas automaticamente para este serviço. Essas métricas também fazem parte da lista global de todas as métricas da plataforma com suporte no Azure Monitor.

Para obter informações sobre retenção de métricas, consulte Visão geral das métricas do Azure Monitor.

Para obter mais detalhes e informações sobre as métricas com suporte para Microsoft.Cache/redisEnterprise, consulte a seção a seguir.

Métricas com suporte para Microsoft.Cache/redisEnterprise

A tabela a seguir lista as métricas disponíveis para o tipo de recurso Microsoft.Cache/redisEnterprise.

• Nem todas as colunas podem estar presentes em todas as tabelas.
• Algumas colunas podem estar além da área de visualização da página. Selecione Expandir tabela para exibir todas as colunas disponíveis.

Títulos de tabela

• Categoria: o grupo ou classificação de métricas.
• Métrica: o nome de exibição da métrica como aparece no portal do Azure.
• Nome na API REST: o nome da métrica, conforme mencionado na API REST.
• Unidade: unidade de medida
• Agregação – o tipo de agregação padrão. Valores válidos: Médio (Méd.), Mínimo (Mín.), Máximo (Máx.), Total (Soma), Contagem.
• Dimensões - Dimensões disponíveis para a métrica.
• Intervalos de agregação: os - em que a métrica é amostrada. Por exemplo, PT1M indica que a métrica é amostrada a cada minuto, PT30M a cada 30 minutos, PT1H a cada hora e assim por diante.
• Exportação de DS: se a métrica é exportável para os Logs do Azure Monitor via configurações de diagnóstico. Para obter mais informações sobre exportação de métricas, consulte as Criar configurações de diagnóstico no Azure Monitor.

Métrica	Nome na API REST	Métricas avançadas da plataforma	Unidade	Agregação	Dimensões	Intervalos de Tempo	Exportação de DS
Ocorrências no Cache O número de pesquisas de chave com êxito. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	cachehits	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Microssegundos de latência de cache (versão prévia) A latência para o cache em microssegundos. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	cacheLatency	Não	Contagem	Mediana	InstanceId	PT1M	Sim
Perdas no Cache O número de pesquisas de chave com falha. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	cachemisses	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Cache Lido A quantidade de dados lidos do cache em Megabytes por segundo (MB/s). Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	cacheRead	Não	Bytes por Segundo	Máximo	InstanceId	PT1M	Sim
Gravação no Cache A quantidade de dados gravados no cache em Megabytes por segundo (MB/s). Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	cacheWrite	Não	Bytes por Segundo	Máximo	InstanceId	PT1M	Sim
Clientes Conectados O número de conexões do cliente com o cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	connectedclients	Não	Contagem	Máximo	InstanceId	PT1M	Sim
Chaves removidas O número de itens removidos do cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	evictedkeys	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Chaves expiradas O número de itens expirados do cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	expiredkeys	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Replicação geográfica saudável A integridade da replicação geográfica em um grupo de replicação geográfica ativa. 0 representa Insalubre e 1 representa Saudável. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	geoReplicationHealthy	Não	Contagem	Máximo	<nenhum>	PT1M	Sim
Obtém O número de operações get do cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	getcommands	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Operações por Segundo O número de operações instantâneas por segundo executadas no cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	operationsPerSecond	Não	Contagem	Máximo	<nenhum>	PT1M	Sim
CPU A utilização da CPU do servidor Azure Redis Cache em porcentagem. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	percentProcessorTime	Não	Porcentagem	Máximo	InstanceId	PT1M	Sim
Carga do Servidor O percentual de ciclos em que o servidor Redis está ocupado processando, em vez de ocioso esperando por mensagens. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	serverLoad	Não	Porcentagem	Máximo	<nenhum>	PT1M	Sim
Define O número de operação de conjuntos para o cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	setcommands	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Total de Operações O número total de comandos processados pelo servidor de cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	totalcommandsprocessed	Não	Contagem	Soma (Total)	<nenhum>	PT1M	Sim
Total de Chaves O número total de itens no cache. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	totalkeys	Não	Contagem	Máximo	<nenhum>	PT1M	Sim
Memória Usada A quantidade de memória cache usada para pares de chave-valor no cache em MB. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	usedmemory	Não	Bytes	Máximo	<nenhum>	PT1M	Sim
Percentual de memória utilizada A porcentagem de memória cache usada para pares de chave-valor. Para obter mais informações, consulte https://aka.ms/redis/enterprise/metrics.	usedmemorypercentage	Não	Porcentagem	Máximo	<nenhum>	PT1M	Sim

Detalhes sobre as métricas do Redis Gerenciado do Azure

As seções a seguir fornecem mais informações e orientações de interpretação para as métricas suportadas do Azure Monitor para a Microsoft. Cache/redisEnterprise. Para a lista completa de métricas com suas unidades e tipos de agregação, veja a tabela de Métricas Suportadas .

Detalhes sobre métricas em nível de cluster

A tabela a seguir fornece a métrica de origem Subjacente do Redis V1 Prometheus e orientações adicionais de interpretação para cada métrica em nível de cluster. Para as definições das métricas de origem, veja a referência de métricas Redis Enterprise Prometheus v1.

Métrica	Fonte e notas
Latência do cache	A latência média de solicitações manipuladas por pontos de extremidade no nó de cache durante o intervalo de relatórios especificado. Essa métrica é medida em milissegundos e é obtida a partir da node_avg_latency métrica V1 Prometheus. Essa métrica só é relatada quando há tráfego ativo no cache.
Acertos de cache	A taxa de consultas de chaves bem-sucedidas, expressa como acertos por segundo. Obtido da bdb_read_hits métrica V1 Prometheus. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Erros de Cache	A taxa de consultas de chave malsucedidas, expressa como falhas por segundo. Obtido da bdb_read_misses_max métrica V1 Prometheus. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo. Erros de cache não significam necessariamente que há um problema com o cache. Por exemplo, ao se usar o padrão de programação cache-aside, um aplicativo procura um item no cache primeiro. Se o item não estiver lá (erro de cache), o item será recuperado do banco de dados e adicionado ao cache na próxima vez. Erros de cache são o comportamento normal para o padrão de programação cache-aside. Se o número de erros de cache for maior do que o esperado, examine a lógica do aplicativo que popula e lê do cache. Se os itens estiverem sendo removidos do cache devido à pressão de memória, talvez haja alguns erros de cache, mas uma métrica melhor para monitorar a pressão de memória seria Used Memory or Evicted Keys.
Cache Lido	Representa a taxa de tráfego de rede recebido para o nó cache em bytes por segundo. Esse valor é obtido da node_ingress_bytes_max métrica Prometheus V1. Se você quiser configurar alertas para limites de largura de banda de rede do lado do servidor, crie-o usando este contador de Leitura de Cache. Confira esta tabela para ver os limites de largura de banda observados para vários tamanhos e tipos de preço de cache. Esta é uma métrica de taxa, expressa em bytes por segundo.
Gravação no Cache	Representa a taxa do tráfego de rede de saída do nó cache em bytes por segundo. Esse valor é obtido da node_egress_bytes_max métrica Prometheus V1. Esta é uma métrica de taxa, expressa em bytes por segundo.
Clientes conectados	Obtido da node_conns métrica V1 Prometheus, que conta clientes conectados aos endpoints no nó. Depois que o limite de conexão for atingido, as tentativas posteriores de se conectar ao cache falharão. Mesmo que não haja aplicativos clientes ativos, ainda pode haver algumas instâncias de clientes conectados devido a conexões e processos internos.
CPU	Derivado da node_cpu_idle métrica V1 Prometheus, que representa a média do tempo ocioso da CPU (um valor de 0 a 1, multiplicado por 100 para expressar uma porcentagem) durante o intervalo, e é invertido para refletir o tempo de ocupação da CPU. A métrica da CPU inclui processos em segundo plano, como antimalware que não são estritamente processos do servidor Redis, portanto, às vezes, pode aumentar independentemente da carga de trabalho redis. É recomendável usar essa métrica sobre a Carga do Servidor para monitoramento, pois ela dá suporte à busca detalhada no nível da instância dividindo-se na ID da Instância, fornecendo mais granularidade na qual o nó está sob pressão.
Chaves removidas	A taxa de despejos importantes, expressa como despejos por segundo. Obtido da bdb_evicted_objects métrica V1 Prometheus. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Chaves expiradas	A taxa de vencimentos de chave, expressa como vencimentos por segundo. Obtido da bdb_expired_objects métrica V1 Prometheus. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Replicação geográfica íntegra	Indica a integridade do link de replicação geográfica entre caches em um grupo do Active Geo-Replication. A métrica relata um dos dois valores: 0 - desconectado/pouco saudável 1 - saudável A métrica está disponível em caches de camada otimizada para memória, balanceada e computação com replicação geográfica habilitada. Um valor de 0 não significa que os dados na replicação geográfica foram perdidos. Isso significa apenas que o link entre a geografia primária e a secundária não é íntegro. Essa métrica pode indicar um status de replicação desconectado/não íntegro por vários motivos, incluindo: aplicação de patch mensal, atualizações do sistema operacional do host, configuração incorreta de rede ou falha no provisionamento de link de replicação geográfica. O serviço Redis Gerenciado do Azure periodicamente corrige caches com os recursos e melhorias mais recentes da plataforma. Durante essas atualizações, cada nó do cache fica offline, o que desabilita temporariamente o link da replicação geográfica. Se o link de replicação geográfica não estiver íntegro, verifique se ele foi causado por um evento de aplicação de patch no cache geográfico ou geográfico secundário usando Diagnosticar e Resolver Problemas no menu Recurso no portal. Dependendo da quantidade de dados no cache, o tempo de inatividade da aplicação de patches pode levar de alguns minutos a uma hora. Se o link de replicação geográfica não estiver íntegro por mais de uma hora, registre uma solicitação de suporte.
Obtém	A taxa de operações de leitura, expressa como operações por segundo. Obtido da bdb_read_req métrica V1 Prometheus, que representa a taxa de todas as requisições de leitura no banco de dados e é equivalente à soma dos acertos e falhas no cache. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Operações por segundo	O número total de solicitações manipuladas por segundo por todos os fragmentos do cache durante o intervalo de relatórios especificado. Esse valor é obtido da bdb_instantaneous_ops_per_sec métrica Prometheus V1. Esta é uma métrica de taxa, expressa como operações por segundo.
Carga do Servidor	A métrica de Carga do Servidor reflete a própria avaliação do servidor Redis sobre a carga total. Assim como a métrica de CPU , ela é derivada da node_cpu_idle métrica V1 Prometheus, invertida para refletir o horário de ocupação do servidor. A diferença é que a Carga do Servidor é medida no nível do cluster, enquanto a CPU é medida no nível do nó (instância). A carga do servidor chegar a 100 não significa necessariamente que a CPU está esgotada em todo o cache; pode indicar que a CPU em um dos nós está se aproximando da saturação. Por esse motivo, avalie tanto a Carga do Servidor quanto a métrica de CPU por nó antes de tomar decisões relacionadas ao desempenho, como ampliar ou particionar dados em múltiplos caches. A alta carga sustentada do servidor pode ter vários efeitos colaterais, incluindo aumento da latência do lado do servidor e exceções de timeout. Atenção: Para caches do Azure Managed Redis, a Carga do Servidor às vezes reflete valores acima de 100. Recomendamos usar a métrica da CPU , ou avaliar ambas as métricas juntos, antes de tomar qualquer decisão baseada em desempenho.
Conjuntos	A taxa de operações de escrita, expressa como operações por segundo. Obtido a partir da bdb_write_req métrica V1 Prometheus, que representa a taxa de todas as solicitações de escrita no banco de dados. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Total de chaves	Obtido da bdb_no_of_keys métrica V1 Prometheus. Importante: Devido a uma limitação no sistema de métricas subjacente para caches com clustering ativado, o Total Keys retorna o número máximo de chaves do shard que teve o maior número de chaves durante o intervalo de relatório. Para ver contagens precisas de chaves por fragmento em um cache clusterizado, use a métrica de Contagem de Chaves de Fragmento em nível de fragmento, fatiada pela Slots (Range) dimensão.
Total de Operações	A taxa de todas as operações, expressa como operações por segundo. Obtido da bdb_total_req métrica V1 Prometheus. Essa é uma métrica de taxa; sua unidade Azure Monitor é exibida como Contagem, mas o valor é uma taxa por segundo.
Memória Usada	Obtido da bdb_used_memory métrica V1 Prometheus. Em caches de camada com otimização flash, esse valor inclui o uso de memória flash e RAM. Esse valor não inclui fragmentação. Quando a Alta Disponibilidade está habilitada, o valor de Memória Usada inclui a memória nos nós primário e de réplica. Isso pode fazer com que a métrica apareça duas vezes maior do que o esperado.
Porcentagem de memória utilizada	Calculado como a razão de bdb_used_memory para bdb_memory_limit a partir das métricas Redis Enterprise V1 Prometheus. Esse valor não inclui fragmentação.

Métricas em nível de shard

O Azure Managed Redis agora expõe métricas em nível de shard que fornecem visibilidade por shard sobre o comportamento do cache. Essas métricas são obtidas dos endpoints Redis V2 Prometheus (redis_server_* métricas).

Dimensões

Cada métrica em nível de fragmento suporta as seguintes dimensões:

Dimensão	Nome na API REST	Description
Instance ID	InstanceId	Identifica o nó Redis específico (instância de VM) dentro do cluster. Use essa dimensão para isolar o comportamento por nó e identificar desequilíbrio de carga entre nós.
Slots (Range)	Slots	Identifica o shard pelo intervalo de slots de hash. Use essa dimensão para detectar desequilíbrio de memória ou distribuição desigual de chaves entre os fragmentos.
Shard ID	Shard	Identificador único de fragmento usando o UID do fragmento Rederis. Use essa dimensão junto Slots (Range) para correlacionar dados do Azure Monitor com identificadores de shard em nível Redis.
Shard Role	Role	Função do nó: primary ou replica. Use essa dimensão para comparar métricas entre nós primário e réplica no mesmo shard.

Note

Quando você dividir ou filtrar por uma dimensão através da API REST do Azure Monitor, use o valor na coluna Nome na API REST em vez do nome exibido do portal. Nomes de métricas e nomes de dimensão na API REST do Azure Monitor são indiferentes a maiúsculas e minúsculas. Por exemplo, consultar percentProcessorTime, PercentProcessorTime, ou PERCENTPROCESSORTIME todos retornam os mesmos resultados. O mesmo se aplica aos valores de filtro de dimensão: instanceId eq '*' e INSTANCEID eq '*' são equivalentes. A carcaça usada neste artigo é uma convenção apenas para legibilidade.

Important

Essas métricas são publicadas no nível do fragmento. Quando consultado sem separar por dimensão, o Azure Monitor agrega valores em todos os shards usando o tipo de agregação padrão. Para a maioria das métricas, essa agregação cross-shard não produz totais significativos em todo o cluster. Sempre dividido pela Slots (Range) dimensão para uma análise precisa por fragmento.

Detalhes sobre métricas em nível de fragmento

A tabela a seguir fornece a métrica de fonte subjacente do Redis V2 Prometheus e orientações adicionais de interpretação para cada métrica em nível de fragmento. Para as definições das métricas de origem, veja a referência de métricas Redis Enterprise Prometheus v2.

Métrica	Detalhes
Memória do Fragmento Usada (Bytes) (Prévia)	Memória usada por este fragmento, em bytes. Em SKUs habilitados para flash, isso inclui tanto o uso de DRAM quanto de flash. Obtido a partir da redis_server_used_memory métrica Redis V2 Prometheus.
Clientes de Memória Shard Normal (Bytes) (Prévia)	Memória atual usada para buffers de entrada e saída de clientes não réplica. Obtido a partir da redis_server_mem_clients_normal métrica Redis V2 Prometheus.
Réplica dos Clientes de Memória Fragmentada (Bytes) (Prévia)	Memória atual usada para buffers de entrada e saída de clientes réplica. Obtido a partir da redis_server_mem_clients_slaves métrica Redis V2 Prometheus.
Contagem de Chaves do Fragmento (Prévia)	Total de chaves. Obtido a partir da redis_server_db_keys métrica Redis V2 Prometheus.
Link de Replicação de Fragmentos (Prévia)	Indica se uma réplica está conectada ao seu primário. Obtido da redis_server_master_link_status métrica Redis V2 Prometheus, que é emitida apenas por fragmentos de réplica, porque apenas uma réplica tem um link de replicação de volta ao seu primário para reportar.

Métricas de grande chave

As métricas a seguir acompanham a distribuição do tamanho das chaves entre shards, ajudando você a identificar chaves grandes antes que causem problemas de desempenho.

Note

Métricas de grandes chaves ainda não são suportadas em caches geo-replicados ativos. O suporte para essas métricas para caches geo-replicados virá em uma data posterior.

Chaves de string (pelo tamanho da memória)

Métrica	Detalhes
Tamanhos das Strings Fragmentos Menores de 128 MB (Prévia)	Número de chaves de string neste fragmento com tamanho de memória inferior a 128 MB.

Chaves de conjunto (por número de elementos)

Métrica	Detalhes
Fragmento Define Itens Abaixo de 1M de Elementos (Prévia)	Número de chaves de conjunto neste fragmento com menos de 1 milhão de elementos.
Conjuntos de fragmentos Itens de 1M a 8M (Prévia)	Número de chaves de conjunto neste fragmento com entre 1 e 8 milhões de elementos.
Fragmento Define Itens Acima de 8M de Elementos (Prévia)	Número de chaves de conjunto neste fragmento com mais de 8 milhões de elementos.

Chaves de conjunto ordenadas (por número de elementos)

Métrica	Detalhes
Itens de conjuntos ordenados em fragmentos abaixo de 1 milhão de elementos (Prévia)	Número de chaves de conjunto ordenadas neste fragmento com menos de 1 milhão de elementos.
Fragmentos Ordenados Itens de 1M a 8M (Prévia)	Número de chaves de conjunto ordenadas neste fragmento com entre 1 e 8 milhões de elementos.
Itens de conjuntos ordenados em fragmentos acima de 8 milhões de elementos (Prévia)	Número de chaves de conjunto ordenadas neste fragmento com mais de 8 milhões de elementos.

Chaves de hash (por número de campos)

Métrica	Detalhes
Shard Hashe Itens Abaixo de 1M de Elementos (Prévia)	Número de chaves de hash neste fragmento com menos de 1 milhão de campos.
Hashes Itens do Fragmento de 1M a 8M (Prévia)	Número de chaves de hash nesse shard, com entre 1 milhão e 8 milhões de campos.
O Shard Hasha Itens Acima de 8M Elementos (Prévia)	Número de chaves de hash neste shard com mais de 8 milhões de campos.

Chaves de lista (por número de elementos)

Métrica	Detalhes
Fragmento lista itens abaixo de 1 milhão de elementos (Prévia)	Número de chaves de lista neste fragmento com menos de 1 milhão de elementos.
Shard lista itens de 1M a 8M (Prévia)	Número de chaves de lista neste fragmento com entre 1 e 8 milhões de elementos.
Shard lista itens acima de 8 milhões de elementos (prévia)	Número de chaves de lista neste fragmento com mais de 8 milhões de elementos.

Solução de problemas com métricas em nível de fragmento

As seções a seguir descrevem cenários comuns em nível de fragmento e como diagnosticá-los:

• Identificação de falhas no link de replicação
• Identificação de desequilíbrio de memória
• Diagnóstico do crescimento do tampão de replicação
• Gerenciamento de chaves grandes

Identificação de falhas no link de replicação

Uma falha no link de replicação ocorre quando um shard primário não consegue estabelecer uma conexão de replicação com seu shard réplica associado, então a réplica não pode mais permanecer sincronizada com o primário. Essa métrica é emitida apenas por fragmentos réplica, porque apenas uma réplica tem um link de replicação de volta ao seu primário para reportar, e ela informa se essa réplica está atualmente conectada ao seu primário. Uma falha sustentada remove a proteção de alta disponibilidade para o shard afetado e aumenta o risco de perda de dados caso o failover ocorra antes da recuperação do link. Dito isso, o link de replicação pode ficar temporariamente instável durante failover, migração de fragmentos, escalonamento ou eventos de manutenção, então essa métrica pode ser ruidosa. Por isso, é importante, ao configurar alertas nessa métrica, alertar apenas por um período prolongado com múltiplos pontos de dados que indicam quedas na saúde.

Abordagem de detecção:

1. Replicação de fragmentos divididos para conectar por Slots (Range). Um valor 0 em qualquer fragmento significa que o link de replicação do fragmento está fora do ar; 1 significa que está para cima.
2. Trate um link que permanece em 0 por um período prolongado (por exemplo, 120 minutos ou mais) como uma falha persistente, e não como uma reconexão transitória. Quedas breves podem ocorrer durante eventos normais de manutenção ou de falha.
3. Correlacione com Shard Memory Used e Shard Memory Clients Replica no mesmo shard para ver se a pressão de recursos no primário acompanha a falha.

Causas comuns:

• Chaves grandes são uma das principais causas. Chaves e coleções grandes tornam a sincronização lenta e cara, o que pode travar a réplica e, eventualmente, levar o link de replicação a um estado insalubre.
• Interrupção de rede ou alta latência entre os nós primário e réplica.
• O shard primário está sobrecarregado (alta taxa de escrita ou saturação do CPU), então não pode atender à replicação.
• Pressão de memória no primário impedindo as operações em segundo plano necessárias para sincronizar a réplica.
• Ciclos repetidos de ressincronização completa causados por uma réplica lenta que fica atrasada em relação ao acúmulo de replicação.

Remediação:

• Reduza a taxa de gravação sustentada ou escale o cache para aumentar a capacidade, de modo que o shard primário fique menos saturado.
• Identifique e fragmente as chaves grandes, que tornam a replicação e a ressincronização mais caras no shard afetado.
• Se o link permanecer fora do ar após a redução da carga, abra uma solicitação de suporte para que a equipe da plataforma possa investigar a saúde dos nós e o backlog interno de replicação.

Identificação de desequilíbrio de memória

O desequilíbrio de memória ocorre quando alguns fragmentos consomem significativamente mais memória que outros, o que pode levar a expulsões em fragmentos específicos enquanto outros têm memória livre de sobra.

Abordagem de detecção:

1. Memória do fragmento dividida usada (bytes) por Slots (Range). Uma relação máxima/mínima maior que 2x indica um desequilíbrio significativo.
2. Correlacione com a contagem de chaves do fragmento para Slots (Range) determinar se o desequilíbrio se deve a mais chaves ou valores maiores em fragmentos específicos.

Causas comuns:

• Uso indevido de hashtags concentrando grandes quantidades de teclas no mesmo shard.
• Chaves grandes: um pequeno número de estruturas de dados muito grandes em um shard específico.
• Políticas TTL inconsistentes causando divergência no uso de memória ao longo do tempo.

Remediação:

• Redistribua as chaves revisando e variando o uso das hashtags.
• Identifique e fragmente as grandes chaves usando as métricas das grandes chaves para localizar os fragmentos afetados.
• Revise políticas TTL para chaves em fragmentos de alta memória.

Diagnóstico do crescimento do tampão de replicação

Cada shard primário mantém um buffer de saída para sua réplica que enfileira escritas que a réplica ainda não aplicou. Quando uma réplica não consegue acompanhar, esse buffer cresce e consome memória no fragmento. Se crescer sem limites, a réplica pode ser desconectada e forçada a uma ressincronização completa, o que é caro e pode se desencadear em ciclos repetidos de resincronização ou até mesmo em sincronização de replicação se tornando prejudicial. Como cada fragmento tem seu próprio buffer réplica, o crescimento geralmente é isolado a fragmentos específicos.

Abordagem de detecção:

1. Divida os clientes de memória do shard Replica (Bytes) e Slots (Range) procure uma tendência sustentada de alta em qualquer shard ao longo de 15 minutos ou mais, em vez de uma única leitura alta. Crescimento constante é o sinal, não um pico momentâneo.
2. Correlacione com o Link Up de Replicação do Fragmento no mesmo fragmento. O crescimento do buffer que termina com o link caindo para 0 indica que a réplica foi desconectada e uma ressincronização é provável.
3. Correlacione com a atividade pesada em escrita (Conjuntos e Operações Totais no nível do cluster) para ver se uma rajada de escrita está impulsionando o crescimento.

Causas comuns:

• Uma rajada de escrita sustentada produzindo mudanças mais rápido do que a réplica pode aplicá-las.
• Uma réplica lenta, sob disputa por recursos, ficando atrás da primária.
• Loops de ressincronização completos repetidos que reabastecem o buffer repetidamente.
• Grandes chaves que tornam operações replicadas individuais grandes e lentas para transferir.

Remediação:

• Suavize ou reduza as rajadas de gravação sempre que possível, ou escale o cache para aumentar a capacidade.
• Identifique e fragmente grandes chaves para reduzir o tamanho das operações replicadas individuais.
• Se o buffer continuar crescendo e a réplica se desconectar repetidamente, abra uma solicitação de suporte para que a equipe da plataforma possa revisar a saúde da réplica e o tamanho do buffer, que são gerenciados pelo serviço.

Gerenciamento de chaves grandes

Chaves grandes e grandes coleções aumentam a pressão de memória sobre fragmentos individuais e tornam a replicação mais cara. Para o melhor desempenho do caminho de dados, mantenha tamanhos de chave/valor individuais abaixo de 512 KB. Isso é uma recomendação de desempenho, não um limite imposto.

Os grandes buckets de métricas monitoram apenas limites — eles não são tamanhos de chave recomendados ou endossados. Por exemplo, o bucket de Shard Strings Tamanhos Abaixo de 128 MB simplesmente conta chaves de string menores que 128 MB para que você possa observar o crescimento; isso não significa que o Azure recomende armazenar chaves perto de 128 MB. Da mesma forma, os baldes de contagem de elementos (1M, 8M) são limites para identificar coleções superdimensionadas, não tamanhos alvo. Sempre mire no menor tamanho prático de chave (idealmente menos de 512 KB) e trate qualquer chave que suba para um compartimento maior como algo a ser investigado.

As métricas de Big Keys agrupam as chaves em faixas de tamanho para que você possa identificar crescimento antes que cause problemas. Para coleções, o primeiro balde representa chaves dentro do intervalo normal, então trate qualquer chave que apareça no segundo ou terceiro balde como valendo a pena investigar. Para chaves de corda, apenas o bucket com menos de 128 MB é exposto, então trate qualquer valor de string que se aproxime ou exceda de 128 MB como uma preocupação.

Por que chaves grandes importam:

• Custo de replicação: Chaves grandes tornam tanto a replicação de alta disponibilidade quanto a geo-replicação ativa (CRDB) mais caras. O efeito não é imediato; Normalmente, ele aparece durante uma ressincronização completa desencadeada por uma falha ou reconexão posterior.
• Impacto do cache otimizado para flash: Em SKUs otimizados para flash, se uma chave for grande, ela permanece na RAM e não é descarregada para flash, o que pode causar erros de falta de memória (OOM) mesmo quando ainda há espaço disponível em disco flash. Valores muito pequenos em relação ao nome da chave também descarregam mal.

Abordagem de detecção:

1. Divida cada métrica de chaves grandes para Slots (Range) ver quais fragmentos guardam as chaves grandes.
2. Para coleções, foque nos segundo e terceiro baldes de contagem de elementos (1M a 8M e acima de 8M). O terceiro balde representa as tonalidades mais extremas. Para strings, apenas o bucket de Strings de Fragmentos com menos de 128 MB é exposto, então trate qualquer valor de string igual ou acima de 128 MB como uma preocupação.
3. Correlacione com a Memória de Fragmentos Usada por Slots (Range) para confirmar se as chaves grandes estão causando desequilíbrio de memória em fragmentos específicos.

Remediação:

• Reduza o tamanho do valor em direção ao primeiro balde ou 512 KB como boa prática. Estratégias comuns incluem dividir ou fragmentar um valor grande entre múltiplas chaves, além de comprimir ou reformatar o valor serializado.
• Para coleções (Listas, Conjuntos, Conjuntos Ordenados e Hashes) que crescem sem limites ao longo do tempo, divida a coleção em várias chaves ou corte-a periodicamente.
• O objetivo é reduzir o tamanho da chave individual e da coleção. O melhor método depende do design da sua aplicação e do tipo de dados.

Recomendações de alerta para métricas em nível de fragmento

Scenario	Métrica	Condition	Janela de avaliação	Severidade
Falha no link de replicação	Link de Replicação de Fragmentos, dividido por Slots (Range)	Mínimo = 0 em qualquer fragmento	120+ min	Alto
Desequilíbrio de memória	Memória de fragmento usada (bytes), dividida por Slots (Range)	Proporção máxima/mínima entre slots > 2x	5 minutos	Medium
Crescimento do buffer de replicação	Réplica dos Clientes de Memória de Fragmentos (Bytes), divididos por Slots (Range)	Aumento sustentado ao longo de 15 minutos	15 minutos	Medium
Coleções muito grandes (terceiro balde)	Qualquer métrica de bucket de coleta "Over 8M Elements", dividida por Slots (Range)	Valor > 0 em qualquer fragmento	Mais de 10 min	Alto
Coleções grandes (segundo balde)	Qualquer métrica de bucket de coleta "1M a 8M" de elementos, dividida por Slots (Range)	A contagem de baldes como uma parcela total de chaves desse tipo excede 10%	Mais de 10 min	Medium
Teclas grandes de corda	Tamanhos das strings de fragmentos menores de 128 MB (o único bucket de cordas exposto)	Qualquer valor de string igual ou acima de 128 MB é motivo de preocupação; observe a contagem abaixo de 128 MB para chaves que crescem em direção ao limiar	Mais de 10 min	Informativo

Note

O alerta de falha de link de replicação pode ser criado diretamente como um alerta de métrica do Azure Monitor, porque a métrica agrega como Minimum, então um valor 0 sobre a janela indica que o link esteve fora do ar em algum momento. O alerta de coleções muito grandes (terceiro balde) também pode ser criado nativamente, pois testa uma única métrica contra um limiar fixo (valor maior que 0). Os cenários restantes não podem ser avaliados nativamente por alertas de métricas do Azure Monitor: alertas de métricas não podem comparar valores entre valores de dimensões (por exemplo, uma relação máxima/mínima entre Slots (Range)eles), não podem calcular uma razão entre duas métricas (por exemplo, um segundo balde conta como uma participação do total de chaves desse tipo) e não conseguem detectar uma tendência sustentada de alta. Eles só testam se um valor ultrapassa um limite fixo em um determinado momento. Crie esses alertas como alertas de busca de log sobre as métricas exportadas: envie métricas para um espaço de trabalho do Log Analytics usando configurações de diagnóstico, depois calcule a proporção máxima/mínima, a participação de baldes ou a tendência em uma consulta Kusto (KQL). Métricas de primeiro balde não precisam de alertas; Monitore a tendência deles ao longo do tempo.

Logs de recursos

Esta seção lista os tipos de logs de recursos que você pode coletar para o este serviço. A seção extrai da lista de todos os tipos de categoria de logs de recursos com suporte no Azure Monitor.

Logs de recursos com suporte para Microsoft.Cache/redisEnterprise/databases

Categoria	Custos de exportação	Tabela de log	Suporta plano de registro básico	Suporta transformação durante a ingestão	Consultas de exemplo
Eventos de conexão (Nova Conexão/Autenticação/Desconexão)	Sim	REDConnectionEvents Registra os eventos de conexão quando o cliente se conecta ao banco de dados do Redis Enterprise.	Sim	Sim	Consultas

Tabelas de Logs do Azure Monitor

Esta seção lista todas as tabelas dos Logs do Azure Monitor relevantes para este serviço e disponíveis para consulta pela análise de logs usando o Kusto. As tabelas contêm dados de log de recursos e possivelmente mais, dependendo do que é coletado e roteado para elas.

Redis Gerenciado pelo Azure

Microsoft.Cache/redisEnterprise

• REDConnectionEvents

Log de atividades

A tabela vinculada lista as operações que podem ser registradas no log de atividades desse serviço. Essas operações são um subconjunto de todas as operações do provedor de recursos possíveis no log de atividades.

Para obter mais informações sobre o esquema de entradas do log de atividades, confira Esquema do log de atividades.

• Operações do provedor de recursos Microsoft.Cache

Conteúdo relacionado

• Confira Monitorar recursos do Azure com o Azure Monitor para ver informações detalhadas sobre o monitoramento dos recursos do Azure.