1.
目次
はじめに 3
なぜゆえの監視 4
誰のためのモニタリング . . . . . . . . . . . . . . . . . . . . . . . . .
監視にもとめられるもの . . . . . . . . . . . . . . . . . . . . . . . . .
Mackerel について 9
導入の容易さ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
プラグイン開発の容易さ . . . . . . . . . . . . . . . . . . . . . . . . .
課金体系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
用語について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mackerel の導入 13
Mackerel に登録する . . . . . . . . . . . . . . . . . . . . . . . . . . .
mackerel-agent のセットアップ . . . . . . . . . . . . . . . . . . . . . .
Windows への mackerel-agent の導入 . . . . . . . . . . . . . . . . . . .
ユーザーの招待について . . . . . . . . . . . . . . . . . . . . . . . . .
Mackerel による Web システム監視 20
標準メトリック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
メモリ使用率の表示について . . . . . . . . . . . . . . . . . . . . . . .
公式プラグインのセットアップ . . . . . . . . . . . . . . . . . . . . . .
TOML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mackerel-plugin-jvm による JVM の監視 . . . . . . . . . . . . . . . . .
mackerel-plugin-inode による inode の監視 . . . . . . . . . . . . . . .
PostgreSQL の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
監視の閾値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.
プラグイン開発による対象メトリックの追加 33
プラグインによるメトリック監視 . . . . . . . . . . . . . . . . . . . .
環境変数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
チェック監視 37
メトリック監視とチェック監視 . . . . . . . . . . . . . . . . . . . . . .
check-http プラグインによる死活監視 . . . . . . . . . . . . . . . . . .
check-log プラグインによるログ監視 . . . . . . . . . . . . . . . . . . .
プラグイン開発によるチェック監視 . . . . . . . . . . . . . . . . . . .
JSON 形式でのログ出力によるチェック監視の設定 . . . . . . . . . . .
バッチ処理のロギングと監視 45
サービスメトリック 48
Azure Functions によるサービスメトリック作成 . . . . . . . . . . . . .
グラフの共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コマンドラインツール mkr 53
まとめ 54
あとがき 55
参考文献 56

3.
はじめに
はじめに
本書は、ソフトウェアテストとデリバリーに関する短編集です。
「Mackerel ではじめるお手軽サーバー監視」は、株式会社はてなが提供する、
サーバー監視サービス Mackerel について、その特徴と、現場で活用するノウ
ハウについてまとめたものです。
サポート
本書の内容のサポートについては、以下のサイトで行います。
http://pub.fieldnotes.jp/
説明中の画面のスクリーンショット等、サービスに関する情報については執筆
時点での最新のものを使用するよう努めていますが、継続的にサービス内容の
更新が行われていますので最新のサービス内容と差異が出る場合はご容赦くだ
さい。
説明に使用するホストの OS は、特に注記がない場合は CentOS Linux ( )
を使用しています。
おことわり
Mackerel(マカレル) は株式会社はてなの登録商標です。

4.
なぜゆえの監視
なぜゆえの監視
平家物語の歌い出しに「諸行無常の響きあり」という言い回しがありますが、
どれだけ完璧なサイジングをしたとしても、IT サービスを取り巻く周囲の環境
の変化は、サーバーやネットワーク帯域などのインフラ* のレイヤーに様々な
影響を及ぼします。
そしてインフラへの影響はパフォーマンスの低下やレイテンシーの増大など、
サービス品質に影響を与える問題を引き起こします。
IT サービス運用を考えるにあたって、ユーザーは増えるものであり、データは
貯まるものであり、アプリケーションの規模は膨らむものです。
現代では、クラウドに代表される仮想化技術の進展により、インフラに関す
るリソースは以前に比べるとはるかに容易に調達ができるようになってきま
した。
しかし、インフラにかかるコストと事業の収益性は比例するものではないとい
うことを考えると、インフラにかかる費用を制限なく青天井で計上するという
こともまた非現実的です。
情報処理の世界には「Measure Don’t Guess.」(推測するな、計測せよ) や、「計
測なくして改善なし」などの格言がありますが、これらの言葉の根底には
世紀のフランスの数学者 Jules-Henri Poincar の「計測なくして科学なし」とい
う言葉があります。
パフォーマンスチューニングとは測定した事象と仮説検証について行う、れっ
* IT サービスにおけるネットワーク、サーバー構築、運用などを「インフラ」と称するのは、
インフラという語が infrastructure の略なので俗語なのですが、業界に定着していることに
鑑み、本書ではこの語を用います。

