Habilitar el registro de depuración para la recopilación de datos
El registro de diagnóstico ayuda a explicar los comandos de SDK, la ejecución de etiquetas, las advertencias y los errores en el tiempo de ejecución en el que se ejecuta la implementación. Utilícelo con inspección de solicitud cuando también necesite inspeccionar solicitudes o procesamiento. Si no está seguro por dónde empezar, consulte la descripción general de depuración y solución de problemas.
Elegir un método de registro choose-a-logging-method
debugEnabled, setDebug, el parámetro de consulta alloy_debug o DebuggerdebugEnabled se aplica a todos los visitantes que ejecutan esa configuración. setDebug y alloy_debug solo se aplican a la pestaña del explorador, persisten en las cargas de la página del mismo origen en esa pestaña y tienen prioridad sobre debugEnabled. Desactívelos explícitamente cuando termine._satellite.setDebug(true)_satellite.setDebug(false) o se borran los datos del sitio.debugEnabled o setDebugMobileCore.setLogLevelEl registro de depuración de Web SDK, la biblioteca de etiquetas y Server SDK está deshabilitado de forma predeterminada. Mobile SDK toma como valor predeterminado el registro de nivel de error en lugar de ningún registro.
Habilitar el registro por biblioteca enable-logging
Expanda la sección de la biblioteca que utiliza su implementación. En cada sección se explica cómo habilitar el registro, dónde leer el resultado y cómo desactivar el registro.
Los siguientes métodos controlan los resultados de diagnóstico de Web SDK. No habilitan el registro de bibliotecas de etiquetas para una implementación independiente de Web SDK.
debugEnableden el comando configure: establezca debugEnabled en true en la llamada existente a configure. Esta configuración es útil en entornos de desarrollo. Si se implementa en el código del sitio, se habilita el registro de visitantes que ejecutan esa configuración.
| code language-js |
|---|
|
Cambie el valor de configuración a false u omítalo en implementaciones posteriores para restaurar el valor predeterminado. No ejecute configure por segunda vez en la misma instancia para alternar el registro; use setDebug en su lugar. Una anulación de depuración local puede tener prioridad sobre el valor de configuración. Consulte debugEnabled para ver la referencia de configuración.
El comando setDebug: Ejecute el comando con la instancia de Web SDK adecuada en la consola del explorador:
| code language-js |
|---|
|
Cuando termine, deshabilite:
| code language-js |
|---|
|
Al ejecutar este comando en la consola, se cambia la instancia local, no los exploradores de otros visitantes. Si coloca el mismo comando en el código de sitio implementado, afectará a los visitantes que ejecuten ese código. La anulación local puede persistir en las cargas de página para esa instancia en la sesión de la pestaña del mismo origen cuando el almacenamiento del explorador está disponible. Consulte setDebug para obtener más información.
El parámetro de cadena de consulta alloy_debug: agregue alloy_debug=true a la dirección URL de la página y, a continuación, cargue la página:
| code language-text |
|---|
|
Use &alloy_debug=true si la dirección URL ya tiene parámetros de consulta. Este parámetro permite el registro local sin cambiar el código implementado. Web SDK lee el parámetro cuando se crea cada instancia, por lo que se aplica a todas las instancias de Web SDK de la página. Cuando el almacenamiento del explorador está disponible, la configuración persiste en la sesión del mismo origen de la pestaña, por lo que al eliminar el parámetro por sí solo no se desactiva el registro. Cargue la página con alloy_debug=false o ejecute setDebug con enabled: false para deshabilitarla. Si la dirección URL aún contiene alloy_debug=true, volver a cargarla habilita el registro de nuevo.
Adobe Experience Platform Debugger: Abra Adobe Experience Platform Debugger, seleccione la sección Web SDK y habilite la depuración en su pestaña de configuración. Desactive la opción cuando termine.
Este procedimiento habilita la salida de diagnóstico; el uso de Debugger para solicitudes o inspecciones de Edge se cubre en Inspeccionar solicitudes de recopilación de datos.
En una página con una biblioteca de etiquetas, ejecute lo siguiente en la consola del explorador:
| code language-js |
|---|
|
Este comando expone los mensajes de la biblioteca de etiquetas, incluida la salida _satellite.logger. En el caso de las instancias de Web SDK administradas por la extensión de etiquetas de Web SDK, la extensión utiliza el modo de depuración de etiquetas al configurar SDK y le reenvía los cambios posteriores en el modo de depuración. No suponga que activar la depuración para una instancia de Web SDK independiente o configurada externamente también habilita el registro de etiquetas.
La extensión de etiquetas Web SDK no proporciona una opción de depuración en su interfaz de usuario de configuración de etiquetas. Utilice el método de consola para una instancia administrada por extensiones. Manténgalo fuera de las reglas de etiquetas.
Para deshabilitar el modo de depuración de etiquetas y el correspondiente registro de SDK administrado por la extensión:
| code language-js |
|---|
|
El modo de depuración de etiquetas se almacena en el almacenamiento local del explorador para el origen de la página. Se mantiene a lo largo de las cargas de página y se reinicia el explorador hasta que se desactiva o se borran los datos del sitio y no se habilita el registro para otros visitantes. Consulte _satellite.setDebug() para obtener detalles de ámbito y persistencia.
La biblioteca de etiquetas notifica a la extensión solo cuando cambia el modo de depuración de etiquetas. Si el modo de depuración de etiquetas ya está activado pero faltan mensajes de Web SDK, es posible que una anulación de Web SDK de setDebug o alloy_debug haya desactivado el inicio de sesión de SDK. Ejecute _satellite.setDebug(false) y, a continuación, _satellite.setDebug(true), o utilice el mismo método de Web SDK que configuró la invalidación.
Server SDK escribe resultados de diagnóstico en la consola del servidor, no en el explorador del visitante.
Establezca debugEnabled: true en la llamada existente del lado del servidor configure para habilitar el registro de la instancia y los identificadores de forRequest creados a partir de esa configuración. El valor predeterminado es false. Consulte debugEnabled para ver un ejemplo de configuración completo.
Para una investigación de destino, llame a setDebug en el identificador con ámbito de solicitud devuelto por forRequest. El registro de cambios solo para ese identificador, de modo que puede depurar una única solicitud sin habilitarla para todos los visitantes:
| code language-js |
|---|
|
Llamar a setDebug en la instancia de nivel superior cambia el registro solo para las llamadas realizadas directamente en esa instancia, no para sus identificadores de solicitud, hasta que lo deshabilite o se reinicie el proceso. Para cambiar la línea de base de todos los identificadores de solicitud, actualice debugEnabled en la configuración del servidor.
Los mensajes identifican la instancia entre corchetes, como [alloy], e incluyen configuración, entradas/resultados de método, advertencias y errores. Revise la salida del proceso del servidor o el destino del registro al que lo enruta su entorno de alojamiento.
Utilice la API setLogLevel de Mobile Core para seleccionar la descripción del diagnóstico. Android tiene el valor predeterminado LoggingMode.ERROR; iOS tiene el valor predeterminado LogLevel.error. Defina el nivel deseado durante la inicialización de la aplicación antes de reproducir el problema.
Android: Habilite el registro detallado en su aplicación de desarrollo:
| code language-kotlin |
|---|
|
Vea el resultado en Logcat de Android Studio para el proceso de aplicación en ejecución. Los mensajes de Mobile SDK utilizan la etiqueta AdobeExperienceSDK, por lo que debe filtrar con tag:AdobeExperienceSDK y asegurarse de que el visor de registro permite los mensajes de depuración y detallados. Restaurar el registro de nivel de error al finalizar:
| code language-kotlin |
|---|
|
iOS: habilita el registro de seguimiento en su aplicación de desarrollo:
| code language-swift |
|---|
|
Vea la consola de la aplicación en ejecución en Xcode y filtre para AEP SDK. Restaurar el registro de nivel de error al finalizar:
| code language-swift |
|---|
|
Volver al nivel de error reduce el resultado del diagnóstico; no suprime los errores. Estas llamadas cambian el registro en la aplicación en ejecución, no en otras instalaciones. Asegúrese de que el código de inicialización no vuelva a habilitar el registro detallado en el siguiente inicio o en una compilación de producción.
Consulte la Referencia de la API principal de Mobile para obtener información sobre Java, Objective-C, niveles compatibles y detalles específicos de la versión. Para React Native o Flutter, usa la API expuesta por tu envoltorio de SDK móvil en lugar de copiar llamadas nativas directamente en el código de envoltorio. Para la inspección de eventos conectados en lugar de la salida de la consola de tiempo de ejecución, consulte Assurance.
Leer y solucionar problemas de salida de diagnóstico read-output
Utilice los siguientes identificadores para buscar mensajes de SDK y etiquetas en la salida del registro ocupado. Si ha cambiado el nombre de una instancia de Web SDK o Server SDK, busque ese nombre en lugar de alloy.
[alloy], seguido del nombre de un componente para los mensajes de componente🚀 seguido del nombre de la regla, extensión o elemento de datos de origen entre paréntesis. Ver _satellite.logger.[alloy]AdobeExperienceSDKAEP SDK, seguido del nivel de registro y la etiqueta de extensión- Compruebe la ubicación de salida: La configuración del explorador no expone los registros del servidor o de la aplicación nativa. Seleccione la página del explorador, el proceso del servidor o el proceso de la aplicación correctos.
- Comprobar niveles de registro: los mensajes de Web SDK utilizan niveles de consola estándar que los exploradores muestran de forma predeterminada. Los mensajes de
_satellite.logger.debug()requieren el nivel detallado de la consola, y los mensajes detallados y de depuración de Mobile SDK requieren un visor de registro que incluya esos niveles. - Habilitar el registro antes de la acción: los mensajes existentes no se vuelven a crear simplemente porque se activa el inicio de sesión. Reproduzca el problema después de habilitarlo.
- Compruebe el control activo: las invalidaciones locales de Web SDK pueden reemplazar la configuración. Las etiquetas y las instancias independientes de SDK no comparten necesariamente una configuración.
- Distinguir registros de las pruebas de transporte: un registro puede mostrar que se ejecutó un comando o se seleccionó un transporte sin probar la recepción. Consulte Inspeccionar solicitudes de recopilación de datos para inspeccionar solicitudes, respuestas y vistas de procesamiento admitidas.
Los vínculos de supervisión de Web SDK son un mecanismo programático independiente y se ejecutan independientemente de la configuración del registro de depuración. Los clientes de API sin procesar, las secuencias de datos y el reenvío de eventos no comparten un modificador de registro universal de SDK; use sus registros de aplicaciones o diagnósticos de servicio según corresponda.