Technische Dokumentation

Datenquellen und Schnittstellenauswahl

NetQuickCheck kombiniert Systemmessungen, aktive Netzwerkprüfungen und abgeleitete Statistiken. Systemmessungen liefern Informationen zu Schnittstellen, WLAN und Prozessverbindungen. Aktive Prüfungen erfassen die Antwort eines Ziels auf eine Anfrage. Statistiken wandeln die Beobachtungen in Übertragungsraten, Perzentile und Diagramme um.

Aufgaben mit einer ausgewählten Schnittstelle binden ihre Anfragen daran. TCP-, UDP- und direkte HTTP-Anfragen verwenden die Network.framework-Schnittstellenbindung; ICMP-Probes verwenden das Schnittstellenargument des Systembefehls. Automatisches Routing lässt macOS den Pfad auswählen und automatische HTTP-Anfragen folgen Systemsitzungs- und Proxy-Richtlinien. Die ausgewählte Schnittstelle wird mit den Ergebnissen gespeichert, um Vergleiche zwischen WLAN, Ethernet und anderen verfügbaren Schnittstellen zu unterstützen.

Aktuelles Netzwerk und Schnellchecks

Schnittstellenwerte und Übertragungsraten

Aktuelles Netzwerk liest Schnittstellenstatus, Adressen, Gateway und DNS sowie drahtlose Messwerte für das verbundene Wi-Fi-Netzwerk. Die übertragenen Bytes stammen von 64-Bit-System-Routing-Schnittstellenzählern. Empfangsfehler, Sendefehler und Empfangswarteschlangenverluste werden separat aufbewahrt.

Empfangsrate (B/s) = Anstieg der empfangenen Bytes zwischen den Abtastungen ÷ Abtastintervall (Sekunden)
Senderate (B/s) = Anstieg der gesendeten Bytes zwischen Abtastungen ÷ Abtastintervall (Sekunden)
Bitrate (Mbps) = Byterate × 8 ÷ 1.000.000

Die Raten beschreiben die mittlere Übertragungsmenge pro Zeitintervall. 1 MiB/s entspricht 1.048.576 B/s; 1 Mbps entspricht einer Million Bit pro Sekunde. Schnittstellenzähler und nach App summierte Zähler erfassen unterschiedliche Datenverkehrsmengen.

Der Ablauf eines Schnellchecks

Die Schnellprüfung bestätigt die lokale Verbindung, prüft das Gateway, fragt DNS ab, prüft die Internetkonnektivität, fordert HTTPS an und überprüft dann die Ausgangsinformationen. Die aktuelle Implementierung erlaubt 8 Sekunden für die gesamte Prüfung. Jeder aktive Schritt kann bis zu 2 Sekunden des verbleibenden Budgets verbrauchen und die Ergebnisse werden nach Abschluss jedes Schritts aktualisiert.

Der Gateway-Schritt versucht, eine TCP-Verbindung zum Gateway-Port 443 herzustellen. Sowohl eine erfolgreiche Verbindung als auch eine explizite Verbindungsablehnung bestätigen eine Antwort vom Gateway; das ursprüngliche Verbindungsergebnis bleibt ebenfalls erhalten. DNS-, Internet- und HTTPS-Schritte zeichnen ihre eigenen Antworten auf, um die Untersuchung jedes Teils des Verbindungspfads zu erleichtern.

WLAN-Scanning und WLAN-Metriken

Beim drahtlosen Scannen wird CoreWLAN verwendet, um die SSID, BSSID, den Primärkanal, das Band, die Kanalbreite und die Stärke des empfangenen Signals von nahegelegenen Access Points zu ermitteln. Der verfügbare Kanalkatalog stammt von der aktuellen drahtlosen Schnittstelle. Broadcast-Informationselemente fügen Sicherheitsfunktionen, Wi-Fi-Standards, Ländercodes und andere Details hinzu. Der Zugriff auf Kennungen wie SSID und BSSID folgt den macOS-Standortberechtigungsregeln.

RSSI, Rauschen und Signal-Rausch-Verhältnis

RSSI und Rauschen verwenden dBm, ein logarithmisches Leistungsmaß relativ zu 1 Milliwatt. Ein RSSI-Wert näher bei 0 bedeutet ein stärkeres empfangenes Signal. Wenn beide Messwerte gültig sind, berechnet die App das Signal-Rausch-Verhältnis:

SNR (dB) = RSSI (dBm) − Rauschen (dBm)

