この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
梅雨入りの湿気、嫌ですね。ただでさえ癖毛で困っているのに遂に諦めの境地に至るくらい毎日が酷いです。
こんにちは、AWS事業本部の癖毛が酷いShirotaです。ここ最近も雨量と湿気が多く、毛量が魍魎でもう相当大変です。
▲ 髪の毛のイメージ図。これに癖が加わるので無敵です。早くスッキリさせて色も変えたい……
複数の監視サービスが共存する環境で気になる事
さて、今日は Mackerel の話をしたいと思います。
Mackerel、使っていますか？個人的には、監視の初期準備が簡単に出来て使い易いサービスだなぁと思います。ただ、複数の監視ツールを導入している環境だと、若干気を遣う事が増えるのではないでしょうか。
例えば、今回はこんな環境を想定してみました。
- 現在は複数の監視ツールが混在している
- リソース毎に監視ツールを分ける必要がある
- いずれはMackerelに監視を一元化させる予定
上記二つの条件を満たす為にこちらで出来る事と言えば、タグ付けで明示的に監視するリソースを宣言してあげる事です。やり方については、Mackerelの公式ヘルプや弊社市田のブログに分かりやすく記載されているのでそちらを参考にして下さい。
AWSインテグレーション
MackerelのAWSインテグレーションで簡単にインスタンスを監視してみた
ただ、いずれはMackerelに監視を一元化させたいから、監視に関しては同じタグを使用したい！という事もあるかもしれません。
その際、Mackerelには 退役 という、登録したホストをMackerelの監視対象から外せる機能が存在します。
今回はこの 退役 を利用して、一時的にホストを監視対象から外した後に、再度Mackerelに登録するまでをやってみたいと思います。
Mackerelに登録したホストを退役させてから再登録させるまで
さて、実際にホストを退役させてから再登録を実施してみました。流れとしては、
- Mackerelでホストを退役させる
- ホストのエージェントを停止/削除する
- ホストのエージェントを起動/再インストールして退役させたホストをMackerelで再登録する
と至極シンプル極まりないものなのですが、この
3.ホストのエージェントを起動/再インストールして退役させたホストをMackerelで再登録する
でMackerelエージェントを起動/再インストールするだけでは実は上手くいきません。
その理由も以下で説明しつつやっていきたいと思います。
今回は、Amazon Linux2のEC2インスタンスにMackerelエージェントを入れて監視の設定をしました。
Mackerelからホストを退役させる
「Host」カラムから退役したいホストのホスト名をクリックすると、ホストの詳細や監視しているメトリックのグラフが見られるページに辿り着きます。
すると、ホスト名の横に設定へのリンクがあります。
▲ 右上の設定をクリックします
設定画面が開くと、右下に「このホストを退役させる」というボタンがあります。
▲ ここをクリック！ターンエンドだ！
退役自体は、これで完了です。ホスト一覧に戻ると、既に退役させたホストは表示されなくなり、メトリックの取得も少し経ってからされなくなります。
▲ 退役させたホストは「退役ホストをみる」から確認する事が出来ます
最後に、ホスト側にインストールしたエージェントを停止/削除して下さい。
退役時に注意する事
Mackerelエージェントは、初回起動時に「id」ファイルを生成します。
(Amazon Linux2では /var/lib/mackerel-agent 配下に生成されます。KDDIクラウドプラットフォームサービスでは /var/lib/mackerel-agent-kcps 配下に、Windows Serverの場合はインストールフォルダ内に生成されます)
[ec2-user@ip-XXX-XXX-XXX-XXX ~]$ ls -la /var/lib/mackerel-agent/
合計 8
drwxr-xr-x 2 root root 16 6月 10 05:41 .
drwxr-xr-x 32 root root 4096 6月 10 04:42 ..
-rw-r--r-- 1 root root 11 6月 10 05:41 ididファイルの中身は一意のホストIDが記載されてます。
Mackerelは、基本的に 一度退役したホスト情報を元に戻すという事が出来ません 。そしてホストIDでホストを認識しているので、 このファイルが残り続けていると次の「ホストをMackerelに再登録する」の作業が上手くいきません 。
また、序盤に記載したようにMackerelエージェントは初回起動時にidファイルを生成します。
ですので、退役したホストを再登録する際にはMackerelを再起動/インストールする前に idファイルを削除しておく必要があります 。
ホストをMackerelに再登録する
idファイルを削除して、Mackerelエージェントが残っていたら再起動、Mackerelエージェントを削除してしまっていたらインストールします。
今回、もし退役したホストに対して「idファイル削除したっけ？Mackerelエージェントは残っていた？」と分からなくなってしまった時にホストをMackerelに再登録する為の簡単なシェルスクリプトを作成してみました。
#!/bin/bash
if [ -f /var/lib/mackerel-agent/id ]; then
rm /var/lib/mackerel-agent/id # idファイルが残っていたら削除する
fi
if [ -f /usr/lib/systemd/system/mackerel-agent.service ]; then
systemctl start mackerel-agent.service # Mackerelエージェントがあったら再起動する
else
curl -fsSL https://mackerel.io/file/script/amznlinux/setup-all-yum-v2.sh | MACKEREL_APIKEY='HOGEHOGE' sh # エージェントがなかったらセットアップし直す(要APIキー記入)
fi実際にやってみて、再度ホストが再登録される事と再生成されたidファイル内のホストIDが前回と異なるIDになっている事が確認出来ました。
再登録した際の留意点
一意のホストIDでホストを認識していると前述したように、再登録した際は別ホストとして認識されます。なので、監視で取得していたメトリクスを 引き継ぐ事は出来ません 。
▲ 退役させたホスト
▲ 再登録したホスト
また、退役させたホストのメトリックは 一定期間経過後非表示となる 為、データが欲しい場合は退役前に取得しておきましょう。
idファイルの特性だけ意識して退役・再登録をしよう！
実際に手を動かしてみて、Mackerelではホストを簡単に退役させる事は出来るのですが、再登録にはひと作業必要になる事が分かりました。
基本的に、複数の監視ツールが共存する環境などの監視リソースを区別する必要のある環境ではタグ分けをして監視する事をオススメします。
ですが、どうしても同じタグを使う必要があったりする場合にはホストを一時的に退役させて、Mackerelにいずれ統合する際に再登録する時には上記のように作業する必要が発生します。
また、idファイルの特性上メトリクスを引き継ぐ事は出来ない為、そこに留意して監視の引き継ぎ等を行うようにして下さい。
▲ 検証の為に生まれた退役ホストの墓場を載せて、今日はお別れです
5
