HAR-logboeken voor WxCalling begrijpen en oplossen

Inleiding

Dit document beschrijft het begrijpen en oplossen van problemen met HAR-logs.

Overzicht van functies

Een HAR Log (afkorting voor HTTP Archive Logging) is een logboek van alle netwerkactiviteiten tussen uw browser en een website tijdens een specifieke sessie.

Wanneer u een website bezoekt, stuurt uw browser verzoeken naar de server en ontvangt deze antwoorden. Het HAR-bestand legt al die verzoeken, antwoorden en de timinginformatie vast.

Ze zijn essentieel voor het diagnosticeren van problemen met webprestaties, het oplossen van netwerkfouten en het analyseren van API-transacties.

HAR-logboeken helpen bij het identificeren van langzaam ladende bronnen, mislukte verzoeken en het volgen van gebruikersinteracties met webtoepassingen.

Beperkingen

• HAR-bestanden kunnen groot en moeilijk handmatig te ontleden zijn.
• Gevoelige gegevens kunnen worden vastgelegd; zorg voor gegevensontsmetting voordat u ze deelt.
• Sommige beveiligingsmaatregelen kunnen volledige HAR-vastlegging blokkeren.

Let op: Het HAR-bestand bevat de volledige inhoud van de verzoeken en antwoorden in duidelijke tekst (inclusief wachtwoorden, sessie-ID, cookies, enz.). Daarom mag u een HAR-bestand dat tijdens een sessie is gemaakt, niet delen met een openbare service. Als het tabblad Netwerk is geopend toen een wachtwoord werd ingevoerd, staat dit in duidelijke tekst in het HAR-bestand. U wilt deze referenties verwijderen voordat u het HAR-bestand deelt. Open het opgeslagen HAR-bestand in een teksteditor, zoek het wachtwoord en vervang het door een willekeurige tekst zoals "". Wijzig de JSON-opmaak van het bestand niet tijdens het aanbrengen van deze wijziging, omdat het dan niet goed wordt geparseerd voor beoordeling.

HAR-reinigingsmiddel

geschiedenis

In 2023 had Okta een beveiligingslek waarbij HAR-bestanden werden gestolen uit hun ondersteunende casemanagementsystemen. De aanvallers gebruikten de toegangstoken en cookies uit die bestanden om toegang te krijgen tot hun klantenaccounts. Als reactie hierop implementeerde Okta een ontsmettingsmiddel.

huidige toestand

Momenteel is er een voortdurende automatisering die probeert de gevoelige materialen uit de sporen te halen, maar de rest intact laat om de mogelijkheid te behouden om problemen op te lossen en uw probleem te analyseren.

Wanneer u een HAR-bestand uploadt, wordt de tool automatisch:

1. Detecteert dat een HAR-bestand is geüpload
2. Reinigt het HAR-bestand met https://har-sanitize.cisco.com
3. Upload het ontsmette bestand naar de case
4. Codeert het originele HAR-bestand met GPG
5. Upload het gecodeerde HAR-bestand naar de case
6. Verwijdert het originele HAR-bestand uit de case
7. Voegt een opmerking toe over de case waarin wordt uitgelegd wat er is gedaan en een link naar deze tool

Opmerking: Als u het probleem niet kunt oplossen met de gedesinfecteerde versie van het HAR-bestand, kunt u een uitzondering indienen zoals uitgelegd in de volgende secties en een kopie van het originele HAR-bestand terugkrijgen.

Hoe te extraheren HAR Log

Genereer een HAR-bestand in uw browser

Zie: Genereer een HAR-bestand in uw browser.

Uittreksel uit het document:

• Chrome:
  Open Hulpmiddelen voor ontwikkelaars (F12) > Tabblad Netwerk > Logboek behouden > Opname starten > Probleem reproduceren > HAR-bestand exporteren.
• Firefox:
  Open Hulpmiddelen voor ontwikkelaars (F12) > Tabblad Netwerk > Motorpictogram > Controleer "Logboeken voortzetten" > Opname starten > HAR opslaan.

Nuttige informatie voor het analyseren van HAR-logs

HTTP-methoden

HTTP-methoden (ook bekend als HTTP-werkwoorden) definiëren het type bewerking dat een client op een bepaalde bron (zoals gegevens of een webpagina) wil uitvoeren.

Elke methode heeft een specifiek doel en een specifieke semantiek.

De meest voorkomende HTTP-methoden zijn: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, en TRACE.

