こんにちは！ はてな の Mackerel チームでセールスエンジニアを担当している id:a-know です！ IDの読み方は「えいのー」「えーの」あたりがしっくり来ます！ 由来は本名（いのうえ）です！
このエントリは Mackerel Advent Calendar 2016 の 23 日目の記事です！
さて、Mackerel のアドベントカレンダーの記事として、「Mackerel をビジネスメンバーと一緒に見る・使う」というタイトルで、
- ビジネスメンバーが気にするメトリック（数字）って、Google スプレッドシートで管理されることも多いよね
- Google スプレッドシートのセルの値なら、GAS（Google Apps Script）を使えば Mackerel にサービスメトリックとして投稿できるよね
- 実際、僕個人のKPIのいくつかも Mackerel のサービスメトリックで管理してたりするのでご紹介しちゃいます！
...って感じの内容のものを当初は考えていました。ですが、既に GAS ネタは結構出てきちゃってるねって感じなので、当初の予定からは方向転換して「Mackerel 公式ヘルプ・ブログをとことん読み尽くす！」というタイトルで書いてみたいと思います。
どういうこと？
Mackerel では、さまざまな使い方・設定方法などを解説しているヘルプページと、主に毎週のアップデート情報を掲載している公式ブログがあります。
これらを改めて "とことん" 読み尽くし、「これ、結構知られていないかも！」って思ったことをダイジェスト的にまとめてみたいと思います！それではさっそく行ってみましょう！
...の前に、注意事項！
- 紹介先がブログの場合は、その記事の公開日時も合わせてご確認ください！
- ここに記載している内容はこの記事の執筆時点での内容です。
- 最新の情報については、各ヘルプページを参照ください！
もくじ
まずは小手調べ！
まずは小手調べ的な内容について！
実は HTTP/2 に対応してます
今年の5月の公式ブログエントリより。
みんなだいすき HTTP/2 ！ mackerel.io も対応しています。
グラフの気になる部分にズームイン！
次は昨年9月の公式ブログエントリです。
グラフ上でマウスを範囲ドラッグすることで、指定した範囲のグラフをズームできるようになりました。
はい、実はできます。これはぜひリンク先のエントリも見てみてほしいです！（GIFアニメーションがあります）
agent がインストールされたホストを、Mackerel ではどのように一意に識別しているか？
こちらは公式ヘルプから。こちら mackerel-agent仕様 - Mackerel ヘルプ です。
ホスト内でエージェントの起動が正常に行われると、Mackerel の本体からホストごとに一意となる id が割り振られます。
その id は「ホストID」と呼んでいるもので、 /var/lib/mackerel-agent/id に保存されています。
ですので、「あるホストをイメージ化して、そのイメージを元に同じ構成のサーバを増やす」といったような運用の際には、このファイルが含まれない状態でイメージ化することがポイントです。
逆に、この仕様を利用し、「インスタンスを再作成しても同じホストとして認識させる」ということも可能です。
「同じホストIDで複数の mackerel-agent が動作しないようにする」という点にだけは、ご注意を！
ホストステータスの意味
Mackerel のホストステータス。なんのことだか覚えていますでしょうか？
...そう、working standby maintenance poweroff ...という4種類の、アレです。
これ、単なるラベルではなく、それぞれのステータスごとに「監視される/されない」「通知される/されない」の挙動が異なっています。
このホストステータスは、API経由でも変更することが可能です。
ホスト - Mackerel API ドキュメント (v0)
あるサーバに対して、毎日深夜にバックアップジョブを実行しているんだけど、高負荷状態になるせいでその時間帯は必ずアラート通知が行われちゃう... といった悩みをお持ちの方、いませんか？
そういったケースにおいて、ジョブスクリプトの最初と最後に、ホストステータスを変更するAPIリクエストをおこなうスクリプトをそっと忍ばせておきましょう。
監視ルールごとのミュートも出来るよ！
↑の工夫はとても便利なのですが、いかんせんホストステータスはそのホスト全体の監視・通知に関わる設定となるため、例えば「定期ジョブ以外に由来する障害があったケース」も考慮したい場合にはイマイチなこともあるかもしれません。
監視ルールごとに、「監視における通知を行わない」ようにする "ミュート"、というものがあります。以下のリンクは、今年の4月の公式ブログエントリです。
API もあります。
監視設定 - Mackerel API ドキュメント (v0)
監視ルールは、そのルールによる監視対象のホストをサービス/ロールで絞り込むことができるので、上述のホストステータスの切り替えと使い分けるのもよいかもしれません。
Mackerel の死活監視の仕組みについて
公式ヘルプページ「FAQ」より。
mackerel における「死活監視」とは、mackerel-agent からのデータ送信（いわゆる「システムメトリック」）が途絶えた時間が一定以上を超えると NG として判断するもの、です。
なので、mackerel-agent をインストールすることなく Mackerel でホストの状態を管理しているものに関しては、死活監視をどうするか？についても考えるようにしましょう（必要性の有無も含め）。
mackerel-agent 自身のメトリックを投稿させる
ことが可能です！「診断モード」と呼んでいます。設定方法については以下のリンクを確認してみてください。
mackerel-agent仕様 - Mackerel ヘルプ
これをオンにすると、エージェント自身のメモリ使用状況を収集しカスタムメトリックとして投稿されるようになります。
metric rate 監視ルールについて
例えば複数のコア（ここでは2コアとします）をもつCPUが搭載されているサーバに mackerel-agent をインストール・起動した場合、そのCPUのメトリックグラフの上限値は 200% になります。そのCPUの使用率に対する監視ルールを作成するとき、例えば使用率が9割を超えたときにアラートとしたい場合、閾値には 180% と指定しなければならないのでしょうか？
監視ルールの作成で監視対象のメトリックを選択する際、「metric rate monitor」というカテゴリがあります。
このカテゴリの中のものは、その閾値を割合で指定します。なので、上述のようなケースでも 90% と、素直に閾値を設定することが可能なのです。
ちなみに、複数のコアを持つCPUの各コアごとの使用率をみたい・ロードアベレージをコア数で割った値がみたい、といったときには mackerel-plugin-multicore プラグインが便利ですので、合わせて紹介します。以下のエントリを確認してみてください（今年7月の記事です）！
チェック監視の詳細設定について
みんなだいすき（？）、チェック監視。「ログファイル内に出現する文字列の検知」や「特定プロセスの有無のチェック」なども、mackerel-agent にプラグインを組み込むことで行なえちゃいます。
そんなチェック監視ですが、
- チェック監視によるアラートの再送間隔の指定
- チェックの結果、アラートとするまでの試行回数の指定
- チェック監視の実行間隔（デフォルトでは毎分）
といった、詳細な設定を行うことが、実は可能です。気になった方、ぜひ以下のページをご覧ください！
HTTP Proxy 経由で接続させる
Mackerel は、基本的には
...という、push 型の監視サービスです。
なので、外部からの通信を想定して特定のポートを開放する、などの必要はないのですが、外部に向けた https 通信は可能である必要があります。
そのため、閉じたネットワーク・外向けへの通信はプロキシサーバ経由で行なうような環境で mackerel-agent を利用してもらう場合には、そのプロキシサーバを指定する必要があるのですが、mackerel-agent に対してはその指定も行なうことができます。
mackerel-agent仕様 - Mackerel ヘルプ
一歩進んだ使い方
以上が「小手調べ」としてみたページでしたが、いかがでしょうか？
続いて、ちょっと難しい？ものについて紹介していきます！
エージェント起動時に自動的にサービス・ロールに所属させる
mackerel-agent仕様 - Mackerel ヘルプ
mackerel-agent.conf に roles 設定項目を指定することで、その conf を持つホストで mackerel-agent が起動したとき、自動的にそのサービス・ロールに所属させることができます。
主にオートスケール環境で威力を発揮する設定ですね。その時点でサービスやロールが存在しない場合には新たに作成もされます。
AWSインテグレーションにより連携したホストへのメトリックの集約
たとえば AWS RDS で MySQL を運用していたとします。Mackerel の AWSインテグレーション機能により、RDSのようなマネージドなサービスについても、独立したホストとして Mackerel に登録することができるのですが、そのホストに対して、別のサーバ上で実行したプラグインにより得られるカスタムメトリックを集約させることができます。
...うまく説明するのが難しいので、ぜひ下記ページを参照してください！
カスタムメトリックを投稿するためのスクリプトで、グラフ定義も指定する
mackerel-agent 経由でカスタムメトリックを投稿することは、とても簡単です。たとえば以下のような設定を conf ファイルに追記してエージェントを再起動するだけで、カスタムメトリックの投稿が始まります。
[plugin.metrics.linux] command = "/path/to/mackerel-plugin-linux"
mackerel-plugin-linux がいわゆる公式プラグイン（メトリックプラグイン）のうちの一つなわけですが、「プラグイン」とはどんなものかというと、以下のようなフォーマットでの標準出力を行なうことができるプログラム、です。
{metric name}\t{metric value}\t{epoch seconds}
なので、このような標準出力を行なうことができれば（それを agent が実行することができれば）、どんなプログラミング言語で書かれていても Mackerel のプラグインとして使用することができる、ということです。
上記のフォーマットでの標準出力をただ行なうだけでも、グラフの表示設定は自動で作成されるのですが、プラグインスクリプト内でグラフ定義も一緒に指定することが可能です。
ホストのカスタムメトリックを投稿する - Mackerel ヘルプ
上記リンクは Ruby での実装例ですが、ぜひ参考にしてみてください！
チェックプラグインに "アレ" を使う
小手調べ編でも紹介したチェックプラグインですが、実はこれ、Nagios のプラグインや Sensu のチェックスクリプトなどとほぼ同じ仕様となっており、Mackerel のプラグインとして使用することが可能です。
今まで Nagios や Sensu を使ってきた、という方が移行しやすいというのはもちろん、それらも Mackerel のプラグイン資産として活用可能なので、監視項目の幅がより広がるかと思います！
メトリックの集合に対して監視をおこなう
たとえば「Webサーバ」といった役割を持つサーバが複数台あったとき、Mackerel ではそれらを web といった「ロール」でまとめることを推奨しています。メトリックに対する監視ルールも、ロールに対して設定することが可能です。
ただ、「複数台ある Web サーバのうちの1台や2台で異常値になったとしても、サービス全体としての障害とはならないのでアラートにする必要がない」といったことも、場合によってはあるかと思います。
Mackerel では「式による監視」が可能なのですが、そこで使える関数に percentile 関数があります。これを使うことで、上述のようなケースでも柔軟な監視ができるようになります。
これについては、今年の6月のブログ記事で紹介しています。
「通知グループ」により柔軟な通知条件を設定する
Mackerel の「通知グループ」、みなさんご存知でしょうか？
これを活用すると、アラートの通知をより柔軟に受け取るための設定を行なうことができます。ぜひ、以下のページを参考に設定をしてみてください！ 設定例もあります！
mackerel-agent.conf に関する Tips
mackerel-agent の設定ファイルである mackerel-agent.conf ですが、この記述形式は TOML 形式というものです。
以下のブログでご紹介している TOML の Multi-line literal strings は、特にプラグイン設定を記述する際にとても便利な記法です。
ちなみにこちら、昨年の Mackerel Advent Calendar のうちの1記事です。それを 2016 年のアドベントカレンダーでも紹介しちゃうのはどうなんだ？という議論が予想されます。
プラグインコマンドをシェル経由で実行させないようにする
mackerel-agent 0.38.0 で、プラグインを組み込む際の設定 command に配列を渡すことができるようになっています。
こちら、なんと昨日・2016-12-22 のアップデート告知ブログエントリです。しかも僕が書いています。
そんな記事を翌日の、しかも自分のアドベントカレンダーで紹介しちゃうのはどうなんだ？という議論が予想されます。
オマケ
ここまでで紹介してきたページとは少し毛色が異なるのですが、改めて「参考になるなぁ！」というページも発掘できましたので、合わせてご紹介しちゃいます。
はてなにおける Mackerel の活用方法について
API を利用したサーバーオペレーション（一部古い記述があります）
以上！
いかがでしたでしょうか？「あ、そんなことまで書いてあったんだ？！」といった、みなさんにとっての発見があればうれしいです。
明日はいよいよクリスマスイブ！ SatoHiroyuki さんが担当です！よろしくおねがいしまっす！
