Metrics

Metrics und Metric Explorer ermöglichen die historische Analyse des kanonischen Katalogs und den Vergleich zweier Metriken. Beide teilen Target, Hosts und Zeitfenster; getrennte Y-Achsen bewahren ihre Einheiten.

Metrics teilt Target-, Host- und Zeitfensterkontrollen mit Operations.

Eine Kennung, zwei Lesarten

Jede Metrik besitzt genau eine kanonische metricId. Dieselbe Kennung liefert:

• current für Landing, Zustandskarten und Alarme;
• series für Charts, Metric Explorer und historische Analyse;
• both, wenn ein Panel aktuellen Zustand und Trend gemeinsam benötigt.

Metric Explorer fordert immer die Projektion series an. Es gibt weder eine zweite Metrik mit Suffix -ts noch eine künstliche Zeitreihe aus einer skalaren Antwort. Beispielsweise liefern icm-queue, enqueue-lock-wait-time und work-process-utilisation-global sowohl die aktuelle Lesart als auch ihren Verlauf.

Operations-Kompositionen gelten hier nicht. Ein Performance-Chart, der acht Abfragen kombiniert, erscheint im Metric Explorer weiterhin als acht separat abfragbare Metriken.

Metrikantworten verwenden den stabilen Vertrag schemaVersion: 2. Im technischen Inspector sehen Sie Kennung, Einheit, Zustand, aktuelle Zusammenfassung und Serien mit stabiler Identität nach Host, Instanz oder Typ. Die früheren Varianten scalar, grouped, table und string gehören nicht mehr zum Metrikkatalog; Jobs, Events und andere Datensätze behalten ihre eigenen Ansichten.

Zustand, Freshness und Aggregate

• Bei Gauges und Zuständen ist current die neueste reale Beobachtung innerhalb des gewählten Fensters, nicht Mittelwert oder Maximum des Fensters.
• Bei Ereigniszählern ist 0 gültig, wenn das Zustandsintervall beobachtet wurde und keine Ereignisse enthält.
• UNKNOWN bedeutet, dass ein frisches Sample fehlt oder die Quelle das Signal noch nicht liefert. Es ist weder 0 noch OK oder ein funktionaler Fehler.
• SPOT betrachtet ein Sample für drei Sammelintervalle als frisch und verwendet 15 Minuten, wenn das Intervall unbekannt ist. Bei einem abgeschlossenen historischen Zeitraum wird die Freshness gegen das gewählte Ende gemessen. Bei einem Fenster bis zur Gegenwart gilt die aktuelle Zeit.
• Jeder sichtbare Punkt wird an seiner Bucket-Grenze ausgerichtet, während die Freshness die reale Beobachtungszeit verwendet. Ein Chart verbindet Samples derselben Serie nur innerhalb des effektiven Kontinuitätshorizonts des Zeitraums. Dieser umfasst bei 1h- oder 6h-Intervallen mindestens zwei sichtbare Buckets; eine größere reale Lücke unterbricht die Linie weiterhin. Freshness und UNKNOWN bleiben unverändert. SPOT verbindet Nullwerte nicht unbegrenzt und füllt Gauges/Zustände nicht mit Null.
• Observed ist der autoritative SAP-@timestamp. Das Quelldokument enthält zusätzlich ingested_at, also den Eingang bei SPOT. Eine Serienbeschriftung zeigt den Anfang des sichtbaren Buckets: Ein SAP-Sample um 09:24 gehört in einem Fünf-Minuten-Chart zum Bucket 09:20. Daraus folgt nicht, dass der Connector um 09:20 lief; alle drei Zeiten müssen verglichen werden, um SAP-, Transport- und Aggregationsverzögerung zu unterscheiden.
• Bei mehreren Serien behält jede Linie ihre Identität. Queues und Zähler werden summiert, Prozentsätze werden nach Kapazität gewichtet, sofern diese verfügbar ist; andernfalls deklariert jede Serie dasselbe explizite Gewicht. Bei Verfügbarkeit bleibt der schlechteste Zustand erhalten; SPOT verwendet keine impliziten Mittelwerte.

work-process-utilisation-by-type richtet alle Typen am selben Snapshot aus und veröffentlicht den Wert 0, wenn ein Typ nicht mehr belegt ist. Dadurch ergibt die aktuelle Zusammensetzung 100 % (oder 0 %, wenn kein Prozess belegt ist). memory-breakdown führt pro Server acht MB-Reihen—RAM configured/used/free sowie Swap configured/used/free/size/maximum—und die Performance-Tabelle schwenkt sie in eine Zeile. Ein unvollständiger Speicher-Snapshot ersetzt niemals den letzten vollständigen.

Wann verwenden