5.
Mackerel について
Mackerel について
「Mackerel」は、株式会社はてなが提供する、サーバー監視サービスです。
ユーザーインターフェースは Web 上で提供されており、https://mackerel.io か
らアクセスすることができます。
Mackerel とは魚の「鯖」を指す英単語です。サービス名称としての「Mackerel」
は、「サーバー」のことを指して「鯖」と俗称するという日本の IT 業界の風習
にちなんでいます。*
Mackerel は直感的な設定が可能なユーザーインターフェースを最たる特徴と
します。
それに加えて、筆者は Mackerel を使用するうえでサービスを特徴付けるポイ
ントとして、以下の三点を挙げます。導入の容易さ、プラグイン開発の容易さ、
課金体系の三点です。
導入の容易さ
Mackerel は監視対象となるホストに mackerel-agent というエージェントを導
入することによってセットアップします。セットアップは、ホスト上でワンラ
イナーを実行することで行うことができます。
このワンライナーのスクリプトの実行が完了した時点で、CPU 使用率など、ホ
ストに対する基本的な項目の監視が行えるようになっています。
* はてなの開発現場を Forkwell Jobs のおおかゆかさんが探る！ “エンジニアの価値” を上げる
インタビューとは - はてなニュース http://hatenanews.com/articles/201412/23091

6.
Mackerel の導入
Mackerel の導入
Mackerel の導入方法については「Mackerel サーバ監視［実践］入門」(井上 et
al. ) にも記述がありますが、本著においても記述を理解するために必要な
範囲についても次の章で説明を行います。
Mackerel に登録する
新規の登録は、https://mackerel.io/signup より行います。図.
メールアドレスを入力すると、作成するオーガニゼーションの入力を求められ
るので、それに従います。図.
続いてプランの選択に移ります。オーガニゼーションの登録から 週間は Trial
プランとして、全ての機能を制限なく使用することができますので、Trial プラ
ンを選択します。図.
プランの選択が完了すると、登録したメールアドレスに
[Mackerel] Please verify your email
という Subject のメールが届くので、メール文中の案内にしたがってアカウン
トのパスワードの設定を行うと、初期登録は完了です。図.
mackerel-agent のセットアップ
mackerel にログインすると、ダッシュボードの左下に、
•「スタートガイド」

7.
Mackerel による Web システム監視
Mackerel による Web システム監視
この章では、アトラシアン社の Jira Software(以降 Jira) とバックエンドに
PostgreSQL を使用した Web システムを題材として、Mackerel による Web サー
ビスの監視の例について述べます。
標準メトリック
mackerel-agent のセットアップが完了してホストが登録された時点で、以下の
メトリックは標準メトリックとして取得可能です。(図. )
• ロードアベレージ
• CPU 使用率
• メモリー
• ネットワークインターフェース
• ディスク使用量
メモリ使用率の表示について
mackerel-agent v . . より、/proc/meminfo より MemAvailable が取得可能
な Linux カーネルについては、MemAvailable を使用してメモリー使用量を表
示するよう仕様が変更になりました。*
このため、既存の環境 (図. ) と対象となる環境 (図. ) では、グラフの表示が異
なります。
* https://mackerel.io/ja/blog/entry/announcement/20180323

8.
プラグイン開発による対象メトリックの追加
プラグイン開発による対象メトリックの追加
Mackerel の特徴の一つとして、プラグインを開発することによる、カスタムメ
トリクスやチェック監視の追加が容易な事があげられます。
mackerel-agent とプラグインの間は、プラグインとして実行したコマンドの返
り値および標準出力によって結果の受け渡しを行います。
このため、特定のプログラミング言語に依存せずにプラグインの実装を行う事
ができます。Mackerel の公式プラグイン* は Go 言語で実装されていますが、
Ruby やシェルスクリプトなど、コマンドの返り値と標準入出力の概念を有し
ているプログラミング言語であればどれでもプラグインの開発が可能です。
特定のプログラミング言語に依存せずにプラグインの実装を行う事ができるこ
とのメリットは、現場の技術者が有しているスキルセットを活用してプラグイ
ンの開発を行う事ができることです。
これは、IT サービスの運用の現場では使用できる技術セットに限りがあるため
です。
現場によって使用できる技術セットは、「シェルスクリプトならできる」「Ruby
なら Serverspec を使っているからわかる」など、現場ごとにばらつきがあり
ます。
このことは運用に従事する技術者がソフトウェア技術者でない以上避けられな
いことです。また運用のために構築するスクリプトは、ビジネス価値に直結す
るプロダクションコードでないため、サービス構築は目的でなく手段の位置づ
けになります。
* https://github.com/mackerelio/mackerel-agent-plugins

9.
チェック監視
コード 22 /usr/local/bin/jiraport(修正後)
#!/bin/bash
EST=$(ss -nat |grep ${HOST}:8080 |grep ESTAB |wc -l)
EPOCH=$(date +'%s')
echo -e "jira.tomcat.port.establisht${EST}t${EPOCH}"
チェック監視
ここまで紹介してきた、同時接続数や、サーバーのさまざまなリソースの状況
など、サーバー上のメトリックを時系列にそって監視する方法をメトリック監
視と呼びます。
これに対し、サーバーのヘルスチェックの状況や、ログファイル内のエラーロ
グ出力など、サーバー上の時系列によらない個別のステータスをチェックした
結果の監視を行う監視を、Mackerel ではチェック監視と呼んでいます。
メトリック監視とチェック監視
以前は、監視と言えばチェック監視が中心でした。
それは、メトリックを時系列で取得するには、ディスク領域や監視に用いる
サーバーの処理性能などの制約があったこともあります。
しかしながら、汎用機のバッチ処理でエラーが発生したら運用者が対応するで
すとか、ハードウェアの診断機能が故障を検出したら保守ベンダーに対応を依
頼するというような、そのような IT サービス運用の現場の作業フローをその

