Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este artículo contiene toda la información de referencia de supervisión de este servicio.
Métricas
En esta sección se indican todas las métricas de la plataforma recopiladas automáticamente para este servicio. Estas métricas también forman parte de la lista global de todas las métricas de plataforma admitidas en Azure Monitor.
Para obtener información sobre la retención de métricas, consulte Información general sobre las métricas de Azure Monitor.
Para obtener más información e información sobre las métricas admitidas para Microsoft.Cache/redisEnterprise, consulte la sección siguiente.
Métricas soportadas para Microsoft.Cache/redisEnterprise
En la tabla siguiente se enumeran las métricas disponibles para el tipo de recurso Microsoft.Cache/redisEnterprise.
- Es posible que todas las columnas no estén presentes en todas las tablas.
- Es posible que algunas columnas estén fuera del área de visualización de la página. Seleccione Expandir tabla para ver todas las columnas disponibles.
Encabezados de tabla
- Categoría: el grupo de métricas o la clasificación.
- Métrica: el nombre de presentación de la métrica tal como aparece en el portal de Azure.
- Nombre en la API REST: el nombre de la métrica por el que se conoce en la API REST.
- Unidad: unidad de medida.
- Agregación: el tipo de agregación predeterminado. Valores válidos: promedio (Avg), mínimo (Min), máximo (Max), total (Sum), recuento.
- Dimensiones - : dimensiones disponibles para la métrica.
-
Intervalos de agregación - : intervalos en los que se obtiene una muestra de la métrica. Por ejemplo,
PT1Mindica que la métrica se muestrea cada minuto,PT30Mcada 30 minutos,PT1Hcada hora, etc. - Exportación de DS: indica si la métrica se puede exportar a los registros de Azure Monitor a través de la configuración de diagnóstico. Para obtener más información sobre la exportación de métricas, consulte Crear configuración de diagnóstico en Azure Monitor.
| Métrica | Nombre en la API de REST | Métricas avanzadas de la plataforma | Unidad | Agregación | Dimensiones | Granulos de tiempo | Exportación de DS |
|---|---|---|---|---|---|---|---|
|
Aciertos de caché El número de búsquedas de claves correctas. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
cachehits |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Microsegundos de latencia de caché (versión preliminar) La latencia de la caché en microsegundos. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
cacheLatency |
No | Contar | Promedio | InstanceId |
PT1M | Sí |
|
Errores de caché El número de búsquedas de claves con error. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
cachemisses |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Lectura de caché La cantidad de datos que se leen de la caché en megabytes por segundo (MB/s). Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
cacheRead |
No | Bytes por Segundo | Máxima | InstanceId |
PT1M | Sí |
|
Escritura de caché La cantidad de datos que se escriben en la caché en megabytes por segundo (MB/s). Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
cacheWrite |
No | Bytes por Segundo | Máxima | InstanceId |
PT1M | Sí |
|
Clientes conectados El número de conexiones de cliente a la memoria caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
connectedclients |
No | Contar | Máxima | InstanceId |
PT1M | Sí |
|
Claves expulsadas El número de elementos expulsados de la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
evictedkeys |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Claves expiradas El número de elementos expirados en la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
expiredkeys |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Replicación geográfica saludable El estado de la replicación geográfica en un grupo de replicación geográfica activa. 0 representa insalubre y 1 representa saludable. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
geoReplicationHealthy |
No | Contar | Máxima | <ninguno> | PT1M | Sí |
|
Obtiene El número de operaciones Get de la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
getcommands |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Operaciones por segundo El número de operaciones instantáneas por segundo ejecutadas en la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
operationsPerSecond |
No | Contar | Máxima | <ninguno> | PT1M | Sí |
|
CPU El uso de CPU del servidor de Azure Cache for Redis como porcentaje. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
percentProcessorTime |
No | Porcentaje | Máxima | InstanceId |
PT1M | Sí |
|
Carga del servidor El porcentaje de ciclos en los que el servidor de Redis está ocupado procesando y no está inactivo esperando mensajes. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
serverLoad |
No | Porcentaje | Máxima | <ninguno> | PT1M | Sí |
|
Conjuntos El número de operaciones Set a la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
setcommands |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Operaciones totales El número total de comandos procesados por el servidor de caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
totalcommandsprocessed |
No | Contar | Suma (Total) | <ninguno> | PT1M | Sí |
|
Total de claves El número total de elementos en la caché. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
totalkeys |
No | Contar | Máxima | <ninguno> | PT1M | Sí |
|
Memoria usada La cantidad de memoria caché usada para pares clave-valor en la caché en MB. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
usedmemory |
No | Bytes (unidades de información digital) | Máxima | <ninguno> | PT1M | Sí |
|
Porcentaje de memoria usada El porcentaje de memoria caché usada para pares clave-valor. Para obtener más información, consulte https://aka.ms/redis/enterprise/metrics. |
usedmemorypercentage |
No | Porcentaje | Máxima | <ninguno> | PT1M | Sí |
Detalles sobre las métricas de Azure Managed Redis
Las siguientes secciones ofrecen más información y orientación de interpretación para las métricas compatibles con Azure Monitor para Microsoft. Cache/redisEnterprise. Para la lista completa de métricas con sus unidades y tipos de agregación, véase la tabla de métricas soportadas .
Detalles sobre métricas a nivel de clúster
La siguiente tabla proporciona la métrica fuente subyacente de Redis V1 Prometheus y guías adicionales de interpretación para cada métrica a nivel de clúster. Para las definiciones de métricas de origen, véase la referencia de métricas Redis Enterprise Prometheus v1.
| Métrica | Fuente y notas |
|---|---|
| Latencia de caché | Latencia media de las solicitudes controladas por puntos de conexión en el nodo de caché durante el intervalo de informes especificado. Esta métrica se mide en milisegundos y se obtiene de la node_avg_latency métrica Prometheus V1. Esta métrica solo se notifica cuando hay tráfico activo en la memoria caché. |
| Aciertos de caché | La tasa de búsquedas exitosas de claves, expresada como aciertos por segundo. Procedente de la bdb_read_hits métrica V1 Prometheus. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Errores de caché | La tasa de búsquedas de claves fallidas, expresada como fallos por segundo. Procedente de la bdb_read_misses_max métrica V1 Prometheus. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. Los errores de caché no significan necesariamente que haya un problema con la memoria caché. Por ejemplo, cuando se utiliza el modelo de programación cache-aside, una aplicación busca un elemento en primer lugar en la memoria caché. Si el elemento no está allí (error de caché), se recupera de la base de datos y se agrega a la caché para la próxima vez. Los errores de caché son un comportamiento normal del modelo de programación cache-aside. Si el número de errores de caché es mayor de lo esperado, examine la lógica de aplicación que rellena y lee de la memoria caché. Si los elementos se expulsan de la memoria caché debido a la presión de memoria, es posible que haya algunos errores de caché, pero una métrica mejor para supervisar la presión de memoria sería Used Memory or Evicted Keys. |
| Lectura de caché | Representa la tasa del tráfico entrante de red hacia el nodo de caché en bytes por segundo. Este valor proviene de la node_ingress_bytes_max métrica Prometheus V1. Si desea configurar alertas para los límites de ancho de banda de red del lado servidor, créelo con este contador de lectura de caché. Consulte esta tabla para conocer los límites de ancho de banda de los diferentes tamaños y planes de tarifa de caché. Esta es una métrica de tasa, expresada en bytes por segundo. |
| Escritura de caché | Representa la tasa del tráfico de red saliente del nodo de caché en bytes por segundo. Este valor proviene de la node_egress_bytes_max métrica Prometheus V1. Esta es una métrica de tasa, expresada en bytes por segundo. |
| Clientes conectados | Procedente de la node_conns métrica V1 Prometheus, que cuenta los clientes conectados a los puntos finales del nodo. Una vez alcanzado el límite de conexión, se producirá un error en los intentos posteriores de conectarse a la memoria caché. Incluso si no hay ninguna aplicación de cliente activa, puede haber algunas instancias de clientes conectadas debido a procesos y conexiones internos. |
| Unidad Central de Procesamiento (CPU) | Derivado de la node_cpu_idle métrica Prometheus V1, que representa la porción media de tiempo de inactividad de la CPU (un valor de 0 a 1, multiplicado por 100 para expresar un porcentaje) durante el intervalo, y se invierte para reflejar el tiempo ocupado de la CPU. La métrica de CPU incluye procesos en segundo plano, como antimalware que no son estrictamente procesos de servidor de Redis, por lo que a veces puede aumentar independientemente de la carga de trabajo de Redis. Se recomienda usar esta métrica sobre la carga del servidor para la supervisión, ya que admite la exploración en profundidad de nivel de instancia mediante la división en el identificador de instancia, lo que proporciona una mayor granularidad en la que el nodo está bajo presión. |
| Claves expulsadas | La tasa de desahucios clave, expresada como desahucios por segundo. Procedente de la bdb_evicted_objects métrica V1 Prometheus. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Claves expiradas | La tasa de expiraciones clave, expresada como expiraciones por segundo. Procedente de la bdb_expired_objects métrica V1 Prometheus. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Replicación geográfica correcta | Indica el estado del vínculo de replicación geográfica entre las memorias caché de un grupo de Active Geo-Replication. La métrica notifica uno de los dos valores: 0 - desconectado/poco saludable 1 - saludable La métrica está disponible en cachés de capas optimizadas para memoria, equilibradas y optimizadas para proceso con replicación geográfica habilitada. Un valor de 0 no significa que se hayan perdido los datos de la réplica geográfica. Simplemente significa que el vínculo entre la base de datos geográfica principal y secundaria es incorrecto. Esta métrica puede indicar un estado de replicación desconectado o incorrecto por varios motivos, como la aplicación de revisiones mensuales, las actualizaciones del sistema operativo host, la configuración incorrecta de la red o el aprovisionamiento de vínculos de replicación geográfica con errores. El servicio Azure Managed Redis revisa periódicamente las memorias caché con las últimas características y mejoras de la plataforma. Durante estas actualizaciones, cada nodo de caché se desconecta, lo que deshabilita temporalmente el vínculo de replicación geográfica. Si el vínculo de replicación geográfica es incorrecto, compruebe si se debe a un evento de aplicación de revisiones en la caché geográfica principal o secundaria geográfica mediante Diagnóstico y solución de problemas en el menú Recurso del portal. En función de la cantidad de datos de la memoria caché, el tiempo de inactividad de la aplicación de revisiones puede tardar entre unos minutos y una hora. Si el vínculo de replicación geográfica es incorrecto durante más de una hora, abra una solicitud de soporte técnico. |
| Se | La velocidad de operaciones de lectura, expresada como operaciones por segundo. Procede de la bdb_read_req métrica V1 Prometheus, que representa la tasa de todas las solicitudes de lectura en la base de datos y es equivalente a la suma de los acertos y fallos de caché. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Operaciones por segundo | Número total de solicitudes controladas por segundo por todas las particiones de la memoria caché durante el intervalo de informes especificado. Este valor proviene de la bdb_instantaneous_ops_per_sec métrica Prometheus V1. Esta es una métrica de tasa, expresada como operaciones por segundo. |
| Carga de servidor | La métrica de Carga del Servidor refleja la propia evaluación del servidor Redis sobre la carga total. Al igual que la métrica de CPU , se deriva de la node_cpu_idle métrica V1 Prometheus, invertida para reflejar el tiempo ocupado del servidor. La diferencia es que la carga del servidor se mide a nivel de clúster, mientras que la CPU se mide a nivel de nodo (instancia).Que la carga del servidor llegue a 100 no significa necesariamente que la CPU esté agotada en toda la caché; puede indicar que la CPU de uno de los nodos se acerca a la saturación. Por esta razón, evalúa tanto la carga del servidor como la métrica de CPU por nodo antes de tomar decisiones relacionadas con el rendimiento, como escalar o particionar datos en múltiples cachés. La alta carga sostenida del servidor puede tener varios efectos secundarios, incluyendo un aumento de la latencia en el lado del servidor y excepciones por tiempo de espera. Precaución: Para las cachés gestionadas de Redis de Azure, la carga del servidor a veces refleja valores superiores a 100. Recomendamos usar la métrica de CPU en su lugar, o evaluar ambas métricas a la unidad, antes de tomar decisiones basadas en el rendimiento. |
| Conjuntos | La tasa de operaciones de escritura, expresada como operaciones por segundo. Procedente de la bdb_write_req métrica Prometheus V1, que representa la tasa de todas las solicitudes de escritura en la base de datos. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Total de claves | Procedente de la bdb_no_of_keys métrica V1 Prometheus.Importante: Debido a una limitación en el sistema de métricas subyacente para cachés con clústeres activados, Total Keys devuelve el número máximo de claves del shard que tuvo el mayor número de claves durante el intervalo de informe. Para ver conteos precisos de claves por fragmento en una caché agrupada, utiliza la métrica de Recuento de Claves de Fragmento a nivel de fragmento, segmentada por la Slots (Range) dimensión. |
| Operaciones totales | La tasa de todas las operaciones, expresada como operaciones por segundo. Procedente de la bdb_total_req métrica V1 Prometheus. Esto es una métrica de tasas; su unidad Azure Monitor se muestra como Conteo, pero el valor es una tasa por segundo. |
| Memoria usada | Procedente de la bdb_used_memory métrica V1 Prometheus. En las memorias caché de niveles optimizados para Flash, este valor incluye tanto el uso de memoria RAM como de memoria flash. Este valor no incluye la fragmentación.Cuando la alta disponibilidad está habilitada, el valor Memoria usada incluye la memoria en los nodos principal y de réplica. Esto puede hacer que la métrica aparezca el doble de grande de lo que se esperaba. |
| Porcentaje de memoria usado | Calculado como la proporción de bdb_used_memory a bdb_memory_limit partir de las métricas Redis Enterprise V1 Prometheus. Este valor no incluye la fragmentación. |
Métricas a nivel de fragmento
Azure Managed Redis ahora expone métricas a nivel de shard que proporcionan visibilidad por shard sobre el comportamiento de la caché. Estas métricas se obtienen de los endpoints Redis V2 Prometheus (redis_server_* métricas).
Dimensiones
Cada métrica a nivel de fragmento soporta las siguientes dimensiones:
| Dimension | Nombre en la API de REST | Description |
|---|---|---|
Instance ID |
InstanceId |
Identifica el nodo Redis específico (instancia de VM) dentro del clúster. Utiliza esta dimensión para aislar el comportamiento por nodo e identificar el desequilibrio de carga entre los nodos. |
Slots (Range) |
Slots |
Identifica el fragmento por su rango de ranuras hash. Utiliza esta dimensión para detectar desequilibrio de memoria o distribución desigual de claves entre fragmentos. |
Shard ID |
Shard |
Identificador único de fragmento usando el UID de fragmentos Rederis. Utiliza esta dimensión junto Slots (Range) para correlacionar los datos de Azure Monitor con identificadores de fragmentos a nivel Redis. |
Shard Role |
Role |
Rol del nodo: primary o replica. Utiliza esta dimensión para comparar métricas entre nodos primario y réplica en el mismo fragmento. |
Note
Cuando dividas o filtres por una dimensión a través de la API REST de Azure Monitor, usa el valor en la columna Nombre de la API REST en lugar del nombre de visualización del portal. Los nombres de métricas y de dimensiones en la API REST de Azure Monitor no distinguen a mayúsculas y mayúsculas. Por ejemplo, consultar percentProcessorTime, PercentProcessorTime, o PERCENTPROCESSORTIME todos devolven los mismos resultados. Lo mismo ocurre con los valores de los filtros de dimensión: instanceId eq '*' y INSTANCEID eq '*' son equivalentes. La carcasa utilizada en este artículo es una convención solo para legibilidad.
Importante
Estas métricas se publican a nivel de fragmento. Cuando se consulta sin dividirla por dimensión, Azure Monitor agrega valores entre todos los shards usando el tipo de agregación predeterminado. Para la mayoría de las métricas, esta agregación cruzada de fragmentos no produce totales significativos a nivel de clúster. Siempre dividido por dimensión Slots (Range) para un análisis preciso por fragmento.
Detalles sobre métricas a nivel de fragmento
La siguiente tabla proporciona la métrica fuente subyacente de Redis V2 Prometheus y guías adicionales de interpretación para cada métrica a nivel de fragmento. Para las definiciones de métricas de origen, consulte la referencia de métricas Redis Enterprise Prometheus v2.
| Métrica | Detalles |
|---|---|
| Memoria del fragmento utilizada (bytes) (vista previa) | Memoria usada por este fragmento, en bytes. En los SKUs habilitados para flash, esto incluye tanto el uso de DRAM como de flash. Procedente de la redis_server_used_memory métrica Redis V2 Prometheus. |
| Clientes de memoria Shard Normal (bytes) (Vista previa) | Memoria actual utilizada para buffers de entrada y salida de clientes no réplica. Procedente de la redis_server_mem_clients_normal métrica Redis V2 Prometheus. |
| Réplica de clientes de memoria fragmentada (bytes) (vista previa) | Memoria actual utilizada para búferes de entrada y salida de clientes réplica. Procedente de la redis_server_mem_clients_slaves métrica Redis V2 Prometheus. |
| Recuento de claves de fragmentos (Vista previa) | Recuento total de claves. Procedente de la redis_server_db_keys métrica Redis V2 Prometheus. |
| Enlace de replicación de fragmentos (Vista previa) | Indica si una réplica está conectada a su primaria. Procede de la redis_server_master_link_status métrica Redis V2 Prometheus, que solo se emite por fragmentos réplica, porque solo una réplica tiene un enlace de replicación de vuelta a su primario para informar. |
Métricas de grandes claves
Las siguientes métricas rastrean la distribución del tamaño de las claves entre shards, ayudándote a identificar claves grandes antes de que causen problemas de rendimiento.
Note
Las métricas de Big Key aún no están soportadas en cachés geo-replicadas activas. El soporte para estas métricas para cachés geo-replicadas llegará en una fecha posterior.
Claves de cadena (por tamaño de memoria)
| Métrica | Detalles |
|---|---|
| Tamaños de cadenas de fragmentos inferiores a 128 MB (Vista previa) | Número de claves de cadena en este fragmento con un tamaño de memoria inferior a 128 MB. |
Claves de conjunto (por número de elementos)
| Métrica | Detalles |
|---|---|
| Fragmento coloca elementos por debajo de 1M de elementos (Vista previa) | Número de claves de conjunto en este fragmento con menos de 1 millón de elementos. |
| Elementos de 1M a 8M de Elementos en el fragmento del fragmento (Vista previa) | Número de claves de conjunto en este fragmento con entre 1 y 8 millones de elementos. |
| Fragmento de elementos sobre 8 millones de elementos (vista previa) | Número de claves de conjunto en este fragmento con más de 8 millones de elementos. |
Claves de conjunto ordenadas (por número de elementos)
| Métrica | Detalles |
|---|---|
| Conjuntos ordenados en fragmentos por debajo de 1M de elementos (vista previa) | Número de claves de conjunto ordenadas en este fragmento con menos de 1 millón de elementos. |
| Fragmentos ordenados Elementos de 1M a 8M (Vista previa) | Número de claves de conjunto ordenadas en este fragmento con entre 1 y 8 millones de elementos. |
| Elementos de conjuntos ordenados en fragmentos sobre 8 millones de elementos (vista previa) | Número de claves de conjunto ordenadas en este fragmento con más de 8 millones de elementos. |
Claves hash (por número de campos)
| Métrica | Detalles |
|---|---|
| El fragmento hasha elementos por debajo de 1M de elementos (Vista previa) | Número de claves hash en este shard con menos de 1 millón de campos. |
| Fragmentos hashean elementos de 1M a 8M (Vista previa) | Número de claves hash en este shard con entre 1 y 8 millones de campos. |
| El fragmento hashea los elementos sobre 8 millones de elementos (vista previa) | Número de claves hash en este shard con más de 8 millones de campos. |
Claves de lista (por número de elementos)
| Métrica | Detalles |
|---|---|
| Fragmento enumera elementos bajo 1M de elementos (vista previa) | Número de claves de lista en este fragmento con menos de 1 millón de elementos. |
| Fragmento enumera elementos de 1M a 8M (Vista previa) | Número de claves de lista en este fragmento con entre 1 y 8 millones de elementos. |
| Shard enumera elementos con más de 8 millones de elementos (vista previa) | Número de claves de lista en este fragmento con más de 8 millones de elementos. |
Resolución de problemas con métricas a nivel de fragmento
Las siguientes secciones describen los escenarios comunes a nivel de fragmento y cómo diagnosticarlos:
- Identificación de fallos en enlaces de replicación
- Identificación del desequilibrio de memoria
- Diagnóstico del crecimiento del búfer de replicación
- Gestión de teclas grandes
Identificación de fallos en enlaces de replicación
Un fallo en el enlace de replicación ocurre cuando un fragmento primario no puede establecer una conexión de replicación con su fragmento réplica asociado, por lo que la réplica ya no puede mantenerse sincronizada con el primario. Esta métrica solo la emiten los fragmentos réplica, porque solo una réplica tiene un enlace de replicación de vuelta a su primario para informar, y informa si esa réplica está actualmente conectada a su primario. Un fallo sostenido elimina la protección de alta disponibilidad para el fragmento afectado y aumenta el riesgo de pérdida de datos si ocurre una conmutación por error antes de que el enlace se recupere. Dicho esto, el enlace de replicación puede volverse temporalmente inestable durante conmutaciones por error, migración de fragmentos, escalado o eventos de mantenimiento, por lo que esta métrica puede ser ruidosa. Por eso es importante, cuando configuras alertas con esta métrica, alertar solo durante un periodo sostenido con múltiples datos que indiquen caídas en la salud.
Enfoque de detección:
-
Enlace de replicación de fragmentos divididos por
Slots (Range). Un valor de 0 en cualquier fragmento significa que el enlace de replicación del fragmento está caído; 1 significa que está arriba. - Trata un enlace que permanece en 0 durante un periodo prolongado (por ejemplo, 120 minutos o más) como un fallo persistente en lugar de una reconexión transitoria. Pueden producirse caídas breves durante el mantenimiento normal o eventos de fallo.
- Correlacionar con Shard Memory Used y Shard Memory Clients Replica en el mismo shard para ver si la presión de recursos sobre el primario acompaña al fallo.
Causas comunes:
- Las llaves grandes son una causa importante. Las claves y colecciones grandes hacen que la sincronización sea lenta y costosa, lo que puede estancar la réplica y, eventualmente, llevar el enlace de replicación a un estado poco saludable.
- Interrupción de la red o alta latencia entre los nodos primario y réplica.
- El shard principal está sobrecargado (alto rendimiento de escritura o saturación de CPU), así que no puede dar servicio a la replicación.
- La presión de memoria en el primario impedía las operaciones en segundo plano necesarias para sincronizar la réplica.
- Ciclos repetidos de resincronización completa causados por una réplica lenta que queda por detrás del atraso de replicación.
Remediación:
- Reduce el rendimiento sostenido de escritura o escala la caché para añadir capacidad y así el shard primario esté menos saturado.
- Identifica y desestructura las claves grandes, lo que hace que la replicación y resincronización sean más caras en el shard afectado.
- Si el enlace permanece caído después de que la carga se reduja, abre una solicitud de soporte para que el equipo de la plataforma pueda investigar la salud del nodo y el backlog interno de replicación.
Identificación del desequilibrio de memoria
El desequilibrio de memoria ocurre cuando algunos fragmentos consumen significativamente más memoria que otros, lo que puede llevar a expulsiones de fragmentos específicos mientras que otros tienen abundante memoria libre.
Enfoque de detección:
-
Memoria de fragmentos dividida utilizada (bytes) por
Slots (Range). Una relación máxima/mínima mayor a 2x indica un desequilibrio significativo. - Correlaciona con el recuento de claves de fragmentos para
Slots (Range)determinar si el desequilibrio se debe a más claves o a valores más altos en fragmentos específicos.
Causas comunes:
- Uso indebido de hashtags concentrando grandes cantidades de teclas en el mismo fragmento.
- Claves importantes: un pequeño número de estructuras de datos muy grandes en un shard específico.
- Políticas TTL inconsistentes que causan divergencia en el uso de memoria a lo largo del tiempo.
Remediación:
- Redistribuye las claves revisando y variando el uso de hashtags.
- Identifica y descompone las grandes claves usando las métricas de claves grandes para localizar los fragmentos afectados.
- Revisa las políticas TTL para claves en fragmentos de alta memoria.
Diagnóstico del crecimiento del búfer de replicación
Cada shard primario mantiene un búfer de salida para su réplica que pone en cola las escrituras que la réplica aún no ha aplicado. Cuando una réplica no puede seguir el ritmo, este búfer crece y consume memoria en el fragmento. Si crece sin límites, la réplica puede desconectarse y forzarse a una resincronización completa, lo cual es costoso y puede desencadenar ciclos repetidos de resincronización o incluso que la sincronización de replicación se vuelva poco saludable. Como cada fragmento tiene su propio buffer réplica, el crecimiento suele aislarse a fragmentos específicos.
Enfoque de detección:
- Divide los clientes de memoria de fragmentos (bytes) y
Slots (Range)busca una tendencia sostenida al alza en cualquier fragmento durante 15 minutos o más, en lugar de una sola lectura alta. El crecimiento constante es la señal, no un pico momentáneo. - Correlaciona con Replicación de Fragmento Enlace Up en el mismo fragmento. El crecimiento del búfer que termina con el enlace bajando a 0 indica que la réplica fue desconectada y es probable una resincronización.
- Correlaciona con la actividad de escritura intensiva (conjuntos y operaciones totales a nivel de clúster) para ver si una ráfaga de escritura está impulsando el crecimiento.
Causas comunes:
- Una ráfaga de escritura sostenida produce cambios más rápido de lo que la réplica puede aplicarlos.
- Una réplica lenta, bajo la contienda por recursos, quedando por detrás de la primaria.
- Bucles de resincronización repetidos que rellenan el búfer repetidamente.
- Claves grandes que hacen que las operaciones replicadas individuales sean grandes y lentas de transferir.
Remediación:
- Suaviza o reduce las ráfagas de escritura cuando sea posible, o escala la caché para aumentar la capacidad.
- Identificar y descomponer las grandes claves para reducir el tamaño de las operaciones replicadas individuales.
- Si el búfer sigue creciendo y la réplica se desconecta repetidamente, abre una solicitud de soporte para que el equipo de la plataforma pueda revisar la salud y el tamaño del búfer de la réplica, que son gestionados por el servicio.
Gestión de teclas grandes
Las grandes claves y colecciones grandes aumentan la presión de memoria sobre fragmentos individuales y hacen que la replicación sea más costosa. Para el mejor rendimiento en la ruta de datos, mantén tamaños de clave/valor individuales por debajo de 512 KB. Esto es una recomendación de rendimiento, no un límite impuesto.
Los buckets de métricas de las grandes claves solo monitorizan límites—no se recomiendan ni avalan tamaños de clave. Por ejemplo, el bucket de Tamaños de Cadenas de Fragmentos por debajo de 128 MB simplemente cuenta las claves de cadena menores a 128 MB para que puedas vigilar el crecimiento; eso no significa que Azure recomiende almacenar claves cerca de 128 MB. Del mismo modo, los cubos de conteo de elementos (1M, 8M) son umbrales para detectar colecciones sobredimensionadas, no tamaños objetivo. Siempre apunta al tamaño de clave práctico más pequeño (idealmente menos de 512 KB), y trata cualquier clave que suba a un compartimento más alto como algo a investigar.
Las métricas de las grandes claves agrupan las buckets en rangos de tamaño para que puedas detectar crecimiento antes de que cause problemas. Para colecciones, el primer cubo representa las claves dentro del rango normal, así que considera cualquier clave que aparezca en el segundo o tercer compartimento como algo que merece la pena investigar. Para las claves de cadena, solo se expone el cubo de menos de 128 MB, por lo que considera cualquier valor de cadena que se acerque o supere los 128 MB como una preocupación.
Por qué importan las teclas grandes:
- Coste de replicación: Las claves grandes hacen que tanto la replicación de alta disponibilidad como la geo-replicación activa (CRDB) sean más costosas. El efecto no es inmediato; normalmente aparece durante una resincronización completa provocada por un fallo o reconexión posterior.
- Impacto en la caché optimizada para Flash: En los SKUs optimizados para Flash, si una clave es grande, permanece en la RAM y no se descarga en flash, lo que puede causar errores de falta de memoria (OOM) incluso cuando queda espacio disponible en disco flash. Los valores que son muy pequeños en relación con su nombre clave también se compensan mal.
Enfoque de detección:
- Divide cada métrica de claves grandes por
Slots (Range)para ver qué fragmentos contienen las claves grandes. - Para colecciones, céntrate en los segundo y tercer compartimentos de conteo de elementos (1M a 8M y más de 8M). El tercer cubo representa las tonalidades más extremas. Para cadenas, solo se expone el bucket de cadenas de fragmentos de menor a 128 MB , así que considera cualquier valor de cadena igual o superior a 128 MB como una preocupación.
- Correlacionar con la memoria de fragmentos Usada por
Slots (Range)para confirmar si las claves grandes están provocando un desequilibrio de memoria en fragmentos específicos.
Remediación:
- Reduce el tamaño del valor hacia el primer cubo o 512 KB como mejor práctica. Las estrategias comunes incluyen separar o fragmentar un valor grande entre varias claves, y comprimir o reformatear el valor serializado.
- Para colecciones (Listas, Conjuntos, Conjuntos Ordenados y Hashes) que crecen sin límites con el tiempo, divide la colección en varias claves o recórtala periódicamente.
- El objetivo es reducir el tamaño de la clave individual y la colección. El mejor método depende del diseño de tu aplicación y del tipo de datos.
Recomendaciones de alerta para métricas a nivel de fragmento
| Scenario | Métrica | Condition | Ventana de evaluación | Severity |
|---|---|---|---|---|
| Fallo del enlace de replicación | Enlace de replicación de fragmentos, dividido por Slots (Range) |
Mínimo = 0 en cualquier fragmento | 120+ min | Alto |
| Desequilibrio de memoria | Memoria de fragmentos utilizada (bytes), dividida por Slots (Range) |
Ratio máxima/mínima entre ranuras > 2x | 5 min | Medium |
| Crecimiento del búfer de replicación | Réplica de clientes de memoria fragmentada (bytes), dividida por Slots (Range) |
Aumento sostenido durante 15 minutos | 15 minutos | Medium |
| Colecciones muy grandes (tercer cubo) | Cualquier métrica de bucket de recopilación "Over 8M Elements", dividida por Slots (Range) |
Valor > 0 en cualquier fragmento | Más de 10 minutos | Alto |
| Colecciones grandes (segundo cubo) | Cualquier métrica de bucket de recopilación "1M a 8M Elements", dividida por Slots (Range) |
El número de cubos como una proporción total de claves de ese tipo supera los 10% | Más de 10 minutos | Medium |
| Teclas grandes de cuerda | Tamaños de cadenas de fragmentos inferiores a 128 MB (el único cubo de cuerdas expuesto) | Cualquier valor de cadena igual o superior a 128 MB es motivo de preocupación; observa el recuento de teclas por debajo de 128 MB que crecen hacia el umbral | Más de 10 minutos | Informativo |
Note
La alerta de fallo de enlace de replicación puede crearse directamente como una alerta de métrica de Azure Monitor, porque la métrica se agrega como Minimum, por lo que un valor de 0 sobre la ventana indica que el enlace estuvo caído en algún momento. La alerta de colecciones muy grandes (tercer cubo) también puede crearse de forma nativa, porque prueba una única métrica frente a un umbral fijo (valor mayor que 0). Los escenarios restantes no pueden evaluarse de forma nativa con alertas métricas de Azure Monitor: las alertas métricas no pueden comparar valores entre valores dimensionales (por ejemplo, una proporción máxima/mínima entre Slots (Range)ellos), no pueden calcular una proporción entre dos métricas (por ejemplo, un segundo cubo cuenta como una cuota de claves totales de ese tipo) y no pueden detectar una tendencia sostenida al alza. Solo prueban si un valor cruza un umbral fijo en un momento determinado. Crea estas como alertas de búsqueda de registro sobre las métricas exportadas: envía métricas a un espacio de trabajo de Log Analytics usando la configuración de diagnóstico, y luego calcula la proporción máximo/minuto, la cuota de cubos o la tendencia en una consulta Kusto (KQL). Las métricas del primer grupo no necesitan alertas; Vigila su tendencia a lo largo del tiempo.
Registros de recursos
En esta sección se enumeran los tipos de registros de recursos que se pueden recopilar para este servicio. La sección extrae de la lista de todos los tipos de categorías de registros admitidos en Azure Monitor.
Registros de recursos admitidos para Microsoft.Cache/redisEnterprise/databases
| Categoría | Costes de exportación | Tabla de registro | Admite el plan de registro básico | Permite la transformación en el momento de la ingesta. | Consultas de ejemplo |
|---|---|---|---|---|---|
| Eventos de conexión (nueva conexión/autenticación/desconexión) | Sí |
REDConnectionEvents Registra los eventos de conexión cuando el cliente se conecta a la base de datos empresarial de Redis. |
Sí | Sí | Consultas |
Tablas de registros de Azure Monitor
En esta sección, se enumeran todas las tablas de registros de Azure Monitor relacionadas con este servicio y que están disponibles para consulta mediante Log Analytics con consultas de Kusto. Las tablas contienen datos de registro de recursos y, posiblemente, más dependiendo de lo que se recopila y se enrutan a ellos.
Azure Managed Redis
Microsoft.Cache/redisEnterprise
Registro de actividad
En la tabla vinculada se enumeran las operaciones que se pueden registrar en el registro de actividad de este servicio. Estas operaciones son un subconjunto de todas las posibles operaciones del proveedor de recursos en el registro de actividad.
Para obtener más información sobre el esquema de las entradas del registro de actividad, consulte Esquema del registro de actividad.
Contenido relacionado
- Consulte Supervisión de los recursos de Azure con Azure Monitor para obtener información sobre la supervisión de los recursos de Azure.