Skip to main content
React Native アプリから LogBrew にログを送信します。まず1件のテストログを送り、CLI を使って正しいプロジェクトで見つけます。このガイドでは Expo を使います。Expo を使わない React Native アプリでは、アプリ独自の設定でキーを読み込みます。 始める前に、次のものが必要です。
  • ローカルで実行できる React Native アプリ。
  • LogBrew のプロジェクト。プロジェクトと設定を参照してください。
  • サインイン済みの CLI。CLI を使うを参照してください。

SDK をインストールする

アプリのディレクトリで両方のパッケージをインストールします。アプリの React と React Native の依存関係はそのままにします。

プロジェクトの SDK キーを作成する

アプリには、プロジェクト単位の書き込み専用 SDK キーを渡します。Expo は EXPO_PUBLIC_* の値をすべてアプリのバンドルに含めます。この変数にアカウントやサーバーの認証情報を入れないでください。 CLI v0.1.32 以降では、既存のプロジェクトにキーを作成できます。新しいプロジェクトは作成しません。プロジェクト ID を確認します。
キーを作成します。所有者だけがアクセスできるディレクトリの、新しいファイルパスを使います。
コマンドが成功してから先に進みます。結果がはっきりしない場合は、同じ引数で同じコマンドをもう一度実行します。--abandon-retry は使わないでください。 キーのファイルはソース管理に含めないでください。CLI を認可したアカウントの認証情報は使わないでください。Expo のローカル開発では、アプリのルートにある、無視対象の .env.local ファイルにキーを入れます。
下の設定モジュールでは、process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY を直接参照する形のままにします。値を変えた後は、アプリを完全に再読み込みします。ビルド時の設定については Expo の環境変数を参照してください。Expo を使わない React Native アプリでは、代わりにアプリ独自の設定でキーを読み込みます。

クライアントを作成する

この設定は、アプリが起動時に読み込む1つのモジュールに置きます。レンダリングのたびにクライアントを作らないでください。サービス、環境、リリースは context に入れます。
fetch のトランスポートは、回数に上限のある再試行とキューを使った自動送信を有効にします。フラッシュ用のタイマーを別に追加しないでください。AppState のリスナーは、アプリが非アクティブになったときやバックグラウンドに移ったときに、最後のフラッシュを要求します。アプリを終了処理するときは stopAppStateListener() を呼び出します。 ネイティブのキューでは、1つのキーを使える有効なクライアントは1つだけです。同じキーで2つ目のクライアントを作ると、configuration_error で失敗します。これも、クライアントを1回だけ作る理由の1つです。

テストログを送信して見つける

開発時だけのテスト操作から、verifyLogBrewSetup() を1回呼び出します。結果を await し、拒否された Promise を処理します。キーやイベントのバッチを出力しないでください。 結果が 2xx で batches が0より大きければ、LogBrew がバッチを受け付けたことを示します。自動送信が先にイベントを送ることがあるため、空のフラッシュは試行0回、バッチ0件で 204 を返します。どちらの場合も、保存されたログを CLI で読みます。
結果のイベント時刻とサービスを確認します。結果が空でも、その原因はわかりません。プロジェクト、キー、期間を確認してください。 RecordingTransport.alwaysAccept() はローカルのテスト専用です。合成の 202 を返し、リクエストは送信しません。

オフライン時と再起動後の送信

実行中のアプリで client.deliveryHealth().storage を読みます。
  • persistent:クライアントはネイティブのキューを使っています。保留中のイベントは、アプリを再起動した後に再び読み込まれます。
  • memory:JavaScript ランタイムが再起動すると、保留中のイベントは失われます。
デフォルトの persistentQueue: "auto" は、アプリのバイナリに LogBrew のネイティブモジュールが含まれている場合にネイティブのキューを使います。Expo Go と古いバイナリはメモリを使います。JavaScript だけの更新では、ネイティブモジュールを追加できません。 本番環境のアプリで再起動後の送信が必要な場合は、persistentQueue: "required" を設定します。この場合、ネイティブのキューがないとクライアントの作成が configuration_error で失敗します。ネイティブモジュールを含めてアプリをビルドし直してください。persistentQueue: "disabled" は、メモリのキューを使いたい場合だけ使います。 ネイティブのキューに保持できるのは、最大1,000件のイベントと4 MiB のイベントデータです。クライアント側の上限がそれより小さい場合は、そちらも適用されます。ネイティブのキューにあるイベントは、再起動後もイベント ID を保持します。 送信は少なくとも1回(at-least-once)なので、再試行でイベントが2回送られることがあります。イベント ID と内容が、LogBrew がすでに受け付けたイベントと一致する場合、LogBrew はそれを再び保存しません。バックグラウンドのフラッシュは試行であり、送信できたことの証明ではありません。オフライン時の取得とアプリの再起動をテストしてください。そのうえで、保存されたイベントをプロジェクトで探します。

送信の状態を読む

client.deliveryHealth() は、イベントの内容を含めずに、キューと送信の状態を返します。まず次のフィールドを読みます。

ログの内容を決める

各メッセージは短く具体的にします。リクエストの失敗や再試行の予定など、アプリで起きた結果を書きます。氏名、メールアドレス、アクセストークン、フォームの値、リクエストボディを含めないでください。 イベントに合った重大度を使います。info、warning、error、critical のいずれかです。関連する記録を見つけられるように、サービス、環境、リリースは一貫させます。 npx react-native log-ios と npx react-native log-android は、ローカルのデバイスのログを表示します。LogBrew には問い合わせません。React Native のネイティブのデバッグを参照してください。

確認が失敗したときに回復する

flush() が失敗すると、SDK のエラーコードで拒否されます。キーやイベントの本文をエラーレポートに含めないでください。 その他の確認については トラブルシューティングを参照してください。

リリース用バンドルで Expo の Debug ID を保持する

Expo の Metro の設定を LogBrew 経由で作成します。これで、実行時のバンドルにソースマップと同じ Debug ID が付きます。
アプリで React Native Worklets のバンドルモードを使っている場合は、LogBrew のヘルパーの後にその変換を適用します。
このヘルパーは、Expo の既存のシリアライズ前プラグインを保持します。 Expo を使わない React Native アプリでは、代わりに完成した Metro の設定を withLogBrewMetroConfig() で囲みます。このラッパーを Expo で使わないでください。使うと、本番環境のビルドが getLogBrewExpoConfig() を案内するメッセージで止まります。