Metrics

Metrics y Metric Explorer permiten investigar el histórico del catálogo canónico y comparar dos métricas. Ambas comparten target, hosts y ventana temporal, pero usan ejes Y independientes para conservar sus unidades.

Metrics comparte selector de target, host y ventana temporal con Operations.

Un identificador, dos lecturas

Cada métrica tiene un único metricId canónico. El mismo identificador alimenta:

• current, para Landing, tarjetas de estado y alertas;
• series, para gráficas, Metric Explorer y análisis histórico;
• both, cuando un panel necesita mostrar a la vez el último estado y su tendencia.

Metric Explorer solicita siempre la proyección series. No mantiene una segunda métrica con sufijo -ts, ni transforma una respuesta escalar en una serie artificial. Por ejemplo, icm-queue, enqueue-lock-wait-time y work-process-utilisation-global sirven tanto para su lectura actual como para su histórico.

Las composiciones de Operations no se aplican aquí. Una gráfica que combina ocho consultas en Performance sigue apareciendo como ocho métricas consultables por separado en Metric Explorer.

Las respuestas de métricas usan el contrato estable schemaVersion: 2. En el inspector técnico verás el identificador, unidad, estado, resumen actual y series con identidad estable por host, instancia o tipo. Las variantes antiguas de scalar, grouped, table o string ya no forman parte del catálogo de métricas; las tablas de Jobs, Events y otros datasets conservan sus pantallas específicas.

Estado, frescura y agregados

• Para gauges y estados, current es la observación real más reciente dentro de la ventana seleccionada, no una media ni un máximo del rango.
• Para contadores de eventos, 0 es válido cuando la ventana de estado fue observada y no contiene eventos.
• UNKNOWN significa que falta una muestra fresca o que la fuente todavía no publica esa señal. No equivale a 0, OK ni error funcional.
• SPOT considera fresca una muestra durante tres intervalos de recolección; aplica 15 minutos cuando no conoce el intervalo. En un rango histórico cerrado, mide esa frescura respecto al final seleccionado. En una ventana que llega al presente, la mide respecto a la hora actual.
• Cada punto visible se alinea con la frontera de su bucket, pero la frescura usa la hora real de la observación. La gráfica une muestras de una misma serie sólo dentro del horizonte efectivo del rango: éste cubre al menos dos buckets visibles cuando se usan intervalos 1h o 6h, pero un hueco real mayor corta la línea. Esto no relaja frescura ni UNKNOWN. SPOT no une nulos sin límite ni rellena gauges/estados con cero.
• Observed es el @timestamp autoritativo devuelto por SAP. El documento conserva además ingested_at, que indica cuándo llegó a SPOT. La etiqueta de una serie representa el inicio del bucket visible: por ejemplo, una muestra SAP de 09:24 pertenece al bucket 09:20 en una gráfica de cinco minutos. Esa etiqueta no implica que el conector se ejecutara a 09:20; para separar retraso de SAP, transporte y agregación hay que comparar los tres tiempos.
• En métricas con varias series, cada línea conserva su identidad. Colas y conteos se suman, los porcentajes se ponderan por capacidad cuando existe y, si la fuente no la publica, cada serie declara el mismo peso explícito. La disponibilidad conserva el peor estado; SPOT no aplica promedios implícitos.

work-process-utilisation-by-type alinea todos los tipos al mismo snapshot y publica ceros cuando un tipo deja de estar ocupado, de modo que la composición actual suma 100 % (o 0 % si no hay procesos ocupados). memory-breakdown conserva ocho series MB por servidor —RAM configured/used/free y Swap configured/used/free/size/maximum— y la tabla de Performance las reúne en una sola fila. Un snapshot de memoria incompleto no sustituye al último completo.

Cuándo usarlo