Beispielsweise ergibt ein RSSI von −55 dBm und ein Rauschen von −92 dBm ein SNR von 37 dB. Die aktuelle Berechnung akzeptiert Werte von −127 bis −1 dBm. Wenn einer der Messwerte fehlt, bleibt SNR leer.

Die drahtlose Signalüberwachung verfügt über zwei Abtastquellen. Der lokale Modus liest regelmäßig das verbundene Wi-Fi-Netzwerk. Der Nearby-Modus scannt wiederholt ausgewählte Zugangspunkte. In den Diagrammen wird der Zeitpunkt jeder Messung gespeichert und die Identitäten der Zugangspunkte unterscheiden verschiedene Funksignale.

Gemeldete Kanalauslastung

Wenn ein Zugangspunkt ein gültiges BSS-Load-Informationselement sendet, wandelt die App sein Kanalnutzungsfeld von 0–255 in einen Prozentsatz um: Feldwert × 100 ÷ 255. Dadurch bleibt die Bedeutung des Broadcast-Werts erhalten. Das Kanalüberlappungsdiagramm verwendet das unten beschriebene Frequenzabdeckungs- und Leistungsmodell.

Kanalabdeckung und -bewertung

Konvertieren von Kanälen in Frequenzbereiche

Die Kanalauswertung bildet Frequenzbereiche aus Band, Primärkanal und Kanalbreite. Für die 2,4-GHz-Kanäle 1–13 beträgt die Mittenfrequenz in MHz 2407 + 5 × Kanalnummer; Kanal 14 wird separat auf 2484 MHz abgebildet. Für 5 GHz sind es 5000 + 5 × Kanalnummer. Ein 20-MHz-Bereich erstreckt sich um 10 MHz zu beiden Seiten der Mitte; breitere Kanäle kombinieren vom Katalog unterstützte Unterkanalblöcke.

Kandidaten werden nach Frequenzband und Kanalbreite generiert und jeder Unterkanal in einem Kandidaten muss im aktuellen Katalog vorhanden sein. Die App wertet 20- und 40-MHz-Kombinationen auf 2,4 GHz sowie 20-, 40-, 80- und 160-MHz-Kombinationen auf 5 und 6 GHz aus. Scan-Datensätze werden nach Band und BSSID zusammengeführt. Wenn die BSSID fehlt, dient die Scan-Datensatzkennung als Fallback-Identität, um zu vermeiden, dass derselbe Zugangspunkt zweimal gezählt wird.

Wenn die Informationen zur Kanalbreite oder -richtung unvollständig sind, speichert die App bestätigte und mögliche Abdeckung separat. Bereiche, die von allen möglichen Positionen geteilt werden, sind bestätigte Abdeckung; der Rest bleibt mögliche Abdeckung. Jeder Zugangspunkt wird einmal gezählt.

Berechnung der Überlappungsleistung aus logarithmischen Signalwerten

Die Signalstärke wird von dBm in relative lineare Leistung umgewandelt und dann mit dem Anteil der Frequenzüberlappung gewichtet. Für Zugangspunkt i und Kandidat c:

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Gesamte überlappende Bandbreite ÷ Gesamte modellierte Zugangspunktbandbreite
Poverlap,c = Σ (Pᵢ × wᵢ,c)

Der +100-Term bietet eine gemeinsame relative Leistungsreferenz. Wenn die Kanalbreite unsicher ist und den Kandidatenbereich überlappt, wird die Gewichtung konservativ auf 1 gesetzt. Daher tragen sowohl die Signalstärke als auch die Abdeckungsbreite dazu bei. Eine RSSI-Differenz von 10 dB entspricht einer zehnfachen linearen Leistungsdifferenz.

Ranking der Kandidaten

Wenn der aktuelle Zugangspunkt identifiziert werden kann, wird er ausgeschlossen, sodass das Ranking Umgebungssignale bewertet. Das aktuelle Ranking filtert DFS-Kandidaten heraus. Auf 2,4 GHz bei 20 MHz wird die Kanalgruppe 1, 6 und 11 bevorzugt, gefolgt von Vergleichen von Zugangspunkten mit fehlendem RSSI, geschätzter Interferenzleistung, Gesamtzahl der Zugangspunkte und Kanalsequenz.

