Consultar métricas de CPU en tiempo real desde BBDD con MGMTDB

Si necesitas obtener métricas de CPU como IOWAIT_TIME, IDLE_TIME, SYS_TIME, USER_TIME, NICE_TIME y STEAL_TIME en Oracle en tiempo real y desagregadas, la vista V$OSSTAT puede no ser suficiente porque presenta valores acumulados desde que la base de datos fue iniciada.

Esto significa que no permite obtener fácilmente métricas puntuales o deltas entre intervalos de tiempo recientes sin realizar cálculos adicionales. Además, Oracle no expone estos datos de forma directa y granular en tiempo real a través de vistas como V$SYSMETRIC o V$SYSMETRIC_HISTORY, las cuales presentan datos preprocesados y a veces no incluyen todas las métricas requeridas, lo que limita su utilidad en ciertos escenarios.

Dado que las métricas de CPU están en constante cambio, obtener información en tiempo real es crucial para el diagnóstico y monitoreo preciso del rendimiento del sistema. Como las vistas mencionadas no están diseñadas para proporcionar una imagen instantánea y desagregada de los estados de la CPU, es necesario buscar una alternativa que capture las métricas de manera más detallada.

Estas alternativas podrían implicar capturar los valores de V$OSSTAT en intervalos específicos, calcular los deltas manualmente, o utilizar herramientas de monitoreo del sistema operativo que ofrezcan este tipo de datos en tiempo real. Puf… añadimos complejidad

Para ello, dándole vueltas, he encontrado una solución interesante para obtener las métricas de CPU en tiempo real en Oracle, y es a través de la base de datos GIMR (Grid Infrastructure Management Repository).

En Oracle GIMR (Grid Infrastructure Management Repository) se almacena en una base de datos interna conocida como MGMTDB. Esta base de datos es parte de la infraestructura de Grid y recopila y almacena métricas y datos de diagnóstico del clúster y las bases de datos Oracle.

La MGMTDB está diseñada para almacenar información relacionada con el monitoreo y diagnóstico del sistema, incluyendo métricas de rendimiento, alertas y eventos.

Aunque en versiones anteriores de Oracle, GIMR era obligatoria para ciertas configuraciones de Oracle Real Application Clusters (RAC), en versiones más recientes, como 19c, se ha vuelto opcional, pero sigue siendo una herramienta útil para la gestión avanzada del entorno y nos ofrece acceso detallado a métricas del sistema y de la base de datos, incluyendo aquellas que no están disponibles directamente en vistas como V$OSSTAT.

Una de las ventajas principales de GIMR es que permite capturar métricas en tiempo real de manera más precisa, sin las limitaciones que presentan otras vistas agregadas o históricas. Esto facilita la monitorización del rendimiento, la identificación de cuellos de botella y el análisis de problemas en el sistema en tiempo real, con información más granular y confiable.

Además, mantener GIMR en tu infraestructura tiene otras ventajas clave:

• Almacenamiento centralizado de métricas: GIMR centraliza las métricas del sistema y de la base de datos, lo que facilita su análisis a lo largo del tiempo, permitiendo un enfoque más proactivo para la gestión del rendimiento.

• Optimización del diagnóstico: Al tener acceso a métricas más detalladas y en tiempo real, las herramientas de diagnóstico son más eficaces, lo que mejora la capacidad de detectar problemas antes de que afecten gravemente el sistema.

• Compatibilidad con herramientas de monitoreo: GIMR se integra bien con herramientas de monitoreo avanzadas, simplemente tienen que poder consultar, lo que facilita la automatización y el análisis continuo del estado del sistema.

Pues aquí vino la idea feliz. Y si obtengo los valores directamente desde la BBDD de GIMR, sin necesidad de explotar con oclumon, y que además puedas consultarlas desde base de datos?

Pues te muestro como obtener las métricas de CPU en tiempo real .

Primer paso, tener desplegada la GIMR :) Pasaremos a monitorizarla como es debido, ya que pasará a ser una gran aliada :)

Crearemos un usuario de monitorización en la GIMR (no me he matado mucho, dba y para delante que para eso es mía):

[grid@rac-xxx-001 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Oct 11 13:30:50 2024
Version 19.24.0.0.0

Copyright (c) 1982, 2024, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SYS@-MGMTDB> show pdbs;

    CON_ID CON_NAME              OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     2 PDB$SEED              READ ONLY  NO
     3 GIMR_DSCREP_10          READ WRITE NO

SYS@-MGMTDB> alter session set container=GIMR_DSCREP_10;

Session altered.

-- Creación del usuario

   CREATE USER "CHA_MONITOR" IDENTIFIED BY "XXXXXXX"
      DEFAULT TABLESPACE "USERS"
      TEMPORARY TABLESPACE "TEMP";

   GRANT "CONNECT" TO "CHA_MONITOR";
   GRANT "DBA" TO "CHA_MONITOR";

   ALTER USER "CHA_MONITOR" DEFAULT ROLE ALL;

Creamos entrada de TNSNames para acceso al repositorio en los servidores de BBDD. En mi caso en un RAC de dos nodos.

GIMR =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (LOAD_BALANCE = OFF)
      (FAILOVER = ON)
      (ADDRESS = (PROTOCOL = TCP)(HOST = racvip-xxx-001.xxxxx.local)(PORT = 1525))
      (ADDRESS = (PROTOCOL = TCP)(HOST = racvip-xxx-002.xxxxx.local)(PORT = 1525))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = gimr_dscrep_10)
    )
  )

Y desde la base de datos productiva crearemos el DbLink de acceso más la vista que la explota.

CREATE DATABASE LINK CHM
CONNECT TO CHA_MONITOR IDENTIFIED BY "XXXXXXXXXXX"
USING 'GIMR';

CREATE VIEW "XXXXX"."VM_MONITOR_CPU" ("HOSTNAME", "user", "system", "iowait", "idle", "nice", "steal")  AS 
  WITH nodos AS (
    SELECT hostname,
           cpuuserpercent/100 "user",
           cpusystempercent/100 "system",
           cpuiowaitpercent/100 "iowait",
           100 - (cpuusagepercent/100) "idle",
           cpunicepercent/100 "nice",
           cpustealpercent/100 "steal",
           ROW_NUMBER() OVER (PARTITION BY hostname ORDER BY sampletime DESC) AS rn
    FROM chm.CHMOS_SYSTEM_SAMPLE_INT_TBL@CHM 
    WHERE hostname IN ('rac-xxx-001', 'rac-xxx-002')
      AND sampletime > (SYSDATE - 0.1/24) -- No quedamos último valor de los ultimos minutos
)
SELECT hostname, "user", "system", "iowait", "idle", "nice", "steal"
FROM nodos
WHERE rn = 1;

Resultado…

SYS@pdb_xxxxx> select * from xxxxx.vm_monitor_cpu;

      HOSTNAME    user    system    iowait     idle    nice    steal
______________ _______ _________ _________ ________ _______ ________
rac-xxx-001       1.16      0.48      0.06    98.35       0     0.05
rac-xxx-002       0.52      0.23      0.01    99.24       0     0.01

Nos hemos saltado la capa de SO y podemos consultarlos directamente desde la BBDD! En tiempo real!! Puedes además consultar histórico para diagnóstico como analista de rendimiento sin precisas acceso a SO… se me ocurren mil implementaciones…