Monitoreo de SAP HANA con RybaFish: KPI personalizados

Hola, comunidad HANA.

Hoy quiero llamar su atención sobre el aspecto visual de la presentación de la información.

El cerebro humano es increíblemente bueno para obtener e interpretar información visual. Pasamos años en nuestras escuelas secundarias y universidades analizando gráficos de funciones y obteniendo información común con esta forma de información. Una gran parte de esos gráficos tiene el tiempo en el eje X, en este caso, tenemos la dependencia del valor en el tiempo. Un ejemplo extremo de este enfoque es la llamada «caja negra» o lecturas del registrador de vuelo utilizadas en la investigación de accidentes de aeronaves.

Esquema simplificado de la lectura de un registrador de vuelo

La característica clave de los cambios en el cuadro negro son varios gráficos en la misma línea de tiempo. Los valores pueden estar en diferentes unidades de medida, lo que puede resultar confuso al principio, porque no puede comparar directamente diferentes métricas. Pero tener cosas en el mismo gráfico permite ver cómo se correlacionan los diferentes indicadores y puede obtener una imagen multidimensional de los procesos del sistema multifactorial.

La gente ha estado usando esos gráficos durante décadas para analizar el comportamiento de un sistema tan complejo como los aviones modernos, entonces, ¿por qué no usamos el mismo enfoque para el análisis de la base de datos? Y en mi experiencia, no tiene más que sentido: puede obtener una impresión muy rápida del comportamiento del sistema con solo echar un vistazo rápido a dicho gráfico.

Bien, ahora a SAP HANA

Afortunadamente, SAP HANA ya contiene un «registrador de vuelo» de este tipo. El servidor de nombres recopila mucha telemetría útil y la coloca en el archivo nameserver_history.trc. Esta información también está disponible en las vistas de m_load_history*. Y estos datos se pueden visualizar para su interpretación, lo que nos brinda un fácil acceso al interior del comportamiento de la base de datos.

La telemetría de servidor de nombres estándar incluye KPI tales como uso de memoria, uso de CPU, actividad de disco y red, transacciones, bloqueos y muchos, muchos más: hay ~50 (!) de ellos disponibles para cada servicio SAP HANA. Esto ya brinda información bastante detallada sobre la salud de la base de datos. Pero el servidor de nombres está limitado a este conjunto decente pero fijo de KPI elegidos por los ingenieros de SAP para ser recopilados cuidadosamente cada 10 segundos por cada instancia de SAP HANA en el universo observable.

En algunas situaciones, podemos beneficiarnos de tener información adicional en la pantalla basado en otras fuentes de datos como vistas de monitoreo, tablas de servicios de estadísticas o incluso tablas de negocios. Y esto se puede hacer con KPI personalizados.

Hay tres tipos de KPI personalizados en rybapeces: Regular, Gantt y Multilínea.

KPI regulares

Los KPI personalizados regulares tienen el mismo principio que los estándar: se realiza una medición en cada momento. A diferencia de los estándar, los KPI personalizados regulares se basan en una fuente alternativa de datos (no vistas m_load_history*). Hay una publicación de blog con una implementación paso a paso de KPI personalizado para monitorear el tamaño de la tabla de SAP HANA.

Gráfico de gantt

Gracias a Henry Gantt, tenemos una forma común de visualizar procesos en líneas de tiempo. Y esta podría ser una forma extremadamente informativa de mostrar actividades en un sistema tan ruidoso como una base de datos corporativa.

A diferencia de los KPI estándar, como el uso de memoria o el consumo de CPU, los procesos tienen tiempos de inicio y finalización. Ejemplos de procesos son: fusiones delta, puntos de guardado, trabajos abap, subprocesos internos, etc. Pero el más utilizado son las declaraciones caras.

La mayoría de las actividades en la base de datos tienen una declaración correspondiente y, con una configuración de seguimiento adecuada, las que generan un consumo excesivo de recursos se registrarán en el seguimiento de declaraciones costosas. Lo que se registra, se puede visualizar.