Wenn jeder Kandidat über vergleichbare Rauschmesswerte verfügt, wird das Rauschen ebenfalls in lineare Leistung umgewandelt und einbezogen. Andernfalls werden Kandidaten nur anhand der überlappenden Signalleistung verglichen. Jeder in Frage kommende Unterkanal verwendet die Mitte seiner sortierten gültigen Rauschmesswerte; der vollständige Kandidat nimmt den höheren dieser Rauschwerte an.

Innerhalb desselben Frequenzbands und derselben Kanalbreite wird die aktuelle Konfiguration bevorzugt, wenn sie die Prioritätsgruppe und Anzahl der Zugangspunkte mit fehlendem RSSI mit dem besten Kandidaten teilt und ihre geschätzte Leistung nicht mehr als das Doppelte der Leistung des besten Kandidaten beträgt. Ein zweifacher linearer Leistungsunterschied beträgt etwa 3 dB. Dies reduziert Rangveränderungen, die durch kleine Unterschiede verursacht werden.

Überlappungskurven anzeigen

Überlappungskurven berechnen die gewichtete Leistung in einem 20-MHz-Fenster um jedes Kanalzentrum herum und nutzen dann logarithmische Komprimierung, um sie einem relativen Anzeigebereich von 0–1 zuzuordnen:

Anzeigeintensität = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

Diese vertikale Achse stellt die relative Überlappungsintensität dar, die aus den Scan-Messwerten abgeleitet wurde. Wenn ein überlappender Zugangspunkt kein gültiges RSSI hat, bleibt diese Position leer und die Kurve wird geteilt. Bestätigte und mögliche Frequenzabdeckung werden getrennt dargestellt.

Erkennung lokaler Netzwerkgeräte

Die Geräteerkennung kombiniert Bonjour-, WS-Discovery-, SSDP- und TCP-Service-Probes. Bonjour stellt angekündigte Serviceinstanzen bereit. WS-Discovery und SSDP fügen Antworten von kompatiblen Geräten hinzu. TCP-Probes prüfen Dienstantworten an Adressen innerhalb des aktuellen Scanbereichs.

Die aktuellen TCP-Probe-Ports sind 80, 443, 445, 22, 631 und 9100 und decken gängige Web-, Dateifreigabe-, Fernzugriffs- und Druckdienste ab. Anfragen verwenden die ausgewählte Schnittstelle. Beobachtungen behalten ihre Quelle, Adresse und tatsächliche Reaktion.

Die Geräteerkennung führt Beobachtungen aus jeder Quelle stapelweise zusammen und ordnet Namen, Typen und Dienste anhand von Geräteadressen und Dienstnachweisen zu. Nicht verfügbare Schnittstellen, Zugriffsverweigerungen, Zeitüberschreitungen und Dienstantworten werden getrennt erfasst. Beim Abbrechen oder Neustarten eines Scans werden verspätete Rückrufe des vorherigen Scans isoliert, damit sie die neuen Ergebnisse nicht beeinflussen.

App-Datenverkehr und Verbindungszuordnung

Suchen von Apps aus der Systemverbindungstabelle

App-Datenverkehr liest Prozesse, Protokolle, lokale und Remote-Endpunkte, Schnittstellen, Verbindungszustände und Bytezahlen von nettop. Die App kombiniert Informationen zur laufenden Anwendung, Beziehungen zu übergeordneten Prozessen und ausführbare Pfade, um Hilfsprozesse mit der zugehörigen App zu verknüpfen.

Der Eigentümerabgleich überprüft zunächst den Prozess selbst und verfolgt dann bis zu 16 übergeordnete Prozesse. Wenn keine Übereinstimmung gefunden wird, wird der App-Bundle-Pfad verwendet, der die ausführbare Datei enthält. Die Prozessidentität umfasst auch die Startzeit, um wiederverwendete PIDs zu unterscheiden.

Verbindungsänderungen berechnen und nach App summieren

Aufeinanderfolgende Messungen ordnen Verbindungen nach Prozess, Protokoll, lokalen und entfernten Adressen und Ports sowie Schnittstelle zu. Übertragungsraten werden nur berechnet, wenn beide Bytezähler zur selben vergleichbaren Verbindung gehören, und anschließend nach App summiert.

Verbindungs-Download-Rate = (aktuell empfangene Bytes − zuvor empfangene Bytes) ÷ Zeitunterschied
Verbindungs-Upload-Rate = (aktuell gesendete Bytes − zuvor gesendete Bytes) ÷ Zeitunterschied
App-Rate = Summe der gültigen Verbindungsraten für die App und die zugehörigen Prozesse

