Skip to main content
Envoyez les logs d’une application React Native à LogBrew. Commencez par un log de test, puis retrouvez-le dans le bon projet avec la CLI. Ce guide utilise Expo. Une application React Native sans Expo charge la clé avec sa propre configuration. Avant de commencer, il vous faut :

Installer le SDK

Installez les deux paquets dans le dossier de l’application. Gardez les dépendances React et React Native de l’application :

Créer une clé SDK de projet

Donnez à l’application une clé SDK limitée au projet et en écriture seule. Expo place chaque valeur EXPO_PUBLIC_* dans le bundle de l’application. Ne mettez jamais un identifiant de compte ou de serveur dans cette variable. La CLI v0.1.32 ou plus récente crée une clé pour un projet existant. Elle ne crée pas de nouveau projet. Trouvez l’ID du projet :
Créez la clé. Utilisez un nouveau chemin de fichier dans un dossier accessible à son seul propriétaire :
Ne continuez qu’une fois la commande réussie. Si le résultat n’est pas clair, relancez la même commande avec les mêmes arguments. N’utilisez pas --abandon-retry. Gardez le fichier de clé hors du dépôt de code. N’utilisez pas l’identifiant de compte qui a autorisé la CLI. Pour le développement Expo en local, placez la clé dans un fichier .env.local ignoré par le dépôt, à la racine de l’application :
Gardez la référence directe process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY dans le module de configuration ci-dessous. Rechargez complètement l’application après avoir modifié la valeur. Consultez Variables d’environnement Expo pour la configuration au moment du build. Une application React Native sans Expo charge plutôt la clé avec sa propre configuration.

Créer le client

Placez cette configuration dans un seul module que l’application charge au démarrage. Ne créez pas de client à chaque rendu. Placez le service, l’environnement et la version dans context :
Le transport fetch active l’envoi automatique, avec une file d’attente et un nombre limité de nouvelles tentatives. N’ajoutez pas de second minuteur de vidage. L’écouteur AppState demande un dernier vidage quand l’application devient inactive ou passe en arrière-plan. Appelez stopAppStateListener() quand l’application se ferme. Avec la file d’attente native, un seul client actif peut utiliser une clé. Un second client pour la même clé échoue avec configuration_error. C’est une raison de plus pour ne créer le client qu’une fois.

Envoyer et retrouver le log de test

Appelez verifyLogBrewSetup() une fois depuis une action de test réservée au développement. Attendez le résultat et gérez le rejet de la promesse. N’affichez ni la clé ni le lot de signaux. Un résultat 2xx avec batches supérieur à 0 montre que LogBrew a accepté le lot. Un vidage sans signal renvoie 204 avec 0 tentative et 0 lot, car l’envoi automatique peut avoir déjà envoyé le signal. Dans les deux cas, lisez le log enregistré avec la CLI :
Vérifiez l’heure du signal et le service dans le résultat. Un résultat vide n’indique pas la cause. Vérifiez le projet, la clé et la période. RecordingTransport.alwaysAccept() sert uniquement aux tests en local. Il renvoie un 202 fictif et n’envoie aucune requête.

Envoyer hors ligne et après un redémarrage

Lisez client.deliveryHealth().storage dans l’application en cours d’exécution :
  • persistent : le client utilise la file d’attente native. Les signaux en attente sont rechargés après un redémarrage de l’application.
  • memory : les signaux en attente sont perdus quand le runtime JavaScript redémarre.
La valeur par défaut persistentQueue: "auto" utilise la file d’attente native quand le binaire de l’application contient le module natif LogBrew. Expo Go et les binaires plus anciens utilisent la mémoire. Une mise à jour JavaScript seule ne peut pas ajouter le module natif. Si une application de production doit envoyer les signaux après un redémarrage, définissez persistentQueue: "required". La création du client échoue alors avec configuration_error quand la file d’attente native manque. Recompilez l’application avec le module natif. N’utilisez persistentQueue: "disabled" que si vous voulez une file d’attente en mémoire. La file d’attente native contient au plus 1 000 signaux et 4 Mio de données. Les limites plus basses du client s’appliquent aussi. Les signaux de la file d’attente native gardent leur ID après un redémarrage. L’envoi suit la garantie « au moins une fois » : une nouvelle tentative peut donc envoyer un signal deux fois. Quand l’ID et le contenu d’un signal correspondent à un signal déjà accepté, LogBrew ne l’enregistre pas une deuxième fois. Un vidage en arrière-plan est une tentative, pas une preuve d’envoi. Testez la capture hors ligne et un redémarrage de l’application. Retrouvez ensuite le signal enregistré dans le projet.

Lire l’état de l’envoi

client.deliveryHealth() renvoie l’état de la file d’attente et de l’envoi, sans le contenu des signaux. Lisez d’abord ces champs :

Choisir le contenu des logs

Gardez chaque message court et précis. Décrivez ce qui arrive dans l’application, comme une requête échouée ou une nouvelle tentative programmée. N’incluez pas de noms, d’adresses e-mail, de jetons d’accès, de valeurs de formulaire ni de corps de requête. Utilisez la gravité qui correspond au signal : info, warning, error ou critical. Gardez le même service, le même environnement et la même version pour retrouver les données associées. npx react-native log-ios et npx react-native log-android affichent les logs locaux de l’appareil. Ils n’interrogent pas LogBrew. Consultez Débogage du code natif React Native.

Corriger une vérification échouée

En cas d’échec, flush() rejette sa promesse avec un code d’erreur du SDK. Gardez les clés et le contenu des signaux hors des rapports d’erreur. Consultez Dépannage pour d’autres vérifications.

Conserver les Debug ID Expo dans les bundles de production

Créez la configuration Metro d’Expo avec LogBrew. Le bundle d’exécution reçoit alors le même Debug ID que sa source map :
Si l’application utilise le mode bundle de React Native Worklets, appliquez cette transformation après le helper LogBrew :
Le helper conserve les plugins de pré-sérialisation Expo existants. Une application React Native sans Expo enveloppe plutôt sa configuration Metro finale avec withLogBrewMetroConfig(). N’utilisez pas cette fonction avec Expo. Sinon, le build de production s’arrête avec un message qui renvoie vers getLogBrewExpoConfig().