New Relic Synthetics の API 外形監視の監視元ロケーションを東京と海外からのマルチロケーションにしてみた

監視元のロケーションが増えてもチェックボックスにチェック入れるだけのお手軽設計
2021.12.29

前回、New Relic Synthetics で外形監視を試してみました。

その中で New Relic のTokyo, JPロケーションはAWS の ap-northeast-1(東京リージョン)であることを知りました。

New Relic から外形監視したい対象のサービス、システムで同じくAWS の ap-northeast-1を利用している場合、AWSの東京リージョン障害で監視が機能しないことも考えられます。

リージョン障害を見据えて New Relic Synthetics から他ロケーションからの監視設定を追加してみます。設定方法と、どのように表示されるのか紹介します。

ロケーション追加

New Relic Synthetics の基本的な設定方法は前回の記事を参考にしてください。New Relic Synsteices の Endpoint availability を利用しPOSTメソッドのリクエストを送り、レスポンス内容をチェックしてOK/NGの判定をしている構成をベースに進めます。

対象のモニターを選択します。

Generalを選択。

ロケーションの選択から、Tokyo, JP(東京)に加え、Singapre, SG(シンガポール)を追加。複数ロケーションから外形監視したいときでもチェックを入れるだけです。

Pingの様な死活監視ならまだわかりますが、モニタリングスクリプトを実行するのも設定はこれだけとは...非常に簡単です。

保存します。

マルチロケーションの追加はこれだけ設定完了です。

ロケーションの追加は地域の名前にチェックを入れ、削除するときはチェックを外すだけのお手軽設定でした。

観測

Summaryから確認するとロケーションが増えています。東京、シンガポール共にチェック成功しています。

応答速度を見比べてみます。並はありますがワーストケースで東京が260msに対して、シンガポールが808msとかなり開きがあります。日本国内のユーザー視点で応答時間を確認したいという場合は海外ロケーションだと厳しそうです。

日本国内での応答時間を把握しつつ、東京リージョン(AWSのap-northeast-1)障害に備えるには、東京(Tokyo, JP)と他のロケーションを1つ追加くらいが落とし所ではないでしょうか。

実行履歴を確認します。東京と、シンガポールが同時刻に実行されている履歴を確認できました。

実行履歴の詳細を比較

東京とシンガポールの詳細からLoad timeを見比べてみました。地理的な問題は避けられないですね。

  • DNS名前解決時間(DNS)に大きな差がある
  • TCPコネクション確立時間(CONNECT)に大きな差がある

東京

シンガポール

クエリ

分析したいときは New Relicのクエリ言語であるNRQL(New Relic Query Language)か、PromQL(Prometheusのクエリ言語)で検索できます。

Events explorer から選択式でクエリを作ることができます。過去6時間分の東京と、シンガポールのDNS名前解決時間(DNS)のグラフと平均値です。ロケーション名はAWSのリージョン名で表示されています。

クエリビルダーを使えば自由に検索できます。ピンク枠のところにマウスを持っていくとEdit in query builderと表示されクリックして編集画面に入ります。

クエリの編集だけではなくChart typeから表にしたり、棒グラフにしたりビジュアルも変更できました。

ちなみに東京と、シンガポールの応答時間の平均値を表示していました。この形式ですとダッシュボードなどに利用できそうですね。

おわりに

現状日本国内からの応答時間を正確に確認したいなら New Relic Syntheticsは東京 + 1ロケーション構成がよいのではないでしょうか。死活監視目的ならとくにロケーションにこだわらなくてもよいかもしれませんけど、AWSの単一のリージョン障害で監視が止まることを考えたら2ロケーション選択しておいてもデメリットはあまりないかと思いました。