Aktivieren der Debug-Protokollierung für die Datenerfassung

Die folgenden Methoden steuern die Ausgabe der Web-SDK-Diagnose. Sie ermöglichen keine Tag-Bibliotheksprotokollierung für eine eigenständige Web-SDK-Implementierung.

debugEnabledim configure Befehl: Setzen Sie debugEnabled auf true in Ihrem vorhandenen configure. Diese Einstellung ist in Entwicklungsumgebungen nützlich. Wenn es im Code Ihrer Site bereitgestellt wird, ermöglicht es die Protokollierung für Besuchende, die diese Konfiguration ausführen.

alloy("configure", {
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  debugEnabled: true
});

Ändern Sie den Konfigurationswert in false oder lassen Sie ihn in nachfolgenden Bereitstellungen aus, um die Standardeinstellung wiederherzustellen. Führen Sie nicht configure ein zweites Mal auf derselben Instanz aus, um die Protokollierung umzuschalten. Verwenden Sie stattdessen setDebug. Eine lokale Debugging-Überschreibung kann Vorrang vor dem Konfigurationswert haben. Siehe debugEnabled für die Konfigurationsreferenz.

Der setDebug Befehl: Führen Sie den Befehl für die entsprechende Web-SDK-Instanz in Ihrer Browser-Konsole aus:

alloy("setDebug", { enabled: true });

Wenn Sie fertig sind, deaktivieren Sie es:

alloy("setDebug", { enabled: false });

Wenn Sie diesen Befehl in der Konsole ausführen, wird die lokale Instanz und nicht die Browser anderer Besucher geändert. Wenn Sie denselben Befehl in bereitgestellten Site-Code einfügen, wirkt sich dies auf Besucher aus, die diesen Code ausführen. Die lokale Überschreibung kann über Seitenladevorgänge für diese Instanz hinweg in der Sitzung derselben Herkunft bestehen bleiben, wenn der Browser-Speicher verfügbar ist. Weitere Informationen finden Sie unter setDebug .

Der alloy_debug Abfragezeichenfolgenparameter: Fügen Sie der Seiten-URL alloy_debug=true hinzu und laden Sie dann die Seite:

https://example.com/?alloy_debug=true

Verwenden Sie &alloy_debug=true, wenn die URL bereits Abfrageparameter enthält. Dieser Parameter ermöglicht die lokale Protokollierung, ohne den bereitgestellten Code zu ändern. Web SDK liest den -Parameter, wenn jede Instanz erstellt wird, sodass er für jede Web SDK-Instanz auf der Seite gilt. Wenn der Browser-Speicher verfügbar ist, bleibt die Einstellung für die Sitzung derselben Herkunft bestehen, sodass die Protokollierung nicht allein durch Entfernen des Parameters deaktiviert wird. Laden Sie die Seite mit alloy_debug=false oder führen Sie setDebug mit enabled: false aus, um sie zu deaktivieren. Wenn die URL weiterhin alloy_debug=true enthält, wird durch erneutes Laden die Protokollierung aktiviert.

Adobe Experience Platform Debugger: Öffnen Sie Adobe Experience Platform Debugger, wählen Sie den Abschnitt Web SDK aus und aktivieren Sie das Debugging auf der Registerkarte Konfiguration . Schalten Sie die Option aus, wenn Sie fertig sind.

Dieses Verfahren ermöglicht eine Diagnoseausgabe. Die Verwendung des Debuggers für Anfragen oder Edge-Prüfungen wird in Prüfungsanfragen für Datenerfassungen ​.

Führen Sie auf einer Seite mit einer Tag-Bibliothek Folgendes in Ihrer Browser-Konsole aus:

_satellite.setDebug(true);

Dieser Befehl macht Nachrichten aus der Tag-Bibliothek verfügbar, einschließlich _satellite.logger. Bei Web SDK-Instanzen, die von der Tag-Erweiterung „Web SDK" verwaltet werden, verwendet die Erweiterung den Tag-Debug-Modus beim Konfigurieren des SDKS und leitet nachfolgende Änderungen des Debug-Modus an diesen weiter. Gehen Sie nicht davon aus, dass durch Aktivieren des Debuggens für eine eigenständige oder extern konfigurierte SDK-Webinstanz auch die Tag-Protokollierung aktiviert wird.

Die Tag-Erweiterung von Web SDK bietet in ihrer Tag-Konfigurationsoberfläche keinen Umschalter zum Debuggen. Verwenden Sie die Konsolenmethode für eine Instanz, die von einer Erweiterung verwaltet wird. Halten Sie es von Tag-Regeln fern.

So deaktivieren Sie den Tag-Debugging-Modus und die entsprechende erweiterungsverwaltete SDK-Protokollierung:

_satellite.setDebug(false);

Der Tag-Debug-Modus wird im lokalen Speicher des Browsers für den Ursprung der Seite gespeichert. Er bleibt so lange über Seitenladevorgänge und Browser-Neustarts hinweg erhalten, bis Sie ihn deaktivieren oder die Daten der Site löschen. Für andere Besucher wird die Protokollierung nicht aktiviert. Details zu Umfang und Persistenz finden Sie unter _satellite.setDebug() .