• Una tarjeta de Operations cambia de estado y necesitas ver el valor bruto.
• Quieres comparar instancias para CPU, memoria, dialog response time, DB request time, filesystem o ICM.
• Un informe de AI menciona un metricId concreto y quieres reproducir la consulta.
• Necesitas confirmar si un hueco visual es falta de datos, rango demasiado corto o target incorrecto.
• Quieres validar un umbral antes de ajustarlo en Tenant console.
• Quieres comparar dos señales, normalizarlas, revisar su cambio porcentual o z-score y calcular Pearson, Spearman y desfase temporal.
• Una tarjeta muestra UNKNOWN y necesitas comprobar si hay puntos antiguos fuera del horizonte de frescura.

IDs canónicos destacados en Operations 02–05

Área	metricId
Dispatcher	dialog-queue-length, icm-queue, update-queue-waiting-time, update-queue-actual, dispatcher-queue-time, dialog-response-time
Work Process	free-dialog-wps, work-process-utilisation-global, work-process-utilisation-by-type, abap-dumps, long-running-work-processes
Jobs	failed-jobs, canceled-jobs, long-running-jobs, job-metrics
Locks Enqueue	enqueue-lock-count, enqueue-server-availability, enqueue-owner-utilisation, enqueue-requests, enqueue-lock-wait-time

enqueue-lock-time, enqueue-lock-count y enqueue-server-availability también pueden consultarse como series en Metric Explorer aunque sus históricos no sean paneles de Locks Enqueue. Long-running jobs consume exclusivamente snapshots XBP por servidor: una consulta correcta publica también un cero explícito; ausencia, error o pérdida de frescura devuelve UNKNOWN.

Relación rango-bucket

SPOT no dibuja todos los puntos sin agrupar. Para series temporales usa un date_histogram con fixed_interval calculado a partir de la duración to - from. La misma regla aplica en SaaS y On-Premise.

Ventana seleccionada	Bucket visible	Uso recomendado
Hasta 30 minutos	1m	Incidentes vivos, picos cortos, errores ICM recientes
Más de 30 minutos y hasta 24 horas	5m	Revisión diaria y comparación normal entre instancias
Más de 24 horas y hasta 7 días	15m	Tendencias semanales sin perder degradaciones breves
Más de 7 días y hasta 30 días	1h	Capacidad, crecimiento y patrones de carga
Más de 30 días	6h	Visión histórica de largo plazo

Las tasas de error ICM conservan resolución 1h también por encima de 30 días para no ocultar picos breves. SPOT usa ese mismo bucket al dibujar continuidad.

Si reduces la ventana, SPOT puede mostrar más detalle. Si amplías la ventana, SPOT compacta para que la gráfica siga siendo legible y comparable. Esto afecta a Metrics, Operations, paneles de AI y cualquier vista que use las mismas métricas.

Comparar y correlacionar

1. Añade dos métricas temporales y carga sus parámetros.
2. Abre Compare two metrics.
3. Si una métrica devuelve varias series, elige una serie exacta para cada eje.
4. Mantén valores brutos o usa normalización 0–100, cambio porcentual o z-score.
5. Revisa Pearson, Spearman, el lag con mayor correlación y el número de pares alineados.

SPOT usa el bucket más grueso de las dos respuestas, excluye pares ausentes y no interpola datos. Un resultado no está disponible con menos de tres pares o con una serie constante. El cursor, el zoom y la ventana temporal permanecen sincronizados. El workspace se conserva como borrador local y puede compartirse mediante su URL.

Las líneas de alertas superpuestas llevan al Alert Control Center, donde se conserva la evidencia que abrió o resolvió la instancia. El inspector técnico sustituye al antiguo Metric Debug y muestra parámetros, serie y reglas de alineación.

Baselines, forecast y anomaly score

En SaaS y on-prem, el menú global Analysis activa de forma opcional Expected range, Forecast, umbrales estáticos o puntos de score. Todas las capas empiezan desactivadas. SPOT calcula el comportamiento esperado con granularidad fina y lo reagrupa al mismo bucket visible.

SPOT sólo consulta baseline cuando Expected range o los puntos de score están visibles, y sólo consulta forecast al activar Forecast. Desactivar las capas evita ese trabajo sin cambiar la serie real.

La visualización es por serie. Si una gráfica compara varias instancias, hosts o tipos de transacción, cada línea real conserva su color y sus datos ML se dibujan con el mismo color. El emparejamiento usa la clave canónica exacta de cada serie; el label es sólo texto visible y no actúa como fallback:

