Mackerelで始めるITインフラ監視

ITインフラ プログラミング

Mackerelで始めるITインフラ監視

Webアプリエンジニア養成読本 Advent Calendar 2014 8日目の記事です。

今日は、本に書ききれなかった内容についてです。

僕はWebアプリエンジニア養成読本(以下 先のムック)にてITインフラの構築(3章)・運用(4章)を担当しました。この中で、監視方針と閾値設計について説明したのですが、紙面の都合で監視サーバ・システムの構築にはあまり触れることはできませんでした。そこで、今回は実際に監視システムの構築について、「なぜ Mackerel か」「Mackerel 設定の流れ」そして「設定が終わったら」にまとめてお話しします。

お手許に先のムックがある方は、ぜひご用意ください。本の内容に沿って説明します。

なお、執筆時点での状況を記します。今後、状況が変わる場合がある事を念頭にご覧下さい。また、OSはRHEL, CentOS 6系である事を前提とします。

2015/01/10追記: Mackerel にディスク容量を割合で監視する機能が追加されたため(「ファイルシステムの使用率による監視ができるようになりました・mackerel-agent v0.14を公開しました・ほか – Mackerel ブログ #mackerelio」参照)、それに合わせて内容を変更しました。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

posted with ヨメレバ
和田 裕介,石田 絢一 (uzulla),すがわら まさのり,斎藤 祐一郎 技術評論社 2014-03-11

なぜ Mackerel か

一言で言えば、手軽に構築できるからです。

先のムックでは、主に自力で監視サーバを構築して運用する方法を紹介しました。しかし、この方法には「監視サーバ自体を構築・運用する」手間が発生します。監視の重要性は理解できたとしても、数台〜数十台のためにこれをやるのは、とてもコストがかかります。

そこで、今回はMackerelを利用して監視を行えるよう設定してみます。Mackerelとは、はてなさんが今年開始したサーバメトリクス収集、監視を行うサービスです。このブログを書いている今現在も、成長を続けています。

僕が考える、Mackerelの特徴は次の通りです。

  1. 監視サーバ自体の構築・運用が不要
  2. Push型のため監視システム側から直接参照できなくても良い
  3. 外部システムに通知が飛ばせる

1は、外部サービスを使う最大のメリットになるかと思います。

2は、エージェントがMackerelのシステムにアクセスさえできれば利用できるため、比較的少ない手間で構築できる事です。従って、ほとんどの場合はNATの裏側にいても、Mackerelのために踏み台サーバやルーターの設定を変えずに利用できます。

3は、ご自身で普段利用しているHipChatやSlack等のチャットルームに通知を飛ばしたり、WebHook を使って障害発生時に別のプログラムにハンドリングさせられやすい機能が整っている事です。ChatOps を積極導入されている方にとっては福音でしょう。

また、いくつか存在する類似サービスの中でも日本語が扱える点が良いと考えられる方もいらっしゃるはずです。これは、Mackerelははてなさんという、日本企業で、かつ大規模なWebサービスを提供している企業が提供しているからこそでしょうね。

ただ、もう少しがんばって欲しいなーという事があります。Mackerel は、現時点では外形監視ができません。従って、この部分だけは別途サービスを契約するなどの監視体制を構築する必要があります。なお、今回はこの点については説明しません。

Mackerel 設定の流れ

はじめに

今回は、Mackerel を使って、CentOS 6上で動作しているApache, MySQLの監視を実施してみます。Mackerelは標準ではホストのメトリックのみの取得なのですが、プラグインを導入するとカスタムメトリックとして様々なミドルウェアのメトリックを収集する事ができます。

あらかじめ、先のムック 3章に記載したPHPに関する構築を全て終えてください。このサーバはグローバルIPを付与して公開する必要は無く、手元のコンピュータ上で動くVM上で構築しても問題ありません。また、本をお持ちでない方は、CentOS 6.6上にApache, MySQLが動く環境を構築してください。

アカウント開設〜エージェントの導入

Mackerelのアカウントお持ちでない方は、開設をお願いします。執筆現在、Free(無料)プランで5ホストまで利用する事ができます。

続いて、エージェントをインストールします。Mackerel公式サイトのヘルプにある「エージェントをインストールする – Mackerel ヘルプ」をご覧頂き、インストールを行ってください。エージェントのインストールは5分もあれば終わります。

その後、Mackerelの管理画面から、エージェントをインストールしたサーバのメトリックが取得できている事を確認します。

Mackerel_metric

サーバ側の設定

このあとに説明するプラグインを利用するための設定を行います。操作はroot権限で実施します。

Apacheは、次の通り設定を追記してください。

vim /etc/httpd/conf.d/monitor.conf   # 以下を記述
---
ExtendedStatus On

Listen 127.0.0.1:1080
<VirtualHost 127.0.0.1:1080>
    <Location /server-status>
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1 ::1
        SetHandler server-status
    </Location>
</VirtualHost>
---
semanage port -a -t http_port_t -p tcp 1080   # selinux有効時のみ実行
semanage port -l | grep -w http_port_t   # selinux有効時のみ 1080番が追加されている事を確認
service httpd configtest   # エラーがでない事を確認
service httpd graceful
ps auxwwf | grep httpd   # プロセスが起動している事を確認
ss -lntp | grep 1080   # 1080番がhttpdにListenされている事を確認
curl http://127.0.0.1:1080/server-status?auto   # エラーがでなければOK

MySQLには、プラグイン用のユーザを作成します。作成は必須ではありませんが、できればアプリケーションで使っているユーザ名とは別にすると良いでしょう。

GRANT SUPER, PROCESS ON *.* TO '(任意のユーザ名)'@'localhost' IDENTIFIED BY "(任意のパスワード)";

プラグインのインストール

Mackerelのプラグインをインストールしましょう。

yum install mackerel-agent-plugins
/usr/local/bin/mackerel-plugin-linux ---help   # 動作確認 - ヘルプがでればOK
/usr/local/bin/mackerel-plugin-apache2 ---help   # 動作確認 - ヘルプがでればOK
/usr/local/bin/mackerel-plugin-mysql ---help   # 動作確認 - ヘルプがでればOK
vim /etc/mackerel-agent/mackerel-agent.conf   # 以下の通り編集
service mackerel-agent restart 
less /var/log/mackerel-agent.log   # エラーが無い事を確認

mackerel-agent.conf

# mackerel-agent.conf: 以下を追記
[plugin.metrics.linux]
command = "/usr/local/bin/mackerel-plugin-linux"
type = "metric"

[plugin.metrics.apache2]
command = "/usr/local/bin/mackerel-plugin-apache2 -p 1080"
type = "metric"

[plugin.metrics.mysql]
command = "/usr/local/bin/mackerel-plugin-mysql --username='(MySQLサーバのユーザ名)' --password='(MySQLサーバのパスワード)'
type = "metric"

正常に設定が完了すると、数分後にカスタムメトリックの表示が始まります。Apache, Linux, MySQLで始まるものが表示されていればOKです。確認の際、1時間間隔にすると見やすくなりますので、あわせて試してみてください。

Mackerel_custom_metric

監視閾値の設定

いよいよ監視設定です。先のムックでは、P.126 表1「監視項目の設定例」に9つの例を示しました。この中で、外形監視以外の設定を進めましょう。

まず、左のメニューから「Monitors」をクリックします。

Mackerel_menu_monitors

Monitorsのページが表示されたら、右上の「監視ルールの追加」ボタンをクリックします。

Mackerel_add_rule

監視ルールの設定ページが表示されます。ここで、監視閾値を登録します。Mackerelで監視可能な項目について、先のムック P.126 表1の内容に従って入力した場合、次の通りとなります。「監視ルール名」は自由につけられますので、変更していただいて構いません。

No. 監視対象のメトリック 監視ルール名 Warning Critical
1 custom.apache2.workers.idle_workers Apache プロセス数 減少 < 5 < 1
2 custom.mysql.threads.Threads_running MySQL プロセス数減少 < 1 < 1
3 custom.mysql.threads.Threads_connected MySQL ログイン数過多 > 35 > 45
4 CPU % CPU 過負荷 > 90 > 98
5 loadavg5 Load Avarage 過上昇 > 4 > 10
6 Swap % Swapメモリ 使用量上昇 > 50 > 75
7 filesystem.vda1.used ディスク使用量過多 > 70% > 90%
8 (サーバ死活) connectivity デフォルトで監視

項目番号毎に補足します。

1は、当初のApache自身のプロセスを確認する方法とはちょっと変わっています。監視の目的であったApacheのプロセスが動作しているかを確認するために、代替処置としてApache自身がリクエストを受けられる状況かを確認するようにしました。

3は、1の事情に近いのですが、当初とは違い接続可能かを確認する方法とは変わっています。監視の目的である接続可能かを確認する代替処置として、max_connections=50のサーバに対して、接続数上限に至っていない事(70%, 90%)を確認する形に変更しました。

5は、監視対象のサーバが2vCPUであるためです。詳細な説明は先のムックに譲りますが、Warningは論理コア数×2、Criticalは論理コア数×5として割り出してみてください。

7は、Mackerelは絶対値で監視(※1)するため、100GBのディスクに対する割合を計算して代入しました。また、デバイス名がvda1となっていますが、ここはご自身の環境によって変更をお願いします。(2015/01/10追記)2015年1月初旬から割合をもとに監視することができるようになりました。

Mackerelは、Freeプランだと10個まで監視項目を設定できます。

なお、僕の現在の監視設定は、次の通りです。ご自身の設定結果と照らし合わせてみてください。

Mackerel_monitors

通知設定

最後に、障害発生時の通知設定を行いましょう。

まず、左のメニューから「Monitors」をクリックします。

Mackerel_menu_monitors

Monitorsのページが表示されたら、右上の「通知チャンネル」ボタンをクリックします。

Mackerel_add_channel

Channelsのページが表示されます。「チャンネルを追加」をクリックして、通知先を登録してください。SlackやHipChat(※2)等で表示できるか試してみるのもいいでしょう。なお、僕は現在メール通知のみ行っています。

Mackerel_channels

設定が終わったら

監視は、設定後からが本番です。以下の3点を確認してみましょう。

  1. 通知が飛ぶかを確認する
  2. 誤報があれば閾値を調整する
  3. 更なる監視項目を検討する

1は、動作確認です。登録した監視項目のどれか1つについて、意図的に警告を出してみてください。最も簡単な方法は、メトリック取得が一時的に止まる事を許容できるなら、Mackerel Agentを停止させる事です。

2は、1週間から1ヶ月程度の間に誤報が頻発するようであれば、閾値を見直すか、「条件の持続時間」を見直してみてください。通知が狼少年状態になると、通知自体を自然と無視してしまう癖がついてしまい、本当に障害が発生した時に気づけなくなります。

3は、より詳細に障害発生を捉えられるように検討してみるのはどうでしょうか。Freeプランでも、監視項目をあと数個設定できます。監視項目の設計の良い訓練になるかと思います。

まとめ

ここまで、Mackerel を利用しITインフラの監視をはじめる方法を、「なぜ Mackerel か」「Mackerel 設定の流れ」そして「設定が終わったら」の3点に分けてお話ししました。

Mackerel を利用すると、サーバの監視がとてもあっさりできてよいなーと僕は思います。サーバ毎に設定をいじる事もあまりありませんし、奥まった所で操作しづらい事もありません。ただ、閾値を何に設定すればいいのか？がピンと来ずに設定を見送っていた方がもしいたら、この機会にお試しいただければと思います。

あっ、著者をはじめ1981年生まれの人が幹事をやる「ハチイチ忘年会」ってのを2014/12/13(土)にやります。IT, Web関連の方でしたら、老若男女どなたでもWelcomeです！ぜひいらしてください。

また、Webアプリエンジニア養成読本 Advent Calendar 2014では読者の皆様からの感想・実践エントリも大募集中です！ふるってご参加ください！！！

それでは皆様、ごきげんよう。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

posted with ヨメレバ
和田 裕介,石田 絢一 (uzulla),すがわら まさのり,斎藤 祐一郎 技術評論社 2014-03-11

参考文献

※1: ディスク使用量は、相対値も監視できたらいいなと思いました。違う容量のものが並んでも汎用的に使えますしね。

※2: HipChatのエンドポイントは固定です。ご自身でHipChatサーバを立ち上げている場合は、WebHook経由でHubot等に飛ばして表示できるようにしてください。

このエントリーをはてなブックマークに追加
LINEで送る
Pocket