HAR-Protokolle für WxCalling verstehen und Fehler beheben

Einleitung

Dieses Dokument beschreibt das Verständnis und die Fehlerbehebung von HAR-Protokollen.

Funktionsüberblick

Ein HAR-Protokoll (Short for HTTP Archive Logging, kurz für HTTP-Archivprotokollierung) ist ein Protokoll aller Netzwerkaktivitäten zwischen Ihrem Browser und einer Website während einer bestimmten Sitzung.

Wenn Sie eine Website besuchen, sendet Ihr Browser Anfragen an den Server und erhält Antworten. Die HAR-Datei erfasst alle diese Anfragen, Antworten und Timing-Informationen.

Sie sind unverzichtbar für die Diagnose von Problemen mit der Web-Performance, die Behebung von Netzwerkfehlern und die Analyse von API-Transaktionen.

Mithilfe von HAR-Protokollen können Ressourcen mit langsamem Laden, fehlgeschlagene Anfragen und Benutzerinteraktionen mit Webanwendungen nachverfolgt werden.

Einschränkungen

• HAR-Dateien können groß und manuell schwer zu analysieren sein.
• Vertrauliche Daten können protokolliert werden; Sicherstellung der Datenbereinigung vor der gemeinsamen Nutzung.
• Einige Sicherheitsrichtlinien können die vollständige Erfassung von HAR blockieren.

Vorsicht: Die HAR-Datei enthält den gesamten Inhalt der Anfragen und Antworten in Klartext (einschließlich Passwörter, Sitzungs-ID, Cookies usw.). Daher dürfen Sie eine HAR-Datei, die in einer Sitzung erstellt wurde, nicht an einen öffentlich zugänglichen Dienst weitergeben. Wenn die Registerkarte Netzwerk bei Eingabe eines Kennworts geöffnet wurde, wird dies in der HAR-Datei als Klartext angezeigt. Sie möchten diese Anmeldeinformationen entfernen, bevor Sie die HAR-Datei freigeben. Öffnen Sie die gespeicherte HAR-Datei in einem Texteditor, suchen Sie das Passwort und ersetzen Sie es durch einen zufälligen Text wie "". Ändern Sie die JSON-Formatierung der Datei nicht, während Sie diese Änderung vornehmen, da sie dann nicht ordnungsgemäß zur Überprüfung analysiert wird.

HAR Sanitizer-Tool

Verlauf

Im Jahr 2023 kam es bei Okta zu einem Sicherheitsvorfall, bei dem HAR-Dateien aus den Systemen zur Verwaltung von Support-Tickets gestohlen wurden. Die Angreifer benutzten den Zugriffstoken und die Cookies dieser Dateien, um Zugang zu ihren Kundenkonten zu erhalten. Als Reaktion darauf implementierte Okta ein Bereinigungstool.

Aktueller Zustand

Derzeit wird eine kontinuierliche Automatisierung durchgeführt, bei der versucht wird, die sensiblen Materialien aus den Spuren zu entfernen. Der Rest bleibt jedoch intakt, um die Fehlerbehebung und die Analyse des Problems zu ermöglichen.

Wenn Sie eine HAR-Datei hochladen, führt das Tool automatisch folgende Schritte aus:

1. Erkennt, dass eine HAR-Datei hochgeladen wurde
2. Bereinigung der HAR-Datei mit https://har-sanitize.cisco.com
3. Lädt die bereinigte Datei in das Ticket hoch
4. Verschlüsselt die ursprüngliche HAR-Datei mit GPG
5. Lädt die verschlüsselte HAR-Datei in das Ticket hoch
6. Löscht die ursprüngliche HAR-Datei aus dem Ticket
7. Fügt eine Notiz zum Vorgang und einen Link zu diesem Tool hinzu.

Anmerkung: Wenn Sie das Problem nicht mit der bereinigten Version der HAR-Datei lösen können, können Sie eine Ausnahme wie in den nächsten Abschnitten erläutert einreichen und eine Kopie der ursprünglichen HAR-Datei zurückerhalten.

So extrahieren Sie HAR-Protokoll

Generieren Sie eine HAR-Datei in Ihrem Browser