• Expected range: banda normal min/max detrás de la serie y media esperada punteada.
• Forecast: extensión futura punteada de la misma serie.
• Anomaly score: puntos sobre el valor real, filtrados mediante un rango 0–100.

Una leyenda compacta bajo la gráfica explica signal, warning y critical según los scores efectivos. No existe una segunda gráfica de score. Al expandir una gráfica puedes activar Forecast y ML scores sólo para ese modal, sin cambiar Analysis global.

Las capas y sus mensajes sólo aparecen en métricas cuya política canónica admite ML y cuando la capa correspondiente está activa. Señales de estado como Instance availability, Instance heartbeat, Instance CCMS status y Database health no muestran controles ni avisos de forecast. Las tasas ICM error rate e ICM connect error rate sí conservan forecast y sólo explican una falta de datos recientes al activarlo.

El score ML no sustituye los umbrales estáticos. Puede alimentar una regla de Alertas con warning/critical ML, pero la visualización por sí sola no envía notificaciones.

adaptive-robust-v3 usa hasta 42 días en buckets de 5 minutos y permanece warming_up hasta tener 21 días, tres ciclos y 70 % de cobertura. Selecciona y valida temporalmente el patrón más adecuado para cada serie, calibra la banda sin usar futuro y combina rareza, materialidad, dirección de salud y persistencia. Un cambio favorable o un pico aislado no excepcional no abre una incidencia ML. El forecast cubre 24 horas.

Baseline y forecast publican estados independientes y un motivo operativo. La allowlist vigente de adaptive-robust-v3 es:

Estado	Lectura operativa
ready	Hay baseline suficiente para comparar el valor actual con el comportamiento histórico.
warming_up	El modelo está acumulando muestras; usa umbrales y comparación manual.
no_recent_data	Falta una observación reciente; revisa la extracción y la ventana seleccionada.
insufficient_history	Todavía no existen los 21 días mínimos de histórico.
insufficient_coverage	Hay histórico, pero no alcanza los tres ciclos y el 70 % de cobertura requeridos.
training_error	El entrenamiento no terminó de forma íntegra; revisa el diagnóstico y vuelve a intentarlo cuando la fuente esté estable.
no_matching_series	Hay baseline vigente, pero no coincide con la clave canónica exacta de la serie filtrada.
unavailable	No hay baseline disponible para ese target, métrica o ventana.

La banda esperada no sustituye al umbral. Usa ambos: el umbral indica riesgo operacional absoluto; el baseline indica desviación respecto al patrón normal. El detalle explica valor típico, cambio, rareza, impacto, dirección y persistencia. El admin puede ajustar ML warning y ML critical por métrica y fuente.

Lectura técnica

1. Selecciona el mismo target que usas en Operations.
2. Selecciona un host solo si quieres aislar una instancia; deja All hosts para ver agregados.
3. Empieza con 24 horas para contexto y baja a 30 minutos si estás siguiendo un incidente.
4. Revisa unidad y tipo de métrica: percent, ms, count, rate, code o seconds.
5. Cruza la gráfica con Events si el cambio es brusco, Jobs si coincide con batch, Alerts para evidencias emitidas y AI para una investigación guiada.

Si no aparecen datos

• Confirma que el target global es el correcto.
• Revisa que la SAP connection esté habilitada y asignada a un connector OK.
• En SaaS, abre Tenant console > Agent logs y busca errores sap.extraction.* o elastic.bulk.*.
• En On-Premise, valida que backend y conector usan el mismo namespace e índices.
• Amplía la ventana a 24 horas para descartar una consulta demasiado corta.
• Si existen puntos pero el estado es UNKNOWN, comprueba el hueco entre el último punto y el final del rango: si supera el horizonte de frescura, SPOT no lo presenta como estado conocido.
• Database health se recoge cada 30 minutos y conserva 90 minutos de frescura; ese ritmo no debe confundirse con un corte. Filesystem y MSSQL separan además cada serie por servidor y recurso para no fusionar ficheros homónimos.