• Eine Operations-Karte ändert Zustand und Sie benötigen den Rohwert.
• Sie möchten Instanzen für CPU, Speicher, dialog response time, DB request time, Filesystem oder ICM vergleichen.
• Ein AI-Bericht nennt eine konkrete metricId und Sie möchten die Abfrage reproduzieren.
• Sie müssen entscheiden, ob ein leerer Chart fehlende Daten, ein zu kurzes Fenster oder ein falsches Target bedeutet.
• Sie möchten einen Threshold prüfen, bevor Sie ihn in der Tenant-Konsole ändern.
• Sie möchten zwei Signale normalisieren, Prozentänderung oder Z-Score prüfen und Pearson, Spearman sowie Zeitversatz berechnen.
• Eine Karte zeigt UNKNOWN und Sie möchten prüfen, ob ältere Punkte außerhalb des Freshness-Horizonts existieren.

Database health wird alle 30 Minuten erfasst und bleibt 90 Minuten frisch; diese Kadenz ist keine Datenlücke. Filesystem- und MSSQL-Serien enthalten zudem Server- und Ressourcenidentität, damit gleichnamige Dateien nicht verschmelzen.

Kanonische IDs in Operations 02–05

Bereich	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 und enqueue-server-availability sind ebenfalls als Serien im Metric Explorer verfügbar, obwohl ihre historischen Verläufe keine Panels der Locks-Enqueue-Domäne sind. Long-running jobs verwendet ausschließlich XBP-Snapshots je Server: Eine erfolgreiche Abfrage veröffentlicht auch eine explizite Null; fehlende Daten, Fehler oder verlorene Freshness ergeben UNKNOWN.

Verhältnis Zeitfenster zu Bucket

SPOT zeichnet nicht alle Rohpunkte ungegliedert. Für Zeitreihen nutzt es ein date_histogram mit fixed_interval, berechnet aus der Dauer to - from. Dieselbe Regel gilt für SaaS und On-Premise.

Gewähltes Fenster	Sichtbarer Bucket	Empfohlene Nutzung
Bis 30 Minuten	1m	Live-Incidents, kurze Peaks, aktuelle ICM-Fehler
Mehr als 30 Minuten bis 24 Stunden	5m	Tägliche Prüfung und normaler Instanzvergleich
Mehr als 24 Stunden bis 7 Tage	15m	Wochentrends ohne kurze Degradationen zu verlieren
Mehr als 7 Tage bis 30 Tage	1h	Kapazität, Wachstum und Lastmuster
Mehr als 30 Tage	6h	Historische Langzeitsicht

ICM-Fehlerraten behalten auch über 30 Tage eine 1h-Auflösung, damit kurze Spitzen sichtbar bleiben. SPOT verwendet denselben Bucket für die Kontinuität.

Kürzere Fenster zeigen mehr Detail. Breitere Fenster werden verdichtet, damit Charts lesbar und vergleichbar bleiben. Das betrifft Metrics, Operations, AI-Panels und jede Sicht, die dieselben Metriken nutzt.

Vergleichen und korrelieren

1. Fügen Sie zwei Zeitreihenmetriken hinzu und laden Sie ihre Parameter.
2. Öffnen Sie Compare two metrics.
3. Wählen Sie bei mehreren Serien je Achse genau eine Serie.
4. Nutzen Sie Rohwerte, Normalisierung 0–100, Prozentänderung oder Z-Score.
5. Prüfen Sie Pearson, Spearman, stärksten Lag und die Anzahl ausgerichteter Paare.

SPOT verwendet den gröberen Response-Bucket, schließt fehlende Paare aus und interpoliert nie. Bei weniger als drei Paaren oder einer konstanten Serie ist keine Korrelation verfügbar. Cursor, Zoom und Zeitfenster bleiben synchron. Der Workspace wird lokal gespeichert und per URL geteilt.

Alarmmarkierungen öffnen die Evidenz im Alert Control Center. Der technische Inspector ersetzt Metric Debug und zeigt Parameter, Serienauswahl und Ausrichtungsregeln.

Baselines, Forecast und Anomaly score

In SaaS und On-Prem aktiviert das globale Analysis-Menü optional Expected range, Forecast, statische Schwellwerte oder Score-Punkte. Alle Ebenen sind anfangs deaktiviert. SPOT berechnet das erwartete Verhalten mit feiner Granularität und gruppiert Baseline und Forecast vor dem Zeichnen in dasselbe Intervall wie der sichtbare Chart um.

SPOT fordert Baseline nur an, solange Expected range oder Score-Punkte sichtbar sind, und Forecast erst nach Aktivierung von Forecast. Das Deaktivieren dieser Ebenen vermeidet diese Arbeit, ohne die reale Serie zu verändern.

Die Visualisierung erfolgt pro Serie. Wenn ein Chart mehrere Instanzen, Hosts oder Transaktionstypen vergleicht, behält jede reale Linie ihre Farbe und ihre ML-Daten nutzen dieselbe Farbe. Der Abgleich verwendet den exakten kanonischen Schlüssel jeder Serie; das Label ist nur sichtbarer Text und dient nie als Fallback:

