Mackerelのmackerel-agent設定とウェブ画面の設定優先度を確認した #mackerelio

監視サービス

#Mackerel

#監視サービス

吉江健斗

2019.10.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんばんわ、札幌のヨシエです。
ふとMackerelを運用する立場になって、mackerel-agentの設定情報とウェブ画面の設定情報が食い違った場合を想定してどのような現象が起こるのか気になったので調べました。

具体的にどういうことか？

mackerel-agent監視を行っているEC2監視で、「監視対象の表示名」や「サービス/ロール」はmackerel-agent.conf(以降、コンフィグと記載)とウェブ画面上のどちらでも設定が可能です。
このような場面でコンフィグとウェブ画面の設定が食い違うとどちらの設定が優先されるのか気になりました。

例1：ホスト名の食い違い

Mackerelでは、以下の図のようにウェブ画面から表示名(管理名)を変更できます。

また、コンフィグではdisplay_name = "<name>"を記述することで表示名を入れることが可能です。

[ec2-user@ip-10-0-1-207 ~]$ cat /etc/mackerel-agent/mackerel-agent.conf
apikey = "xxx"
display_name = "test-api" ★ココに記載

例2：サービス/ロールの食い違い

例1と同じように監視対象のサービス/ロールを変更することが可能です。

コンフィグでは以下のように記述が可能です。

[ec2-user@ip-10-0-1-207 ~]$ cat /etc/mackerel-agent/mackerel-agent.conf
apikey = "xxx"
display_name = "test-api"

roles = [ "00_DevIO:00_DevIO_Sapporo"] ★ココに記載

確認内容について

前提として以下のような状態を想定してみます。

運用チームは「00_DevIO」というサービスに「00_DevIO_Sapporo」と「01_DevIO_Tokyo」というロールが存在するとします。
※これはテストであり、検証以外では勧めないサービス/ロール構成です。

ここから以下のパターンを確認してみます。

パターン①:ホスト名の変更

「00_DevIO_Sapporo」というロールに存在するtest-xxというホストの表示名をprod-xxという名前に変更するとします。

ウェブ画面からprod-apiに表示名を変更して、mackerel-agentサービスを再起動します。

[root@ip-10-0-1-207 ~]# more /etc/mackerel-agent/mackerel-agent.conf
apikey = "xxx"
display_name = "test-api"

[root@ip-10-0-1-207 ~]# systemctl restart mackerel-agent.service

結果：コンフィグに記載されているホスト名であるtest-apiに戻りました

パターン②：サービス/ロールの変更

ウェブ画面で11_DevIO_reGrowth_Tokyoのロールを作成し、対象ホストを変更します。
その後、mackerel-agentの再起動を行います。

[root@ip-10-0-1-207 ~]# cat /etc/mackerel-agent/mackerel-agent.conf
apikey = "xxx"
display_name = "test-api"
roles = [ "00_DevIO:01_DevIO_Tokyo"]

結果：監視対象が所属するロールに01_DevIO_Tokyoが追加されて、マルチロール構成になりました。

結果を踏まえての考え

当初の予想では全てコンフィグで記述されている設定に置き換わると思いましたが、ロール部分で別ロールに所属する結果は外れました。
この予想の根拠はmackerel-agent仕様から複数ロールを指定していなかったことから11_DevIO_reGrowth_Tokyoのみに変更されると考えておりました。

この結果から組織改編によって、運用者が変わった後に引き継ぎ作業から設定の管理方法が漏れていると、ウェブ画面上の設定変更後にインスタンス再起動等が発生することによるmackerel-agent再起動が実行された際に混乱を招く可能性を考えました。

基本的にはコンフィグの記述が優先されるとして考える点は問題ないかと思いますが、事前の運用検証は考慮に入れるべきと考えます。
反面コンフィグ管理を行った際に複数インスタンスを運用している環境では管理が難しくなるため、mackerel-container-agentのように HTTP/HTTPSやS3を参照するような設定が可能になると嬉しいと思いますが、現在は対応していないと見受けられるのでEC2インスタンス起動時にuserdataを使用してS3からコンフィグファイルをコピーする形がトラブルを回避する一つの方法と思いました。