こんにちは！インフラエンジニアの木村奈美です。
今回は、フェンリルのとあるプロジェクトで利用している監視ツール Mackerel（マカレル） をご紹介します。 前編では選定理由と導入方法、後編ではプロジェクトの要件に合わせた応用的な監視を紹介していきます。
Mackerelとは
株式会社はてなが開発しているSaaS型サーバー監視サービスです。 監視対象のサーバーにエージェントをインストールするだけで監視を始められます。 グラフを表示したり監視ルールを設定したりといった監視サーバー相当の機能はWebサービスとして提供されており、自分で監視サーバーを構築する必要はありません。
詳しい製品紹介はMackerelの 公式サイト をご覧いただくのが分かりやすいかと思います。
選定理由
一言でいうと、Mackerelの監視機能および課金体系が、対象のプロジェクトのインフラ構成と相性が良かったためです。
入れ替わるインスタンスを監視しやすい
監視ツールでやりたかったことは、 Auto Scalingで入れ替わるEC2インスタンス1台1台に対する監視 です。 本プロジェクトの一部のサーバーは、Auto Scaling Groupの台数が増加するときに新しいインスタンスが起動し、台数が減少するときに古いものから消えるという、FIFO(First In First Out)のライフサイクルで稼働しています。
このように監視対象が不定であることから、外部からの監視は難しいと判断し、エージェントタイプの監視ツールから選ぶことにしました。
AWSを利用しているため、他の候補としてはCloudWatch Agentが挙がっていました。CloudWatch Agentでメトリクスを収集し、CloudWatchのアラームで監視するという方法です。 目的のメトリクスを収集するだけならそれでも十分だったのですが、入れ替わるEC2インスタンスを監視するのは難しいという課題がありました。 CloudWatchではアラームとメトリクスは1対1のため、グループの平均値は簡単に監視できますが、1台1台を個別に監視したい場合はインスタンスの数だけアラームを作成しなくてはなりません。 1日に何台も入れ替わるインスタンスに対して手作業で対応するのは現実的ではありませんし、自動化するのも一筋縄ではいきません。
Mackerelを使えば、この課題を簡単にクリアできます。 Mackerelでは、「ホスト（監視対象のサーバー）」を「サービス」と「ロール」という単位でグルーピングできます。サービスはプロジェクトや環境単位、ロールはWebサーバーやDBサーバーといった役割単位と考えるとイメージしやすいかと思います。 このグルーピングの便利な点は、特定のサービスやロールに属するホスト1台1台に対し、 1つの監視ルールを作るだけで一括で同じ監視ができる ことです。ホストの数だけ監視ルールを作成する必要はありません。 これは、まさに我々のやりたいことにマッチしていました。
課金体系がシンプルかつ良心的
課金体系についても、Auto Scaling Groupと相性が良い仕様となっています。
課金対象は 「監視したホスト台数」 これだけです。 そして、このホスト台数のカウント方法は 「1ヶ月分の平均」 です。 つまり、局所的に台数の増えた時間帯があったとしても、料金が極端に増えることはありません。 Auto Scaling Groupを使っていても安心して利用できるのが魅力の1つです。
導入手順
それでは、一通りの基本的な設定をご紹介します。
アカウント登録を済ませ、監視対象のサーバーにエージェントをインストールしていきます。 アカウント登録および初期設定については割愛します。
公式サイトの インストール手順 に沿って進めていきます。 今回の対象サーバーはAmazon Linuxのため、Amazon Linux用の手順を参照しています。
以下のコマンドは、すべて管理者権限を持つユーザで実行します。
Mackerelエージェントのインストール
インストールコマンドを実行します。 APIキーは、Mackerelにログインしてオーガニゼーションのページから確認できます。 公式ドキュメントにもある通り、このAPIキーは外部に漏らさないようご注意ください。
curl -fsSL https://mackerel.io/file/script/amznlinux/setup-all-yum-v2.sh | MACKEREL_APIKEY='<YOUR_API_KEY>' sh
設定ファイル作成
設定ファイル /etc/mackerel-agent/mackerel-agent.conf を編集します。
書式は mackerel-agent仕様 の「設定ファイル」を参照します。
apikey = "<YOUR_API_KEY>" # 特定のプロジェクトとロールに属するよう指定する roles = [ "prd_ProjectName:rolename" ] diagnostic = true [host_status] on_start = "working" # Auto Scaling における停止 = インスタンス終了 のため、 on_stop 設定は不要 # on_stop = "poweroff"
基本的な監視をするだけなら、これだけで十分です。ファイルシステム使用率やメモリ使用量といった基本のメトリックは、特に設定を書かずとも収集されます。
プラグインを利用する場合はここにいろいろ追記していくことになるのですが、そちらは後編にてご紹介します。
自動退役の有効化
Auto Scalingで終了したインスタンスを監視対象から外すよう、自動退役を有効化します。
Auto Scaling環境で使う を参考にし、 /etc/sysconfig/mackerel-agent に以下の設定を追記します。
AUTO_RETIREMENT=1
Mackerelエージェントの再読み込み
Mackerelエージェントを再読み込みして、これまでの設定を反映します。
systemctl reload mackerel-agent.service
Auto Scaling Groupの起動設定を作成
Auto Scaling Groupで新しいEC2インスタンスが起動した際、Mackerelエージェントがすでにインストールされた状態となるようにします。 MackerelエージェントをインストールしたEC2インスタンスを元にしてAMIと起動設定を作成し、Auto Scaling Groupに設定します。
ここで注意が必要なのが、 ホスト識別ファイル の存在です。
Mackerelがホストを識別するためのIDが記載されたファイルで、 /var/lib/mackerel-agent/id にあります。
複数のインスタンス間でこの内容が同じだと、同一ホストとしてMackerelに認識されてしまい、正常に監視ができません。
そのため、このファイルを退避または削除した状態でAMIと起動設定を作成する必要があります。
メトリックを確認してみる
ここまでの手順で基本的なメトリックの収集ができるようになっているため、確認してみましょう。
以下の例はサービスのページです。サービスに属するホストのメトリックを並べて確認できます。
ホスト名をクリックすると、ホストの詳細ページに遷移し、ホストメトリックを全て確認できます。
監視ルールを作成
では、メトリックの収集ができるようになったところで、監視ルールを作成していきます。
監視の種類は複数ありますが、ここでは「ホストメトリック監視」をご紹介します。 冒頭で説明した、特定のサービスやロールに属するホスト1台1台を監視するルールです。
以下の例は、特定のロールに属するホストに対して、ファイルシステム使用率を監視する設定です。 70%を超えるとWarning、90%を超えるとCriticalとして扱われます。1つの監視設定で2つのアラートレベルを設定できるのが嬉しいですね。 これらのアラートレベルは、後の通知設定にてアラートレベルに応じた挙動をさせるのに役立ちます。
通知先を設定
Mackerelの通知は多くのサービスに対応していますが、ここでは例としてSlackに通知する手順をご紹介します。 通知の宛先を設定する「通知チャンネル」と、通知の条件を設定する「通知グループ」を作成します。
通知チャンネルを作成
Slackをターゲットとする通知チャンネルを作成します。
- URL: Incoming Webhook URLを入力します。
- Mentions: OK、Warning、Criticalのそれぞれのアラートレベルにおいて、添えるテキストを指定できます。ここでは、Criticalの場合のみメンション
@hereを付けるようにしています。 - 関連するグラフを表示: Slackの投稿にグラフを表示するかどうか選択します。
通知グループを作成
「何を」「どこに」通知するかを指定する通知グループを作成します。
最初からデフォルトの通知グループが存在していますが、デフォルトの通知グループはすべてのサービスについて通知するため、そのままでは全ての通知が一緒くたに通知されてしまいます。 サービスが1つだけならそれでも問題ないかもしれませんが、必要な通知を必要な宛先に飛ばせるよう、新しい通知グループを作成するのがおすすめです。
- 通知対象: 通知したいサービスまたは監視ルールを設定します。
- 通知先: 手順1で作成した通知チャンネルを選択します。
- 通知レベル: アラートレベルCriticalのみを通知するかどうか選択します。
これでアラートがSlackに通知されるようになりました🎉
以上、ごく一部分ではありますがMackerelの特徴と一通りの導入手順をご紹介しました。 導入のしやすさ、扱いやすさが伝わりますと幸いです。
後編では、プラグインを利用した応用的な監視についてご紹介します！
