> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> アプリケーションは Auth0 に依存して動作します。Auth0 の稼働状況を監視することで、Auth0 に問題が発生した場合に特定のエラーを通知したり、ユーザーへの影響を軽減したりできます。詳細はこちら。

# アプリケーションの監視

アプリケーションとサービスは Auth0 に依存して動作します。Auth0 の稼働状況を監視することで、Auth0 に問題が発生した場合に、顧客に特定のエラーを通知したり、ユーザーへの影響を軽減したりできます。

Auth0 を監視する方法は複数あり、それぞれの方法は互いに補完し合います。ニーズと導入にかけられるコストに応じて選択してください。

<div id="synthetic-transactions">
  ## 合成トランザクション
</div>

Auth0 を監視する最も簡単な方法は次のとおりです。

* 定期的なリクエストを設定して、認証トランザクションを実行します。
* リクエストが成功すれば、Auth0 は正常に動作しています。
* リクエストが失敗した場合、次のいずれかが考えられます。

  * Auth0 の問題
  * 合成トランザクションに使用しているテナント固有の問題
  * または、単発のリクエスト失敗

合成トランザクションには、本番テナントの構成にできるだけ近い環境を使用してください。場合によっては、本番テナント自体を使用することもできます。リダイレクトフローやサードパーティプロバイダーを使用した合成トランザクションの設定は難しい場合があるため、[リソースオーナー パスワード グラント](/ja/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow) の使用を推奨します。このフローでは、ブラウザーのリダイレクトは発生せず、UI も必要ありません。

[Rules](/ja/docs/customize/rules)、[カスタムデータベース接続](/ja/docs/authenticate/database-connections/custom-db)、またはその他の拡張ポイントを使用している場合は、システムのその部分が正しく機能していることを確認するため、合成トランザクションが Rules やカスタム DB スクリプトを利用するように設定してください。

[Pingdom](http://pingdom.com/) のようなツールを使えば、合成トランザクションを簡単に設定できます。

<div id="check-period">
  ### チェック間隔
</div>

合成トランザクションは 1 分間隔で実行することを推奨します。このシンプルな方法であれば、Auth0 のレート制限クォータをあまり消費せずに、十分に迅速な応答を得られます。

<div id="limitations-of-synthetic-transactions">
  ### 合成トランザクションの制限事項
</div>

合成トランザクションは、Auth0テナントの健全性を監視するためのシンプルで低コストな方法です。ただし、いくつかの制限があります。

* 合成トランザクションは、エンドユーザーの実際の体験をそのまま反映するものではありません。代わりに、その代替的な指標を提供します。
* 合成トランザクションでは、ユーザーと同じフローが使用されない場合があります。
* アトミックではなく (通常は1分ごとに実行) 、エンドユーザーに発生した可能性のあるエラーは報告されません。

より詳細なデータが必要な場合は、[エラーの追跡](#error-tracking) と [メトリクスとログ](#metrics-and-logs) を参照してください。

<div id="error-tracking">
  ## エラーの追跡
</div>

このアプローチは、既存の Auth0 呼び出しで発生するエラーを追跡するのに役立ちます。具体的には、Auth0 への呼び出しが失敗するたびにエラーを報告します。[Sentry](https://sentry.io/) はこのような用途でよく使われるツールで、フロントエンドとバックエンドの両方で利用できます。

このアプローチが有用なのは、エンドユーザーが実際に経験しているエラーを把握できるためです。ただし、追跡するのはエラーだけであり (すべてのリクエストではないため) 、影響を受けているエンドユーザーがどの程度いるのかを正確に把握することはできません。1% なのか 5% なのかはわかりません。また、別個の「擬似的な呼び出し」を設定する必要もありません。これは、特に設定を誤ると、レート制限のクォータの一部を消費する可能性があります。

<div id="metrics-and-logs">
  ## メトリクスとログ
</div>

このアプローチは、Auth0 への呼び出しを自分で管理しているバックエンドから実行する場合に有効です。たとえば、次のようなケースです。

* [Auth0's Management API](https://auth0.com/docs/api/management/v2) へのほとんどの呼び出し
* Regular Web Applications およびマシン間アプリケーションからの [Authentication API](https://auth0.com/docs/api/authentication) の呼び出し ([クライアントタイプの詳細](/ja/docs/get-started/applications)) 。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  一部のオブザーバビリティ製品では、フロントエンドアプリケーションやモバイルアプリケーションからメトリクスやログを送信することもできます。
</Callout>

このアプローチでは、メトリクスやログを使用して Auth0 への呼び出しのエラー率を追跡します。メトリクス/ログは、エンドユーザーが実際に経験している内容を正確に反映したエラー率を報告できるため、別途「擬似的な呼び出し」を設定する必要がありません。擬似的な呼び出し は、特に設定を誤ると、レート制限クォータの一部を消費する可能性があります。

<div id="alerting">
  ## アラート
</div>

どのような監視手法を使用していても、エラーが一定の頻度で発生したときにアラートやページャー通知を受けるのは一般的です。その頻度はアプリケーションによって異なります。

チームがAuth0からアラートを受け取った場合は、アラートのペイロード/プレイブックに [Auth0のステータスを確認](/ja/docs/deploy-monitor/monitor/check-auth0-status) へのリンクを追加することをお勧めします。これにより、問題の原因がAuth0にあるのか、それとも自社のアプリケーションやサービスにあるのかを、Auth0の公式ステータス報告チャネルですばやく確認できます。

<div id="learn-more">
  ## 詳細情報
</div>

* [Auth0 のステータスを確認する](/ja/docs/deploy-monitor/monitor/check-auth0-status)
* [外部サービスのステータスを確認する](/ja/docs/deploy-monitor/monitor/check-external-services-status)
* [System Center Operations Manager を使用して Auth0 を監視する](/ja/docs/deploy-monitor/monitor/monitor-using-scom)