- Une application React Native que vous pouvez exécuter en local.
- Un projet LogBrew. Consultez Projets et configuration.
- Une CLI connectée. Consultez Utiliser la CLI.
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 valeurEXPO_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 :
--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 :
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 danscontext :
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
AppelezverifyLogBrewSetup() 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 :
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
Lisezclient.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.
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 :withLogBrewMetroConfig(). N’utilisez pas cette fonction avec
Expo. Sinon, le build de production s’arrête avec un message qui renvoie vers
getLogBrewExpoConfig().