> ## 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 に問題がある
  * 合成トランザクションに使用しているテナント固有の問題がある
  * または、単に 1 回のリクエストが失敗しただけである

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

[rules](/docs/ja-jp/customize/rules) や [custom database connection(s)](/docs/ja-jp/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 および Machine-to-Machine Applications からの [Authentication API](https://auth0.com/docs/api/authentication) の呼び出し ([クライアントタイプの詳細はこちら](/docs/ja-jp/get-started/applications)) 。

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

このアプローチでは、メトリクスやログを使って Auth0 への呼び出しのエラー率を追跡します。メトリクスやログを使えば、エンドユーザーが実際に経験している状況を正確に反映したエラー率を把握できます。また、別途「synthetic call」を設定する必要もありません。synthetic call は、特に設定を誤ると、レート制限のクォータの一部を消費してしまう可能性があります。

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

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

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

<div id="learn-more">
  ## 詳細はこちら
</div>

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