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

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

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

問題を作成する

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

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

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

前提条件

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

以下のPrivate Minionダッシュボードの例のJSONは、使用してアカウントにインポートすることができます。

輸入までの流れ

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

ヒント

プライベート・ロケーションが親アカウントにあり、Synthetics のモニターがサブアカウントにある場合、 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台 という静的なしきい値で構成されており、ミニオンのいずれかがオフラインになった場合にアラートを受け取ることになります。

ミニオンの1つを手動で停止させることで、アラートポリシーが期待通りに動作することを確認できます。その後、アラート違反が発生すると、設定されているあらゆる通知チャネルによって通知されます。ミニオンが再起動され、オンラインに戻ると、アラートは回復します。

ミニオンが正常に機能しているかどうかを確認するためには、より強固な方法がありますが、このクエリと条件は、マシンが故障したり、誤って廃止されたり、ミニオンのプロセスがクラッシュした場合に、シンプルかつうまく対処します。また、ミニオンが New Relic と通信できることも確認しています。

私のプライベート・ロケーションにはもっとミニオンが必要ですか?

この質問に答えるには、 SyntheticsPrivateLocationStatus イベントの checksPending 属性を使用することができます。 checksPending 属性は、予定されている(または"queued" )が、指定された場所でミニオンがまだ受け入れていないモニターチェックの数を反映しています。スケジュールされたチェックがあり、ミニオンがいない場所では、このグラフは上から右に向かって直線的に伸びていきます。

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

この使用例は、 ベースライン NRQL アラート条件 に最適です。この条件では、指標の静的な値ではなく、その偏差を監視することができます。例えば

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

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

負荷を処理するためにミニオンの数を2倍にすると、アラートは回復します。たとえば、 Synthetics プライベートロケーション ダッシュボードの例を使用して、インシデントとリカバリーの過程で保留中のチェックが増えたり減ったりしていることに気づきます。NRQL 条件を使用することで、ロケーションがより多くのミニオンの容量を必要とする場合には、New Relic が通知します。

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

ミニオンがどのように動作しているかは、ミニオンに直接連絡して確認することもできます。ミニオンが公開している一連のHTTPエンドポイントを使用して、アプリケーションが何をしているかを判断することができます。これらのエンドポイントにアクセスするには、ポート 80808180 をホスト上のポートにバインドします。例えば、Dockerの場合は、 docker run -p 80:8080 -p 81:8180 ...) を使用します。

  • :8080/status/check: ミニオンが行う内部ヘルスチェックの詳細。HTTP 200は、"が健全であることを意味します。"
  • :8080/status: ミニオンのステータスに関する詳細。同じデータが として報告される。 SyntheticsPrivateMinion event.
  • :8180/: JVMアプリケーションの管理エンドポイント。ミニオンの内部状態を高度に表示します。

このアプローチは、 checksPending のような自動化や柔軟性はありません。しかし、完全なネットワーク接続障害が発生した場合、この手動のアプローチは状況のトラブルシューティングに役立ちます。

Copyright © 2024 New Relic株式会社。

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