Felsökning av Application Insights JavaScript SDK
Den här artikeln beskriver hur du felsöker olika problem som rör Application Insights JavaScript SDK. Ämnena i den här artikeln innehåller SDK-inläsningsfel för JavaScript-webbappar och stöd för källkarta för JavaScript-appar.
Felsöka SDK-inläsningsfel för JavaScript-webbappar
I följande avsnitt beskrivs symptom, orsaker och lösningar för ett specifikt SDK-inläsningsfelscenario för JavaScript-webbappar.
Symptom
<I huvudelementet> på webbsidan som du övervakar skapar och rapporterar JavaScript-kodfragmentet (version 3 eller senare) följande undantag när det upptäcker att SDK-skriptet inte laddade ned eller initierade:
SDK-INLÄSNINGsfel: Det gick inte att läsa in Application Insights SDK-skript (mer information finns i stacken)
Det här meddelandet anger att användarens klient (webbläsare) inte kan ladda ned Application Insights SDK eller initiera från den identifierade värdsidan. Därför ser du ingen telemetri eller händelser.
Obs!
Det här undantaget stöds i alla större webbläsare som stöder API:et fetch() eller XMLHttpRequest. Dessa webbläsarversioner exkluderar Microsoft Internet Explorer 8 och tidigare versioner. Dessa webbläsare rapporterar därför inte den här typen av undantag om inte din miljö innehåller en hämtningspolyfill.
Stackinformationen innehåller grundläggande information om de URL:er som används av användaren.
| Namn | Beskrivning |
|---|---|
| <CDN-slutpunkt> | Url:en som användes (och misslyckades) för att ladda ned SDK:en. |
| <Hjälplänk> | En URL som länkar till felsökningsdokumentationen (den här sidan). |
| <Värd-URL> | Den fullständiga URL:en för sidan som användaren använde. |
| <Slutpunkts-URL> | Den URL som användes för att rapportera undantaget. Det här värdet kan hjälpa dig att identifiera om det offentliga Internet eller ett privat moln har åtkomst till värdsidan. |
Följande lista innehåller de vanligaste orsakerna till att det här undantaget inträffar:
Tillfälligt nätverksanslutningsfel
Avbrott i Application Insights Content Delivery Network (CDN)
SDK-initieringsfel efter inläsning av skriptet
Blockering av Application Insights JavaScript CDN
Tillfälliga nätverksanslutningsfel är den vanligaste orsaken till det här undantaget, särskilt i scenarier med mobil roaming.
I följande avsnitt beskrivs hur du felsöker varje potentiell rotorsak till det här felet.
Obs!
Vissa av de här stegen förutsätter att programmet har direkt kontroll över kodfragmentskriptet </> taggen och dess konfiguration som returneras som en del av HTML-värdsidan. Om dessa villkor inte gäller för ditt scenario gäller inte heller de här stegen.
Orsak 1: Tillfälligt nätverksanslutningsfel
Om användaren får tillfälliga nätverksanslutningsfel finns det färre möjliga lösningar än andra orsaker. Det här felet löser sig dock vanligtvis snabbt. Om användaren till exempel uppdaterar sidan för att läsa in webbplatsen igen laddas filerna ned och cachelagras lokalt tills en uppdaterad version släpps.
Lösning 1a: Ladda ned en uppdaterad version av SDK:et
För att minimera tillfälliga nätverksanslutningsfel implementerade Cache-Control vi huvuden på alla CDN-filer. När användarens webbläsare har laddat ned den aktuella versionen av SDK:t behöver den inte ladda ned den igen eftersom den återanvänder den tidigare erhållna kopian. (Se hur cachelagring fungerar.) Om cachelagringskontrollen misslyckas eller om det finns en ny version tillgänglig måste användarens webbläsare ladda ned den uppdaterade versionen. Därför kan du se en bakgrundsnivå av "brus" i scenariot med kontrollfel. Eller så kan du se en tillfällig topp när en ny version inträffar och blir allmänt tillgänglig (distribuerad till CDN).
Lösning 1b: Använd npm-paket för att bädda in SDK:n tillsammans med programmet i ett enda paket
Är SDK-inläsningsfelsfelet beständigt och inträffar det för många användare tillsammans med en minskning av normal klienttelemetri? I det här fallet är tillfälliga problem med nätverksanslutningen förmodligen inte den verkliga orsaken till problemet, och du bör utforska andra möjliga orsaker.
Obs!
En vanlig indikation på att det här felet inträffar för flera användare är att undantaget rapporteras på en snabb och varaktig nivå.
I det här fallet är det osannolikt att värd för SDK på ditt eget CDN tillhandahåller eller minskar förekomsten av det här undantaget. Samma problem påverkar ditt eget CDN och det inträffar även om du använder SDK:n via en npm-paketlösning. Fel i det senare scenariot inträffar särskilt om Application Insights ingår i ett annat paket än det program som övervakas, eftersom felet garanterat inträffar i minst ett av dessa paket. När det här undantaget inträffar från användarens perspektiv går det inte att läsa in eller initiera hela programmet, inte bara telemetri-SDK:t (som användarna inte ser). Därför fortsätter användarna förmodligen att uppdatera webbplatsen tills den läses in helt.
Du kan försöka använda npm-paket för att bädda in Application Insights SDK tillsammans med det övervakade programmet i ett enda paket. Även om ett intermittency-fel fortfarande kan inträffa i det här scenariot, erbjuder ett kombinerat paket en verklig chans att åtgärda problemet.
Orsak 2: Application Insights CDN-avbrott
Försök att komma åt CDN-slutpunkten direkt från webbläsaren från en annan plats än användarnas för att kontrollera att det finns ett Application Insights CDN-avbrott. Du kan till exempel prova att https://js.monitor.azure.com/scripts/b/ai.2.min.js komma åt från din egen utvecklingsdator. (Detta förutsätter att din organisation inte har blockerat den här domänen.)
Lösning 2: Skapa ett supportärende
Om du kontrollerar att det finns ett avbrott kan du skapa ett nytt supportärende.
Orsak 3: SDK initierades inte när skriptet lästes in
Om SDK:n inte initieras laddas skriptet </> fortfarande ned från CDN,men misslyckas under initieringen. Det här felet uppstår på grund av saknade eller ogiltiga beroenden, eller på grund av någon form av JavaScript-undantag.
Lösning 3: Sök efter en lyckad SDK-nedladdning eller JavaScript-undantag eller aktivera webbläsarfelsökning
Steg 1: Sök efter en lyckad SDK-nedladdning
Kontrollera om SDK:et har laddats ned. Om ingen skriptnedladdning inträffade är det här scenariot inte orsaken till SDK-inläsningsfelet. Använd en webbläsare som stöder utvecklarverktyg. Välj F12 för att visa utvecklarverktygen och välj sedan fliken Nätverk . Kontrollera att skriptet som har definierats i src-kodfragmentkonfigurationen har laddats ned. Det gör du genom att söka efter svarskod 200 (lyckades) eller 304 (inte ändrats). Om du vill granska nätverkstrafiken kan du också använda ett webbfelsökningsverktyg som Fiddler.
Om SDK:n inte laddades ned korrekt läser du följande tabell för att förstå de olika rapporteringsalternativen.
| Scenario | Orsak | Åtgärd |
|---|---|---|
| Problemet påverkar bara ett fåtal användare och en viss webbläsarversion eller en delmängd av webbläsarversionerna. (Kontrollera informationen om det rapporterade undantaget.) | Problemet är förmodligen bara om specifika användare eller miljöer kräver att ditt program tillhandahåller extra polyfill implementeringar. |
Skapa ett problem på GitHub. |
| Problemet påverkar hela programmet och alla användare. | Det är ett versionsrelaterat problem. | Skapa en ny supportbegäran. |
Om SDK:et har laddats ned läser du följande avsnitt för att åtgärda SDK-initieringsproblemet.
Steg 2: Sök efter JavaScript-undantag
Sök efter JavaScript-undantag. Använd en webbläsare som stöder utvecklarverktyg. Välj F12 för att visa utvecklarverktygen, läs in sidan och kontrollera sedan om några undantag har inträffat. Orsakar SDK-skriptet (till exempel i ai.2.min.js) undantag? I det här fallet inträffade något av följande scenarier:
Konfigurationen som skickas till SDK innehåller en oväntad konfiguration.
Konfigurationen som skickas till SDK saknar en nödvändig konfiguration.
En felaktig version distribuerades till CDN.
Om du vill söka efter en felaktig konfiguration ändrar du konfigurationen som skickas till kodfragmentet (om du inte redan har gjort det) så att den endast innehåller instrumentationsnyckeln som ett strängvärde. Följande kod visar ett exempel på konfigurationsändring av kodfragment.
Obs!
Stödet för instrumenteringsnyckelinmatning upphör den 31 mars 2025. Inmatningen av instrumenteringsnyckeln fortsätter att fungera, men vi kommer inte längre att tillhandahålla uppdateringar eller stöd för funktionen. Se Övergång till anslutningssträngar för att dra nytta av nya funktioner.
<script type="text/javascript">
...
src: "https://js.monitor.azure.com/scripts/b/ai.2.min.js",
cfg: {
instrumentationKey: "<instrumentation-key-guid>"
}});
</script>
Om du fortfarande ser ett JavaScript-undantag i SDK-skriptet skapar du ett nytt supportärende när du använder den här minimala konfigurationen. För att åtgärda problemet måste du återställa den felaktiga versionen. Det beror på att en nyligen distribuerad version förmodligen är orsaken till problemet.
Om undantaget försvinner orsakar förmodligen ett typmatchningsfel eller ett oväntat värde problemet. Börja felsöka genom att återställa konfigurationsalternativen en i taget och testa efter varje ändring tills undantaget inträffar igen. Kontrollera sedan dokumentationen för det objekt som orsakar problemet. Om dokumentationen är otydlig eller om du behöver hjälp kan du skapa ett problem på GitHub.
Har konfigurationen tidigare distribuerats och fungerat, men rapporterar nu det här undantaget? I det här fallet kan det finnas ett problem som påverkar en nyligen distribuerad version. Kontrollera om undantaget endast påverkar en liten uppsättning användare eller webbläsare. Skapa ett nytt supportärende på GitHub eller skapa ett nytt supportärende.
Steg 3: Aktivera felsökning av webbläsarkonsol
Om inga undantag utlöstes bör du aktivera konsolfelsökning genom att lägga till inställningen loggingLevelConsole i konfigurationen, enligt följande exempel på kodfragmentkonfiguration. Den här ändringen skickar alla initieringsfel och varningar till webbläsarens konsol. (Om du vill visa webbläsarkonsolen väljer du F12 för att öppna utvecklarverktygen och väljer sedan fliken Konsol .) Eventuella rapporterade fel bör vara självförklarande. Om du behöver ytterligare hjälp kan du skapa ett problem på GitHub.
<script type="text/javascript">
...
src: "https://js.monitor.azure.com/scripts/b/ai.2.min.js",
cfg: {
instrumentationKey: "<instrumentation-key-guid>",
loggingLevelConsole: 2
}});
</script>
Obs!
Under initieringen utför SDK vissa grundläggande kontroller för kända större beroenden. Om den aktuella körningen inte tillhandahåller dessa kontroller rapporterar körningen felen som varningsmeddelanden till konsolen (men bara om loggingLevelConsole inställningsvärdet är större än noll).
Om SDK fortfarande inte initieras kan du prova att aktivera konfigurationsinställningen enableDebug. När du har gjort den här ändringen genereras alla interna fel som undantag. Detta orsakar förlust av telemetri. Eftersom den här inställningen endast gäller för utvecklare leder det förmodligen till att fler undantag genereras på grund av interna kontroller. Granska varje undantag för att avgöra vilket problem som orsakar att SDK:et misslyckas. Använd den oförminserade versionen av skriptet (genom att ändra filnamnstillägget från .min.js till bara .js). Annars går det inte att läsa undantagen. Följande kod visar exempel på ändringar i kodfragmentkonfigurationen.
Varning
Den här inställningen endast för utvecklare bör ALDRIG aktiveras i en fullständig produktionsmiljö eftersom detta gör att du förlorar telemetri.
<script type="text/javascript">
...
src: "https://js.monitor.azure.com/scripts/b/ai.2.js",
cfg:{
instrumentationKey: "<instrumentation-key-guid>",
enableDebug: true
}});
</script>
Om den här åtgärden fortfarande inte ger några insikter bör du skapa ett problem på GitHub genom att ange information och en exempelwebbplats, om du använder en. Ta med information om webbläsarversion, operativsystem och JavaScript-ramverk för att identifiera problemet.
Orsak 4: Blockering av Application Insights JavaScript CDN
En CDN-blockering är möjlig om en Application Insights JavaScript SDK CDN-slutpunkt rapporteras eller identifieras som osäker. I det här fallet blockeras slutpunkten offentligt och konsumenter av dessa listor börjar blockera all åtkomst.
För att lösa det här problemet bör CDN-slutpunktens ägare arbeta med den blocklistningsentitet som markerade slutpunkten som osäker. Sedan kan entiteten blocklisting ta bort slutpunkten från den relevanta listan.
Kontrollera följande webbplatser för Internetsäkerhet för att se om de identifierar CDN-slutpunkten som osäker:
Det kan ta lång tid att lösa problemet. Användare eller företagets IT-avdelningar kan behöva framtvinga en uppdatering eller uttryckligen tillåta CDN-slutpunkterna. Den totala tid som krävs för att lösa det här problemet beror på den frekvens som krävs av programmet, brandväggen eller miljön för att uppdatera sina lokala kopior av listorna.
Om CDN-slutpunkten identifieras som osäker skapar du ett supportärende för att lösa problemet så snart som möjligt.
I följande avsnitt beskrivs mer specifikt hur en blockering kan ske och hur du åtgärdar blockering.
Orsak 4a: Användarblockering (webbläsare, installerad blockerare eller personlig brandvägg)
Kontrollera om användarna har vidtagit någon av följande konfigurationsåtgärder:
Installerade ett plugin-program i webbläsaren (vanligtvis i form av en annons, skadlig kod eller popup-blockerare)
Blockerad eller otillåten Application Insights CDN-slutpunkter i webbläsaren eller proxyn
Konfigurerade en brandväggsregel som orsakar en blockering av CDN-domänen för SDK :n (eller ett fel vid matchning av DNS-posten)
Lösning 4a: Lägga till blocklistefel för CDN-slutpunkter
Om användarna vidtog någon av konfigurationsåtgärderna i listan kan du samarbeta med dem (eller tillhandahålla dokumentation) för att tillåta CDN-slutpunkterna.
Användare kan ha installerat plugin-program som använder den offentliga blockeringslistan. Annars använder de förmodligen en annan manuellt konfigurerad lösning, eller så använder plugin-programmen en blockeringslista för privat domän.
Be användarna att tillåta nedladdning av skript från Application Insights CDN-slutpunkter genom att inkludera slutpunkterna i webbläsarens undantagslista för plugin-program eller brandväggsregler. De här listorna varierar beroende på användarmiljön.
Här är ett exempel på den här situationen som visar hur du konfigurerar Google Chrome för att tillåta eller blockera åtkomst till webbplatser.
Orsak 4b: Blockera företagsbrandvägg
Om användarna finns i ett företagsnätverk är företagsbrandväggen sannolikt källan till CDN-blockering. Företagets IT-avdelning har förmodligen implementerat någon form av Internetfiltreringssystem.
Lösning 4b1: Lägga till undantag för CDN-slutpunkter för företag
Viktigt
Använder användarna ett privat moln och har de inte åtkomst till det offentliga Internet? I det här fallet måste du antingen använda Application Insights npm-paket för att bädda in SDK eller vara värd för Application Insights SDK på din egen CDN.
Samarbeta med företagets IT-avdelning för att tillåta nödvändiga regler för dina användare. Den här lösningen liknar att lägga till undantag för användare. Be IT-avdelningen konfigurera Application Insights CDN-slutpunkterna för nedladdning genom att inkludera (eller ta bort) dem i alla domänblockerings- eller tillåtlistningstjänster.
Lösning 4b2: Värdhantera SDK:n på din egen CDN
I stället för att låta användarna ladda ned Application Insights SDK från den offentliga CDN:n kan du vara värd för Application Insights SDK på din egen CDN-slutpunkt. Vi rekommenderar att du använder en specifik version (ai.2.#.#.min.js) av SDK:n för att göra det enklare att identifiera vilken version du använder. Uppdatera även SDK:n regelbundet till den aktuella versionen (ai.2.min.js) så att du kan använda eventuella felkorrigeringar och nya funktioner som blir tillgängliga.
Lösning 4b3: Använd npm-paket för att bädda in Application Insights SDK
I stället för att använda kodfragmentet och lägga till offentliga CDN-slutpunkter kan du använda npm-paketen för att inkludera SDK:n som en del av dina egna JavaScript-filer. SDK:et blir bara ännu ett paket i dina egna skript. Mer information finns i avsnittet npm-baserad konfiguration på GitHub-sidan För Application Insights JavaScript SDK.
Obs!
När du använder npm-paket rekommenderar vi att du även använder någon form av JavaScript-paketerare för att hjälpa dig att dela upp och minimera kod.
Precis som med kodfragmentet kan samma blockerande problem som visas här påverka dina egna skript (med eller utan att använda SDK npm-paketen). Beroende på ditt program, dina användare och ditt ramverk kan du överväga att implementera något som liknar logiken i kodfragmentet för att identifiera och rapportera dessa problem.
Felsöka stöd för källkarta för JavaScript-program
I följande tabell förklaras vissa problem som rör stöd för källkarta för JavaScript-program, och det finns strategier för att åtgärda dessa problem.
| Fråga | Beskrivning |
|---|---|
| Nödvändiga azure-inställningar för rollbaserad åtkomstkontroll (Azure RBAC) i din blobcontainer | Alla användare i portalen som använder den här funktionen måste tilldelas minst en roll för Storage Blob Data Reader för din blobcontainer. Du måste tilldela den här rollen till alla som vill använda källkartningarna via den här funktionen. Beroende på hur containern skapades kanske den här rollen inte har tilldelats automatiskt till dig eller ditt team. |
| Det går inte att hitta källkartan | Åtgärda problemet genom att vidta följande åtgärder:
|
Åtgärda varningen "Klicka på händelserader utan parentId-värde"
När du använder Application Insights och plugin-programmet Click Analytics Auto-Collection i programmet kan följande telemetrivarning visas i application insights-arbetsboken: "Klicka på Händelserader utan parentId-värde."
Orsak
Det här problemet kan inträffa om det överordnade ID:t inte anges i det överordnade HTML-elementet. Det här villkoret gör att händelsen utlöses på alla dess överordnade element.
Lösning
Åtgärda problemet genom att lägga till data-parentid attributet eller data-<customPrefix>-parentid i det överordnade HTML-elementet. Här är ett exempel på HTML-koden:
<div data-heart-id="demo Header" data-heart-parentid="demo.Header" data-heart-parent-group="demo.Header.Group">
Nästa steg
Ansvarsfriskrivning för information från tredje part
De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för