* PATCH is over het algemeen idempotent, maar het hangt af van de implementatie.

Uitleg van de kolommen

• Veilig: geeft aan of de HTTP-methode als veilig wordt beschouwd, wat betekent dat de methode geen middelen wijzigt of de serverstatus Veilige methoden zijn alleen bedoeld voor ophalen, niet voor het aanbrengen van wijzigingen. Ze worden meestal gebruikt voor alleen-lezen bewerkingen.
• Idempotent: Hiermee geeft u aan of het meerdere keren herhalen van hetzelfde HTTP-verzoek hetzelfde effect heeft als het één keer doen. Een idempotente methode betekent dat het niet uitmaakt hoe vaak het verzoek wordt herhaald, het resultaat ongewijzigd blijft (na het eerste succesvolle verzoek)
• Typisch gebruik: Beschrijft het algemene doel of scenario waarvoor de HTTP-methode wordt gebruikt. Dit geeft context voor wanneer en waarom u elke methode zou gebruiken in webontwikkeling of API-ontwerp.
• Verzoeksinstantie: geeft aan of het HTTP-verzoek doorgaans een instantie bevat (gegevens die naar de server worden verzonden). De verzoekinstantie wordt vaak gebruikt om gegevens (zoals JSON, XML, formuliergegevens) naar de server te verzenden, zoals bij het maken of bijwerken van bronnen. 
• Responsstructuur: geeft aan of de HTTP-respons meestal een hoofdtekst bevat (gegevens die door de server worden geretourneerd). De antwoordinstantie is de gegevens die van de server naar de client worden teruggestuurd, zoals de gevraagde bron, statusberichten of bevestiging van een actie.

Anatomie van een HAR Log

Opmerking: Alle voorbeeldafbeeldingen in deze sectie zijn gemaakt wanneer u de locaties in Control HUB voor een organisatie probeert te laden

Koppen

Hiermee worden metagegevens vastgelegd die worden uitgewisseld tussen de client (browser) en de server tijdens HTTP-verzoeken en -reacties.

Headers bieden context over de gegevens die worden verzonden of ontvangen, zoals het type inhoud, authenticatiegegevens, cachingbeleid en meer.

Headers zijn opgenomen in deze secties van een HAR-log:

1. Verzoekkoppen: Deze worden vanuit de browser (client) naar de server verzonden als onderdeel van het HTTP-verzoek.
2. Reactiekoppen: Deze worden door de server teruggestuurd naar de browser als reactie op het verzoek.

Headers worden opgeslagen als arrays van sleutelwaardeparen, waarbij:

• Belangrijkste: de naam van de header.
• Waarde: de waarde die is gekoppeld aan de koptekst.

Kopteksten voor algemene aanvragen

1. Host: geeft de domeinnaam van de server (zoals example.com) en het poortnummer op.

• Voorbeeld: host: www.example.com

2. User-Agent: identificeert de browser of client die het verzoek doet, samen met de versie en het besturingssysteem.

• Voorbeeld: User-Agent: Mozilla/5.0 \(Windows NT 10.0; Win64; x64\)

3. Accepteren: geeft de soorten inhoud aan die de client kan verwerken (zoals HTML, JSON, afbeeldingen).

• Voorbeeld: Accepteren: tekst/html, toepassing/xhtml+xml

4. Accept-Encoding: geeft de typen codering aan (zoals gzip, deflate) die de client kan decoderen.

• Voorbeeld: Accept-Encoding: gzip, deflate

5. Autorisatie: Bevat referenties voor authenticatie, zoals tokens of basisreferenties voor authenticatie.

• Voorbeeld: autorisatie: drager <token>

6. Cookies: omvat cookies die door de klant naar de server worden verzonden.

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

7. Inhoudstype: geeft het soort gegevens aan dat in de verzoekende instantie wordt verzonden (voor POST-/PUT-verzoeken).

• Voorbeeld: Content-Type: application/json

8. Referer: identificeert de URL van de pagina die de client naar de huidige bron heeft verwezen.

• Voorbeeld: Referer: https://www.example.com/

Koppen voor gemeenschappelijke respons

1.Content-Type: geeft het MIME-type van de bron (zoals tekst/html, toepassing/json).

• Voorbeeld: Content-Type: application/json

2. Inhoud-lengte: geeft de grootte van het antwoordlichaam in bytes aan.

• Voorbeeld: lengte inhoud: 1234

