COLUMN

クラウドの運用にMackerelを使ってみた(第2回：サービス・ロールの設定～通知設定)

「クラウド導入・運用サービス」のサービス企画担当のとりとりです。
前回は、Mackerelのアカウントを登録し、監視対象のホストにエージェントをインストールするところまでやりました。
今回は、エージェントをインストールしたホストのサービス・ロール等の設定、通知設定を行います。

• 第1回：アカウント開設～インストール(前回)
• 第2回：サービス・ロールの設定～通知設定(今回)
• 第3回：プロセスやログ等の詳細監視設定
• 第4回：ネットワーク死活監視設定
• 第5回：AWS/Azureインテグレーション機能を使ってみる
• 第6回：今度こそAzureインテグレーション機能を使ってみる

構成図・やりたいこと

構成図

アプリケーションサーバー（以降、APサーバー）とデータベースサーバー（以降、DBサーバー）がAWS上に各1台ずつある構成とします。各サーバーの初期設定及び、Mackerelエージェントのインストールは完了しているものとします。

各サーバーのスペック

インスタンス：t2.micro(1vCPU,メモリ：1GiB)
OS：Amazon linux2
ディスクサイズ：8GiB

やりたいこと

それぞれのサーバーは役割が違うので、役割ごとに監視項目及びしきい値を設定したい

• APサーバー：CPU利用率
• DBサーバー：メモリ利用率、ディスク容量

しきい値を超過したら、メールで自動通知されるようにしたい

上記やりたいことを実現するために、Mackerelの設定を行います。

サービス・ロールの設定

Mackerelでは、各サーバーやPaaSをサービスやロールといったグループでまとめて、監視や管理を行います。各用語の定義は以下のようになります。

サービス

Mackerelにおいて、サービスとはホストを運用する上でもっとも大きな単位です（例: 「はてなブックマーク」「社内システム（勤怠管理）」など）。通常、複数のホストがそれぞれの「役割」（→ ロール）を担当し、協調しあってひとつのサービスを形づくります。関係しあうホストをひとつのサービスに属するものとしてまとめることで、ホストの管理・監視が容易になります。

ロール

ロールはサービスに所属するホストをさらにその「役割」（アプリケーション、データベース、etc…）によって分類する概念です。Mackerelではホストの状況をロールごとにまとめて可視化できます。

Mackerel用語集より引用

したがって、今回サービスとロールは以下のように設定します。

ロール名①：AP

所属させるサーバー：APサーバー

ロール名②：DB

所属させるサーバー：DBサーバー

サービス名：NTTeast-Column
所属させるロール：AP、DB

具体的にやっていきましょう。エージェントのインストール完了後は、このような状態になっていると思いますので、Servicesをクリックして、サービスの設定画面に移ります。

まだ何もサービスはありませんので、サービス追加を行います。

すると、サービス名を入力する画面になりますので、サービス名を入力して作成します。

Servicesの下部に「NTTeast-Cloumn」というサービス名のリンクが追加されるので、クリックします。まだこの時点ではロールが作成されていないので、ロールを作成します。

APロールとDBロールを作成します。

ロールを作成すると、グラフの欄が追加されますが、まだロールにホストが何も追加されていないので、Hostsページからロールを設定します。

中央にある「ロールを設定」を選択

ロールの設定が完了すると、各ホストがどのロールに所属しているかわかるようになります。

これでロールの設定が完了しました。

監視ルール・通知設定

ロールの設定が完了しただけでは、まだ監視ルールや通知先の設定が完了していませんので、これらの設定を行います。

監視ルール設定

ここでは、監視項目やしきい値等の設定を行います。左側のMonitorsを開き、監視ルール設定を行います。

初期設定では、Connectivityという項目の設定のみがされています。これは、エージェントからのデータ送信を監視しているものとなります。
(https://mackerel.io/ja/docs/entry/faq/monitoring/how-work-connectivity-monitoring)

今回は、CPU利用率、メモリ利用率及びディスク容量の監視と通知設定を行いたいので、左上の「監視ルールを追加」を選択します。

CPU利用率、メモリ利用率、ディスク容量はホストメトリックとなりますので、「ホストメトリック監視」を選択します。

監視内容、しきい値、アラート発生までの回数を設定します。

続けて、先程設定した監視内容やしきい値をどのサービス・ロールに設定するか選択します。今回はCPU利用率の設定なので、APロールに設定します。すべての設定が終わったら、下の作成ボタンを選択します。

同様に、メモリ利用率やディスク容量の設定を行います。

通知設定

監視ルール設定が終わったら、次に通知先の設定を行います。左のChannelsページを選択します。
デフォルト設定では、すべての通知をオーガニゼーションに登録したすべてのメールアドレスに対して通知する設定になっています。今回は、一部のユーザのみにアラート通知を行う設定を行います。

右上の「通知グループ／通知チャンネルを追加」を選択します。

次に、通知先となるツールを選択します。SlackやLINEなどのメッセージアプリやコミュニケーションツールも利用可能ですが、今回はメール通知にしたいと思います。

チャンネル名と、通知先のメールアドレスを指定し、作成ボタンを選択します。

通知対象となる監視ルールを設定するため、通知グループを設定します。先程と同じく、右上の「通知グループ／通知チャンネルを追加」を選択します。

「通知グループ」を選択します。

通知グループ名を入力し、通知対象及び通知先を選択し、作成ボタンを選択します。

作成後は以下のようになります。デフォルト設定については、無効の設定にしてあります。

これで通知先の設定まで完了しました。

通知試験

設定が完了したら、意図したアラートが通知されるかの試験を行います。CPU利用率の試験を行ってみます。
CPU利用率の監視はAPサーバーのみ設定しているので、APサーバーのアラート通知だけがされていれば成功です。

CPU利用率を上げるコマンドは、以下となります。

yes >> dev/null &

これをAPサーバーとDBサーバーの両方に入力します。しばらくすると、このようにCPU利用率が100%となります。

すると、アラート通知メールを受信しています。

Mackerelのサイトに戻ると、APサーバーのみアラートが「In Progress」(継続中)となっていることがわかります。

アラート通知の項目を選択すると、アラート履歴等、詳しい状況が確認できます。

アラート通知ができたことがわかったので、先程のCPU利用率を上げるコマンドを終了させます。
終了させるコマンドは以下となります。

kill $(pgrep –f ‘yes’)

すると、CPU利用率が下がっていきます。

CPU利用率が下がると、アラートは自動で「closed」になります。

アラート終了の通知もメールで届きます。

これで通知設定まで完了しました！

まとめ・次回予告

今回は、取得したメトリックのアラート通知を確認するところまで行ないました。複数のツールへの通知設定もあり、きめ細やかな監視ルールや通知設定を視覚的に行えると感じました。
次回は、プロセスやログ監視など、詳細設定を行っていきます。お楽しみに！