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

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

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

問題を作成する

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

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

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

前提条件

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

以下のPrivate Minionダッシュボードの例の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で構成されており、ジョブ マネージャーまたはミニオンのいずれかがオフラインの場合に集計を受け取ることを意味します。

アラートポリシーが期待どおりに動作するかどうかを確認するには、ミニオンの 1 つを手動で停止します。 そして、アラートインシデントが発生したときに、設定された通知チャネルを通じて通知されます。 ジョブ マネージャーまたはミニオンが再起動され、オンラインに戻ると、集計は回復します。

ジョブ マネージャーまたはミニオンが正しく機能しているかどうかを確認するより堅牢な方法もありますが、このクエリと条件は、マシンに障害が発生したり、誤って廃止されたり、ジョブ マネージャーまたはミニオン プロセスがクラッシュしたりした場合を簡単かつ適切に処理します。 また、ジョブ マネージャーまたはミニオンが 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 は、保留中のチェックの数が増えてきたことをすぐに通知します。

負荷を処理するためにジョブ マネージャーまたはミニオンの数を 2 倍にすると、集計は回復します。 たとえば、 Synthetics private locationダッシュボードの例を使用して、インシデントと回復の過程で保留中のチェックの増加と減少に注目してください。 NRQL 条件を使用すると、New Relic は、その場所にミニオン容量がさらに必要になった場合に通知します。

特定のミニオンの状態を直接確認することはできますか？

ミニオンやジョブマネージャーに直接連絡して、その動作を確認することもできます。 ミニオンによって公開される一連の HTTP エンドポイントを使用して、アプリケーションが何を実行しているかを判断できます。 これらの インフォメーション にアクセスするには、 コンテナ化された プライベートミニオン (1分間あたりの呼出し回数)の場合はポート8080と8180をホスト上のポートにバインドし、外形監視ジョブ マネージャの場合はポート8080と8082バインドします。 たとえば、 dockerの場合は docker run -p 8080:8080 -p 8082:8082 ... を使用します):

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

このアプローチは、 checksPendingの例ほど自動化されておらず、柔軟性もありません。 ただし、ネットワーク接続が完全に失敗した場合は、この手動のアプローチが状況のトラブルシューティングに役立ちます。

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

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