3. Cachecontrole: geeft het cachebeleid voor de resource aan (bijvoorbeeld of de resource cachable is en voor hoe lang).

• Voorbeeld: Cache-Control: geen cache, geen opslag, opnieuw valideren vereist

4. Server: identificeert de serversoftware/versie.

• Voorbeeld: Server: Apache/2.4.29

5. Set-Cookie: Bevat cookies die de server wil dat de client opslaat.

• Voorbeeld: Set-Cookie: sessionId=67890; Path=/; Secure

6. Datum: de datum en het tijdstip waarop de server het antwoord heeft gegenereerd.

• Voorbeeld: Datum: di, 10 okt 2023 12:00:00 GMT

7. Locatie: wordt gebruikt in omleidingen, met vermelding van de URL waarnaar de client moet navigeren.

• Voorbeeld: Locatie: https://www.example.com/new-page

8. ETag: een unieke identificatiecode voor de bron, die vaak wordt gebruikt voor caching en versiebeheer.

• Voorbeeld: ETag: 12345abcd

9. Content-Encoding: Geeft aan hoe het responslichaam wordt gecodeerd (zoals gzip, deflate).

• Voorbeeld: Content-Encoding: gzip

10. Access-Control-Allow-Origin: geeft aan welke bronnen toegang mogen krijgen (gebruikt in CORS).

• Voorbeeld: Access-Control-Allow-Origin: *

Opmerking: Het meest relevant voor Webex Calling is de Trackingid Header, omdat dit de ID is die u kunt opzoeken in de LMA-tool.

nuttige lading

Gegevens verzonden of ontvangen in de hoofdtekst van een HTTP-verzoek of -antwoord.

Het wordt meestal geassocieerd met POST-, PUT- of PATCH-verzoeken, waarbij de client gegevens naar de server verzendt, zoals formulierinzendingen, bestandsuploads of JSON-gegevens voor API's.

De payload kan ook bestaan in HTTP-antwoorden, die gegevens bevatten die door de server zijn geretourneerd, zoals HTML, JSON of binaire inhoud (zoals afbeeldingen, bestanden).

Waar payload wordt weergegeven in HAR-logboeken

De payload wordt meestal gevonden in twee hoofdsecties van het HAR-logboek:

1. Payload aanvragen: gegevens die van de client (browser) naar de server worden verzonden in de hoofdtekst van een HTTP-verzoek.
2. Response Payload: Gegevens die door de server aan de client worden geretourneerd in de hoofdtekst van een HTTP-reactie.

Voorbeeld

Maakt deel uit van het object response.content en biedt een weergave van de gegevens die door de server worden geretourneerd in een gestructureerd en door de mens leesbaar formaat, indien beschikbaar.

De preview wordt meestal gebruikt om geparseerde of gestructureerde gegevens van de responsbody op een gebruiksvriendelijke manier weer te geven, zoals JSON, XML of andere indelingen.

Deze sectie is met name handig voor het debuggen van API's, het inspecteren van geretourneerde gegevens of het begrijpen van de structuur van de serverrespons.

reactie

Het antwoord geeft gedetailleerde informatie over de HTTP-reactie die de server naar de client (browser) stuurt voor een specifiek verzoek. Deze sectie bevat metagegevens, kopteksten, inhoudsdetails en andere kritieke gegevens die u kunnen helpen het gedrag van de server tijdens de reactiecyclus van het verzoek te begrijpen. Het biedt een gedetailleerde momentopname van het serverantwoord op een HTTP-verzoek.

initiatiefnemer

De Initiator geeft inzicht in wat een specifiek HTTP-verzoek heeft geactiveerd tijdens het laden van een webpagina. Het identificeert de bron of oorzaak van een netwerkverzoek en helpt ontwikkelaars de keten van gebeurtenissen te begrijpen die tot het verzoek hebben geleid. De initiator helpt ook bij het traceren van de oorsprong van een verzoek en kan verwijzen naar de exacte regel code of bron die verantwoordelijk is voor het maken ervan.

timing

Timing geeft een gedetailleerd overzicht van de verschillende fasen die betrokken zijn bij het verwerken van een HTTP-verzoek en -reactie. Het helpt ontwikkelaars te begrijpen hoe lang elke stap van de request-response cyclus duurt, van het initiëren van de verbinding tot het ontvangen van de uiteindelijke reactie. Timing houdt ook de volgorde en duur bij van gebeurtenissen die plaatsvinden wanneer een browser een verzoek indient bij een server en een reactie ontvangt.  Het bevat gedetailleerde statistieken voor DNS-resolutie, het tot stand brengen van de verbinding, het verzenden van het verzoek, wachten tot de server reageert en het downloaden van de responsgegevens.

