- Eine React-Native-App, die Sie lokal ausführen können.
- Ein LogBrew-Projekt. Siehe Projekte.
- Eine angemeldete CLI. Siehe CLI einrichten.
SDK installieren
Installieren Sie beide Pakete im App-Verzeichnis. Behalten Sie die Abhängigkeiten der App für React und React Native bei:SDK-Schlüssel für das Projekt erstellen
Geben Sie der App einen SDK-Schlüssel, der auf das Projekt begrenzt ist und nur schreiben darf. Expo legt jedenEXPO_PUBLIC_*-Wert in das App-Bundle.
Legen Sie nie Zugangsdaten eines Kontos oder Servers in diese Variable.
Die CLI ab v0.1.32 erstellt einen Schlüssel für ein bestehendes Projekt. Sie
erstellt kein neues Projekt. Ermitteln Sie die Projekt-ID:
--abandon-retry.
Halten Sie die Schlüsseldatei aus der Versionsverwaltung heraus. Verwenden
Sie nicht die Konto-Zugangsdaten, mit denen Sie die CLI autorisiert haben.
Legen Sie den Schlüssel für die lokale Expo-Entwicklung in eine ignorierte
Datei .env.local im Stammverzeichnis der App:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY
im Einrichtungsmodul unten. Laden Sie die App vollständig neu, nachdem Sie
den Wert geändert haben. Die Konfiguration zur Build-Zeit beschreibt
Expo environment variables.
Eine reine React-Native-App lädt den Schlüssel stattdessen über ihre eigene
Konfiguration.
Client erstellen
Legen Sie diese Einrichtung in ein Modul, das die App beim Start lädt. Erstellen Sie nicht bei jedem Rendern einen Client. Tragen Sie Dienst, Umgebung und Release incontext ein:
stopAppStateListener() auf, wenn die App beendet wird.
Mit der nativen Warteschlange kann nur ein aktiver Client einen Schlüssel
nutzen. Ein zweiter Client für denselben Schlüssel schlägt mit
configuration_error fehl. Ein weiterer Grund, den Client nur einmal zu
erstellen.
Test-Log senden und finden
Rufen SieverifyLogBrewSetup() einmal aus einer Testaktion auf, die es nur
in der Entwicklung gibt. Warten Sie auf das Ergebnis und behandeln Sie ein
abgelehntes Promise. Geben Sie weder den Schlüssel noch den Ereignis-Batch
aus.
Ein Ergebnis 2xx mit batches über 0 zeigt, dass LogBrew den Batch
angenommen hat. Ein leerer Flush gibt 204 mit 0 Versuchen und 0 Batches
zurück, denn die automatische Zustellung kann das Ereignis schon vorher
senden. Lesen Sie in beiden Fällen das gespeicherte Log mit der CLI:
RecordingTransport.alwaysAccept() ist nur für lokale Tests gedacht. Es
gibt ein künstliches 202 zurück und sendet keine Anfrage.
Zustellung offline und nach Neustart
Lesen Sieclient.deliveryHealth().storage in der laufenden App:
persistent: Der Client nutzt die native Warteschlange. Ausstehende Ereignisse werden nach einem Neustart der App wieder geladen.memory: Ausstehende Ereignisse gehen verloren, wenn die JavaScript-Laufzeit neu startet.
persistentQueue: "auto" nutzt die native Warteschlange,
wenn das App-Binary das native LogBrew-Modul enthält. Expo Go und ältere
Binaries nutzen den Arbeitsspeicher. Ein reines JavaScript-Update kann das
native Modul nicht hinzufügen.
Wenn eine Produktions-App eine Zustellung über Neustarts hinweg braucht,
setzen Sie persistentQueue: "required". Das Erstellen des Clients schlägt
dann mit configuration_error fehl, wenn die native Warteschlange fehlt.
Bauen Sie die App mit dem nativen Modul neu. Verwenden Sie
persistentQueue: "disabled" nur, wenn Sie eine Warteschlange im
Arbeitsspeicher wollen.
Die native Warteschlange fasst höchstens 1.000 Ereignisse und 4 MiB
Ereignisdaten. Kleinere Grenzen im Client gelten ebenfalls. Ereignisse in
der nativen Warteschlange behalten nach einem Neustart ihre Ereignis-IDs.
Die Zustellung erfolgt mindestens einmal. Eine Wiederholung kann ein
Ereignis also zweimal senden. Wenn Ereignis-ID und Inhalt zu einem Ereignis
passen, das LogBrew schon angenommen hat, speichert LogBrew es nicht noch
einmal. Ein Flush im Hintergrund ist ein Versuch, kein Beweis für die
Zustellung. Testen Sie die Erfassung offline und einen Neustart der App.
Finden Sie dann das gespeicherte Ereignis im Projekt.
Zustellstatus lesen
client.deliveryHealth() gibt den Zustand von Warteschlange und Zustellung
ohne Ereignisinhalte zurück. Lesen Sie zuerst diese Felder:
Log-Inhalt wählen
Halten Sie jede Nachricht kurz und konkret. Beschreiben Sie das Ergebnis in der App, zum Beispiel eine fehlgeschlagene Anfrage oder eine geplante Wiederholung. Nehmen Sie keine Namen, E-Mail-Adressen, Zugriffstokens, Formularwerte oder Anfrage-Bodys auf. Verwenden Sie den Schweregrad, der zum Ereignis passt:info, warning,
error oder critical. Halten Sie Dienst, Umgebung und Release einheitlich,
damit Sie zusammengehörige Einträge finden.
npx react-native log-ios und npx react-native log-android zeigen lokale
Geräte-Logs. Sie fragen LogBrew nicht ab. Siehe
React Native native debugging.
Nach einer fehlgeschlagenen Prüfung wiederherstellen
Ein fehlgeschlagenesflush() wird mit einem SDK-Fehlercode abgelehnt.
Halten Sie Schlüssel und Ereignisinhalte aus Fehlerberichten heraus.
Weitere Prüfungen finden Sie unter Fehlerbehebung.
Expo-Debug-IDs in Release-Bundles behalten
Erstellen Sie die Expo-Metro-Konfiguration über LogBrew. Das Laufzeit-Bundle erhält dann dieselbe Debug-ID wie seine Source Map:withLogBrewMetroConfig(). Verwenden Sie diesen Wrapper
nicht mit Expo. Sonst stoppt der Produktions-Build mit einer Meldung, die
auf getLogBrewExpoConfig() verweist.