アプリケーションとサービスは Auth0 に依存して動作します。Auth0 の稼働状況を監視することで、Auth0 に問題が発生した場合に、顧客に特定のエラーを通知したり、ユーザーへの影響を軽減したりできます。
Auth0 を監視する方法は複数あり、それぞれの方法は互いに補完し合います。ニーズと導入にかけられるコストに応じて選択してください。
Auth0 を監視する最も簡単な方法は次のとおりです。
-
定期的なリクエストを設定して、認証トランザクションを実行します。
-
リクエストが成功すれば、Auth0 は正常に動作しています。
-
リクエストが失敗した場合、次のいずれかが考えられます。
- Auth0 の問題
- 合成トランザクションに使用しているテナント固有の問題
- または、単発のリクエスト失敗
合成トランザクションには、本番テナントの構成にできるだけ近い環境を使用してください。場合によっては、本番テナント自体を使用することもできます。リダイレクトフローやサードパーティプロバイダーを使用した合成トランザクションの設定は難しい場合があるため、リソースオーナー パスワード グラント の使用を推奨します。このフローでは、ブラウザーのリダイレクトは発生せず、UI も必要ありません。
Rules、カスタムデータベース接続、またはその他の拡張ポイントを使用している場合は、システムのその部分が正しく機能していることを確認するため、合成トランザクションが Rules やカスタム DB スクリプトを利用するように設定してください。
Pingdom のようなツールを使えば、合成トランザクションを簡単に設定できます。
合成トランザクションは 1 分間隔で実行することを推奨します。このシンプルな方法であれば、Auth0 のレート制限クォータをあまり消費せずに、十分に迅速な応答を得られます。
合成トランザクションは、Auth0テナントの健全性を監視するためのシンプルで低コストな方法です。ただし、いくつかの制限があります。
- 合成トランザクションは、エンドユーザーの実際の体験をそのまま反映するものではありません。代わりに、その代替的な指標を提供します。
- 合成トランザクションでは、ユーザーと同じフローが使用されない場合があります。
- アトミックではなく (通常は1分ごとに実行) 、エンドユーザーに発生した可能性のあるエラーは報告されません。
より詳細なデータが必要な場合は、エラーの追跡 と メトリクスとログ を参照してください。
このアプローチは、既存の Auth0 呼び出しで発生するエラーを追跡するのに役立ちます。具体的には、Auth0 への呼び出しが失敗するたびにエラーを報告します。Sentry はこのような用途でよく使われるツールで、フロントエンドとバックエンドの両方で利用できます。
このアプローチが有用なのは、エンドユーザーが実際に経験しているエラーを把握できるためです。ただし、追跡するのはエラーだけであり (すべてのリクエストではないため) 、影響を受けているエンドユーザーがどの程度いるのかを正確に把握することはできません。1% なのか 5% なのかはわかりません。また、別個の「擬似的な呼び出し」を設定する必要もありません。これは、特に設定を誤ると、レート制限のクォータの一部を消費する可能性があります。
このアプローチは、Auth0 への呼び出しを自分で管理しているバックエンドから実行する場合に有効です。たとえば、次のようなケースです。
一部のオブザーバビリティ製品では、フロントエンドアプリケーションやモバイルアプリケーションからメトリクスやログを送信することもできます。
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム