Skip to main content
Monitoring Agentは、公開済みアプリの問題を調査するのに役立ちます。Auto-fix を有効にするとAgentがモニタリングアラートに対応し、Auto-republish を有効にすると修正を自動的に公開します。また、必要なときにいつでも本番環境のログやメトリクスについてAgentに質問できます。 ご自身で確認できるグラフ、リソース使用状況、ログについては、モニタリングをご覧ください。

​
仕組み

モニタリングアラート、Auto-fix、Auto-republish はそれぞれ独立した設定です。Agentにコードの変更を許可せずにアラートだけを受け取ることも、公開は自分で管理したままAgentに修正を試みさせることもできます。 自動チェックでは、アプリケーションのエラーログ、HTTPエラー、リクエストレイテンシーの3つのシグナルを監視します。これらのチェックは、Agentが調査できるすべてのメトリクスを対象としているわけではありません。 Auto-fix を有効にすると、Monitoring Agentはバックグラウンドでアラートに対応します：
1

アラートを調査する

Agentは、アプリの本番環境のメトリクス、ランタイムログ、コードを使って原因を調査します。
2

修正を試みて検証する

対応可能な原因を特定すると、Agentは修正を試み、変更を検証します。アラートが発生しても修正が保証されるわけではありません。たとえば、外部サービスの問題では、アプリの外で対応が必要になる場合があります。
3

修正を公開する

Auto-republish を有効にすると、Agentは検証済みの修正を自動的に公開できます。無効の場合は、Agentチャットで結果を確認し、アプリを再公開して修正を反映します。
Auto-republish は実験的な機能で、Auto-fix が必要です。Auto-fixだけでは、ライブアプリへの変更の公開は許可されません。マイグレーションやインデックス操作など、一部の変更にはリスクが伴う場合があります。

​
Monitoring Agentを設定する

モニタリングは、公開済みアプリごとに個別に設定します。Monitoring Agentの実行には、Agentの利用料金が発生する場合があります。支出は使用状況ページで確認できます。
1

公開設定を開く

Publishing ツールを開きます。公開済みのアプリの場合は、その公開設定を開きます。新しいアプリの場合は、最初の公開時にモニタリングを設定します。
2

モニタリングアラートを有効にする

公開済みのアプリの場合は、Monitoring alerts をオンにします。変更は再公開せずにすぐに保存されます。アップタイムチェックは別に管理されます。最初の公開時には、Suggested add-ons の下にある Enable Active monitoring をオンにします。利用可能な場合は、アップタイムチェックも有効になります。この例は、モニタリングが有効で、Auto-fix と Auto-republish がまだオフの状態の、最初の公開時の設定を示しています。Enable Active monitoringがオン、Auto-fixがオフ、実験的なAuto-republishのコントロールが表示されオフになっている、最初の公開時の設定
3

自動修正を有効にする

Auto-fix をオンにすると、Monitoring Agentがモニタリングエラーを調査して修正できるようになります。公開済みのアプリの場合、この変更はすぐに保存されます。新しいアプリの場合は、Publish を選択して設定を適用し、モニタリングを開始します。
4

自動で再公開するかどうかを選択する

Auto-republish を有効にすると、Agentが修正を自動的に公開します。変更を自分で確認して公開したい場合は、オフのままにしてください。公開済みのアプリの場合、この変更はすぐに保存されます。新しいアプリの場合、この設定は最初の公開から有効になります。
自動での調査と修正を停止するには、同じ設定で Auto-fix をオフにします。Monitoring alerts はオンのままにして、アラートを受け取り続けることもできます。自動修正は維持しつつ、変更をライブにする前に確認したい場合は、代わりに Auto-republish をオフにします。

​
アラートを確認する

Monitoring ツールを開き、Monitoring alerts テーブルを見つけます：
  • Active：現在アプリに影響している問題です。
  • Resolved：過去30日以内にアプリへの影響がなくなった問題です。
アラートを展開すると、アラートが発生した理由と、何回のモニタリングパスで検出されたかを確認できます。Replitが現在評価できないアラートには Cannot measure と表示されます。

​
メールの設定

Settings > Notifications を開き、Active monitoring alerts でアラートメールを管理します。 Production alert emailsが有効で、Active monitoring alertsがCritical severity onlyに設定されている通知設定 重大度セレクターが無効になっている場合は、本番環境のアラートメールを有効にしてください。Critical severity only、High severity and above、Medium severity and above、All severity levels、No emails から選択します。 アカウント全体の受信者設定は、個人のメール設定とは別です。アカウントの詳細設定で、Monitoring alert recipients を開きます。権限を持つ管理者は、受信者として Off、Admins、Custom を選択でき、重大度のしきい値も別に設定できます。 メールをオフにしても、モニタリングや Auto-fix はオフになりません。

​
本番環境についてAgentに質問する

アラートを待ったり Auto-fix を有効にしたりしなくても、公開済みアプリについてAgentに質問できます。次のようなプロンプトを試してください：
  • 「直近1時間でアプリが500エラーを返したのはなぜですか？」
  • 「今日最も遅かったエンドポイントはどれですか？ p50とp99のレイテンシーを比較してください。」
  • 「前回の公開以降のCPUとメモリの使用状況を確認してください。」
  • 「起動に失敗したリビジョンのランタイムログを読んでください。」
わかっている場合は、おおよその時刻、タイムゾーン、影響を受けたエンドポイントを含めてください。Agentはその情報をもとに調査範囲を絞り込みます。

​
利用可能なテレメトリー

Agentは、自動アラートに使用される3つのシグナルよりも多くのテレメトリーをオンデマンドで照会できます。利用可能なメトリクスは、デプロイメントタイプとクラウドプロバイダーによって異なります。
  • HTTP traffic：リクエスト数、リクエストレイテンシー、4xxおよび5xxレスポンス数、可用性。
  • Endpoint performance：エンドポイントごとのリクエスト数、レイテンシー、4xxおよび5xxレスポンス数。レイテンシーには、平均値、p50、p95、p99の値が含まれます。
  • Compute：CPUとメモリの使用率、アクティブなインスタンス数、起動レイテンシー、インスタンスの稼働時間。
  • Storage and network：ディスク使用量、ディスク使用率、ネットワークエグレス。
  • Application errors：エラーログ数と、重大度またはデプロイメントのリビジョンで絞り込んだランタイムログ。

​
次のステップ