Die Tag-Bibliothek benachrichtigt die Erweiterung nur, wenn sich der Tag-Debugging-Modus ändert. Wenn der Tag-Debugging-Modus bereits aktiviert ist, aber Web-SDK-Meldungen fehlen, könnte eine Web-SDK-Überschreibung von setDebug oder alloy_debug die Protokollierung von SDK deaktiviert haben. Führen Sie _satellite.setDebug(false) und dann _satellite.setDebug(true) aus oder verwenden Sie dieselbe Web-SDK-Methode, die die Überschreibung festlegt.

Der Server-SDK schreibt Diagnoseausgaben in die Serverkonsole und nicht in den Browser des Besuchers.

Legen Sie debugEnabled: true in Ihrem vorhandenen Server-seitigen configure fest, um die Protokollierung für die Instanz und die aus dieser Konfiguration erstellten forRequest-Handles zu aktivieren. Die Standardeinstellung lautet false. Ein vollständiges Konfigurationsbeispiel finden Sie unter debugEnabled .

Rufen Sie für eine zielgerichtete Untersuchung setDebug das Handle für Anfragen auf, das von forRequest zurückgegeben wird. Die Protokollierung erfolgt nur für dieses Handle, sodass Sie eine einzelne Anfrage debuggen können, ohne sie für alle Besucher zu aktivieren:

const visitor = alloy.forRequest({ request: req });

await visitor.setDebug({ enabled: true });
await visitor.sendEvent({
  xdm: { eventType: "web.webpagedetails.pageViews" }
});

Beim Aufrufen von setDebug auf der Instanz auf oberster Ebene ändert sich die Protokollierung nur für Aufrufe, die direkt auf dieser Instanz getätigt werden, nicht für die Anforderungs-Handler, bis Sie diese deaktivieren oder der Prozess neu gestartet wird. Um die Grundlinie für alle Anforderungs-Handles zu ändern, aktualisieren Sie debugEnabled in der Konfiguration des Servers.

Meldungen identifizieren die Instanz in eckigen Klammern, z. B. [alloy], und enthalten Konfiguration, Methodeneingaben/-ergebnisse, Warnungen und Fehler. Überprüfen Sie die Ausgabe des Server-Prozesses oder das Protokollziel, an das ihn Ihre Hosting-Umgebung weiterleitet.

Verwenden Sie die setLogLevel-API von Mobile Core, um die diagnostische Ausführlichkeit auszuwählen. Android ist standardmäßig auf LoggingMode.ERROR eingestellt; iOS ist standardmäßig auf LogLevel.error eingestellt. Legen Sie die gewünschte Ebene bei der App-Initialisierung fest, bevor Sie das Problem reproduzieren.

Android: Aktivieren Sie die ausführliche Protokollierung in Ihrer Entwicklungs-App:

import com.adobe.marketing.mobile.LoggingMode
import com.adobe.marketing.mobile.MobileCore

MobileCore.setLogLevel(LoggingMode.VERBOSE)

Ausgabe für den laufenden App Prozess im "" von Android Studio anzeigen. Mobile SDK-Nachrichten verwenden das AdobeExperienceSDK-Tag. Filtern Sie also mit tag:AdobeExperienceSDK und stellen Sie sicher, dass der Protokoll-Viewer Debugging- und ausführliche Meldungen zulässt. Wiederherstellen der Protokollierung auf Fehlerebene nach Abschluss:

MobileCore.setLogLevel(LoggingMode.ERROR)

iOS: Aktivieren Sie die Ablaufverfolgungsprotokollierung in Ihrer Entwicklungs-App:

import AEPCore
import AEPServices

MobileCore.setLogLevel(.trace)

Zeigen Sie die Konsole der ausgeführten App in Xcode an und filtern Sie nach AEP SDK. Wiederherstellen der Protokollierung auf Fehlerebene nach Abschluss:

MobileCore.setLogLevel(.error)

Die Rückkehr zur Fehlerebene reduziert die Diagnoseausgabe, unterdrückt aber keine Fehler. Diese Aufrufe ändern die Protokollierung in der laufenden App, nicht in anderen Installationen. Stellen Sie sicher, dass der Initialisierungs-Code die ausführliche Protokollierung beim nächsten Launch oder in einem Produktions-Build nicht erneut aktiviert.

Weitere Informationen zu Java​ Objective-C, unterstützten Ebenen und versionsspezifischen ​ finden Sie in der „Mobile Core API-Referenz“. Verwenden Sie für React Native oder Flutter die API, die von Ihrem Mobile SDK-Wrapper bereitgestellt wird, anstatt native Aufrufe direkt in Wrapper-Code zu kopieren. Informationen zur Überprüfung von Connected Events anstelle der Ausgabe der Laufzeitkonsole finden Sie unter Assurance.