QoS Dashboards sind für NOC-Teams dann wirklich hilfreich, wenn sie nicht „alles zeigen, was möglich ist“, sondern in Sekunden die drei entscheidenden Fragen beantworten: Ist Echtzeitqualität gerade gefährdet? Wo im Netz entsteht das Risiko? Und ist es ein QoS-/Congestion-Thema, ein physisches Problem oder ein Applikations-/Provider-Problem? In vielen Organisationen scheitern QoS Dashboards daran, dass sie zu technisch für den 1st-Level sind oder zu oberflächlich für eine belastbare Eingrenzung. Gleichzeitig sind Echtzeitdienste wie Voice, Video, WebRTC und IPTV extrem sensibel gegenüber kurzen Queue-Spitzen, Jitter-Events und paketbasiertem Verlust, der in klassischen 5-Minuten-Interfacesummen untergeht. Ein gutes QoS Dashboard für ein NOC kombiniert daher wenige, starke Panels: Service-KPIs (Bad-Call-/Bad-Meeting-Rate, MOS-Trends), Engpassindikatoren (Queue Depth/Delay, Per-Class Drops, Drop Reasons), Pfad-/Standort-Sicht (Top-Offender) und klare Drilldowns bis zur betroffenen Queue am betroffenen Interface. Dieser Artikel zeigt, welche Panels NOC-Teams wirklich brauchen, wie Sie sie strukturieren und welche typischen Fehler Sie vermeiden, damit QoS Dashboards im Alltag nicht zur „bunten Tapete“, sondern zum Frühwarnsystem und Incident-Kompass werden.
Was ein NOC-Dashboard leisten muss: Geschwindigkeit vor Detailtiefe
NOC-Teams arbeiten unter Zeitdruck. Im Incident zählt nicht, ob eine Metrik theoretisch spannend ist, sondern ob sie handlungsleitend ist. Ein QoS Dashboard muss daher in drei Ebenen gedacht werden: (1) Überblick: „Alles grün oder gibt es Risiko?“ (2) Lokalisierung: „Welche Standorte/Links/Queues sind betroffen?“ (3) Diagnose: „Warum passiert es – Congestion, Policing, Bufferbloat, WLAN, Provider?“ Die Detailanalyse kann danach in Spezial-Ansichten erfolgen, aber das Hauptdashboard darf nicht aus dutzenden Charts bestehen, die nur Experten interpretieren können.
- Ein Blick: Servicequalität und Risikoindikatoren müssen sofort erkennbar sein.
- Top-Offender: Liste der schlimmsten Standorte/Links/Queues spart Minuten.
- Drilldown: Vom KPI zum Interface zur Queue zum Drop Reason ohne Umwege.
- Operational: Panels müssen zu konkreten Aktionen führen (Ticket, Eskalation, Mitigation).
Dashboard-Architektur: Drei Sichten statt ein „Monster-Dashboard“
In der Praxis funktioniert eine klare Trennung am besten. Ein „NOC Wallboard“ zeigt nur wenige Status-Panels für schnelle Erkennung. Ein „Ops Dashboard“ liefert Top-Offender und Engpassdetails für Erstdiagnose. Ein „Engineering Drilldown“ enthält tiefe Telemetry, Rohdaten, Segmentierungen und Vergleichsansichten. So überfrachten Sie die NOC-Sicht nicht, bieten aber trotzdem einen sauberen Weg zur Ursachenanalyse.
- Wallboard: Ampelstatus + Top 5 Problemspots.
- Ops Dashboard: Per-Class Drops, Queue Depth/Delay, Shaper, Link-Heatmaps.
- Engineering: Drop Reasons, Microburst-Analyse, Flow-/App-Korrelation, Change-Overlay.
Panel-Gruppe 1: Service-KPIs, die NOC-Teams sofort verstehen
NOC-Teams brauchen zuerst eine serviceorientierte Sicht, weil Tickets meist als „Voice schlecht“ oder „Video ruckelt“ reinkommen. Ideal sind KPIs, die Nutzererfahrung abbilden, aber gleichzeitig mit Netzmetriken korrelierbar sind. Für Voice sind das MOS-Trends und Bad-Call-Rate; für Video/RTC sind es Bad-Meeting-Rate, Jitter-/Loss-Perzentile und Quality-Events (Freeze, Downshift). Wichtig: Nicht nur Mittelwerte zeigen, sondern Perzentile und Quoten, damit Peaks sichtbar werden.
- Bad-Call-Rate: Anteil Calls unter definierter Schwelle (z. B. MOS oder Loss/Jitter-Kriterien).
- MOS Perzentile: 50p/95p/99p statt nur Durchschnitt, um „schlechte Momente“ zu sehen.
- Jitter/Loss Trends: pro Serviceklasse (Voice vs. Video) und als Zeitreihe.
- Quality Availability: Anteil der Zeit, in der KPI-Grenzen eingehalten werden.
Warum Quoten besser alarmieren als Einzelwerte
Ein einzelner schlechter Call kann ein Endgeräteproblem sein. Wenn aber die Bad-Call-Rate in einem Standort in 15 Minuten deutlich steigt, ist das ein Netzsignal. Dashboards sollten daher Quoten und Perzentile als „NOC-taugliche“ Trigger verwenden, nicht einzelne Ausreißer.
Panel-Gruppe 2: Top-Offender – die wichtigste NOC-Liste
Ein QoS Dashboard ohne Top-Offender-Liste zwingt das NOC, zu raten. Ein gutes Panel zeigt die „schlimmsten“ Standorte, Links oder Queues der letzten 15/60 Minuten – jeweils mit dem relevanten Symptom: höchste Bad-Call-Rate, höchste Voice-Queue-Delay, meisten Per-Class Drops in Media, höchste Shaper-Auslastung. Diese Ranglisten sind der schnellste Weg, aus einem globalen Alarm eine konkrete Stelle zu machen.
- Top Standorte nach Bad-Call-/Bad-Meeting-Rate
- Top Interfaces nach Voice/Media Queue Delay
- Top Interfaces nach Per-Class Drops (Voice/Media)
- Top Links nach Shaper-Headroom (dauerhaft am Limit)
Panel-Gruppe 3: Queue Depth und Queue Delay als Frühwarnsystem
Wenn NOC-Teams nur ein QoS-Panel hätten, sollte es Queue Depth und Queue Delay pro Echtzeitklasse sein. Damit erkennen Sie Congestion, Bufferbloat und Microbursts, bevor Nutzerqualität kollabiert. Ideal ist eine Darstellung als Zeitreihe plus „Peak/Max“-Wert, weil viele Echtzeitprobleme in kurzen Peaks entstehen. Ergänzend hilft ein „Heatmap“-Panel: Zeit (x) gegen Queue-Delay (y) pro Standort/Link, um Muster zu erkennen.
- Voice Queue Delay (95p/99p): Alarmkriterium für Echtzeitrisiko.
- Media/Video Queue Delay: wichtig für Video/Screen Sharing Stabilität.
- Queue Depth + Peak Depth: zeigt Microbursts und Bufferbloat-Tendenzen.
- Trend nach Tageszeit: wiederkehrende Peaks deuten auf Jobs/Backups oder Lunch-Hour-Meetings hin.
Panel-Gruppe 4: Per-Class Drops – der harte Beweis für Paketverlust
Per-Class Drops sind die Metrik, mit der ein NOC Paketverlust nicht nur sieht, sondern klassenspezifisch zuordnen kann. Das ist entscheidend für Priorisierung: Drops in Best Effort sind häufig tolerierbar, Drops in Voice oder Media sind ein Incident. Dashboards sollten Drops als Rate (Drops/s) und als kumulative Zähler darstellen, damit Sie sowohl akute Ereignisse als auch langfristige Trends sehen. Für NOC ist besonders wichtig, dass Drops pro Klasse am Engpassinterface sichtbar sind – nicht nur als globaler Gerätewert.
- Voice Drops: sofort kritisch; oft korrelierend mit MOS-Abfall und Audioaussetzern.
- Media Drops: führt zu Videoartefakten, Freeze oder starken Downshifts.
- Signalisierung/Control Drops: zeigt Setup-/Reconnect-Probleme, auch wenn Medien stabil sind.
- Best Effort/Bulk Drops: zur Einordnung, ob QoS schützt oder ob globaler Engpass vorliegt.
Panel-Gruppe 5: Drop Reasons – das „Warum“ auf Knopfdruck
Ein NOC braucht nicht jede herstellerspezifische Drop-Variante, aber es braucht die großen Kategorien, die konkrete Maßnahmen auslösen. Ein Drop-Reasons-Panel zeigt z. B. Top Drop Reasons pro Standort/Interface im Zeitfenster und ordnet sie verständlich ein: Tail Drop (Queue voll), Policer Drop (Rate überschritten), WRED Drop (frühzeitige Drops), Buffer Exhaustion (Shared Buffer), Policy/ACL Drop (Filter). Das spart Eskalationszeit, weil die Hypothese sofort klarer wird.
- Tail Drop / Queue Full: Congestion; Klassenreserve, Shaping, Kapazität prüfen.
- Policer Drop: zu aggressiv oder falsch klassifiziert; Policer/Marking/Trust Boundary prüfen.
- WRED Drop: sinnvoll für TCP, meist falsch für RTP; Policy prüfen.
- Buffer Exhaustion: Microbursts/Plattformressourcen; Peak-Analyse und Buffer-Pools prüfen.
- Policy Drop: Security/ACL/NAT; Pfad und Regeln prüfen.
Panel-Gruppe 6: Shaper und Headroom – der WAN-/Internet-Realitätscheck
Viele Echtzeitprobleme entstehen am Uplink. Deshalb braucht ein NOC Dashboard Panels, die Shaping sichtbar machen: aktuelle Shaper-Rate, Backlog, Headroom und Zeitanteil „am Limit“. Ohne diese Sicht wird Congestion häufig falsch interpretiert („Provider ist schuld“), obwohl der eigene Uplink dauerhaft an der Grenze läuft. Besonders wichtig ist die Trennung nach Klassen: Wenn der Shaper am Limit ist, aber Voice-Klasse stabil bleibt, wirkt QoS. Wenn Voice-Delay gleichzeitig steigt, ist die Reserve zu klein oder falsch konfiguriert.
- Shaper Utilization: Prozent der Zeit, in der der Shaper limitiert.
- Backlog/Queueing am Shaper: zeigt Bufferbloat-Risiko.
- Headroom pro Standort: „wie knapp“ ist der Uplink im Alltag?
- Top Sites by Saturation: Ranking für Kapazitätsplanung.
Panel-Gruppe 7: Klassifizierung und Trust Boundary – die stille Fehlerquelle
Ein QoS Dashboard muss zeigen, ob Traffic überhaupt in den richtigen Klassen landet. Fehlklassifizierung ist ein häufiger Grund für Echtzeitprobleme: Voice läuft plötzlich in Best Effort, weil DSCP nicht trusted wird oder weil ein neuer Client anders markiert. Ein NOC braucht dafür einfache Panels: Classifier Hits (Matched Packets/Bytes pro Klasse), Anteil „Default/Unmatched“ und Re-Mark Counters. Damit lässt sich schnell erkennen, ob ein QoS-Change, ein neues Endpoint-Profil oder ein Security-Device DSCP verändert.
- Matched Traffic pro Klasse: Volumenverteilung zeigt, ob Voice/Video tatsächlich in den vorgesehenen Klassen läuft.
- Default/Unmatched Anteil: steigt bei Problemen oft an.
- Re-Marking Events: Indikator für Trust Boundary oder Policy-Eingriffe.
- Klassen-Drift: Vergleich „heute vs. Baseline“ als Anomaliepanel.
Panel-Gruppe 8: Standort- und Pfadsegmentierung – LAN/WLAN/VPN/Provider
NOC-Teams müssen schnell unterscheiden, ob Probleme im WLAN, im LAN, im VPN oder im Providersegment entstehen. Deshalb sollten Dashboards segmentieren können: Calls/Meetings nach Netzwerktyp, nach SSID, nach Standort, nach Underlay (MPLS/Internet/LTE) und nach Cloud-Region. So lässt sich z. B. erkennen, ob nur WLAN-Clients betroffen sind (Airtime/Retries) oder ob auch kabelgebundene Clients leiden (Uplink/Provider). Diese Segmentierung ist oft der schnellste Weg zur richtigen Eskalation.
- Bad-Call-Rate nach Netzwerktyp: WLAN vs. LAN vs. VPN.
- RTC-Qualität nach Underlay: SD-WAN Pfad A vs. Pfad B.
- Cloud-Region/PoP: regionale Anomalien und Peering-Effekte sichtbar machen.
- SSID/Access-Cluster: Fokus auf Problemzonen bei VoWLAN/Meetingräumen.
Panel-Gruppe 9: Incident Timeline – Ursache-Wirkung sichtbar machen
Ein NOC muss nicht nur sehen, dass etwas schlecht ist, sondern wann es angefangen hat und wie es sich entwickelt. Ein Incident-Timeline-Panel bündelt für einen ausgewählten Standort/Link die wichtigsten Zeitreihen: Bad-Call-Rate/MOS, Voice-Queue-Delay, Per-Class Drops, Shaper-Auslastung und ggf. Interface-Errors. Diese „Kausalitätsleiste“ ist extrem hilfreich für die Eskalation, weil sie die Beweiskette liefert: Qualität sinkt, Queue-Delay steigt, Drops setzen ein. Damit ist das Problem nicht mehr „unklar“, sondern dokumentiert.
- Qualität: MOS/Bad-Call-Rate oder Video-Freeze/Downshift-Rate.
- Queues: Voice/Media Delay und Depth.
- Drops: Per-Class Drops und Drop Reasons.
- Edge: Shaper und Headroom.
- Physik: CRC/Errors als schneller Ausschluss von Layer-1/2-Problemen.
Panel-Gruppe 10: Baselines und Anomalien – weniger Lärm, bessere Treffer
Statische Schwellen sind in komplexen Netzen oft entweder zu sensibel oder zu stumpf. Baseline- und Anomalie-Panels vergleichen aktuelle Werte mit dem Normalverhalten für denselben Wochentag und dieselbe Uhrzeit. Das reduziert Fehlalarme und erkennt echte Veränderungen, z. B. nach einem Provider-Change oder nach einer QoS-Policy-Anpassung. Für NOC ist das besonders hilfreich bei wiederkehrenden Lastmustern: Morning-Meeting-Peaks sind normal, aber ein ungewöhnlicher Peak am Nachmittag kann ein Incident sein.
- Deviation Panels: Abweichung von Baseline für Queue Delay und Bad-Call-Rate.
- Change Overlays: Markierung von Deployments/Changes in Zeitreihen.
- Seasonality: Wochentag-/Uhrzeitmuster als Kontext.
WLAN-spezifische Ergänzung: Wenn Echtzeit im Funk entscheidet
Wenn NOC-Teams VoWLAN oder viele RTC-Clients im WLAN betreiben, brauchen sie ein kompaktes Funkpanel – aber nur die wirklich relevanten Metriken. Signalstärke allein ist selten ausreichend. Entscheidend sind Airtime, Retry-Rate, Datenratenverteilung, Roaming-Zeiten und Client-Dichte. Diese Werte sollten mit Voice/RTC-Qualität korrelierbar sein, sonst bleibt es bei „WLAN fühlt sich schlecht an“. Ein gutes Dashboard zeigt daher pro SSID/Area die Top-Zonen nach Airtime und Retries sowie die korrelierte Bad-Call-Rate.
- Airtime Utilization: primärer Überlastindikator im WLAN.
- Retry Rate: Treiber für Jitter und Loss.
- Roaming Duration: korreliert mit kurzen Audioaussetzern.
- Client Density: erklärt Lastspitzen in Meetingräumen.
Typische Dashboard-Fehler: Was NOC-Teams ausbremst
Viele QoS Dashboards scheitern an Überfrachtung oder fehlender Handlungslogik. Zu viele Panels ohne Priorität führen dazu, dass das NOC im Incident die falschen Dinge anschaut. Zu grobe Zeitauflösung verschleiert Microbursts. Ohne Segmentierung werden WLAN-Probleme mit WAN-Problemen verwechselt. Und ohne Klassifizierungs- und Drop-Reason-Panels bleibt die Ursachenanalyse spekulativ. Dashboards sollten daher konsequent nach „Signalstärke“ der Metrik gebaut werden: Queue Delay/Depth und Per-Class Drops sind stärker als Interface-Auslastung; Drop Reasons stärker als „Drops gesamt“.
- Zu viele Charts: das NOC braucht Prioritäten, nicht Vollständigkeit.
- 5-Minuten-Mittelwerte: Echtzeitprobleme passieren in Sekunden.
- Keine Drilldowns: ohne Pfad zum betroffenen Interface bleiben Alarme „diffus“.
- Keine Trust-Boundary-Sicht: Fehlklassifizierung bleibt unentdeckt.
- Keine Korrelation: Qualität ohne Queue/Drops oder Queue/Drops ohne Qualität ist halbe Wahrheit.
Pragmatische Minimal-Ausstattung: Das „NOC QoS Dashboard in 10 Panels“
- Service Health: Bad-Call-/Bad-Meeting-Rate + MOS/Quality Availability.
- Top-Offender Standorte: nach Bad-Rate.
- Top-Offender Interfaces: nach Voice/Media Queue Delay.
- Queue Delay Zeitreihe: Voice/Media (95p/99p) für ausgewählten Standort.
- Queue Depth + Peak: Voice/Media zur Microburst-Erkennung.
- Per-Class Drops: Voice/Media/Signalisierung am Engpass.
- Drop Reasons: Top-Gründe im Zeitfenster.
- Shaper/Headroom: Uplink-Limitierung und Backlog.
- Klassifizierung: Matched/Default/Unmatched + Re-Mark Events.
- Incident Timeline: Qualität + Queue + Drops + Shaper + Errors kombiniert.