Siehe: Generieren Sie eine HAR-Datei in Ihrem Browser.

Aus dem Dokument extrahieren:

• Chrome:
  Öffnen Sie Entwicklertools (F12) > Registerkarte Netzwerk > Protokoll beibehalten > Aufzeichnung starten > Problem reproduzieren > HAR-Datei exportieren.
• Firefox:
  Öffnen Sie Entwicklertools (F12) > Registerkarte Netzwerk > Modulsymbol > Aktivieren Sie "Persist Logs" > Aufzeichnung starten > HAR speichern.

Nützliche Informationen vor der Analyse von HAR-Protokollen

HTTP-Methoden

HTTP-Methoden (auch als HTTP-Verben bezeichnet) definieren den Typ des Vorgangs, den ein Client für eine bestimmte Ressource (z. B. Daten oder eine Webseite) ausführen möchte.

Jede Methode hat einen bestimmten Zweck und Semantik.

Die gängigsten HTTP-Methoden sind: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS und TRACE.

* PATCH ist in der Regel imposant, hängt jedoch von der Implementierung ab.

Erläuterung der Spalten

• Safe: Gibt an, ob die HTTP-Methode als sicher angesehen wird, d. h., dass sie keine Änderungen an Ressourcen oder am Serverstatus vornimmt. Safe-Methoden sind nur für den Abruf und nicht für Änderungen vorgesehen. Sie werden in der Regel für schreibgeschützte Vorgänge verwendet.
• Idempotent: Gibt an, ob eine mehrmalige Wiederholung derselben HTTP-Anforderung dieselbe Wirkung hat wie eine einmalige Anforderung. Eine idempotent-Methode bedeutet, dass das Ergebnis unabhängig davon, wie oft die Anforderung wiederholt wird, unverändert bleibt (nach der ersten erfolgreichen Anforderung).
• Typische Verwendung: Beschreibt den allgemeinen Zweck oder das Szenario, für den bzw. das die HTTP-Methode verwendet wird. Dies gibt den Kontext für den Zeitpunkt und die Gründe an, warum Sie die einzelnen Methoden in der Webentwicklung oder im API-Design verwenden würden.
• Request Body: Gibt an, ob die HTTP-Anfrage in der Regel einen Body enthält (Daten, die an den Server gesendet werden). Der Anforderungstext wird häufig zum Senden von Daten (z. B. JSON, XML, Formulardaten) an den Server verwendet, z. B. beim Erstellen oder Aktualisieren von Ressourcen. 
• Antworttext: Gibt an, ob die HTTP-Antwort in der Regel einen Textkörper enthält (Daten, die vom Server zurückgegeben werden). Der Antworttext ist die Daten, die vom Server an den Client zurückgesendet werden, z. B. die angeforderte Ressource, Statusmeldungen oder die Bestätigung einer Aktion.

Anatomie eines HAR-Protokolls

Anmerkung: Alle Beispielbilder in diesem Abschnitt wurden erstellt, als versucht wurde, die Speicherorte in Control HUB für eine Organisation zu laden.

Header

Erfasst Metadaten, die zwischen dem Client (Browser) und dem Server bei HTTP-Anfragen und -Antworten ausgetauscht werden.

Header stellen Kontext zu den gesendeten oder empfangenen Daten bereit, z. B. den Inhaltstyp, Authentifizierungsinformationen, Caching-Richtlinien usw.

Header sind in den folgenden Abschnitten eines HAR-Protokolls enthalten:

1. Anforderungs-Header: Diese werden im Rahmen der HTTP-Anfrage vom Browser (Client) an den Server gesendet.
2. Antwort-Header: Diese werden vom Server als Antwort auf die Anforderung an den Browser zurückgegeben.

Header werden als Arrays von Schlüssel-Wert-Paaren gespeichert, wobei:

• Wichtigste: Der Name des Headers.
• Wert: Der dem Header zugeordnete Wert.

Häufig verwendete Anforderungsheader

1. Gastgeber: Gibt den Domänennamen des Servers (z. B. as example.com) und die Portnummer an.

• Beispiel: Host: www.example.com

2. Benutzer-Agent: Identifiziert den Browser oder Client, der die Anforderung sendet, sowie dessen Version und Betriebssystem.