Neue Verbindungen stellen zunächst eine Basislinie her. Ein Zurücksetzen des Zählers, eine Schnittstellenänderung oder eine Probenlücke von mehr als 15 Sekunden erfordert neue vergleichbare Proben. Wenn das System mehrere identische Zeilen zurückgibt, die nicht eindeutig zugeordnet werden können, behält die App diese Zeilen bei und lässt ihre Raten leer, sodass Unklarheiten bei der Übereinstimmung nicht als Traffic-Spitze erscheinen.

Fernverbindungen und ICMP-Beobachtungen

Die App-Verbindungsüberwachung speichert die ersten und letzten gesehenen Zeiten, Statusänderungen und Verkehrsdeltas und prüft unabhängig erkannte Remote-IPs mit ICMP. Datenverkehr, Verbindungsaktivität und ICMP-Ergebnisse werden nach Zeit ausgerichtet. Der Latenzwert stammt aus der ICMP-Antwort der Ziel-IP.

Ping- und TCP-Prüfungen

ICMP Echo und das No-Response-Verhältnis

Ping löst die Zieladresse auf, hält sie für die Messung fest und sendet eine IPv4-ICMP-Echo- oder IPv6-ICMPv6-Echo-Anfrage. Die kontinuierliche Überwachung wiederholt dies gemäß der Konfiguration und erfasst tatsächliche Sendungen, Antworten, ausbleibende Antworten und zurückgegebene Umlaufzeiten.

Nicht-Antwort-Verhältnis = Anfragen ohne Antwort ÷ Tatsächlich gesendete Anfragen × 100 %

Bei der Zählung wird die Anzahl der durch die Systemausgabe bestätigten Versendungen verwendet. Fehler bei der Namensauflösung, Berechtigungsverweigerungen und Anfragen, die nicht gesendet werden konnten, behalten ihren spezifischen Status und gehen nicht in den Nenner der gesendeten Probe ein. Latenzstatistiken verwenden gültige Antwort-RTTs.

TCP-Portverbindungen

Nach der Auflösung des Ziels versucht die TCP-Portüberwachung, eine Verbindung zum ausgewählten Port herzustellen und misst mithilfe einer monotonen Uhr die Zeit bis zum Erfolg oder einem Fehler. Die DNS-Auflösung wird zuerst abgeschlossen und die TCP-Verbindungszeit wird separat gemessen. Erfolgs-, Verbindungsverweigerungs-, Timeout- und andere Systemfehler werden separat gespeichert, um zu zeigen, wie sich derselbe Service-Port im Laufe der Zeit verhält.

DNS-Abfragen und Antwortvalidierung

Die DNS-Überwachung fragt den ausgewählten Server und Datensatztyp ab, z. B. A, AAAA, CNAME, MX, TXT, NS, SOA oder PTR. Systemauflösung und explizite Serverabfragen folgen getrennten Pfaden. Automatisches Routing nutzt Systemauflösung oder dig je nach Anforderung; Anfragen, die an eine ausgewählte Schnittstelle gebunden sind, tauschen Pakete über den UDP-Port 53 aus.

Direkte Abfragen generieren eine Transaktions-ID und bilden den Fragennamen, den Typ und die IN-Klasse. Antworten werden auf Paketlänge, Transaktions-ID, Antwort-Flag, Fragenanzahl, Name, Typ und Klasse überprüft, bevor Antwortcodes, Ressourcendatensätze und TTLs analysiert werden. Der Paketparser erweitert komprimierte Domänennamenzeiger.

NOERROR mit Datensätzen des ausgewählten Typs, NOERROR ohne diese Datensätze, NXDOMAIN, abgeschnittene Pakete und Transportfehler werden separat aufgezeichnet. PTR-Abfragen konvertieren zunächst die IPv4- oder IPv6-Adresse in ihren Reverse-Lookup-Namen. Das Timing umfasst das Parsen von Abfragen und Antworten, und die Ergebnisse behalten den tatsächlichen Server- und Datensatzinhalt bei.

HTTP-Antwort und Phasen-Timing

Die Website-Überwachung sendet HTTP- oder HTTPS-HEAD-Anfragen und zeichnet den zurückgegebenen Statuscode, die endgültige URL und die Dauer auf. Das automatische Routing verwendet URLSession-Transaktionsmetriken. Bei einer expliziten Schnittstelle oder einem expliziten Auflösungspfad verwendet die direkte HTTP-Implementierung Network.framework-Verbindungsberichte und Anforderungszeitstempel.

