Mackerelに触れる前にサーバー監視について考えてみよう from gu4
おもに横浜に関わる(テーマに関心があれば横浜に縁がない人も大歓迎)、ふつうのソフトウェアエンジニアを対象とした勉強会「横浜クラウド勉強会」第九回を開催しました。今回のテーマは監視サービスmackerelです。
第九回「Mackerelを使ってサーバーのモニタリングをしてクラウド時代の運用を体感してみよう！」
https://ykcloud.doorkeeper.jp/events/27668
開催にあたって
今回のテーマして監視サービスmackerelは最近話題になっていて気になっていました。クラウド時代に監視を自身で構築し、メンテナンスしていくという面でみると色々な事を配慮しないといけなく、簡単なことではありません。
SaaSとして監視サービスを使えれば運用コスト（手間と時間と、もしかしたら費用）を大幅に下げる事が可能になるかもしれません。
そういう事を考えている中で、Mackerelはとっつきやすく必要な機能は備えていてUIも優れているとのことで、まだ使った事ないユーザが使うとどうなるのか？というのを自身のテーマとして勉強会開催に踏み切りました。
当時の主な進行構成
主に3部構成です。
- なぜ監視をするのか？
- Mackerelについて
- ハンズオン
参加者は監視について深く関わった事がなかったり、イメージが異なる可能性もありました。また、時代によって監視のやり方や流れや主流もあり、ツールも溢れていますので順を追って話をし、最後にクラウド時代のサービスに話しを繋げました。
次に、Mackerelについて。公式サイトの説明やヘルプがとてもわかりやすく、ほぼ引用させて頂き紹介をしました。
最後にハンズオン。私を含めまったく触った事ない人が使ってみてどう感じるのか？そこに焦点をあててやってみました。
当日の様子と所感
当日開始直前にわかったことですが、mackerelを作っているはてなの中の方が参加者の一人としてエントリーされていることを知りました。参加者は10名。
既にAWSを使っていてそれなりの台数で運用されており、AWS Cloud Watchを利用しているのと比べてなにがうれしいの？など質問が飛び交います。そして、zabbixなどと比べて何がいいの？と。私なりに考えて答えた事。そして、はてなの方が質問に答えてくださった事など、わかった事にまとめておきたいと思います。
サーバーはAWSでt2.microインスタンスを10台用意し、一人につき一つのサーバーを使ってもらいました。*1
ハンズオン
- サインアップ
- エージェントインストール
- 負荷をかけて監視確認
- 通知先をチャットを加えDevOpsについて言及
- Qiitaのmackerelタグを写経
ハンズオンはgetting-startedを足がかりに進めていきましたが、サインアップ後のホーム画面にわかりやすいナビゲートがあり、ユーザの事をよく考えているなぁと感心しました。
エージェントインストールは、手順に従えばまず迷わずインストールできました。予想以上にハマらない。
そして、負荷をかけての監視確認。stressコマンド使って以下のように負荷をかけ、htopコマンドは負荷状況をわかりやすく確認する為にインストールし利用しました。
$sudo apt-get install stress $sudo apt-get install htop # CPUの負荷を指定した数のプロセスでかける $stress --cpu 4 # メモリを消費する $stress -m 1 --vm-bytes 512M # ディスクに負荷をかける $stress --hdd 1
Monitorsメニューで監視ルールを増やす事でCPUやメモリなど閾値を設定し監視項目を追加できました。そして、
アラートは時系列になにがいつ起きたのかというが状態の推移が視覚的にわかります。通知のタイミングも期待通り。
ハンズオンの進行でiPadに通知されstressコマンドで叩きまくった結果を体感できました！もちろん、通知が止まらないという事はありませんでした。自身でアラートを処理という流れもわかりやすく使いやすかったです。
アラート通知の画面
通知先の追加も設定しやすくチャットサービス（typetalk）への通知もできました！ドキュメントをしっかり読まなかった部分で躓きはありましたがうまくできました。
チャットサービスへの通知画面
所感を総括
その他、進めている時に中の方から色々とアドバイスや助言など頂きとても参考になり、有意義な時間を過ごす事ができました。
一日をとおして感じた事としては、ポテンシャルが高いので実際に仕事のプロジェクトや会社で適用できる所を見つけて使いたくなったというのは言うまでもありません！
わかったこと
- mackerelはうわさ通りとても使いやすくわかりやすいサービスであった
- メトリクスを測定する為のagent-pluginもパッケージ管理で簡単にインストールできる
- 監視するのは基本的にエージェントが入っているサーバーを監視する
- サーバー間で監視対象に繋がるかどうかなど（例えばSecurityGroupなどの設定が正常か）の確認はデプロイ前にServerSpecなどを使おう。テスト層とは別と考える。
- 公開されているアドレスに対して監視する機能（External Http）があるよ！（uptimer.atのような）
- これは現時点では実験的機能
- ミドルウェアはチェックスクリプトという仕組みを使って監視できる
- 料金面でクラウドがオートスケールした時に最大数のカウントの仕方はどうなっているの？
- 月平均でならしてカウントしています。なので、オートスケールで一時的（例えば週末のみサーバーが増えるなど）に増えた場合も請求としてEC2請求代にほぼ比例する形になります。
- 料金面でサーバーのカウントで仮想コンテナの扱いはどうなの？
- 現在は1サーバーとしてカウントされてしまうが今後の課題としてどういうアプローチをするかは検討中
- 先行して実験的機能を使いたい
- アカウント設定→オーガニゼーション→設定→実験的機能をON
- 今後も活発に開発し機能やサービスの充実が期待できそう
改善点
私が一方的にしゃべる時間も多く参加者にとってはつまらないと感じる時間も多かったのではと反省。また、自分の事ばかり話しちゃった感も否めない。周辺事情など必要以上にアウトプットしすぎたかもなぁと・・・
また、参加者が触れあう時間を作れなかったのは失敗です。
例えば、ハンズオンの時に自己紹介をお互いにして頂きテーブルで一つのテーマに取り組むなどをして頂ければ、また違った結果や雰囲気や持ち帰ってもらえるもの、次への繋がりがあったのではとこちらに関しては大きく反省しています。接続トラブルなどがなかった反面、いつもはできていた配慮やボトムアップのハンズオンがうまくできていませんでした。
知る・伝えること以上に体感や会話などから得る事ができるエクスペリエンスが大事だなと感じています。地域に根ざした敷居の低い勉強会を目指しているので、懇親会の場があるとは言えほぼ周りの人と会話せず、一人で参加している感のまま帰宅しちゃうような形にしちゃったのは駄目だった・・・
たぶん、楽しければ周りは知らない人ばかりだけど懇親会も行ってみようかなという気になるとは思いますので。
最後に
参加して頂いた方々お疲れさまでした。ありがとうございました！！
とても楽しい時間がすごせました。
