Service Levels
Operative Sicht auf Benutzererfahrung. SLEs zeigen Erfolg, Misserfolg, User Minutes und Ursachenklassifizierungen.
1. Lernziele
- operative Dashboards, Insights, Analytics und Reports begrifflich trennen,
- Organization-, Site-, Device-, Client- und Zeit-Scope korrekt setzen,
- SLE-Werte bis zu Classifiern und betroffenen User Minutes auflösen,
- Full-Stack Insights für Wireless, Wired und WAN zielgerichtet nutzen,
- Standard und Premium Analytics nach Lizenz, Historie und Zweck auswählen,
- Tiles, Measures, Entities, Filter und Zeitreihen korrekt interpretieren,
- Reports reproduzierbar exportieren und zustellen,
- Datenlücken, Aggregation und Korrelation kritisch prüfen.
Leitfrage: Welche Ansicht beantwortet die konkrete Betriebsfrage mit dem richtigen Scope, Zeitraum und Detaillierungsgrad – und welche Rohdaten oder Ereignisse belegen das Ergebnis?
2. Das Ansichtsmodell
Insights
Untersuchung von Site, Gerät oder Client über Zeit: Events, Zustände, Traffic, Sessions und Korrelationen.
Analytics & Reports
Trend-, Vergleichs- und Managementsicht mit Tiles, Filtern, längeren Zeiträumen, Export und – bei Premium – Planung.
| Frage | Primärer Einstieg | Beispiel |
|---|---|---|
| Wo ist die Nutzererfahrung schlecht? | Monitor → Service Levels | Wireless Successful Connects fällt ab |
| Was geschah an Gerät oder Client? | Insights | AP-Reboot, Roam, Authentifizierungsfehler |
| Wie entwickelt sich das Netz? | Analytics | Client-, Traffic- oder SLE-Trend |
| Was soll regelmäßig verteilt werden? | Premium Report Scheduling | monatlicher Executive Summary |
Dashboard = Visualisierung | Insight = Untersuchung | Report = reproduzierbare Ausgabe
3. Scope, Zeitraum und Filter
Jede Kennzahl gilt nur für den ausgewählten Datenraum. Eine technisch richtige Zahl wird irreführend, wenn Organization, Site, Gerät, Client, WLAN oder Zeitraum nicht zur Fragestellung passen.
Organisation→Site / Site Group→Floor / Zone→Device / WLAN→Client
| Dimension | Prüffrage | Typischer Fehler |
|---|---|---|
| Scope | Entire Org, Site oder einzelnes Objekt? | Sitewert wird als Organisationswert berichtet |
| Zeit | Live, Stunde, Tag, Woche, Monat oder Custom? | kurze Störung verschwindet im Monatsmittel |
| Zeitzone | Site-, Benutzer- oder Delivery-Zeitzone? | Ereignisse werden falscher Schicht zugeordnet |
| Filter | SSID, Band, Modell, OS oder Applikation? | Filter bleibt unbemerkt aktiv |
| Aggregation | Summe, Durchschnitt, Rate, Count oder Perzentil? | Mittelwert wird als Einzelwert gelesen |
Vor jeder Aussage dokumentieren: Ansicht, Organization, Site, Objekt, Zeitraum, Zeitzone, Filter, Kennzahl und Exportzeitpunkt.
4. Service-Level-Dashboard
Unter Monitor → Service Levels stellt Mist die Ergebnisse seiner Predictive Analytics and Correlation Engine als Service Level Expectations dar. Die verfügbaren Wireless-, Wired-, WAN-, Location- oder Routing-Schaltflächen hängen von Subscriptions und aktivierten Diensten ab.
Beispielsweise Successful Connects, Time to Connect, Coverage, Capacity oder Roaming.
Anteil der User Minutes, die das konfigurierte Ziel erfüllen.
Den Einbruch nicht nur im Gesamtmittel, sondern im betroffenen Zeitfenster untersuchen.
Ursachen wie DHCP, Authorization, Coverage, Capacity oder Clientverhalten auflösen.
Sites, APs, WLANs oder Clients nach Beitrag und Auswirkung priorisieren.
Ereignisse und Messwerte im gleichen Zeitraum verifizieren.
Success Rate und User Minutes
SLE Success Rate = erfolgreiche User Minutes ÷ relevante User Minutes × 100 %
Eine hohe Rate kann bei geringem Nutzungsvolumen wenig Aussagekraft besitzen. Umgekehrt kann ein kleiner prozentualer Abfall in einer großen Site viele Nutzer betreffen. Prozentwert und Nenner gehören deshalb zusammen.
5. Full-Stack Insights
Die Insights-Seite bietet eine zeitbezogene Untersuchung der Netzwerkexperience über Wireless, Wired und WAN. Juniper beschreibt Einstiege über Karten-, Floorplan- und Timeline-Sichten. Ein Drill-down kann den Kontext von Site auf AP, Switch, WAN Edge, Port oder Client verengen.
| Bereich | Typische Informationen | Geeignete Frage |
|---|---|---|
| Events | Konfigurationsänderungen, Reboots, Alarme, Verbindungsereignisse | Was änderte sich kurz vor dem Fehler? |
| Traffic | Bytes, Datenrate, Applikationen, TX/RX | War das Objekt tatsächlich belastet? |
| Sessions | Verbindungs- und Sessiontrends | Welche Clients waren gleichzeitig betroffen? |
| Health | CPU, Memory, Ports, Power oder Tunnelzustände | Lag eine Geräte- oder Pfadstörung vor? |
| Current Values | gegenwärtige Eigenschaften und Zustände | Was gilt jetzt – unabhängig vom historischen Zeitraum? |
Wichtige Abgrenzung: Juniper weist bei Switch Insights ausdrücklich darauf hin, dass „Current Values“ nicht mit einer Änderung des historischen Zeitbereichs wechseln. Historie und Ist-Zustand dürfen nicht vermischt werden.
6. Site Insights
Die überarbeitete Site-Insights-Ansicht bündelt den Full Stack einer Site. Sie zeigt unter anderem Gerätestatus, Client-Verbindungstrends, Traffic, kritische Alerts, Events und Anwendungen.
Summary
Status von APs, Switches, WAN Edges und Wi-Fi-Clients sowie zentrale Siteindikatoren.
Network Swimlanes
Getrennte Sichten für vorhandene Wireless-, Wired- und WAN-Domänen.
Events
Nach Gerätetyp gegliederte Ereignisse im zeitlichen Zusammenhang.
Applications
Applikationsname, Clientanzahl sowie gesendete und empfangene Bytes.
Weitere Siteinformationen können aktuelle WLANs mit SSID, AP-/Clientanzahl, Bytes, Bändern und Security sowie AP-, Client- und Switchlisten enthalten. Ein Klick auf ein Objekt lädt den entsprechenden engeren Insights-Kontext.
Organization Insights
Für Entire Org dokumentiert Juniper eine Organization-Insights-Ansicht mit Overview und Trends. Die aktuelle Dokumentation kennzeichnet diese Funktion als Beta; Verhalten und Oberfläche können sich daher ändern.
7. Geräte- und Client-Detailansichten
| Kontext | Beispiele | Beweiskraft |
|---|---|---|
| AP Insights | Traffic, Clients, Funkwerte, AP-Events, aktuelle Eigenschaften | Radio-/AP-bezogene Ursache |
| Client Insights | Association, Auth, DHCP, DNS, Roaming, RSSI/SNR, Timeline | End-to-End-Verlauf eines Clients |
| Switch Insights | CPU, Memory, Bytes, Port Errors, Power Draw, Events, Tabellen | Wired Underlay und Portzustand |
| Wired Client | Switch, Port, VLAN, Authentifizierung, verbundene Geräte | Endpoint- und Access-Port-Pfad |
| WAN Edge | Links, Anwendungen, Pfade, Tunnel und WAN-SLEs | Standort- und Applikationspfad |
Ein einzelnes Diagramm beweist selten eine Ursache. Erst die zeitliche Übereinstimmung von User Impact, Gerätedaten, Events und Pfadmetriken ergibt eine belastbare Korrelation.
8. Marvis Actions im Dashboard-Kontext
Marvis Actions priorisieren erkannte Probleme und Handlungsmöglichkeiten. Sie ergänzen SLEs und Insights: SLEs zeigen die Wirkung, Insights liefern den Verlauf, Marvis strukturiert die wahrscheinliche Ursache und mögliche Aktion.
SLE-Abweichung→korrelierte Evidenz→Marvis Action→Adminprüfung→Aktion und Validierung
| Prüfung | Frage |
|---|---|
| Scope | Organisation, Site, Gerät oder Client? |
| Impact | Wie viele User Minutes, Clients oder Sites? |
| Evidence | Welche Messwerte und Ereignisse stützen die Diagnose? |
| Recommendation | Welche konkrete Änderung wird vorgeschlagen? |
| Guardrails | Ist Self-Driving freigegeben und welcher Rollback existiert? |
| Outcome | Welche SLE oder Betriebskennzahl muss sich verbessern? |
Keine Gleichsetzung: Eine Marvis Action ist eine priorisierte, datenbasierte Handlungshilfe. Sie ersetzt nicht Change-Bewertung, Verantwortlichkeit und Erfolgskontrolle.
9. Standard Analytics
Standard Analytics ist laut Juniper im Mist-Portal enthalten und benötigt keine separate Premium-Analytics-Subscription. Die Dokumentation nennt historische Sichtbarkeit bis zu 30 Tagen.
Network Analytics
Netzwerkleistung, Traffic, verbundene Geräte, Measures, Entities und Events.
Events
Aufgelöste und laufende Ereignisse einer Site in analytischer Sicht.
Occupancy Analytics
Auslastung und Überbelegung von Bereichen, sofern die Standortdaten vorhanden sind.
Engagement Analytics
Besuche, Verweildauer und Wartezeit im Location-/Engagement-Kontext.
Die tatsächliche Sichtbarkeit einzelner Menüs hängt zusätzlich von Rolle, konfigurierten Diensten und Datenverfügbarkeit ab.
10. Network Analytics
Unter Analytics → Network Analytics lassen sich Netzwerkperformance, Traffic, Geräteinformationen und Trends untersuchen. Der Scope kann laut Juniper unter anderem gesamte Organisation, Site, Floorplan, AP, Client oder Zone umfassen; der Zeitraum Stunde, Tag, Woche, Monat oder einen benutzerdefinierten Bereich.
Beispielhafte Measures
| Measure | Bedeutung | Interpretationsgrenze |
|---|---|---|
| Bytes | übertragenes Clientdatenvolumen | kein direkter Beleg für Qualität |
| Auth Latency | mittlere Authentifizierungsdauer | Scope und Authverfahren beachten |
| DHCP Latency | Zeit für DHCP-Verbindungsaufbau | Client-, Relay- und Serveranteile korrelieren |
| DNS Latency | Zeit der DNS-Verarbeitung aus Clientsicht | Resolver, Pfad und Cache beeinflussen Wert |
| Channel Utilization | Auslastung nach Band/AP | Auslastung ist nicht automatisch Wi-Fi-Traffic |
| RSSI / SLE | Signal- beziehungsweise Experience-Trend | Aggregation kann Ausreißer verdecken |
Über das Werkzeug zum globalen Anwenden von Scope und Zeitraum werden dieselben Randbedingungen auf alle Tiles übertragen. Das ist für einen konsistenten Vergleich wesentlich.
11. Tiles und benutzerdefinierte Reports
Network Analytics stellt Standard-Reports als Vorlagen bereit. Juniper nennt beispielsweise AP Count, Active Client Trends across WLANs, Bytes Counts, Active Clients Count, Sites by Clients und Traffic Utilization across WLANs.
Die Ausgangsvisualisierung passend zur Fragestellung auswählen.
Zweck, Scope und Kennzahl im Reportnamen kenntlich machen.
Messgröße sowie Gruppierung – etwa Site, AP, WLAN oder Client – definieren.
Count, Trend, Average, List oder Ranking sachgerecht einsetzen.
Band, Modell, Gerätetyp, Betriebssystem oder WLAN dokumentieren.
Tile im Dashboard mit identischem Scope und Zeitraum validieren.
Ein Tile ist keine Rohdatentabelle: Visualisierung, Gruppierung, Sortierung und Aggregation verändern die Wahrnehmung. Für technische Entscheidungen muss die Definition der dargestellten Kennzahl erhalten bleiben.
13. Premium-Dashboard-Katalog
Der Katalog entwickelt sich weiter. Die folgenden Kategorien zeigen typische Einsatzfelder, keine für jede Subscription garantierte Vollständigkeit.
| Kategorie | Beispiel-Dashboards | Nutzen |
|---|---|---|
| Wireless | Wireless Network Insights, AP Insights, RF Health and Utilization | SLE, Sessions, Bänder, RF und Clientverteilung |
| Wired | Wired Network Insights, Switch Insights, Executive Summary – Wired | Ports, Traffic, Fehler, Geräte- und SLE-Trends |
| WAN | WAN-/Application-/Peer-Path-Insights | Links, Pfade, Applikationserfahrung und Ausfälle |
| Location | Occupancy, Engagement, Asset Insights | Besuche, Verweildauer, Flächen- und Assetnutzung |
| Operations | Audit Logs, Inventory-/Firmware-orientierte Reports | Änderungsnachweis, Bestand und Compliance |
Für jeden Report werden erforderliche Datenquelle, Subscription, Scope, Retention und Schutzbedarf vor dem Einsatz geprüft.
14. Download und Export
Premium-Dashboards unterstützen Dashboard- und Tile-Aktionen. Die dokumentierten Optionen unterscheiden sich je Exportweg und Dashboard.
| Ebene | Optionen laut Juniper | Einsatz |
|---|---|---|
| Gesamtes Dashboard | PDF oder CSV; Papierformat; Tabellen erweitern; einspaltige Anordnung | Managementbericht oder Archiv |
| Einzelnes Tile | Daten herunterladen, vergrößern, Cache aktualisieren | technische Detailanalyse |
| geplante Zustellung | PDF, CSV oder PNG per E-Mail; maximal 15 MB | regelmäßiger Empfängerkreis |
| Tabellendaten | formatiert oder unformatiert; aktuelle/custom Zeilen | Weiterverarbeitung und Nachweis |
PDF oder CSV?
Erhält die visuelle Aussage und eignet sich für Freigabe, Besprechung und unveränderte Ablage.
CSV
Eignet sich für Nachrechnung und weitere Analyse; Format, Dezimalzeichen, Zeitzone und Einheiten müssen erhalten bleiben.
Juniper nennt für erweiterte Tabellen in geplanter Zustellung bis zu 5.000 dargestellte Zeilen, warnt jedoch vor Kürzung bei Überschreitung der 15-MB-Dateigrenze.
15. Reports planen und zustellen
Premium Analytics kann Reports regelmäßig erzeugen und per E-Mail zustellen. Dokumentierte Intervalle umfassen unter anderem Monate, Wochen, Tage, Stunden, Minuten, bestimmte Monate oder Tage sowie einen Data-Group-Update-Trigger.
Reportziel, fachlicher Verantwortlicher und Empfänger festlegen.
Reportperiode und Sites begrenzen; bei der dokumentierten Zustellmaske bis zu drei Sites.
PDF, CSV oder PNG nach Verwendungszweck auswählen.
Recurrence, Uhrzeit und Delivery Timezone festlegen.
Client-, Standort-, Besucher- und Auditdaten nach Erforderlichkeit minimieren.
Größe, Filter, Zeitzone, Links, Empfänger und Lesbarkeit prüfen.
Empfängerkreis und fachliche Relevanz regelmäßig bestätigen.
Juniper dokumentiert bis zu 50 konfigurierbare Report-Zeitpläne. Diese Plattformgrenze ersetzt keine interne Begrenzung nach Bedarf und Verantwortlichkeit.
16. Datenqualität und Interpretationsgrenzen
| Risiko | Wirkung | Kontrolle |
|---|---|---|
| Datenlücke | AP, Switch oder Edge war offline; Zeitraum wirkt zu gut oder unvollständig | Device Status und Events mitprüfen |
| Aggregation | kurze oder lokale Ausfälle verschwinden im Mittel | Zeitraum und Scope verengen |
| kleiner Nenner | hohe/geringe Prozentwerte wirken übertrieben | User Minutes und Clientanzahl anzeigen |
| Filterrest | Dashboard zeigt nur Teilmenge | Filter zurücksetzen und dokumentieren |
| Current vs. Historical | Ist-Zustand wird fälschlich historisiert | Felddefinition lesen |
| Zeitzonenversatz | Event und Ticket scheinen nicht zusammenzugehören | Zeitbasis normalisieren |
| Korrelation | gleichzeitige Trends werden als Ursache interpretiert | Event, Pfad und Gegenprobe verlangen |
| UI-/Produktänderung | Menü oder Kennzahl verändert sich | aktuelle Dokumentation und Release Notes prüfen |
Belastbare Aussage = definierte Kennzahl + korrekter Scope + vollständiger Zeitraum + nachvollziehbare Evidenz
17. Rollen, Sichtbarkeit und Datenschutz
Reports zeigen nur Daten, die Rolle, Scope und Subscription zugänglich machen. Juniper stellt seit 2025 eine eingeschränkte Rolle Reporting bereit. Sie besitzt laut Produktupdate denselben API-Zugriff wie eine Observer-Administrator-Rolle, ist im Portal jedoch auf Engagement, Occupancy, Network und – bei aktiver Lizenz – Premium Analytics begrenzt.
| Prinzip | Umsetzung |
|---|---|
| Least Privilege | Reporting-Rolle statt allgemeiner Schreibrechte, wenn ausreichend |
| Scope-Minimierung | nur notwendige Organisationen, Site Groups oder Sites |
| Datenminimierung | Client-, Besucher-, Asset- und Auditdaten nur bei Erforderlichkeit |
| Empfängerkontrolle | Verteiler, externe Adressen und Weiterleitungsrisiko prüfen |
| Auditierbarkeit | Owner, Zweck, Zeitplan und Änderungen dokumentieren |
| Aufbewahrung | exportierte Dateien nach interner Lösch- und Schutzregel behandeln |
Datenschutzprüfung: Ob ein Report personenbezogene Daten enthält und auf welcher Grundlage er verarbeitet werden darf, hängt vom konkreten Inhalt und Einsatzzweck ab. Das ist organisatorisch beziehungsweise rechtlich zu prüfen; das Dashboard entscheidet dies nicht.
18. SLEs und Insights über APIs
Juniper stellt SLE- und Insights-Daten auch über REST APIs bereit. Das ermöglicht historische Auswertung, Automatisierung oder die Integration in eigene Observability-Systeme.
Mist API→authentifizierte Abfrage→normalisierte Zeitreihe→eigener Report / Alert
Technische Mindestanforderungen
- Region beziehungsweise API-Basis-URL korrekt
- Organization- und Site-IDs statt bloßer Anzeigenamen
- least-privilege Token und sichere Secret-Verwaltung
- Zeitraum, Intervall, Pagination und Rate Limits berücksichtigt
- Einheiten, Nullwerte und fehlende Daten dokumentiert
- API-Ergebnis gegen Portalansicht mit identischem Scope verglichen
- Schema- und Produktänderungen überwacht
Numerische Unterschiede können aus Zeitfenstergrenzen, Aggregationsintervallen, verspäteter Verarbeitung, Filtern oder unterschiedlichen Datenmodellen entstehen. Portal und API werden deshalb nur bei identischer Definition verglichen.
19. Drei praxistaugliche Report-Workflows
A. NOC-Tageslage
Org/Site Insights→schlechte SLEs→Marvis Actions→kritische Events→Ticket
Kurzer Zeitraum, operative Priorisierung, konkrete Owner und betroffene User Minutes.
B. Technische Wochenanalyse
Network Analytics→SLE-/Traffic-Trend→Top Sites/APs→Insights Drill-down→Maßnahme
Gleiche Filter jede Woche, Ursachenbeleg und Vorher-/Nachher-Vergleich.
C. Management-Monatsbericht
Premium Dashboard→Langzeittrend→Impact→Maßnahmenstatus→PDF-Zustellung
Wenige stabile KPIs, verständliche Definitionen, Trend statt Einzelfall und keine unnötigen personenbezogenen Details.
20. Systematische Fehlersuche
Nicht „Dashboard ist rot“, sondern Site, Dienst, Nutzerwirkung und Zeit benennen.
Organization, Site, Objekt und aktive Filter notieren.
Zeitraum, Intervall, Zeitzone und Datenvollständigkeit abgleichen.
Zähler, Nenner, Einheit, Aggregation und Threshold klären.
SLE → Classifier → betroffene Objekte → Insights → Event.
Client, Funk, AP, Switchport, DHCP/DNS/Auth und WAN/Anwendung prüfen.
anderer Client, Site, Zeitraum oder ungefilterte Ansicht vergleichen.
Export, Scope, Timestamp, Befund und Maßnahme dokumentieren.
| Symptom | Wahrscheinliche Erklärung | Erste Prüfung |
|---|---|---|
| Dashboard leer | falscher Scope, keine Telemetrie, Rolle oder Subscription | Filter, Device Status, Lizenz |
| Tiles zeigen verschiedene Zahlen | abweichender Scope/Zeitbereich oder Aggregation | globale Filter anwenden |
| Portal und CSV weichen ab | Formatierung, Cache, Zeilenumfang oder Zeitfenster | Exportoptionen und Rohwerte |
| SLE gut, Tickets schlecht | betroffene Anwendung nicht durch SLE abgebildet oder Scope zu breit | Client-/App-Insights |
| Report unvollständig | 15-MB-Grenze oder Tabellenkürzung | Dateigröße und Row-Option |
| Menü fehlt | Rolle, Subscription oder Dienst nicht aktiv | Adminrolle und Subscription |
| Eventzeit passt nicht | Zeitzonenunterschied | Portal-, Site- und Delivery-Zeit |
21. Report- und Abnahmecheckliste
Vor Erstellung
- Zweck und Zielgruppe definiert
- operative oder analytische Ansicht gewählt
- Subscription und Rolle geprüft
- Scope und Zeitraum festgelegt
- Kennzahlen definiert
- Datenvollständigkeit geprüft
- Datenschutzbedarf bewertet
Vor Verteilung
- Filter sichtbar dokumentiert
- Zeitzone und Exportzeit notiert
- Prozentwert mit Nenner geprüft
- Trend durch Insights belegt
- Format und Dateigröße geprüft
- Empfänger bestätigt
- Owner und Review-Termin gesetzt
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „Dashboard und Report sind dasselbe.“ | Falsch | Das Dashboard ist eine interaktive Sicht; ein Report ist eine gespeicherte oder zugestellte Ausgabe mit definiertem Scope. |
| „Premium Analytics ist immer enthalten.“ | Falsch | Juniper führt Premium Analytics als lizenzpflichtigen Dienst. |
| „Ein Monatsmittel zeigt jede Störung.“ | Falsch | Aggregation kann kurze oder lokale Probleme verdecken. |
| „95 % SLE sind ohne weitere Angaben eindeutig.“ | Falsch | Zeitraum, Scope, Threshold und relevante User Minutes fehlen. |
| „Gleichzeitigkeit beweist die Ursache.“ | Falsch | Korrelation benötigt Event-, Pfad- und Gegenbelege. |
| „CSV und Diagramm müssen optisch identisch sein.“ | Falsch | CSV kann unformatierte Werte enthalten; Visualisierung kann runden und aggregieren. |
| „Ein Reporting-Zugang braucht Org-Admin-Rechte.“ | Falsch | Juniper bietet eine eingeschränkte Reporting-Rolle; der konkrete Scope bleibt zu prüfen. |
| „Current Values folgen immer dem Zeitfilter.“ | Falsch | Bei Switch Insights dokumentiert Juniper aktuelle Werte unabhängig vom historischen Zeitbereich. |
Merksätze
- Die Betriebsfrage bestimmt die Ansicht – nicht umgekehrt.
- Jede Kennzahl braucht Scope, Zeitraum, Einheit und Definition.
- SLE-Prozentwert und User Minutes gehören zusammen.
- Insights liefern den zeitlichen und objektbezogenen Beleg.
- Standard Analytics ist nicht Premium Analytics.
- Ein Tile visualisiert aggregierte Daten und ist keine Rohdatentabelle.
- Current Values sind nicht automatisch historische Werte.
- Exportformat und Empfänger richten sich nach Zweck und Schutzbedarf.
- Korrelation ist ein Hinweis, keine alleinige Kausalitätsprüfung.
- Ein guter Report bleibt reproduzierbar und fachlich nachvollziehbar.
Offizielle Grundlagen
- Introduction to Juniper Mist Analytics
- Mist Standard Analytics Dashboards
- Network Analytics
- Mist Premium Analytics Dashboards
- Wireless Network Insights
- Wired Network Insights
- Insights Overview
- Site Insights
- Organization Insights (Beta)
- Use Mist SLEs and Insights with APIs
- Reporting Role – Product Update
Stand der fachlichen Prüfung: August 2026. Portalnavigation, Beta-Funktionen, Dashboard-Katalog, Datenhaltung, Exportoptionen und Rollen können sich ändern. Für den produktiven Einsatz gelten die aktuelle Juniper-Dokumentation, die konkrete Cloudregion, aktive Subscriptions und die wirksamen Administratorrechte.