みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
少しずつ季節の変わり目を感じる今日この頃ですが、最近栗を使ったスイーツがスーパーやコンビニなどでちらほら出始めているので、新しいスイーツが気になって夜しか眠れませんｗ
そういえば、New Relicのホスト一覧で表示されている情報が分かりにくくて・・という話をいただいて、 確かに設定次第ではそうなるよな～と思ったことから少し深堀して調べたのが今回の記事の内容になります。
この記事の対象者
- New Relicを使ってオブザーバビリティをしたいと考えている方
- New RelicのInfrastructure agentのインストールはしたけど、Infrastructure agentの設定って必要なんだっけ？という方
- オンプレやEC2などのホスト管理をNew RelicのInfrastructure agentでおこないたい方
記事の概要と背景
当記事の背景として、サーバ管理をしている際にこのシステムはこういう用途で使用するからサーバの名前をxxxにすることで、システムに問題が発生した際にどのシステムで事象が発生しているのかすばやく理解するために命名規則を付けているケースは多々あるかと思います。基本的にはサーバのホスト名、インスタンスタグ名など管理に必要な部分を同じように設定変更して管理いただいているとは思いますが、AWS環境のみでご使用いただいている場合はリソースにNameタグを設定するだけでもある程度の把握ができることから、OS側の設定漏れがあるケースなどが推測されます。
New RelicのInfrastructure agentの設定をおこなう際の設定項目はたくさんありますが、その設定項目を変更すると送信されるデータがどのように変化するかといった点にフォーカスしており、細かい設定パラメータを変更することでNew Relicの管理上どのような影響があるんだっけ？といったことを当記事で知ることができます。
Infrastructure agentの設定をデフォルトで使用されている方も多いと思いますが、設定をカスタマイズすることでちょっとだけ痒い所に手が届くかもしれません。
公式ドキュメント
まず、公式ドキュメントでホスト名の設定に対して明記されているのは下記の２つで、ひとつは実際の設定に関する内容、もう一つは間違ったホスト名が表示された場合の対処方法となっております。
まずは、こんな時どうする？の間違ったホスト名が表示された場合の対処方法のページからご紹介します。
１．間違ったホスト名が表示された場合の対処方法
Problem
The agent is working, but the infrastructure UI shows the wrong hostname or duplicated hosts appear.Solution
Review the hostname related settings in the agent configuration. To set the correct hostname, try the following steps:
- Edit the newrelic-infra.yml configuration file and add the override_hostname option, whose value is your expected hostname.
- Use your init system to restart the agent service
<日本語訳>
事象
エージェントは動作しているが、インフラストラクチャUIに間違ったホスト名が表示されたり、重複したホストが表示されたりする。改善案
エージェント設定のホスト名関連の設定を見直してください。 正しいホスト名を設定するには、以下の手順を試してください。
- newrelic-infra.yml設定ファイルを編集し、override_hostnameオプションを追加する。
- initシステムを使ってエージェントサービスを再起動する
ドキュメントを見る限りでは、newrelic-infra.ymlの設定で、override_hostname に意図した設定を追記しろとあります。
それでは、この値を設定することでどのような変化があるか確認してみましょう。具体的な確認ポイントは下記の通りです。
- New Relicのホスト名を確認できる箇所がどれだけあるか確認すること
- 今回の設定変更でどこに影響するか確認すること
newrelic-infra.ymlの設定変更
今回はoverride_hostnameの設定を追加します。基本的にyaml形式で記載しますので、追加される設定は下記のような内容となります。
override_hostname: <ここにホスト名を記載>
設定変更前
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli
設定変更後
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli override_hostname: nr-kensho-hostnamechange
設定後のサービス再起動
設定ファイルを変更した後、サービスの再起動を実施する必要があります。 今回の検証環境Linuxの場合は下記のコマンドを使用しました。
sudo systemctl restart newrelic-infra.service
状況確認
まず、サービス再起動前の状況から確認しましょう。下記の通り metrics & event の画面で見える情報（＝生データ）では、entityName、fullHostname、hostnameで実際のホスト名の情報が見えていることからこのあたりの情報に変化があるかもしれないという推測を立てることができます。
次に、サービス再起動後の状況を確認してみましょう。fullHostnameのところに新しい情報が追加され、サービス再起動後から転送されている値が異なっていることがグラフのデータから判別できます。この辺の背景について詳しくは後述しますが、ここではそのような変化があったという事だけ覚えておいてください。
最後にNew Relicの管理画面上でどのような変化があるかという点ですが、こちらは状況が変わらないということから管理画面上に影響のない設定ということがわかりました。
２．Infrastructure agentの設定値
次にInfrastructure agentの設定値について見ていきましょう。下記ページのHostname variablesの項目が今回の対象となります。
| yaml設定名 | 設定内容 |
|---|---|
| display_name | レポート用に自動生成されるホスト名を上書きします。 インフラストラクチャ監視ではホスト名を各ホストの一意な識別子として使用するので、同じ名前のホストが複数ある場合に便利です。 この値はエンティティ名のループバックアドレス置換にも使われることに注意してください。 |
| dns_hostname_resolution | trueの場合、完全なホスト名は、ホストのアドレスの逆引きを行うことで解決される。 そうでない場合は、Linuxではhostnameコマンドで、WindowsではレジストリのTCP/IPパラメータから取得されます。 |
| override_hostname | 設定されている場合、これは完全なホスト名に対して報告される値です。そうでない場合、エージェントは通常のルックアップ動作を行います。 |
| override_hostname_short | 設定されている場合、これはホスト名に対して報告される値です。そうでない場合、エージェントは通常のルックアップ動作を行います。 |
前項の設定内容の振り返り
前項の設定（override_hostname）は、「エージェントは通常のルックアップ動作を行います」とあるため、エージェントがホストの値を引っ張ってくるという解釈が正しいでしょう。この点についてもう少しだけ深堀りすると、override_hostname と override_hostname_short を使って差し替える値は両方ともOSのホスト名がベースとなりますが、今回の挙動でも明らかになった override_hostname で差し替えられる fullHostname は、OSで設定されているホスト名に対するDNSルックアップ値となり、override_hostname_short でで差し替えられる hostname はOSで設定しているホスト名そのものという事になります。
整理すると下記のとおりです。
| 種別 | 値の概要 | 取得方法 |
|---|---|---|
| 短縮ホスト名(hostname) | ホスト自身の名前 | /proc/sys/kernel/hostname から取得 |
| 完全なホスト名(fullHostname) | 短縮ホスト名のDNSルックアップ値 | short-hostname の値に対する DNS ルックアップによって取得。失敗した場合は、hostname -f で取得 |
上記の仕様部分については、公式ドキュメントではなくInfrastructure agentのGithubレポジトリに詳しい情報が記載されていますので、合わせてご確認いただければと思います。
管理画面の表示に影響する設定
それでは本題の管理画面の表示に影響する設定について見ていきましょう。Infrastructure agentの設定値の表でなんとなく気が付いている方もいらっしゃるのではないかと思いますが、display_name の設定変更を行うことで、OSのホスト名を変更することなくInfrastructure agentの設定変更だけでNew Relicの管理画面の表示変更が可能です。ここでいっているNew Relicの管理画面の表示変更とは、例えば下記画面などの表示でip-10-x-x-x という表示になっているものを hoge-instance など見た目にわかりやすい名前に変更することです。
では、設定変更をレッチラGO～！
newrelic-infra.ymlの設定変更
今回はdisplay_nameの設定を追加します。 yaml形式で記載しますので、追加される設定は下記のような内容となります。
display_name: <ここにホスト名を記載>
設定変更前
前項の設定を残したまま設定変更していますので、設定変更前の値にoverride_hostnameを含んでいます。 通常はoverride_hostnameの値が設定されていないかと思いますので、その点ご注意ください。
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli override_hostname: nr-kensho-hostnamechange
設定変更後
設定変更後の値が分かりやすいように、意図的に「nr-kensho-hostnamechange_display」という値を設定しました。 この状態でサービス再起動するとどうなるか次の項目で見てみましょう。
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli override_hostname: nr-kensho-hostnamechange display_name: nr-kensho-hostnamechange_display
設定後のサービス再起動
設定ファイルを変更した後は、設定反映のためサービスの再起動を実施する必要があります。 今回も下記のコマンドを使用しました。
sudo systemctl restart newrelic-infra.service
状況確認
それでは、New Relicの管理画面上で表示上の変化があったのか否か再度確認してみましょう。 まずは設定変更前の状況からおさらいして、変更後にどのように変化したのか見ていきます。
設定変更前
Nameの部分にIPアドレスベースの名前が記載されており、この中の一部のホストの名前が変更されれば今回の設定変更が意図したとおりのものになったことが確認できます。 なお、i-xxxx といったインスタンスIDで表示されているものは、そもそもNew RelicのInfrastructure agentがインストールされていないものになりますのでご留意ください。
設定変更後
意図したとおりに画面上の表示が変更されました。
metrics & event のイベントの値がどうなっているかも確認してみましょう。現在の設定では、override_hostnameでnr-kensho-hostnamechangeと設定しており、display_nameでnr-kensho-hostnamechange_display と設定していることから、metrics & event のイベントの値がnr-kensho-hostnamechangeなのかnr-kensho-hostnamechange_displayなのかを確認するという事になります。
ここで注目したい点としては、display_name で設定した上の名称がホストの名称になっていること、fullHostname の値は override_hostnameで設定している値から変化がないことです。 つまり、display_nameでは管理上の名称が変更されていることになり、内部的なNRQLクエリなどで使用する fullHostname の方は、 override_hostnameで指定された値となっているという点です。実運用の場合はdisplay_nameやfullHostnameは統一したほうがよさそうに見えますが、fullHostname はDNSの名前解決で得られた値という点を考慮すると、その点を運用でどこまで使う可能性があるかどうかで fullHostname じゃなくて hostname を変更して fullHostname はそのままでもいいんじゃない？といったような判断がもしかしたらあるかもしれません。もちろんその運用の場合はdns_hostname_resolutionの設定も必須となるでしょう。
後で見返して気が付いたのですが、display_nameの値を変更することで、データ上は entityName の値が変更されているようでした。
この挙動から、New Relicの管理画面で表示している名称（値）は entityName を参照しているということが推測できそうです。
短縮ホスト名の設定
今までの内容でおおよそどの設定を変更すると、転送されるデータや画面がどのように変化するかを見てきておおよその内容が把握できたと思います。 次に、短縮ホスト名の設定（override_hostname_short）をさらっと確認しましょう。
newrelic-infra.ymlの設定変更
yaml形式で記載しますので、追加される設定は下記のような内容となります。
override_hostname_short: <ここにホスト名を記載>
設定変更前
前項の設定を残したまま設定変更していますので、その点ご注意ください。
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli override_hostname: nr-kensho-hostnamechange display_name: nr-kensho-hostnamechange_display
設定変更後
設定変更後の値が分かりやすいように、意図的に「nr-kensho-hostnamechange_short」という値を設定しました。
license_key: <ライセンスキー> status_server_enabled: true status_server_port: 18003 custom_attributes: nr_deployed_by: newrelic-cli override_hostname: nr-kensho-hostnamechange display_name: nr-kensho-hostnamechange_display override_hostname_short: nr-kensho-hostnamechange_short
設定後のサービス再起動
設定ファイルを変更した後は、設定反映のためサービスの再起動を実施する必要があります。 今回も例にならって下記のコマンドを使用しました。
sudo systemctl restart newrelic-infra.service
状況確認
それでは状況を確認していきましょう。想定通り設定反映後より hostname の部分の値が変化していることがわかりました。
OSのホスト名を変更
上記はOSのホスト名変更が難しい場合を想定して、Infrastructure agentの設定でなんとかできないかといった観点での設定となります。 運用の観点で考えたとしても本筋ではOSのホスト名を変更いただくのがベターではないかと考えていますが、設定の反映にOSの再起動が必要になるためエージェントの再起動よりハードルは高めと推測しております。
最後にOSのホスト名を変更した場合の挙動を確認しておきましょう。
OS再起動の設定
今回は下記の設定を使用しました。今回設定に使用した名称はnr-kensho-hostです。
また、OS設定を変更するにあたり、当記事で設定変更してきたInfrastructure agentの設定はすべて削除しております。また、設定項目ごとにホスト名を変更している理由は、変更したホスト名がどのように影響しているかを確認することが目的ですので、無いとは思いますが通常の運用で設定項目ごとにホスト名を変更するようなことはオススメいたしません。
hostnamectl set-hostname <ホスト名>
状況確認
設定変更後にOS再起動を行い状況の確認をおこないました。
まずホスト一覧の画面を確認すると、OSに設定したホスト名が表示されている状況が確認できました。
次に metrics & event のイベント情報ですが、こちらも、entityName、fullHostname、hostnameでOSのホスト名の情報が表示されていることが確認できました。 予想通りOS側でちゃんとホスト名を指定していれば、そのホスト名が管理画面上に表示されるのは間違いないため一番確実なのはOSのホスト名をちゃんと設定しようねということだと考えられます。
まとめ
Infrastructure agentの設定が実際のNew Relicの管理画面上ではどの部分に影響するかという観点で調査を行った結果を記事にまとめてみました。 今回の記事に取り上げたホスト名設定以外にもいろいろ設定項目があり、例えばコスト削減に有効な設定だったり、ログ出力関係の設定だったり、インスタンスのグループをまとめて管理するような設定だったり、様々なことができますので、ご興味がある方は公式ドキュメントをご確認いただければと思います。
当記事がどなたかのお役に立てれば幸いでございます。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