• Beispiel: Benutzer-Agent: Mozilla/5.0 \(Windows NT 10.0; Win64 x64

3. Akzeptieren: Gibt die Inhaltstypen an, die der Client verarbeiten kann (z. B. HTML, JSON, Bilder).

• Beispiel: Akzeptieren: text/html,application/xhtml+xml

4. Akzeptieren der Kodierung: Gibt die Codierungsarten an (z. B. gzip, deflate), die der Client decodieren kann.

• Beispiel: Accept-Encoding: gzip, deflationieren

5. Genehmigung: Enthält Anmeldeinformationen für die Authentifizierung, z. B. Token oder grundlegende Authentifizierungsinformationen.

• Beispiel: Berechtigung: Träger <Token>

6. Cookies: Enthält Cookies, die vom Client an den Server gesendet werden.

• Beispiel: Cookie: sessionId=12345; userPref=darkMode;

7. Inhaltstyp: Gibt den Datentyp an, der im Anforderungstext gesendet wird (für POST-/PUT-Anforderungen).

• Beispiel: Inhaltstyp: application/json

8. Referent: Gibt die URL der Seite an, die den Client an die aktuelle Ressource verwiesen hat.

• Beispiel: Referent: https://www.example.com/

Häufig verwendete Antwort-Header

1.Inhaltstyp: Gibt den MIME-Typ der Ressource an (z. B. text/html, application/json).

• Beispiel: Inhaltstyp: application/json

2. Inhaltslänge: Gibt die Größe des Antwortkörpers in Byte an.

• Beispiel: Inhaltslänge: 1234

3. Cache-Steuerung: Gibt Zwischenspeicherungsrichtlinien für die Ressource an (z. B. ob und wie lange ein Zwischenspeicher verfügbar ist).

• Beispiel: Cache-Steuerung: Kein Cache, kein Store, Neuvalidierung erforderlich

4. Server: Identifiziert die Serversoftware/-version.

• Beispiel: Server: Apache/2.4.29

5. Set-Cookie: Enthält Cookies, die der Server vom Client speichern möchte.

• Beispiel: Set-Cookie: sessionId=67890; Path=/; Sicher

6. Datum: Das Datum und die Uhrzeit, an dem bzw. zu der der Server die Antwort generiert hat.

• Beispiel: Datum: Dienstag, 10. Oktober 2023, 12:00:00 Uhr GMT

7. Ort: Wird in Umleitungen verwendet und gibt die URL an, zu der der Client navigieren muss.

• Beispiel: Standort: https://www.example.com/new-page

8. ETag Ein eindeutiger Bezeichner für die Ressource, der häufig für Zwischenspeicherung und Versionsverwaltung verwendet wird.

• Beispiel: ETag: 12345abcd

9. Inhaltskodierung: Gibt an, wie der Antworttext codiert ist (z. B. gzip, deflate).

• Beispiel: Inhaltscodierung: gzip

10. Zugriffskontrolle - Herkunft zulassen: Gibt an, welcher Ursprung auf Ressourcen zugreifen darf (in CORS verwendet).

• Beispiel: Access-Control-Allow-Origin *

Anmerkung: Am relevantesten für WebEx Anrufe ist der Trackingid-Header, da Sie diese ID im LMA-Tool nachschlagen können.

Nutzlast

Daten, die im Text einer HTTP-Anfrage oder -Antwort gesendet oder empfangen werden.

Sie wird in der Regel mit POST-, PUT- oder PATCH-Anforderungen verknüpft, bei denen der Client Daten an den Server sendet, z. B. Formulareingaben, Datei-Uploads oder JSON-Daten für APIs.

Die Payload kann auch in HTTP-Antworten vorhanden sein, die vom Server zurückgegebene Daten enthalten, z. B. HTML, JSON oder binäre Inhalte (z. B. Bilder, Dateien).

Wo Payload in HAR-Protokollen erscheint

Die Payload ist in der Regel in zwei Hauptabschnitten des HAR-Protokolls enthalten:

1. Payload anfordern: Vom Client (Browser) an den Server gesendete Daten im Text einer HTTP-Anfrage.
2. Antwort-Payload: Vom Server an den Client zurückgegebene Daten im Text einer HTTP-Antwort.

Vorschau

Ist Teil des response.content-Objekts und stellt eine Darstellung der vom Server zurückgegebenen Daten in einem strukturierten und für Menschen lesbaren Format bereit, sofern verfügbar.

Die Vorschau wird in der Regel verwendet, um analysierte oder strukturierte Daten aus dem Antworttext benutzerfreundlich anzuzeigen, z. B. JSON, XML oder andere Formate.

Dieser Abschnitt ist besonders hilfreich beim Debuggen von APIs, beim Überprüfen zurückgegebener Daten oder beim Verstehen der Struktur der Serverantwort.

Antwort

Die Antwort enthält detaillierte Informationen über die HTTP-Antwort, die der Server für eine bestimmte Anforderung an den Client (Browser) sendet. Dieser Abschnitt enthält Metadaten, Header, Inhaltsdetails und andere wichtige Daten, die Ihnen helfen, das Verhalten des Servers während des Anforderungsantwortzyklus zu verstehen. Es bietet einen detaillierten Snapshot der Serverantwort auf eine HTTP-Anfrage.

Initiator

Der Initiator gibt Aufschluss darüber, was beim Laden einer Webseite eine bestimmte HTTP-Anforderung ausgelöst hat. Er identifiziert die Quelle oder Ursache einer Netzwerkanforderung und hilft Entwicklern dabei, die Ereigniskette zu verstehen, die zu der Anforderung geführt hat. Der Initiator hilft außerdem dabei, den Ursprung einer Anforderung zu verfolgen und kann auf die genaue Codezeile oder Ressource verweisen, die für die Erstellung verantwortlich ist.

Zeitplan

Die Zeitplanung bietet eine detaillierte Aufschlüsselung der verschiedenen Phasen, die bei der Verarbeitung einer HTTP-Anforderung und -Antwort erforderlich sind. Sie hilft Entwicklern dabei zu verstehen, wie lange jeder Schritt des Anforderungs-Antwort-Zyklus vom Initiieren der Verbindung bis zum Empfangen der endgültigen Antwort dauert. Die Zeitmessung verfolgt auch die Abfolge und Dauer von Ereignissen, die auftreten, wenn ein Browser eine Anforderung an einen Server sendet und eine Antwort empfängt. Sie umfasst detaillierte Metriken für die DNS-Auflösung, die Herstellung der Verbindung, das Senden der Anforderung, das Warten auf die Antwort des Servers und das Herunterladen der Antwortdaten.

Fehlerbehebung

Internes Tool zum Anzeigen von HAR-Protokollen

Navigieren Sie zu EasyLmaSearch > HAR-/Saz-Datei importieren.

Allgemeine Schritte zur Fehlerbehebung

1. Öffnen Sie die HAR-Datei in einem .
2. Erkennen fehlgeschlagener Anfragen (z. B. HTTP-4xx-/5xx-Fehler)

3. Antwortzeiten und Zeitlupenelemente prüfen.

4. Analysieren Sie die Header für Anfragen/Antworten auf Authentifizierungs- und CORS-Probleme.

5. Suchen Sie in Netzwerkanforderungen und nach Nachverfolgungs-IDs.
6. Gegenprüfung von Fehlern anhand der Antworten, falls möglich.

Beispiel für die Fehlerbehebung von Tickets

Elemente mit langsamer Belastung

Beispiel:

• Control Hub benötigt viel Zeit zum Laden der Nummern für einen Standort.

Fehlerbehebung:

• Video des Problems anfordern (Versuch, die Nummernseite für einen Standort zu laden)
• Anfordern eines HAR-Protokolls beim Laden der Nummern für einen Standort

1. Öffnen Sie die HAR-Datei in einem HAR Viewer oder in einem Browser.
   
2. Identifizieren Sie die Anfrage im Wasserfall Ansicht
   
3. Klicken Sie auf die Anforderung, deren Laden sehr lange dauert.
4. Überprüfen Sie die Registerkarte Timing des Protokolls:

5. Antwortzeiten und Zeitlupenelemente prüfen.

6. Ermitteln Sie die Trackingid für diesen Header.

7. Öffnen Sie EasyLMA und suchen Sie mit der Trackingid.

Erläuterung der Zeitgliederungsphasen

Hier finden Sie weitere Informationen zu den einzelnen Phasen, die Sie auf der Registerkarte Timing sehen können:

• Warteschlangenverwaltung: Der Browser stellt Anforderungen in die Warteschlange, bevor die Verbindung gestartet wird, und wenn:
  • Es gibt Anfragen mit höherer Priorität. Die Anforderungspriorität wird durch Faktoren wie den Ressourcentyp und den Speicherort im Dokument bestimmt. Weitere Informationen finden Sie im Ressourcenprioritätsabschnitt des Leitfadens zum Abrufen von Prioritäten.
  • Es sind bereits sechs TCP-Verbindungen für diesen Ursprung geöffnet, das ist die Grenze. (Gilt nur für HTTP/1.0 und HTTP/1.1)
  • Der Browser weist kurz Speicherplatz im Festplatten-Cache zu.
• Blockiert. Die Anforderung kann nach dem Start der Verbindung aus einem der unter Warteschlange beschriebenen Gründe gestoppt werden.
• DNS-Suche. Der Browser löst die IP-Adresse der Anforderung auf.
• Erstverbindung. Der Browser stellt eine Verbindung her, einschließlich TCP-Handshakes oder -Wiederholungen und Aushandeln einer SSL-Verbindung.
• Proxy-Aushandlung. Der Browser verhandelt die Anforderung mit einem Proxyserver.
• Anfrage gesendet. Die Anfrage wird gesendet.
• ServiceWorker-Vorbereitung. Der Service Worker wird vom Browser gestartet.
• Anfrage an ServiceWorker. Die Anforderung wird an den Servicemitarbeiter gesendet.
• Warten (TTFB) Der Browser wartet auf das erste Byte einer Antwort. TTFB steht für Time To First Byte (Zeit bis erstes Byte). Dieses Timing umfasst einen Round-Trip der Latenz und die Zeit, die der Server zur Vorbereitung der Antwort benötigte.
• Herunterladen von Inhalten Der Browser erhält die Antwort entweder direkt vom Netzwerk oder von einem Service-Mitarbeiter. Dieser Wert gibt die gesamte Zeit an, die zum Lesen des Antwortkörpers benötigt wird. Größer als erwartet kann ein langsames Netzwerk sein, oder der Browser ist mit anderen Aufgaben beschäftigt, die das Lesen der Antwort verzögern.

Ressource nicht verfügbar

Beispiel: 

"Ich habe SNR für meinen Benutzer im Admin Control Hub aktiviert, sehe jedoch keine Option zum Einrichten der SNR-Nummer, wenn ich mich beim Portal user.webex.com anmelde.
Könnten Sie bitte meine Organisation und den Benutzer überprüfen, um zu erfahren, warum diese auf dem Benutzer-Hub nicht angezeigt wird?"

Fehlerbehebung:

1. Bestätigen Sie, was der Benutzer sieht, indem Sie nach einem Screenshot eines funktionierenden Benutzers und eines nicht funktionierenden Benutzers fragen.

2. Fordern Sie ein HAR-Protokoll an, während Sie die Optionen für den Benutzer laden.

Weitere Schritte:

1. Öffnen Sie die HAR-Datei in einem HAR Viewer oder in einem Browser. 
   
2. Identifizieren von Anforderungen:

Service sendet eine Anfrage (GET), um die Dienste des Benutzers zu kennen

Anforderung der Endbenutzer-Funktionszugriffsvorlage (GET) für die Vorlage der Dienste, die dem Benutzer angezeigt werden:

1. Analysieren Sie Anforderungs-/Antwort-Header.
   
   "Kein Zugriff" bedeutet, dass die Vorlage diese Optionen für den Benutzer ausblendet.
2. Sie müssen die Vorlage für die Organisationseinheit überprüfen und die Erreichbarkeit unter einer Rufnummer aktivieren, damit der Benutzer sie im Benutzer-Hub sehen kann.

Beispiel:

Feature kann nicht aktiviert werden

Beispiel mit Anrufaufzeichnung:

Wenn Sie versuchen, die Anrufaufzeichnung für einen Benutzer zu aktivieren, erhalten Sie eine Fehlermeldung: "Änderung der Anrufaufzeichnung fehlgeschlagen".

So beheben Sie Probleme:

1. Bestätigen Sie den Fehler, indem Sie den vollständigen Text der Fehlermeldung anfordern.

2. Fragen Sie nach einem Screenshot des Fehlers.

3. Fordern Sie ein HAR-Protokoll an, während Sie versuchen, die "Anrufaufzeichnung" im betroffenen Benutzer zu aktivieren.

4. Öffnen Sie die HAR-Datei in einem HAR Viewer oder Browser Developer Tools.

5. Ermitteln Sie fehlgeschlagene Anfragen (z. B. HTTP-4xx-/5xx-Fehler).

6. Suchen Sie in EasyLMA nach den Tracking-IDs.


7. Mit der cpapi-Ausnahme können Sie ein BEMS öffnen:

8. Öffnen Sie ein BEMS mit den gesammelten Informationen:

• Screenshots
• Fehlermeldung abschließen
• Nachverfolgungs-ID
• cpapi-Ausnahme
  
  

9. Bitten Sie im Bereich "Dubber" oder das BU-Team, den Fehler zusammen mit dem Team von Dubber zu überprüfen:
"Zusammenfassung der Fehlerantwort: 400: Ungültiges Produkt: Fehler beim Erstellen des Dubpunkts in Dubber. HTTP-Status: 502"

FAX-Messaging

Das folgende Diagramm veranschaulicht den Bereitstellungsablauf beim Durchlaufen von Mikroservices:

Bei der Behebung von Problemen bei der Bereitstellung von Fax-Messaging im Control Hub muss eine HAR-Ablaufverfolgung erfasst werden, um detaillierte Einblicke in die Art des Problems zu erhalten und die Gründe für Bereitstellungsfehler zu ermitteln. 

Bei Aktivierung der Fax-Messaging-Funktion erfasst der HAR-Trace die entsprechende Anforderung von CH an CPAPI und zeigt diese an. Diese erfasste Anforderung folgt einem bestimmten Format.

Aus der CH → CPAPI:

PATCH
Anforderungs-URL:https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail
TrackingID ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Daten veröffentlichen {
"aktiviert": Richtig,
"Benachrichtigungen": {
"aktiviert": Richtig,
"Ziel": "lazoclaudiafi+faxmessaging@gmail.com"
},
"AlleAnrufe senden": {
"aktiviert": falsch
},
"sendBusyCalls": {
"aktiviert": Richtig,
Begrüßung: "STANDARD"
},
"SendUnansweredCalls": {
"aktiviert": Richtig,
Begrüßung: "STANDARD",
"maxRings": 3
},
"transferToNumber": {
"aktiviert": falsch
},
"emailCopyOfMessage": {
"aktiviert": Richtig,
"emailId": "lazoclaudiafi+faxmessaging@gmail.com"
},
"faxMessage": {
"aktiviert": Falsch,
"Telefonnummer": "+12099193323",
"Durchwahl": Null
},
"messageStorage": {
"mwiEnabled": Richtig,
"storageType": "INTERN",
ExterneE-Mail: "lazoclaudiafi+faxmessaging@gmail.com"
}

Um diese Informationen in EasyLMA effektiv zu verfolgen, lesen Sie bitte die hier bereitgestellten detaillierten Anleitungen: 

Kategorie: TrackingID
Unterkategorie: global
WebEx Tracking-ID: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Eskalationsinformationen

• HAR-Protokolldatei
• Screenshots zu Fehlern
• Schritte zur Reproduktion des Problems
• Zeitstempel des Vorfalls
• LMA-Protokolle

Bitte beantworten Sie vor dem Öffnen der BEMS-Eskalation die folgenden Fragen, da dies bei der weiteren Fehlerbehebung hilfreich ist:

• Welchen Fehler sehen Sie?
• Welche Tracking-IDs sehen Sie?
• Haben Sie die Sendungsverfolgungs-ID in LMA überprüft?
• Was sehen Sie in LMA?
• Ist dieser BEMS wirklich notwendig?