Die Phasendauer ist die Differenz zwischen End- und Startzeitstempeln. Eine wiederverwendete Verbindung verfügt möglicherweise über keine neue DNS-, TCP- oder TLS-Stufe; Stufen ohne gültige Zeitstempel bleiben leer. Weiterleitungen behalten das Timing für jede Anfrage bei. Die gesamte Prüfdauer wird separat gemessen, da sie auch Auflösung, Weiterleitungen, Planung und anderen tatsächlichen Overhead umfasst.

HTTPS nutzt die Vertrauensvalidierung von Systemzertifikaten und extrahiert den Zertifikatsinhaber (Subject), den Aussteller, den Gültigkeitszeitraum und den SHA-256-Fingerabdruck aus gültigen Zertifikaten. HTTP-Statuscodes beschreiben die Antwort des Servers; Transportfehler beschreiben den Verbindungsvorgang. Beide werden getrennt gespeichert.

Netzwerkpfad- und Hop-by-Hop-Prüfungen

Die Netzwerkpfadüberwachung ermittelt die Zieladresse und hält sie für die Messung fest und sendet dann ICMP-Probes mit einem von 1 ansteigenden IPv4-TTL- oder IPv6-Hop-Limit. Zwischenrouter geben möglicherweise Antworten nach Zeitüberschreitung zurück, während das Ziel möglicherweise eine Echo-Antwort zurückgibt. Die App verwendet diese Antworten, um Hop-Adressen und verfügbare Zeiten zu organisieren.

In jeder Runde werden derzeit bis zu 16 Hops geprüft. Wenn ein Hop nicht antwortet, werden spätere Hops trotzdem überprüft. Eine Zielantwort beendet die Runde. Nicht erreichbare und durch Richtlinien verweigerte Antworten behalten ihre ursprünglichen Ergebnisse. Wenn eine Adresse ohne gültige Dauer verfügbar ist, wird die Adresse beibehalten und das Timing bleibt leer.

Durchsatz und Reaktionsfähigkeit unter Last

Aktuelles Netzwerk: Apple networkQuality

Aktuelles Netzwerk führt macOS networkQuality aus und analysiert seine strukturierten Ergebnisse, einschließlich Download, Upload, Leerlauflatenz und Reaktionsfähigkeit unter Last in RPM. RPM bedeutet Roundtrips pro Minute, gemessen mit dem Apple-Tool; die App behält den zurückgegebenen Wert. Die rohen Download- und Upload-Bitraten werden zur Anzeige in Mbit/s durch 1.000.000 geteilt.

Wenn eine Schnittstelle ausgewählt wird, schließt der Geschwindigkeitstestbefehl deren Schnittstellenargument ein und überprüft den im Ergebnis zurückgegebenen Schnittstellennamen. Wenn das System nur einige Metriken liefert, bleiben diese Felder erhalten und die anderen bleiben leer.

Monitor: Server- und System-Geschwindigkeitstests

Jede Monitor-Geschwindigkeitstestrunde führt Download- und Upload-Tests für den ausgewählten Cloudflare- oder LibreSpeed-Endpunkt durch und führt dann Apple networkQuality aus. Die beiden Methoden behalten ihre eigene Quelle, Zeit und tatsächlichen Ergebnisse. Endpunkt-Downloads lesen Testnutzlasten; beim Hochladen werden temporäre Daten verwendet, die von der App generiert werden. Der durchschnittliche Durchsatz wird aus den tatsächlich übertragenen Bytes und der für diese Phase verstrichenen Zeit berechnet:

Durchsatz (Mbps) = Tatsächlich übertragene Bytes × 8 ÷ Verstrichene Zeit (Sekunden) ÷ 1.000.000

Anfragen verwenden explizite Testnutzlasten, Zeitüberschreitungen und Cache-Richtlinien, wobei der Übertragungsfortschritt, die Zielbyteanzahl und die tatsächlich übertragenen Bytes separat gespeichert werden. Die Phasenergebnisse unterscheiden abgeschlossene, teilweise und fehlgeschlagene Übertragungen. Datensätze behalten den Server und die Schnittstelle bei, um Vergleiche unter denselben Bedingungen zu unterstützen.

Kontinuierliche Überwachung, Diagramme und Statistiken

Unabhängige Messungen auf einer gemeinsamen Zeitachse

