New Relicの監視データをプライベート経由で送る(概要編)

# はじめに
今回書く内容としては、<font color="red">**New Relicの監視データをプライベート経由で送る(概要編)**</font>です。
以前、下記記事でも同じような内容を書いたのですが、その概要編ということで、今回も書いていこうと思います。

https://qiita.com/yes_dog/items/c2a78f45b11b1c210710

本記事は、<font color="red">**「New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2024」の20日目の記事**</font>となります。(すいません、投稿遅れました)

https://qiita.com/advent-calendar/2024/newrelic

# 前提条件
- 2024年2月に構築した内容を元に記載しているので、一部情報が古いことがありますが、その点ご了承ください

# 概要

## (1)プライベート経由で監視データを送る手法に関して
New Relicとは、基本的にはAgent導入型のプッシュ型の監視サービスであり、各監視対象のサーバは、特定のドメイン(newrelic.com、nr-data.net)に対して、自身の監視メトリクス/ログデータをインターネット経由で送らせるアーキテクチャです。インターネット経由で監視データを送るということが、社内で定めるセキュリティ的に許容できないということになり、今回プライベート経由で監視データを転送するアーキテクチャを構築しました。
New Relic社では、各監視対象サーバが、プライベート経由で監視データを送る手法として、AWS PrivateLink経由でのデータ転送手段を公開してます。公開されているAWS PrivateLinkのエンドポイントは、下記4つのリージョンしかなく、それ以外の環境からアクセスさせる際には、別途対応が必要となります。
- us-east-1(米国東部 (バージニア北部))
- us-east-2(米国東部 (オハイオ))　<font color="red">**←この記事では、これを使う前提で書いていきます。**</font>
- us-west-2(米国西部 (オレゴン))
- eu-central-1(欧州 (フランクフルト))

主な対応事項としては、「別環境から通信できるようにさせる」と「AWS PrivateLinkの名前解決をさせる」です。
そこで使用したアーキテクチャとしては、「Transit Gatewayのリージョン間ピアリング」と「Route53での名前解決の設定」です。
イメージ図としては下記となるのですが、実際に構築した内容としては、下記となります。
- (1)バージニア北部のVPC内で、[この記事](https://docs.newrelic.com/jp/docs/data-apis/custom-data/aws-privatelink/)にあるPrivateLinkを必要に応じて作成する
- (2)Route53のプライベートホストゾーン(newrelic.com/nr-data.net)を作成し、各ドメインごとにprivateLinkのホスト名を関連付ける。
- (3)Transit Gatewayのリージョン間ピアリング/ルーティン設定
- (4)Route53のプライベートホストゾーンをVPCに関連付ける

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252895/85906eef-096c-dbc1-25bf-8a358642807f.png)

上記の設定をすることで、以下表に記載されているドメインに対して、プライベート経由で監視データを送れるようになります。※Route53の名前解決の優先順位により、Route53のプライベートホストゾーンに設定されるドメインの名前解決が優先され、結果として、監視データはPrivateLink経由で送られるようになる。

| ドメイン | 説明 |
|:-:|:-:|
|collector.newrelic.com   |APM   |
|insights-collector.newrelic.com   |イベントのAPI   |
|metric-api.newrelic.com   |メトリック API (Prometheus およびその他の統合を含む)   |
|log-api.newrelic.com   |ロギング   |
|trace-api.newrelic.com   |ディストリビューティッド（分散）トレーシング   |
|cloud-collector.newrelic.com   |AWS Lambda と Cloudwatch Logs のモニタリング   |
|infra-api.newrelic.com   |インフラストラクチャの監視とオンホスト統合   |
|otlp.nr-data.net   |OpenTelemetry   |

## (2)Route53のルール設定に関して
手順(1)を実施したことで、特定のドメインに対しては、プライベート経由でデータを送れるようになりました。しかし、newrelic.com、nr-data.net内で未定義のサブドメイン(identity-api.newrelic.com/infrastructure-command-api.newrelic.com/api.newrelic.comなど)へ通信が必要になった際は、名前解決ができないことが原因で通信に失敗してしまいます。
なので、「このドメインの名前解決はRoute53のプライベートホストゾーン」「それ以外の名前解決は外部のDNSサーバに問い合わせをしてね」といったルール設定が必要になります。
そのルール設定は、Amazon Route 53 Resolverのルール設定で定義する必要があり、各ルール設定で定義できる項目は下記の通りとなります。
|ルール名称 |説明 |今回の設定対象 |
|:-:|:-:|:-:|
|再帰的   |AWS側で自動的に作成されるルールで、Route53に登録がないドメインに対して、再帰リゾルバーとして機能させる設定   |-   |
|Forward(転送)   |指定したドメイン名のDNSクエリをネットワーク上のリゾルバーに転送する設定   |〇   |
|System(システム)   |指定したドメインに対して、Route53で名前解決をさせる設定。   |〇   |

上記内容を踏まえ、実際に設定した際の画面は下記画像となります。これで、定義済みのサブドメインはプライベート経由で名前解決がされ、それ以外のサブドメインは外部のDNSサーバで名前解決がされるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252895/9cfebf19-1eda-2221-6b9a-cee84bda1061.png)

## (3)Proxyの利用に関して
手順(1)、(2)を実施したことで、プライベート経由で監視データを送る手法が確立できました。しかし、横展開を考えた場合、VPCの数がある分だけ、下記の対応が必要になることが課題として挙がりました。
- Route53のプライベートホストゾーンの関連付けを監視対象があるVPC毎に実施しなければならない
- Route53 Resolverの各ルール単位で、監視対象があるVPCを関連付けなくてならない

上記の対応は、今後の運用を考えた場合、作業漏れのリスクが大きくある為、汎用性のある環境を別途考える必要がありました。そこで、Proxy経由で監視データを送るという手法にたどり着きました。
実際に実施した内容は下記となります。

- ProxyサーバをRoute53のプライベートホストゾーンが関連付けられたVPCに配置する
- 各監視対象のサーバは、Proxy経由で監視データを送る設定をする

上記の手法をすることで、newrelic.com/nr-data.netといった名前解決はProxyが行うようになるので、名前解決を絞っているオンプレミス環境に対してもNewRelicの導入ができるようになりました。実際に構築した後のイメージ図としては、下記のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252895/9dac0a81-91ea-28d0-3b66-33211df097bb.png)

また、NewRelicでは、Infrastructure agentやAPM Agent毎に専用のProxy環境変数を用意しているので、OS標準で用意されているHTTP_PROXY/HTTPS_PROXYを使うことなく、監視データを送れるのが、ほんとにありがたいです。※既存の通信に影響を与えることなく、PROXY経由で監視データを送れる。

# 最後に
今回の環境は、かなり苦戦して構築しました。AWSサポートやNewRelicのサポートに確認しながら進めたので、自身にとってとても勉強になりました。
この記事が、どなたかのお役に立てば幸いです。