Probleemoplossing

Intern gereedschap om HAR-logs te bekijken

Navigeer naar EasyLmaSearch > HAR/Saz-bestand importeren.

Algemene stappen voor probleemoplossing

1. Open het HAR-bestand in een .
2. Identificeer mislukte verzoeken (zoals HTTP 4xx/5xx-fouten).

3. Controleer de responstijden en de elementen voor langzaam laden.

4. Analyseer de koppen voor verzoeken/antwoorden voor verificatie en CORS-problemen.

5. Zoek naar tracking-ID's in netwerkverzoeken en.
6. Indien mogelijk, kruiscontrole van mislukkingen aan de hand van antwoorden.

Voorbeeld Problemen oplossen met tickets

Slow-loading elementen

Voorbeeld:

• Control Hub heeft veel tijd nodig om de nummers voor een locatie te laden

Problemen oplossen:

• Vraag een video van het probleem aan (probeer de pagina nummers voor een locatie te laden)
• Een HAR-log aanvragen terwijl u probeert de nummers voor een locatie te laden

1. Open het HAR-bestand in een HAR Viewer of browser Developer Tools.
   
2. Identificeer het verzoek in de waterval gezichtspunt
   
3. Klik op het verzoek dat lang duurt om te laden.
4. Bekijk het tabblad Timing van het log:

5. Controleer de responstijden en de elementen voor langzaam laden.

6. Verzamel de Trackingid voor die koptekst.

7. Open EasyLMA en zoek met de trackingid.

Uitsplitsingsfasen van timing toegelicht

Hier is meer informatie over elk van de fasen die u kunt zien in het tabblad Timing:

• Wachtrij. De browser stelt aanvragen in wachtrijen in voordat de verbinding wordt gestart en wanneer:
  • Er zijn verzoeken met een hogere prioriteit. De prioriteit van het verzoek wordt bepaald door factoren zoals het type resource en de locatie in het document. Lees voor meer informatie het gedeelte met bronprioriteit van de gids met ophaalprioriteit.
  • Er zijn al zes TCP-verbindingen geopend voor deze oorsprong, wat de limiet is. (Alleen van toepassing op HTTP/1.0 en HTTP/1.1.)
  • De browser wijst kort ruimte toe in de schijfcache.
• Vastgelopen. Het verzoek kan worden geblokkeerd nadat de verbinding is gestart om een van de redenen die worden beschreven in de wachtrij.
• DNS-zoekopdracht. De browser lost het IP-adres van de aanvraag op.
• Eerste verbinding. De browser maakt een verbinding, inclusief TCP-handshakes of herhalingen en onderhandelt over een SSL.
• Proxyonderhandeling. De browser onderhandelt over het verzoek met een proxyserver.
• Verzoek verzonden. Het verzoek wordt verstuurd.
• Voorbereiding van de servicemedewerker. De browser start de servicewerker op.
• Verzoek aan ServiceWorker. Het verzoek wordt naar de medewerker van de dienst gestuurd.
• Wachten (TTFB). De browser wacht op de eerste byte van een antwoord. TTFB staat voor Time To First Byte. Deze timing omvat 1 retourvlucht van latentie en de tijd die de server nodig had om de respons voor te bereiden.
• Inhoud downloaden. De browser ontvangt het antwoord, hetzij rechtstreeks van het netwerk of van een servicemedewerker. Deze waarde is de totale hoeveelheid tijd die wordt besteed aan het lezen van het responslichaam. Groter dan verwachte waarden kunnen wijzen op een traag netwerk of op het feit dat de browser bezig is met andere werkzaamheden waardoor de reactie niet wordt gelezen.

Resource niet beschikbaar

Voorbeeld: 

"Ik heb SNR ingeschakeld voor mijn gebruiker op de beheerdershub, maar ik zie niet de optie om het SNR-nummer in te stellen wanneer ik me aanmeld bij het portaal user.webex.com.
Kunt u alstublieft mijn org en gebruiker controleren om te zien waarom ik het niet kan zien op de gebruikershub?"

Problemen oplossen:

1. Bevestig wat de gebruiker ziet door te vragen om een screenshot van een werkende gebruiker versus een niet-werkende gebruiker.