• Expected range: normale Min/Max-Bandbreite hinter der Serie plus gepunktete erwartete Mitte.
• Forecast: gepunktete zukünftige Fortsetzung derselben Serie.
• Anomaly score: Punkte auf dem Istwert, gefiltert über einen Bereich von 0–100.

Eine kompakte Legende unter dem Chart erklärt Signal, Warning und Critical anhand effektiver Scores. Es gibt keinen zweiten Score-Chart. In einem erweiterten Chart lassen sich Forecast und ML scores nur für dieses Modal aktivieren.

Ebenen und ihre Meldungen erscheinen nur für Metriken, deren kanonische Richtlinie ML unterstützt, und nur bei aktivierter Ebene. Zustandssignale wie Instance availability, Instance heartbeat, Instance CCMS status und Database health zeigen keine Forecast-Steuerung oder Warnung. ICM error rate und ICM connect error rate behalten Forecast und erklären fehlende aktuelle Daten erst nach der Aktivierung.

Der ML-Score ersetzt keine statischen Schwellwerte. Er kann eine Regel unter Alarme über ML warning/critical speisen; die Visualisierung allein sendet keine Benachrichtigung.

adaptive-robust-v3 nutzt bis zu 42 Tage in 5-Minuten-Buckets und bleibt warming_up, bis 21 Tage, drei Zyklen und 70 % Abdeckung verfügbar sind. Das passende Muster wird je Serie zeitlich ausgewählt und validiert, das Band ohne Zukunftsdaten kalibriert und Seltenheit, Materialität, Gesundheitsrichtung und Persistenz kombiniert. Eine günstige Änderung oder ein nicht außergewöhnlicher Einzelausschlag öffnet keinen ML-Vorfall. Forecast umfasst 24 Stunden.

Baseline und Forecast veröffentlichen unabhängige Zustände und einen operativen Grund. Die aktuelle Allowlist von adaptive-robust-v3 lautet:

Zustand	Operative Lesart
ready	Genügend Baseline vorhanden, um den aktuellen Wert mit Historie zu vergleichen.
warming_up	Das Modell sammelt Samples; verwenden Sie Thresholds und manuelle Vergleiche.
no_recent_data	Eine aktuelle Beobachtung fehlt; prüfen Sie Extraktion und gewählten Zeitraum.
insufficient_history	Die mindestens erforderlichen 21 Tage Historie sind noch nicht verfügbar.
insufficient_coverage	Historie ist vorhanden, erreicht aber nicht die erforderlichen drei Zyklen und 70 % Abdeckung.
training_error	Das Training wurde nicht vollständig abgeschlossen; prüfen Sie die Diagnose und wiederholen Sie es bei stabiler Quelle.
no_matching_series	Eine aktuelle Baseline existiert, passt aber nicht zum exakten kanonischen Schlüssel der gefilterten Serie.
unavailable	Keine Baseline für Target, Metrik oder Fenster verfügbar.

Die erwartete Bandbreite ersetzt keine Schwellwerte. Statische Werte zeigen absolutes Betriebsrisiko, Baselines die Abweichung vom Normalmuster. Details erklären typischen Wert, Änderung, Seltenheit, Auswirkung, Richtung und Persistenz. Administratoren können ML warning und ML critical je Metrik und Quelle einstellen.

Technische Lesart

1. Wählen Sie dasselbe Target wie in Operations.
2. Wählen Sie einen Host nur, wenn Sie eine Instanz isolieren wollen; lassen Sie All hosts für Aggregate.
3. Starten Sie mit 24 Stunden Kontext und verengen Sie auf 30 Minuten bei aktiven Incidents.
4. Prüfen Sie Einheit und Typ: percent, ms, count, rate, code oder seconds.
5. Kreuzen Sie mit Events bei abrupten Änderungen, Jobs bei Batch-Korrelation, Alerts für erzeugte Evidenz und AI für geführte Untersuchung.

Wenn keine Daten erscheinen

• Prüfen Sie das globale Target.
• Prüfen Sie, dass die SAP connection aktiviert und einem OK-Connector zugeordnet ist.
• In SaaS öffnen Sie Tenant console > Agent logs und suchen sap.extraction.* oder elastic.bulk.*.
• On-Premise validieren Sie, dass Backend und Connector denselben Namespace und dieselben Indizes nutzen.
• Erweitern Sie das Fenster auf 24 Stunden, um ein zu kurzes Abfragefenster auszuschließen.
• Wenn Punkte vorhanden sind, der Zustand aber UNKNOWN ist, prüfen Sie die Lücke zwischen dem letzten Punkt und dem Bereichsende: Überschreitet sie den Freshness-Horizont, zeigt SPOT den Punkt nicht als bekannten Zustand.