Skip to main content
Envía logs desde una app de React Native a LogBrew. Empieza con un log de prueba y después usa la CLI para buscarlo en el proyecto correcto. Esta guía usa Expo. Una app de React Native sin Expo carga la clave con su propia configuración. Antes de empezar, necesitas:

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 valor EXPO_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:
Crea la clave. Usa una ruta de archivo nueva en un directorio al que solo accede su propietario:
Continúa solo cuando el comando termine bien. Si el resultado no está claro, vuelve a ejecutar el mismo comando con los mismos argumentos. No uses --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:
Conserva la referencia directa a 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 en context:
El transporte fetch activa el envío automático con reintentos limitados y una cola. No añadas un segundo temporizador de flush. El listener de AppState solicita un flush final cuando la app pasa a estar inactiva o en segundo plano. Llama a 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 a verifyLogBrewSetup() 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:
Comprueba la hora del evento y el servicio en el resultado. Un resultado vacío no muestra la causa. Revisa el proyecto, la clave y el intervalo de tiempo. 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

Lee client.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.
El valor predeterminado 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

Un flush() 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:
Si la app usa el modo bundle de React Native Worklets, aplica esa transformación después del helper de LogBrew:
El helper conserva los plugins de preserialización de Expo existentes. Una app de React Native sin Expo envuelve su configuración de Metro terminada con 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().