2. Vraag een HAR-log aan tijdens het laden van de opties voor de gebruiker.

Volgende stappen:

1. Open het HAR-bestand in een HAR Viewer of browser Developer Tools. 
   
2. Verzoeken identificeren:

Service doet een verzoek (GET) om de services van de gebruiker te kennen

Aanvraag voor toegang tot de functie Eindgebruiker (GET) in de template van de services die aan de gebruiker worden getoond:

1. Verzoek-/antwoordkoppen analyseren.
   
   De "Geen toegang" betekent dat de sjabloon deze opties voor de gebruiker verbergt.
2. U moet de sjabloon voor de ORG bekijken en het bereik van één nummer inschakelen voor de gebruiker om deze in de gebruikershub te kunnen zien.

Voorbeeld:

Kan een functie niet inschakelen

Voorbeeld met gespreksopname:

Wanneer u probeert om gespreksopname voor een gebruiker in te schakelen, ontvangt u een foutmelding: "Wijziging van gespreksopname is mislukt".

Problemen oplossen:

1. Bevestig de fout door de volledige tekst van het foutbericht op te vragen.

2. Vraag om een screenshot van de fout.

3. Vraag een HAR-log aan terwijl u probeert "Oproepopname" in te schakelen in de getroffen gebruiker.

4. Open het HAR-bestand in een HAR Viewer of browser Developer Tools.

5. Identificeer mislukte verzoeken (zoals HTTP 4xx/5xx-fouten).

6. Zoek naar de tracking-ID's in EasyLMA.


7. Met uitzondering van cpapi kunt u een BEMS openen:

8. Open een BEMS met de verzamelde informatie:

• Screenshots
• Voltooide foutmelding
• Volgnummer
• CPAPI-uitzondering
  
  

9. Vraag in de Dubber-ruimte of aan het BU-team om de fout met het Dubber-team te bekijken:
"Foutresponsoverzicht: 400: Ongeldig product: het maken van een dub-punt is mislukt in Dubber. HTTP-status: 502 inch

FAXberichten

Hier is het diagram dat de provisioningstroom illustreert terwijl deze door microservices beweegt:

Bij het oplossen van problemen met de levering van faxberichten binnen de Control Hub is het essentieel om een HAR-trace te verzamelen om gedetailleerde inzichten te verkrijgen in de aard van het probleem en de redenen achter fouten in de levering te begrijpen. 

Wanneer u de functie voor faxberichten inschakelt, legt de HAR-tracering het relevante verzoek van CH naar CPAPI vast en geeft deze weer. Dit vastgelegde verzoek volgt een specifiek formaat.

Uit de CH → CPAPI:

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

Postgegevens {
"ingeschakeld": true,
"kennisgevingen": {
"ingeschakeld": true,
"Bestemming": "lazoclaudiafi+faxmessaging@gmail.com"
}
"sendAllCalls": {
"Ingeschakeld": onwaar
}
"sendBusyCalls": {
"ingeschakeld": true,
"GROET": "STANDAARD"
}
"sendUnansweredCalls": {
"ingeschakeld": true,
"GROET": "STANDAARD",
"maxRings": 3
}
"transferToNumber": {
"Ingeschakeld": onwaar
}
"emailCopyOfMessage": {
"ingeschakeld": true,
"emailId": "lazoclaudiafi+faxmessaging@gmail.com"
}
"faxMessage": {
"ingeschakeld": onwaar,
"phoneNumber": "+12099193323",
"Uitbreiding": null
}
"messageStorage": {
"mwiEnabled": true,
"storageType": "INTERNAL",
"externalEmail": "lazoclaudiafi+faxmessaging@gmail.com"
}

Om deze informatie effectief te volgen in EasyLMA, raadpleegt u de gedetailleerde richtlijnen die hier worden gegeven: 

Categorie: TrackingID
Subcategorie: Wereldwijd
Webex Tracking ID: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Informatie over doorverwijzing

• HAR-logboekbestand
• Screenshots van fouten
• Stappen om het probleem te reproduceren
• Tijdstempel van het incident
• LMA-logs

Beantwoord deze vragen voordat u de BEMS-escalatie opent, omdat dit helpt bij de verdere probleemoplossing:

• Welke fout zie je?
• Welke tracking ID’s zie je?
• Heb je de tracking ID in LMA beoordeeld?
• Wat zie je bij LMA?
• Is deze BEMS echt nodig?