「Mackerelハンズオンセミナー in 岡山」に参加してきました。

勉強会 ハンズオン

はじめに

12/7(土)に、「Mackerelハンズオンセミナー in 岡山」に参加してきました。

1ヶ月ほど前に申し込んだ時から楽しみにしていたイベントでした。
実際に触れてみての所感なんかを記録しときます。

Mackerelとは

mackerel.io

Mackerel(マカレル)は、株式会社はてなさんが展開するSaaSのサーバー監視・管理サービスです。
「エンジニアをワクワクさせる『直感的サーバー監視サービス』」を売りとしており、大手への導入実績もあるようです。

参加のきっかけ

Mackerel自体は岡山のイベントであれこれ見聞きしており、認知はしていたのですが、これまではそこまで興味を持ってはいませんでした。
それが変わったのが、11月頭に開催された「Developers.IO 2019 Okayama」での井上さん(@a_know) の発表でした。

「ソフトウェアの梃子（てこ）」と Mackerel #cmdevio / mackerel with software insulator - Speaker Deck

「ソフトウェアの梃子」とは、標準的なI/Fで構成されたものをつなぎ合わせて大きな仕事の達成に繋げる、という考え方とのことでした。
MackerelもAPIやWebhookなどの形でこの考えをを取り入れて他との柔軟な連携を実現しており、これが「ワクワク」にも繋がっているとのことでした。

ソフトウェアの開発知識が活きる部分が多く、自分のような開発寄りのエンジニアでもサーバー管理における要求実現がしやすそうと感じました。
ちょっと興味が湧いていたところ、今回のハンズオンのお話を聞いたので、実際に触ってみたくて申し込んだ次第です。

会場

今回の会場は、駅元町にあるオカジョブカフェさんでした。 www.jobcircle.jp

岡山駅西口を出て徒歩3分程度のところにあるおしゃれなカフェです。
その中の、30人程度入れそうなレンタルスペースを利用して開催されました。

プロジェクターやスクリーンといった設備はもちろん、Wi-Fi完備な点はITイベントでは嬉しい点かと思います。 駅からのアクセスも抜群なので、小〜中規模のイベントを開催しやすい会場だと感じました。
ちなみに、カフェはコワーキングスペースとしても利用可能とのことでした。Mac持ち込んでコーヒー片手にリモートワークとかしてみたいですねー。

内容

まずは、主催の井上さんによる自己紹介と、サーバー監視についての説明から入りました。
物理→クラウドへのサーバーの変遷、「なぜサーバー監視が重要か」など、初心者でも分かりやすいように説明されていました。

その後は、Mackerelがどんなサービスかの簡単な紹介。
ちなみに、井上さん曰くMackerelの一番難しいところは「綴り」とのことでした。

