- Una app de React Native que puedas ejecutar en local.
- Un proyecto de LogBrew. Consulta Proyectos y configuración.
- La CLI con la sesión iniciada. Consulta Usar la CLI.
Instala el SDK
Instala los dos paquetes en el directorio de la app. Conserva las dependencias de React y React Native de la app:Crea una clave del SDK del proyecto
Da a la app una clave del SDK limitada al proyecto y de solo escritura. Expo pone cada valorEXPO_PUBLIC_* en el bundle de la app. Nunca pongas una
credencial de cuenta ni de servidor en esa variable.
La CLI v0.1.32 o posterior crea una clave para un proyecto existente. No crea
un proyecto nuevo. Busca el ID del proyecto:
--abandon-retry.
Mantén el archivo de la clave fuera del control de versiones. No uses la
credencial de cuenta que autorizó la CLI. Para el desarrollo local con Expo,
pon la clave en un archivo .env.local ignorado en la raíz de la app:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY
en el módulo de configuración de abajo. Recarga la app por completo después de
cambiar el valor. Consulta
Variables de entorno de Expo
para la configuración en tiempo de compilación. Una app de React Native sin
Expo carga la clave con su propia configuración.
Crea el cliente
Pon esta configuración en un módulo que la app cargue al iniciarse. No crees un cliente en cada render. Pon el servicio, el entorno y el release encontext:
stopAppStateListener() cuando la app se desmonte.
Con la cola nativa, solo un cliente activo puede usar una clave. Un segundo
cliente con la misma clave falla con configuration_error. Es un motivo más
para crear el cliente una sola vez.
Envía y busca el log de prueba
Llama una vez averifyLogBrewSetup() desde una acción de prueba que solo
exista en desarrollo. Espera el resultado y gestiona una promesa rechazada. No
imprimas la clave ni el lote de eventos.
Un resultado 2xx con batches mayor que 0 muestra que LogBrew aceptó el
lote. Un flush vacío devuelve 204 con 0 intentos y 0 lotes, porque el envío
automático puede enviar el evento antes. En los dos casos, lee el log guardado
con la CLI:
RecordingTransport.alwaysAccept() es solo para pruebas locales. Devuelve un
202 sintético y no envía ninguna solicitud.
Envío sin conexión y tras reiniciar
Leeclient.deliveryHealth().storage en la app en ejecución:
persistent: el cliente usa la cola nativa. Los eventos pendientes se vuelven a cargar después de reiniciar la app.memory: los eventos pendientes se pierden cuando se reinicia el runtime de JavaScript.
persistentQueue: "auto" usa la cola nativa cuando el
binario de la app contiene el módulo nativo de LogBrew. Expo Go y los binarios
anteriores usan la memoria. Una actualización solo de JavaScript no puede
añadir el módulo nativo.
Si una app de producción necesita enviar tras un reinicio, define
persistentQueue: "required". Así, la creación del cliente falla con
configuration_error cuando falta la cola nativa. Vuelve a compilar la app con
el módulo nativo. Usa persistentQueue: "disabled" solo cuando quieras una
cola en memoria.
La cola nativa guarda como máximo 1.000 eventos y 4 MiB de datos de eventos.
También se aplican los límites del cliente si son menores. Los eventos de la
cola nativa conservan sus ID de evento después de un reinicio.
El envío es «al menos una vez», así que un reintento puede enviar un evento dos
veces. Cuando el ID y el contenido del evento coinciden con un evento que
LogBrew ya aceptó, LogBrew no lo vuelve a guardar. Un flush en segundo plano es
un intento, no una prueba de envío. Prueba la captura sin conexión y un
reinicio de la app. Después busca el evento guardado en el proyecto.
Lee el estado del envío
client.deliveryHealth() devuelve el estado de la cola y del envío sin el
contenido de los eventos. Lee primero estos campos:
Elige el contenido del log
Escribe cada mensaje corto y concreto. Describe el resultado en la app, como una solicitud fallida o un reintento programado. No incluyas nombres, direcciones de correo electrónico, tokens de acceso, valores de formularios ni cuerpos de solicitudes. Usa la severidad que corresponda al evento:info, warning, error o
critical. Mantén coherentes el servicio, el entorno y el release para poder
encontrar los registros relacionados.
npx react-native log-ios y npx react-native log-android muestran los logs
locales del dispositivo. No consultan LogBrew. Consulta
Depuración nativa de React Native.
Recupérate de una comprobación fallida
Unflush() fallido se rechaza con un código de error del SDK. Mantén las
claves y los cuerpos de los eventos fuera de los informes de errores.
Consulta Solución de problemas para más
comprobaciones.
Conserva los Debug ID de Expo en los bundles de release
Crea la configuración de Metro de Expo con LogBrew. Así, el bundle de ejecución recibe el mismo Debug ID que su mapa de origen:withLogBrewMetroConfig(). No uses ese envoltorio con Expo. Si lo haces,
la compilación de producción se detiene con un mensaje que apunta a
getLogBrewExpoConfig().