10.
チェック監視
ままシステムに置き換えた結果、チェック監視中心の運用フローが生まれたと
いうこともあります。
しかし IT サービスの社会への普及やサーバー仮想化やパブリッククラウドの
普及の中で、継続的に成長を続ける IT サービスの運用を続けるうえで、アク
セス負荷の変化によるスケールアウト・スケールインなど、インフラ構成を能
動的に変動できるようにすることへのニーズが高まってきました。
その中で、ホスト上やサービスに関するメトリック収集と監視を継続的に行
い、可視化する事が必要であるという考えが普及してきました。
また、技術面の向上やハードウェア性能の向上などにより、以前は難しかっ
たメトリックの監視を中心に据えた監視システムの運用が可能になってきま
した。
この流れに則り、Mackerel はメトリック監視を中心に据えた設計になってい
ます。
しかしエラーログの監視や外形監視などのサービスのエンドポイントやヘルス
チェックの監視など、メトリックによらない監視へのニーズも依然として存在
しています。この場合はチェック監視の機能を用いた監視を行います。
check-http プラグインによる死活監視
Mackerel では、チェック監視に対応した公式プラグイン集が OSS として* 提
供されています。
インストールは、yum コマンドないし apt コマンドで行います。コード.
各プラグインのコマンドは/usr/bin/以下にインストールされます。
* https://github.com/mackerelio/go-check-plugins

11.
バッチ処理のロギングと監視
図 : JSON 形式でのログ出力
バッチ処理のロギングと監視
Linux サーバーにおいて cron によるバッチ処理は未だに IT サービス運用で重
要な地位を占めています。バックアップ処理やログファイルのアーカイブ・
ローテーションなどです。
バッチ処理は、エンドユーザーに対してユーザーインターフェースを持ちませ
ん。このため、実行の結果を確認するために、実行結果やログの監視は重要な
地位を占めます。
しかし、モダンなプログラミング言語やフレームワーク上でのシステム開発と
比べて、シェルスクリプトを基調としたシステムの監視・運用は容易でないも

12.
バッチ処理のロギングと監視
のがあります。
それは、例外処理やロギングフレームワーク、エラー発生時のスタックトレー
ス出力など、モダンなフレームワークが有している機能をシェリスクリプトが
有していないためです。このような運用に必要な仕組みをフルスクラッチで作
り込むことは、
本章では、シェルスクリプトを基調としたバッチ処理のおいて、OS が提供す
る枠組みの中で運用に必要な仕組みを作り込み、Mackerel での監視に組み込む
仕組みについて述べます。

13.
サービスメトリック
サービスメトリック
アプリケーションのメトリックや、売上やページビューなどのビジネス指標
等、特定のホストに関連付かないメトリックを Mackerel ではサービスメトリッ
クと呼称します。
サービスメトリックの投稿は、コード. のように、Mackerel が提供している
API* に https で POST することによって行います。
POST する URL は/api/v0/services/<サービス名>/tsdb です。
POST の body の JSON は
• name: メトリックの名称
• time: UNIX EPOCH
• value: メトリックの値
からなるオブジェクトの配列です。
コード 30 サービスメトリックの投稿
curl -v https://api.mackerelio.com/api/v0/services/techbookfest/tsdb
-H 'X-Api-Key: <API キー>'
-H 'Content-Type: application/json' -X POST
-d '[{"name": "circleCheck", "time": '$(date +%s)', "value": 16}]'
コード. は、技術書典の弊サークルの被チェック数をサービスメトリックと
して投稿する curl コマンドの例です。
からなるオブジェクトの配列です。
* https://mackerel.io/ja/api-docs/

14.
コマンドラインツール mkr
コマンドラインツール mkr
Mackerel ではホストの操作などをコマンドラインから行うツールが OSS とし
て* 提供されています。
インストールは yum または apt コマンドによって行います。(コード. )
コード 32 mkr のインストール
sudo yum install mkr
コード. に示すのは、サーバーのバックアップ処理時にサーバーのプロセ
スが停止している際に、ヘルスチェックの警告が発生しないよう、Mackerel
のホストのステータスを maintenance とし、バックアップ処理の終了後に
working に復帰するスクリプトです。
mackerel-agent が起動しているホストでは/var/lib/mackerel-agent/id
にホストを識別する id が格納されているので、この id を mkr コマンドに引き
渡すようにしています。
コード 33 ステータスを maintenance にする
export MACKEREL_APIKEY="<API キー>"
cat /var/lib/mackerel-agent/id
|xargs mkr update --status maintenance
(バックアップ処理)
cat /var/lib/mackerel-agent/id
|xargs mkr update --status working
* https://github.com/mackerelio/mkr