あと、Mackerelは日本語で「鯖」とのこと。(鯖とサーバ…

そして、ハンズオンへと入っていきます。
参加者ごとにAWS EC2で監視対象サーバが用意されており、そこに対してMackerelのエージェントを入れます。
ハンズオン用の手順資料も公開されており、コピペで使えるようになっていました。
普段ターミナルを使い慣れていない方への配慮、素晴らしいです。復習用にも使えます。

Mackerel内て提示される手順に沿って進めます。
以下のように、監視対象のOSを選択する画面が出るので、選択していきます。
f:id:Koba_emon:20191213055530p:plain:w300

今回の対象であるCentOS 7を選択します。
すると、以下のようにクライアントインストール用のコマンドが出てきます。
f:id:Koba_emon:20191213055735p:plain:w300

これを、監視対象にSSHしてコピペ実行します。
エージェントのインストール、これだけです。超簡単！
systemdによる自動起動設定もさっきのコマンド内で入れてくれてるようです。
f:id:Koba_emon:20191213061139p:plain:w300

ここまで出来た時点で、インストールしたMackerelエージェントが監視対象の各種情報をMackerel側に送信するようになり、Mackerelの管理画面(Hosts)で確認できるようになります(画像は後日自分のEC2に入れて取ったものです)。 f:id:Koba_emon:20191213062002p:plain:w300

続いて、Mackerel側の設定をしていきます。
Mackerelでは、協調してはたらくホスト群をまとめる「サービス」と、サービス内の役割である「ロール」を使ってホストを管理します。
サービス…Webサイトなど、実際に運用するサービス単位で作成
ロール…アプリケーションサーバ、データベースサーバなどの単位で作成
監視単位を細かく設定出来て、柔軟性が高いなーと感じました。

そして、作ったロールに、先ほどエージェントを入れて監視対象になっているホストを入れます。
1つのホストに複数のロールを設定したり、あるロールを複数のホストに紐付けたり出来ます。あるサーバがAppもDBも兼任してる場合とか、複数サーバにAppを分散しているなどの状況にもこれで対応出来ますね。
f:id:Koba_emon:20191213064544p:plain:w300

これで、サービス単位、ロール単位で情報を可視化出来ました。
次は、監視ルールを設定します。ここからがサーバ監視ツールの本領といったところでしょうか。
CPU使用率、ストレージ残量などの項目を対象に指定し、WarningとCriticalとする閾値を決めます。
面白いのが、平均値監視の機能で、過去N回の数値との平均値を閾値チェックにかけるものです。恒常的に高まっている状況に絞ったりするのに便利だと感じました。

ちなみに、死活監視ルールはデフォルトで入れてくれています。 (下の「Connectivity」がそうです。エージェントがしばらく情報送ってこないと発火するそうです。) f:id:Koba_emon:20191213065703p:plain:w300

設定出来たら、動作確認です。
監視対象のホスト側で、

$ yes > /dev/null

を実行し、CPU負荷を高めます。
しばらくすると、CPU使用率のグラフがぐんぐん上がり始め…アラートメールが飛んできました！

Mackerel側でもAlertが上がってきており、「CPU使用率がCritical領域に入った」と言うことがわかります。
実業務なら、ここからエンジニアが鎮圧に動き始めるイメージです。
便利だと思ったのが、このAlertにコメントを残せる機能でした。「今誰が対応中か」といった状況共有に使えるようです。

動きも確認できたので、先ほどのyesコマンドを止めて負荷を減らします。
しばらくすると、Mackerel画面のAlertが「Closed」になり、無事鎮圧できたことがわかりました。
Mackerelでは、WarningやCriticalになったときだけでなく、監視データが正常値に戻って「Closed」となった場合にもメールを飛ばしてくれます。鎮圧できたことがメールでもわかって便利ですねー。

この後は、カスタムプラグインを入れたりしました。
プラグインを使うことで、NginxやPostgreSQLなど、デフォルトのMackerelエージェントでは取得できないミドルウェアのデータを取得できるようになります。
公式プラグイン集が公開されており、CentOSならyumを使って

sudo yum install -y mackerel-agent-plugins

でインストールし、使いたいプラグインを設定ファイルに書き込んでエージェント再起動するだけで有効化できます。楽チン！
監視対象に合わせて、「とりあえず取れるものは全部取る」ようにプラグインを積んでおくのも1つのアプローチのようです。

スクリプトの戻り値をプラグインの出力として扱うこともできるそうで、たとえ公式にプラグインがなくてもスクリプト書けるエンジニアならそれなりのものを簡単に自作できそうです。
これ、「ソフトウェアの梃子」ってやつですね！

この他、各種サービスとの連携やAWSインテグレーションについての紹介がありました。
主要なチャットツール、BIツールとの連携はもちろん、Webhookを扱えるのでその受け口さえ作ればどんなサービスとも連携できそうでした。これも「ソフトウェアの梃子」ですね！

参加してみて

Mackerelを使うと、数ステップの簡単な手順で「直感的」に監視を始められることがよくわかるセミナーでした。
井上さんがおっしゃっていた「ソフトウェアの梃子」と言う考えを随所にうまく取り入れている様子もわかり、「非インフラのエンジニアでも、『ちょっと手を出してみようかな』と思える」そんなサービスだと感じました。
無料で使える範囲もあるとのことなので、まずは自分でちょこちょこ触ってみようかと思います。

井上さん、ありがとうございました！！