Monitor umfasst zehn Tooltypen: Ping, TCP, DNS, Websites, Netzwerkpfade, Geschwindigkeitstests, WLAN-Signal, Schnittstellenverkehr, App-Datenverkehr und App-Verbindungen. Jede Aufgabe behält ihr eigenes Ziel, ihre eigenen Parameter und Abtastzeiten. Ein gemeinsames Zeitfenster ordnet Beobachtungen zeitlich ein, um Latenz, drahtlose Messwerte, Datenverkehr und Servicereaktionen im Laufe der Zeit zu vergleichen.

Aktive Prüfungen und Datenübertragungen erhalten getrennte Ressourcenkontingente. Das Standardbudget erlaubt 8 gleichzeitige Prüfungen und 2 gleichzeitige Übertragungen. Weitere Vorgänge warten auf ein freies Kontingent. Bei einem Abbruch wird es erst freigegeben, wenn der tatsächliche Vorgang beendet ist. Kontingente gelten für einzelne Prüfungen oder Übertragungen; wiederkehrende Aufgaben beantragen sie in jeder Runde erneut.

Diagrammsegmente und relative Änderungen

Diagramme verbinden Punkte nach Abtastzeit und Segmentidentität, halten Unterbrechungen getrennt und zeigen Ausfälle einzeln an. Die Interpolation an den Grenzen des Ansichtsfensters wird nur zum Zeichnen verwendet. Statistiken verwenden tatsächliche Beobachtungen.

Bei aktivierten Markierungen für relative Latenzspitzen berechnet die App den Median m der vorherigen 5 Messwerte im selben Segment. Latenzen über max(3 × m, m + 5 ms) werden markiert. Beim WLAN-Signal werden Abweichungen von mindestens 8 dB vom jüngsten Median markiert. Die Markierungen zeigen Änderungen gegenüber dem jüngsten Referenzniveau.

Median, P95 und Variation

Für die Statistik werden gültige, endliche Werte im Zeitfenster ausgewählt und aufsteigend sortiert. Bei ungerader Anzahl ist der Median der mittlere Wert; bei gerader Anzahl ist er der Mittelwert der beiden mittleren Werte. Ohne gültige Messwerte bleibt die Statistik leer. P95 verwendet die Nearest-Rank-Methode:

P95 = Wert an der Position ceil(0.95 × n) in aufsteigenden Abtastwerten
ICMP-No-Response-Verhältnis = unbeantwortete Anfragen ÷ tatsächlich gesendete Anfragen
ICMP-Latenzschwankung = Summe der absoluten RTT-Unterschiede zwischen gültigen benachbarten Antworten ÷ Anzahl gültiger benachbarter Paare

App-Verbindungs-ICMP-Sitzungen sammeln Perzentile mithilfe eines Histogramms mit einer Genauigkeit von 0,1 ms, unabhängig vom Aufbewahrungsfenster für den Rohverlauf. Gültige Antworten von 0 bis 2000 ms werden in Histogramm-Buckets eingegeben. Größere Werte führen zu einem Überlaufzähler und tragen zum Maximum bei; Perzentile, die in den Überlaufbereich fallen, bleiben leer. Bei der Latenzvariation werden nur gültige benachbarte Antworten im selben Segment mit einer Lücke von nicht mehr als 2,5 Sekunden gepaart.

Überwachungsaufzeichnungen und Berichtsexport

Überwachungsaufzeichnungen speichern Aufgabenparameter, Ziele, Probenzeiten, tatsächliche Ergebnisse und unterstützende Beweise. Diagramme zeigen Veränderungen im Laufe der Zeit, während Berichte Beobachtungen zum Lesen oder zur weiteren Verarbeitung organisieren.

HTML

Ein lesbarer Bericht mit Aufgabenzusammenfassungen, Ergebnissen und Details.

CSV

In Spalten wie Zeit, Kategorie, Objekt, Ziel, Methode, Status, Wert, Einheit und Details organisierte Beweise für die Tabellenanalyse.

JSON

Strukturierte Aufzeichnungen, Konfigurationen und Ergebnisse zur weiteren Verarbeitung.

Lange App-Verbindungssitzungen verwenden segmentierte Archive. Der Export legt zunächst den Lesebereich des Archivs fest und streamt dann die archivierten Daten und das aktuelle In-Memory-Tail, sodass ein Export konsistente Datengrenzen verwendet. Fehlende Werte, Fehler und Abbrüche behalten ihren eigenen Status, um eine konsistente Interpretation während der Überprüfung zu unterstützen.