En este caso, vemos que tres usuarios (DATALOAD, RIP_THE, TESTER) estaban ejecutando declaraciones en este lapso de tiempo. Está muy claro que las sentencias ejecutadas por el usuario RYP_THE están perfectamente alineadas con un mayor consumo de memoria y CPU. Por lo tanto, conocemos al usuario, el impacto exacto y, si es necesario, también la declaración en sí: en la aplicación, se puede hacer clic en las barras de Gantt y puede ver el texto real de la declaración.

Esta técnica cubre al menos el 80-85% de las actividades inusuales en la base de datos, y es muy conveniente cuando puede acceder a esta información con solo un clic del mouse.

multilínea

En algunos casos, la información tiene una “dimensión” adicional proveniente de la propia fuente de datos. Esta característica se puede utilizar en la visualización para obtener información adicional sobre el gráfico.

Por ejemplo, echemos un vistazo a los datos agregados de host_heap_memory. Hay una columna de «componentes» que proporciona información adicional sobre los propósitos de asignación de memoria:

select server_timestamp, component, sum(exclusive_size_in_use)
from _sys_statistics.host_heap_allocators
where port = 30003
group by server_timestamp, component
order by server_timestamp desc, component;

Una vez visualizado esto, veremos la distribución de la memoria del montón entre los diferentes componentes (no se incluye el almacenamiento de filas):

Ahora es obvio que el mayor consumo de memoria está relacionado con los componentes «Sistema» y «Column Store». Lo que también es interesante: después de la ejecución de cada declaración, el componente del sistema cae a su línea de base, pero el componente del almacén de columnas generalmente permanece en un nivel un poco más alto, en comparación con el inicio de la ejecución de la declaración. Esto ya revela mucho sobre esta actividad, pero podemos obtener aún más del mismo diagrama.

Si hacemos zoom en la «Ejecución sospechosa» después de las 07:30, podemos ver que hay una superposición con otra declaración, ejecutada por el usuario llamado TESTER:

Este usuario desencadenó dos ejecuciones, y en ambas ocasiones resultó en un pico de uso de memoria hasta el límite de asignación.

Lo que también es interesante aquí: después de la primera ejecución a las 07:38:20, el consumo de memoria en el componente Column Store disminuyó. Teóricamente, podría haber varias razones para eso, pero considerando que el uso de la memoria aumentó hasta el límite de asignación, lo más probable es que haya sido un evento de descarga de columna: HANA estaba tratando de liberar algo de memoria en un intento desesperado por continuar con la declaración codiciosa. Y esto se confirma al verificar el KPI de descarga de columna (un pico de la línea rosa). En este caso particular, ambas declaraciones fueron terminadas como víctimas del evento de falta de memoria.

Nota: el servidor de nombres recopila los KPI estándar del servidor de nombres con mayor granularidad en comparación con los componentes de memoria. De forma predeterminada, la granularidad del servidor de nombres es de 10 segundos, los componentes de memoria: 15 minutos. Por el bien de esta demostración, esas configuraciones se ajustaron a 1 segundo y 1 minuto respectivamente.

La información no agregada de la misma fuente proporciona una visión aún más profunda del propósito del uso de la memoria: por categoría de memoria (los llamados asignadores):

Nota: a diferencia del ejemplo anterior, en este caso se utiliza la visualización “apilada”.

Resumen

La visualización puede reducir significativamente el esfuerzo para obtener una comprensión rápida del comportamiento del sistema y el desarrollo de la situación. Por supuesto, no puede reemplazar a los humanos y es solo una herramienta en manos del experto. Ayuda a reducir el área problemática y obtener un RCA detallado más rápido.

Un resumen de esto también está disponible en el video:

• Diagrama de Gantt KPI para visualización de extractos caros
• KPI multilínea para detalles de consumo de memoria
• Patrón típico de falta de memoria
• Descripción general rápida de la consola SQL.

Comparta sus comentarios, preguntas, ideas para KPI personalizados y los posibles próximos temas a tratar en el tema de análisis de rendimiento visual de SAP HANA.