• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

プライベートロケーションの監視

シンセティック・モニタリングの プライベート・ロケーション と New Relic のアラートを併用すると、ロケーションのプロビジョニング不足や設定ミス、あるいは一般的な誤動作があった場合に通知を受けることができます。

このガイドでは、 New Relic ダッシュボード と NRQL アラート を使用して、プライベートロケーションヘルスに関する以下の基本的な質問に答えることができます。

前提条件

このガイドの指示に従う前に、以下のことを確認してください。

以下のプライベートジョブマネージャーダッシュボードの例JSONは、以下の方法でアカウントにインポートできます。

輸入までの流れ

  1. ダッシュボードのJSONをコピーして、テキストエディターに貼り付けます。
  2. "accountId": 0,と"accountIds": [ 0 ]を、JSON コード内の各出現箇所の New Relic アカウント ID または ID のリストに置き換えます。
  3. テキストエディターからDashboardのJSONをコピーし、上記のいずれかの方法でインポートします。
  4. facet filtering を使用したいチャートを編集します。

ヒント

プライベート ロケーションが親アカウントに存在し、外形監視 モニターがサブアカウントに存在する場合は、SyntheticPrivateLocationStatus と SyntheticsPrivateMinion を使用するNRQLクエリに親アカウント ID を挿入し、SyntheticCheck と SyntheticRequest を使用するクエリにサブアカウント ID を挿入します。

私の個人求人担当者はオンラインですか？

この質問に答えるには、 SyntheticsPrivateMinionイベントの属性を利用できます。プライベート外形監視ジョブ マネージャーは、このイベントを 30 秒ごとにNew Relicに送信します。 ジョブマネージャーがオンラインかどうかを確認する簡単な方法は、ミニオンIDの固有数と、オンラインになっていると予想されるジョブマネージャーの数を比較することです。

レポートしているジョブ マネージャーの数を理解するには、この例のNRQL書き込みを実行します。

SELECT uniqueCount(minionId)
FROM SyntheticsPrivateMinion
WHERE minionLocation = '1-acme_okc_dc-309'

このクエリを使用すると、予想よりも少ないジョブマネージャーからの報告があった場合にチームに通知するアラート条件を作成できます。この条件は静的な2 unitsで設定されています。これは、いずれかのジョブマネージャーがオフラインの場合、 を受信することを意味します。

ジョブマネージャーのいずれかを手動で停止することで、アラートポリシーが期待どおりに機能していることを確認できます。そして、アラートインシデントが発生すると、設定されている通知チャネルによって通知されます。 ジョブマネージャーが再起動され、オンラインに戻ると、 は復旧します。

ジョブマネージャが正しく機能しているかどうかを確認するより堅牢な方法は他にもありますが、このクエリと条件は、マシンが故障した場合、誤って廃止された場合、またはジョブマネージャのプロセスがクラッシュした場合を、シンプルかつ適切に処理します。また、ジョブマネージャーがNew Relicと通信できることも保証します。

私のプライベートロケーションにはさらに多くのジョブマネージャーが必要ですか?

この質問に答えるには、 SyntheticsPrivateLocationStatusイベントのchecksPending属性を使用できます。checksPendingプロパティは、スケジュールされている (または「キューに入れられている」) が、指定された場所の外形監視ジョブ マネージャーによってまだ受け入れられていない監視チェックの数を反映します。 定期点検が実施され、ジョブマネージャーがいない場所の場合、このグラフは右上方向に直線的に伸びます。

追加の属性を使用すると、 checksPending属性の増加の原因となっているジョブ タイプを特定し、tr の取り組みをどこに集中させるかを特定できます。

このメトリクスは、値が高いからといって必ずしも場所の状態が悪いとは限らないため、 uniqueCount(minionId)よりも監視が複雑です。 メトリックが直線的に右上がりに増加していない限り (そしてチェックがスケジュールどおりに実行されている限り)、その場所は良好な状態にあります。

このユースケースは、静的な値ではなくメトリックの偏差を監視できる異常NRQLアラート条件に最適です。 例えば：

SELECT average(checksPending)
FROM SyntheticsPrivateLocationStatus
WHERE name = '1-acme_tokyo_dc-512'

このアラート条件をテストするには、1分間のブラウザベースのモニターを、あなたの所在地から実行するようスケジュールします。ブラウザベースのジョブはPingジョブよりも多くのリソースを消費するため、負荷シミュレーションに適しています。New Relic は、保留中のチェックの数が増えてきたことをすぐに通知します。

負荷に対応するためにジョブマネージャーの数を倍増させた後、 回復しました。 例えば、 Synthetics private locationダッシュボードの例を使用して、インシデント発生から復旧までの過程における保留中のチェックの増減に注目してください。NRQL条件を使用することで、New Relicは、その場所でジョブマネージャーの容量がさらに必要になった場合に通知します。

特定のジョブマネージャーのステータスを直接確認することはできますか？

ジョブマネージャーの運営状況を確認するには、直接連絡を取ることもできます。ジョブ マネージャーによって公開される HTTP エンドポイントのセットを使用して、アプリケーションが何を行っているかを判断できます。 これらのエンドポイントにアクセスするには、ポート8080と8180 、外形監視ジョブ マネージャーのホスト上のポートにバインドします。 例えば、Dockerの場合はdocker run -p 8080:8080 -p 8082:8082 ...を使用します。

  • :8080/status/checkジョブマネージャーが実行する内部ヘルスチェックの詳細。HTTP 200は「正常」を意味します。
  • :8080/status: ジョブマネージャーのステータスに関する詳細。同じデータは、 SyntheticsPrivateMinionイベントとして報告されます。
  • :8082/: JVM アプリケーション管理エンドポイント。ジョブ マネージャーの内部状態の詳細なビュー。

このアプローチは、 checksPending例ほど自動化されておらず、柔軟性もありません。しかし、ネットワーク接続が完全に途絶えてしまった場合は、この手動による方法が状況のトラブルシューティングに役立つ可能性があります。

Copyright © 2026 New Relic株式会社。
採用情報サービス利用規約DMCAポリシー特許通知プライバシー通知Cookie ポリシー英国現代奴隷法

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.