アプリケーションのモニタリング

アプリケーションおよびサービスはAuth0に依存しています。Auth0の健全性をモニタリングすることで、Auth0に問題があった場合、具体的なエラーを顧客に報告でき、ユーザーへの影響を抑えることができます。

Auth0をモニタリングする方法はいくつもありますが、各アプローチがお互いを補完します。ご自分のニーズと投資の可能性に基づいて、お選びください。

合成トランザクション

Auth0をモニタリングするための最も簡単なアプローチです。

  • 認証トランザクションを実行する定期的な要求を設定します。

  • 要求が成功した場合、Auth0は正常に機能しています。

  • 要求が失敗した場合は、以下の可能性があります。

    • Auth0の問題

    • 合成トランザクションに使用されたテナントに特有の問題

    • または失敗した単一の要求。

合成トランザクションは、可能な限り運用テナントの構成に近い環境を使用してください。場合によっては、同じ運用テナントを使用することもあります。リダイレクトフローおよびサードパーティプロバイダーを含む合成トランザクションの設定は難しいため、リソース所有者のパスワード付与を使用することをお勧めします。このフローは、ブラウザーリダイレクトを含まず、またUIを必要としません。

ルールやカスタムのデータベース接続、またはその他の拡張ポイントを使用する場合は、システムのアスペクトを機能させるために、合成トランザクションをそのルールおよび/またはカスタムDBスクリプトを利用するように構成する必要があります。

Pingdomなどのツールは、合成トランザクションの設定を簡単にしてくれます。

期間の確認

1分間隔で合成トランザクションを実行することをお勧めします。このシンプルなアプローチのその頻度は、Auth0レート制限の割り当てを多く消費することなく、タイムリーな応答を提供します。

合成トランザクションの制限

合成トランザクションは、Auth0のテナントの健全性をモニタリングする費用のかからないシンプルな方法です。ただし、いくつかの制限があります。

  • 合成トランザクションはエンドユーザーのエクスペリエンスを表しません。代わりに、プロキシメトリックを提供します。

  • 合成トランザクションは、ユーザーと同じフローを使用しない場合があります。

  • 原子性に欠け（通常1分に一度実行）、エンドユーザーが見る可能性があるエラーを報告しません。

より詳細なデータの取得をご希望の場合は、エラーの追跡およびメトリックとログをご覧ください。

エラーの追跡

このアプローチは、Auth0への既存の呼び出しのエラーを追跡するのに役立ちます。Auth0への呼び出しが失敗した場合は常にエラーを報告します。Sentryは、これらのケースに通常使用されるツールであり、フロントエンドおよびバックエンドのシナリオの両方で機能します。

このアプローチは、エンドユーザーが体験している実際のエラーを知ることができるため、有益です。ただし、エラーのみを追跡するため（すべての要求ではなく）、「どれくらい」のエンドユーザーが影響を受けているのか正確に理解することはできません（1%か、それとも5%か、など）。また、個別の「合成コール」を設定する必要がないため、特に構成を誤った場合は、レート制限の割り当ての一部を消費する可能性があります。

メトリックとログ

このアプローチは、Auth0への呼び出しがご自身が制御しているバックエンドから行われる場合に役立ちます。以下が該当します。

このアプローチは、Auth0への呼び出しのエラー率を追跡するための、メトリックおよび/またはログの使用で構成されています。メトリック/ログは、特に構成を誤った場合は、レート制限の割り当ての一部を消費する可能性がある個別の「合成コール」を設定する必要なく、エンドユーザーが体験していることを正確に表すエラー率を報告します。

アラート

どの監視アプローチを使用するかに関係なく、ある特定の率でエラーが発生した場合は、通常アラートまたはページを受け取ります。率は、アプリケーションによって異なります。

あなたのチームがAuth0からアラートを受け取った場合、 Check Auth0 Status（Auth0のステータスを確認）へのリンクをアラートペイロード/プレイブックに追加することをお勧めします。こうすることで、問題がAuth0またはアプリケーション/サービスで発生しているのかを確認するために、Auth0の公式ステータス報告チャネルをすばやく見ることができます。

もっと詳しく