Monitoring

Von Funkwerten zur belegten Übertragung.

Metriken zeigen Veränderungen. Logs erklären die Ereignisse dahinter. Unser Monitoring verbindet Small Cell, Open5GS-Core und Anwendungsverkehr, um eine Verbindung über ihre verschiedenen Messpunkte zu untersuchen.

Was läuft wo?

Die Small Cell liefert Funkstatistiken und Protokollereignisse. Erfassung, Speicherung und Grafana laufen auf der Core-VM. Zusammen schaffen sie Observability: Messwerte und Ereignisse helfen, den internen Systemzustand zu erklären.

Die Grafik seitlich verschieben oder in voller Größe öffnen.

Small Cell außerhalb der Core-VM; Observer, Exporter, Prometheus, Alloy, Loki, Grafana, Roharchiv und MCP innerhalb. Separate Clients lesen Exporte und Monitoringdaten.
Beobachtungsdaten mit Hostgrenzen: Small Cell, Core-VM und externe Analyseclients. Pfeile zeigen Datenfluss; Prometheus ruft Metriken ab und wertet Alarmregeln aus, Grafana fragt Prometheus und Loki ab. Grafik in voller Größe öffnen ↗

Small Cell auslesen

Der im Projekt entwickelte Small-Cell-Observer liest Zell- und UE-Statistiken, Konfiguration und Protokollereignisse über die Management-API. Er läuft auf der Core-VM und nutzt das Managementnetz. N2 überträgt davon getrennt die Signalisierung zwischen gNB und AMF.

Metriken und Logs speichern

Prometheus ruft die Metriken des Observers, von Open5GS, des eigenen InfoAPI-Exporters und des Node Exporters ab. Es wertet auch Alarmregeln aus. Alloy überträgt Small-Cell-Ereignisse, Open5GS-Dienstlogs und Zeek-Protokolle nach Loki.

Ein gemeinsames Zeitfenster untersuchen

Grafana fragt Prometheus und Loki ab. Der InfoAPI-Exporter führt AMF- und SMF-Zustände zusammen. Small-Cell-Kontextkennungen und Core-Ereignisse ordnen Funkbeobachtungen einer bestimmten Session zu.

Welche Messgröße beantwortet welche Frage?

Jede Quelle beobachtet einen anderen Teil der Verbindung. Funkbitrate, Verkehr am Core-Interface und Anwendungsdurchsatz beziehen sich auf unterschiedliche Messpunkte.

Welche Messgröße beantwortet welche Frage?
QuelleVerfügbare BeobachtungenBedeutung
Small Cell · ZelleUL-/DL-PHY-Bitrate, GTP-Nutzdatenbitrate, Ressourcennutzung, UE- und Bearer-Anzahl, TX/RETX/ERRFunkaktivität, Last und gemeldete Übertragungsergebnisse. Native Blockwerte sind Momentaufnahmen; ihre Summe ergibt keine verlässliche Ereignisanzahl.
Small Cell · UEPUSCH-SNR, CQI, Rang, UL-/DL-MCS, Layer und geschätzte PfaddämpfungSNR beschreibt das Signal-Rausch-Verhältnis, CQI die gemeldete Kanalqualität und MCS die gewählte Modulation und Codierung. Die Werte gehören zu einem UE-Kontext; ein Beobachtungsplatz kann später einem anderen Gerät zugeordnet sein.
Small Cell · RF und KonfigurationBand, ARFCN, Antennen-/Layer-Konfiguration, RF-Frequenz und Gain; Sample- und DecoderdiagnostikEingestelltes Funkprofil und Hardwarediagnostik. Gain ist keine kalibrierte Strahlungsleistung; native Diagnosezeiten sind keine Netzwerklatenz.
Open5GSRegistrierungen, PDU-Sessions, gNB-Verbindungszustand und zugehörige SessiondetailsOb der Core das UE kennt und eine Datensession eingerichtet hat. Der InfoAPI-Exporter verbindet Beobachtungen aus AMF und SMF.
Core-VMCPU, Arbeitsspeicher, Dateisystem und NetzwerkinterfacesHostlast und Ressourcenengpässe, die Core- oder Monitoringdienste beeinflussen können.
UE und AnwendungstestsModem-RSRP/RSRQ/SINR, Paketumlaufzeiten, iperf-Nutzdatendurchsatz und AnwendungsantwortenZusätzliche laufbezogene Messungen am Client oder Empfänger. Sie ergänzen die kontinuierliche Erfassung auf der VM.

Fehlende Daten unterscheiden sich von null. Ein inaktives UE kann seinen letzten CQI- oder SNR-Wert beibehalten, obwohl die API erfolgreich antwortet. Ungeklärte Quelleinheiten bleiben native Diagnosewerte.

Funkereignisse und Core-Logs nebeneinander.

Die internen Grafana-Ansichten trennen den Protokolltrace der Small Cell von den Open5GS-Serverlogs. Beide lassen sich im selben Zeitfenster untersuchen.

Small Cell Radio Monitoring

Erfassungszustand, Datenalter und aktuelle UE-Kontexte bilden den Einstieg. Danach folgen Verkehr, Ressourcennutzung und Signalqualität. Zell-/RF-Konfiguration und Diagnosewerte lassen sich für konkrete Fragestellungen aufklappen.

Small Cell and Core Logs

Die Small-Cell-Tabelle zeigt Quellzeit, Richtung, Protokoll, UE, Zelle, Kanal und Nachrichtenname. Der Body-Inspektor öffnet den dekodierten Inhalt. Das benachbarte Core-Panel zeigt Dienstmeldungen; beide Seiten haben eigene Filter.

Explore und Verkehrsprotokolle

Über das Panelmenü → Explore werden Abfrage, Filter und Zeitfenster in Grafana Explore übernommen. Zeek-Protokolle zeigen den am UPF-Interface ogstun beobachteten Verkehr einschließlich dekodierbarer Anwendungsprotokolle.

Die Small-Cell-Quellzeit bleibt erhalten; Loki wählt diese Ereignisse nach dem Empfangszeitpunkt des Observers aus. Beim Hostvergleich sind unterschiedliche Uhren zu beachten. Die Ereignistabelle ist eine begrenzte Ansicht; Exporte sichern die verfügbaren Laufdaten.

Eine Verbindung über ihre Messpunkte verfolgen.

Zuerst werden Gerät und Sessionkontext für das gewählte Testfenster zugeordnet. Der folgende Diagnoseablauf erklärt die Beobachtungspunkte; er stellt keinen neuen aufgezeichneten Protokolltrace dar.

  1. Registrierung und Identität

    Small-Cell-Protokollereignisse + Open5GS-AMF-Logs

    Verfügbare RRC-, NAS- und NGAP-Nachrichten sowie den AMF-Registrierungseintrag verfolgen. Core-Identitätsnachweise und das RAN-/AMF-Kontextpaar ordnen die Sequenz dem getesteten UE zu.

  2. Sicherheit und Datensession

    Dekodierte Nachrichten + AMF-/SMF-Logs + InfoAPI

    Authentisierung und Sicherheitsaktivierung anhand der dekodierten Inhalte untersuchen. Anschließend PDU-Sessionaufbau, DNN und zugewiesene UE-Adresse abgleichen. Diese Angaben verknüpfen den Aufbau mit dem späteren Verkehr.

  3. Tatsächliche Datenübertragung

    Funkmetriken + Zeek am UPF + Client oder Empfänger

    Funkaktivität mit dem Verkehr der zugewiesenen UE-Adresse vergleichen. HTTP-Antwort, iperf-Ergebnis oder empfangener Wetterwert belegen das jeweilige Anwendungsergebnis.

  4. Eine Lücke erklären

    Zeitlicher Abgleich aller drei Beobachtungspunkte

    Bei einer fehlgeschlagenen Probe Release-/Reaktivierungsereignisse, Verkehr und Erfassungsabdeckung gemeinsam untersuchen. So lassen sich fehlende Beobachtungen von fehlgeschlagenen Anfragen unterscheiden; zeitliche Nähe allein erklärt noch keine Ursache.

Validierung und Forschung →

Liveansicht, Laufdaten und KI-gestützte Auswertung.

Die öffentliche Website bietet einen Überblick. Detaillierte Sessionanalysen und Laufexporte verwenden die internen Forschungswerkzeuge.

Öffentliche Liveansicht

Ausgewählte Core- und VM-Aggregate zeigen Netzaktivität und Dienstzustände. Die öffentliche JSON-API liefert dieselbe festgelegte Datenauswahl.

Laufbezogenes Roharchiv

Der Observer hält API-Antworten in einem begrenzten Archiv vor. Authentifizierte Downloads sichern das Benchmarkfenster vor der Rotation. Die Exportabdeckung ist zu kontrollieren; native Small-Cell-Dumps bleiben eine eigene Quelle.

Lesender Grafana-MCP-Zugang

Ein authentifizierter MCP-Dienst ermöglicht Analyseclients, Monitoringdaten über Grafana abzufragen. Er unterstützt KI-gestützte Untersuchungen ohne Zugriff auf die Netzkonfiguration. Die Wirksamkeit der Diagnose benötigt einen eigenen Versuch.