Describe cómo ejecutar el diagnóstico de instancias y cómo interpretar los informes de diagnóstico, incluidas las métricas de rendimiento, la distribución sesgada de solicitudes y las consultas lentas.
Ejecutar el diagnóstico en una instancia
Tair (Redis OSS-compatible) integra la función de informes de diagnóstico de Database Autonomy Service (DAS). Esta función le permite crear un informe de diagnóstico para evaluar el estado de una instancia durante un periodo específico. Los informes de diagnóstico recopilan métricas como el nivel de rendimiento, la distribución sesgada de solicitudes y registros de consultas lentas para ayudarle a identificar excepciones en la instancia.
Procedimiento
Inicie sesión en la consola y vaya a la página de Instances. En la barra de navegación superior, seleccione la región donde reside la instancia que desea gestionar. A continuación, busque la instancia y haga clic en su ID.
En el panel de navegación izquierdo, elija .
Haga clic en Create Reports.
-
En el cuadro de diálogo que aparece, especifique el intervalo de tiempo para el cual desea crear un informe de diagnóstico y haga clic en OK.
NotaEl intervalo de tiempo no puede exceder un día. Si especifica un intervalo más corto para el diagnóstico, se recopilarán estadísticas más detalladas en el informe.
-
Actualice la página Diagnostic Report para ver el progreso de la tarea de diagnóstico. Una vez creado el informe, haga clic en View Report en la columna Actions.
NotaPara obtener más información sobre cómo interpretar un informe de diagnóstico, consulte
Understand an instance diagnostic report
.
Interpretación de un informe de diagnóstico de instancia
Un informe de diagnóstico evalúa el estado de una instancia de ApsaraDB for Redis mediante el análisis de métricas de rendimiento, la distribución de solicitudes y los datos de consultas lentas. Utilícelo para identificar anomalías y tomar medidas antes de que afecten a su negocio.
Secciones del informe
Un informe de diagnóstico consta de cuatro secciones:
Información básica de la instancia: el ID de la instancia, el tipo de instancia, la versión del motor y la zona donde está desplegada la instancia.
Resumen: la puntuación de salud de la instancia y un desglose de las deducciones.
Nivel de rendimiento: el estado actual de las métricas clave de rendimiento.
TOP 10 nodos con mayor número de consultas lentas: los 10 principales nodos de datos por cantidad de consultas lentas, con detalles sobre dichas consultas.
Información básica de la instancia
Muestra el ID de la instancia, el tipo de instancia, la versión del motor y la región donde está desplegada la instancia.
El periodo de diagnóstico abarca desde las 11:10:23 del 1 de marzo de 2021 hasta las 14:10:23 del 1 de marzo de 2021. La información básica de la instancia incluye los siguientes campos:
Instance ID: El ID y el nombre de la instancia (ejemplo de sufijo: "-Diagnostic Report Test").
Specification: 2 GB Cluster Edition (2 nodos).
Instance type: Redis 5.0.
Zone: China (Hangzhou).
Resumen
Muestra la puntuación general de salud de la instancia. La puntuación máxima es 100. Las puntuaciones inferiores a 100 enumeran los elementos de diagnóstico que causaron deducciones y explican el motivo.
La puntuación de salud es de 70 sobre 100. Los siguientes elementos causaron deducciones:
Alta utilización de CPU: La utilización de CPU alcanzó el 85.9%, superando el umbral seguro. Se dedujeron 10 puntos.
Alto uso de memoria: El uso de memoria alcanzó el 100.0%, superando el umbral seguro. Se dedujeron 10 puntos.
Acceso a registros lentos: Se registraron 12 entradas principales de registros lentos en el servidor. Se dedujeron 10 puntos.
Nivel de rendimiento
Muestra el estado actual de las métricas clave de rendimiento. Preste especial atención a cualquier métrica en estado Hazard, ya que lecturas sostenidas por encima del umbral pueden degradar el rendimiento y aumentar la latencia.
Para instancias que se ejecutan en una arquitectura de clúster o de división de lectura/escritura, compruebe si las métricas están distribuidas de manera desigual entre los nodos de datos. Revise los gráficos de curva de Top 5 Nodes para cada métrica e identifique qué nodos tienen la carga más alta. Para obtener detalles sobre la arquitectura, consulte Cluster master-replica instances y Read/write splitting instances .
La siguiente tabla describe cada métrica, su umbral, el impacto empresarial de superar dicho umbral y cómo solucionar problemas.
| Métrica | Umbral | Aplicable a | Impacto | Posibles causas y siguientes pasos |
|---|---|---|---|---|
| Utilización de CPU | 60% | Todas las arquitecturas | Una alta utilización de CPU reduce el rendimiento y aumenta el tiempo de respuesta. Los clientes pueden dejar de responder. | Causas: comandos de alta complejidad, claves activas o creación frecuente de conexiones. Consulte Troubleshoot high CPU utilization on an instance. |
| Memory usage | 80% | Todas las arquitecturas | Un uso elevado y sostenido de memoria aumenta el tiempo de respuesta, desestabiliza las consultas por segundo (QPS) y provoca la expulsión frecuente de claves. | Causas: agotamiento de memoria o gran cantidad de claves grandes. Consulte Troubleshoot high memory usage on an instance. |
| Connections usage de nodos de datos | 80% | Solo instancias de clúster en modo de conexión directa. Cuando los clientes se conectan a través de nodos proxy, monitoree las conexiones a nivel de nodo proxy. Consulte Enable the direct connection mode y View performance monitoring data. | Cuando las conexiones alcanzan el límite, las nuevas solicitudes de conexión caducan o fallan. | Causas: picos de tráfico o conexiones inactivas no liberadas. Consulte Instance sessions. |
| Tráfico entrante | 80% | Todas las arquitecturas | Cuando el tráfico supera el ancho de banda proporcionado por el tipo de instancia, el rendimiento del cliente se degrada. | Causas: picos de carga de trabajo o claves grandes que se leen o escriben con frecuencia. Consulte Troubleshoot high traffic usage on an instance. |
| Outbound traffic | 80% | Todas las arquitecturas |
Distribución sesgada de solicitudes
Para instancias que se ejecutan en cluster architecture o read/write splitting architecture, el informe también verifica si las solicitudes están distribuidas uniformemente entre los nodos de datos. Si se detectan solicitudes sesgadas para una métrica, identifique qué nodos reciben la carga desigual.
El informe marca solicitudes sesgadas cuando se cumplen ambas condiciones siguientes:
-
Los valores máximos en todos los nodos de datos superan los umbrales mínimos indicados a continuación:
Utilización de CPU: 10%
Uso de memoria: 20%
Tráfico entrante y saliente: 5 Mbit/s
Uso de conexiones: 5%
La puntuación de equilibrio supera 1.3. La puntuación de equilibrio se calcula como:
max{average performance value of all data nodes} / median performance value of all data nodes. Por ejemplo, una instancia tiene cuatro nodos de datos con una utilización promedio de CPU del 10%, 30%, 50% y 60%. La mediana es 40% y la puntuación de equilibrio es 60% / 40% = 1.5. Dado que 1.5 > 1.3, el informe considera que la utilización de CPU está sesgada.
|
Posible causa |
Método de solución |
|
Un nodo de datos tiene un exceso de claves grandes. |
Utilice offline key analysis feature o top key statistics feature para identificarlas y redistribuirlas. |
|
Un nodo de datos tiene claves activas. |
Utilice top key statistics feature para identificar las claves activas. |
|
Las etiquetas hash están configuradas incorrectamente. Las claves con la misma etiqueta hash siempre se colocan en el mismo nodo de datos. Si muchas claves comparten una etiqueta hash, ese nodo se sobrecarga. |
Revise y ajuste su configuración de etiquetas hash para distribuir las claves entre los nodos. |
TOP 10 nodos con mayor número de consultas lentas
Enumera los 10 principales nodos de datos por cantidad de consultas lentas y proporciona detalles sobre dichas consultas. El informe extrae datos de dos fuentes de registros lentos:
Registros de auditoría del sistema: registros lentos conservados durante 4 días.
Registros de nodos de datos: las 1,024 entradas de registro más recientes, almacenadas directamente en cada nodo de datos. Conéctese a la instancia mediante redis-cli y ejecute el comando
SLOWLOG GETpara recuperarlas.
Dos nodos, r-bp***-db-0 y r-bp***-db-1, tienen 6 consultas lentas cada uno. Los principales comandos de consulta lenta y sus duraciones de ejecución son los siguientes:
keys *: Tiempo máximo de ejecución aproximadamente 86 ms, promedio aproximadamente 86 ms.keys key:0000001*: Tiempo máximo de ejecución aproximadamente 62 ms, promedio aproximadamente 59 ms.Múltiples comandos
del: Tiempo de ejecución aproximadamente 12–18 ms.
Utilice los datos de consultas lentas para identificar los comandos que causan problemas de rendimiento.
|
Causa |
Solución |
|
Comandos con complejidad temporal O(N) o alto costo de CPU, como |
Evalúe y deshabilite comandos de alto riesgo como |
|
Claves grandes que se leen o escriben frecuentemente en los nodos de datos |
Analice las claves grandes mediante offline key analysis feature y luego divídalas según sus requisitos empresariales. |