Mackerel の CRE だけど、何か質問ある？〜回答編

この記事は、Mackerel アドベントカレンダー（全部CRE）の21日目の記事です。深刻なネタ不足です。そう、思わずこんな↓ツイートをしてしまうほどに......！

深刻なアドベントカレンダーネタ不足のため、Mackerel に関する質問を募集します！！！ - 歩く信頼性こと a-know だけど Mackerel について何か質問ある？ https://t.co/xwerB5cZhz #質問箱 #peing
— a-know | Daisuke Inoue (@a_know) 2018年12月19日

↑ちなみにもう締め切らせていただいてます :pray:

普段の僕の思考回路ならたぶんこんなことはしない気がするんですが、ただ、おかげさまでたくさんの質問をいただきました、ありがとうございました！！

ということで今回は、この質問箱にお寄せいただいたみなさんからのご質問をひとつずつ、回答していきたいと思います。最初は「答えられるのは個人の公開ブログという場で答えられる範囲内の質問のみだよなー」と思ってたのですが、特にきわどい質問もなく、いただいた質問には全部答えられました！（一部ズルいのはあるかもですが......ｗ）

では張り切ってまいりましょう！質問の順番は受付順です！

AWSのFargateをmackerelで監視する際のベストプラクティスを教えてください！

おっ、いきなりいい質問ですね！

下のスライドは、今年の夏に開かれた Mackerel Meetup #12 において、Mackerel のプロダクトオーナーである松木が使用したスライドなのですが、

Fargate を含む ECS や k8s などでコンテナオーケストレーションしている環境で使っていただける mackerel-container-agent（仮称） というものをリリース予定で、これを使うのがベストプラクティスとなります！　Task や Pod という単位で仕込んでおいていただく、サイドカーコンテナ的な位置づけです。

mackerel-container-agent 自体はほぼほぼ完成しているので、お披露目の日までもう少し、お待ちを......！！

Pixela楽しいですね！

Pixela！　これ↓ですね！！

blog.a-know.me

ありがとうございます！！！（質問？？）

RDSを監視するときに、postgresプラグインを適当なホストに入れてリモート接続で監視しているのですが、ホストとメトリックの対応が崩れてしまってわかりづらく、特になんとなくグラフを見ているだけのメンバーの誤解を誘発してしまっていました。なにか良い解決策などないでしょうか。

なるほど！日々現場で活用いただいているからこそのご質問ですね、ありがとうございます！

いきなりお答えをする前に、Mackerel のAWSインテグレーションに関するヘルプページに記載されている、以下のテクニックをご存知でしょうか。

### プラグインにより取得したカスタムメトリックの連携ホストへの集約に関して

mackerel-agent の plugin 設定には、custom_identifier を指定することができます。
custom_identifier とは、ホストの識別子としてユーザー独自の identifier を付与するための仕組みです。
これを利用して、別のマシンにインストールした mackerel-agent から投稿されたメトリックを、
AWSインテグレーション連携ホストのメトリックとして集約することができます。
custom_identifier は、カスタムメトリックを投稿するためのプラグイン設定に指定します。


例として、Amazon RDS と mackerel-plugin-mysql プラグインを利用している場合、
mackerel-agent.conf のプラグイン設定に、以下のように custom_identifier の記述を追加することで、
プラグインで取得したメトリックをRDSホストのカスタムメトリックとして集約することができます。



[plugin.metrics.mysql]
command = "mackerel-plugin-mysql -host=<RDSのエンドポイント> -username=user -password=pass"
custom_identifier = "<RDSのエンドポイント>"



AWSインテグレーション - Mackerel ヘルプ https://mackerel.io/ja/docs/entry/integrations/aws

AWSインテグレーションによりMackerelに登録されたRDSホスト情報として、custom_identifier というフィールドにRDSのエンドポイント情報が自動的に入ることを利用した手法です。今回のご質問は、これが活用できるかと思っています。

寄り代としてのホストは手動で作成してあげる必要がありますが、以下のホスト登録APIを使えば、難なく作成することはできるかと思います。

ホスト - Mackerel API ドキュメント (v0)

このとき、 customIdentifier を指定することを忘れずに。値はぶっちゃけなんでもいいわけですが、一意な感じなものであるべきです。

あとは上記引用のように、postgresプラグインの設定において custom_identifier を設定すればOK。ぜひ試してみてください！

Pixelaで前日に草が生えてなかったらアラート飛ばすMackerelプラグインの説明が聞きたいです

またPixela！！　ありがとうございます！！

「前日に草が生えてなかったら」というのは、「投稿してるはずなのに投稿できてない場合に、それに気が付きたい」って感じですかねー。真面目な話、この質問のようなケースとか、あとはcronジョブみたいな、「動くはずのものが動かなかった場合」に対する監視って、難しさがあると思っていて。

それに対して僕がよく見聞きする対処方法としては、（Mackerelプラグインじゃなくて申し訳ないんですが）Songmu/horenso を使う、というもの。

github.com

README に書いてあるとおりなんですが、Synopsis はこんな↓かんじで、

$ horenso --reporter /path/to/report.pl -- /path/to/yourjob

Option、Usage は↓こんなかんじ。

Usage:
  horenso --reporter /path/to/reporter.pl -- /path/to/job [...]

Application Options:
  -r, --reporter=/path/to/reporter.pl     handler for reporting the result of the job
  -n, --noticer='ruby/path/to/noticer.rb' handler for noticing the start of the job
  -T, --timestamp                         add timestamp to merged output
  -t, --tag=job-name                      tag of the job
  -o, --override-status                   override command exit status, always exit 0

-n を使えばジョブのスタートも通知させることができます。

監視、というよりは、気が付きやすい体制づくり、みたいなかんじですが、Pixelaへの値の投稿にもこの horenso の利用を検討してみてはいかがでしょうか？

Mackerelプラグインを作りたいんですけど、どこを参考にしたらいいとかありますか？また気をつけるポイントとかありますか？

おっ！素晴らしい！公式プラグインレベルにカッチリ書きたい、という場合には以下のヘルプページが参考になると思います。

mackerel.io

もっとゆるふわに書きたいというあなたには、ちょうどいい記事がありますぜ！

blog.a-know.me

まぁこれ、ついこないだ書いたアドベントカレンダーの記事なんですけどね......。。やっぱり淡々と書いてるだけじゃ、必要としている人に情報を届けられるわけじゃないんだなぁ......（遠い目）。

MackerelのAPIドキュメントはHTMLで提供されていますが、他にプログラムからの利用がしやすい形式、例えばSwaggerやAPI Blurprint形式での提供がされていたり、提供予定があったりしますか？

おー、いいですね！便利ですよね！！

残念ながら、今の時点でご提供はなく、またこれといって予定はないのですが、要望として社内の GitHub に issue を起票しておきました！貴重なご意見、ありがとうございます！！！

REST APIを監視する技術知りたいです。

僕も、先述の Pixela という Web API サービスを提供しているので、そのお気持ちすごくわかります。というか、僕は監視してます。

やり方としてはすごくシンプルで、Mackerel のURL外形監視機能を使うというもの。

mackerel.io

ちょっと前のアップデートで、HTTP GET 以外にも、POST / PUT / DELETE を投げられるようになっています。

f:id:a-know:20181220160013p:plain

これを使って、ひととおりのAPIに対しては定期的にリクエストを送り、ちゃんと成功するか・意図するレスポンスとなっているかどうか・レイテンシは問題ないかどうか、といった観点で監視をおこなっています。

f:id:a-know:20181220160123p:plain — こんなかんじで設定しまくってます

これ、すごく良いなという実感があって、アプリケーションのリリースによりデグレとか起きた場合でもいち早く気づける・「アラートがあがってこないってことは最低限大丈夫な状態でしょ」という安心感が得られる、という点（もちろんテストなどでも担保すべき観点だとは思いますが......）。

あと、これはケースバイケースかもしれないんですが、そういう監視がおこなわれるということを、その対象であるAPIを開発する側も心得ておく、ってことも大事なんじゃないかなって気もしています。

クラウド環境だとどうやって導入するんですか？AWSのログメトリクスとかよりメリットがどのくらいありますか？

ここでいう「クラウド環境」っていうのは、任意のソフトウェア（Mackerelの場合、mackerel-agent という公式エージェントソフトウェアをインストールすることで監視をおこなうのが基本形）をインストールできないようなマネージドサービス（AWS だと RDS とか ELB とか）はどうやって監視するの？っていうご質問ですかね。

その場合、ご安心ください、AWSインテグレーション・Azureインテグレーションという機能がありまして、これを使えばマネージドサービスも簡単にMackerelと連携させることが可能です！

mackerel.io

あと、AWSやAzureに備わっている監視ソリューションに対しての Mackerel のメリット、ですが、これはまぁ利用される組織とか状況によっても異なると思うのですが、

AWSとオンプレ、みたいに複数の異なる環境を活用している場合でも、同じツールで統一することができる・横断的に情報を確認することができる
より詳細なメトリックを取得しようとした場合（カスタムメトリックスクリプト）の設定の容易さ
通知連携設定が楽
UIなどの使い勝手（これは好みの問題もありそう）

といったような点かなーと。いやもう本当、各クラウドプロバイダに備わっている監視ソリューションも日々進歩していて、それぞれいいプロダクトだと思ってるので、答えとしてはつまらないけど本当に「状況によりけり」だと思っておりますです。

datadog logsみたいにmackerelでもlogging Serviceを作る予定はありますか？リソースモニタリングと合わせて見たいです

いいですよねloggingサービス。これは今僕から言えることは、先程も登場した以下の資料中にある、今年夏時点でのプロダクトの展望に関する以下の言及以上も以下もないです！

弊社CTOが「マカレル試してみたけどイケてない」とzabbixをずっと使っています、どうすればいいでしょうか？

なんと！いいですね、燃えますね！！（？）

いやもちろん、Zabbixもめっちゃすごいプロダクトだと思っていて、これもやっぱりケースバイケース・道具の使い分けだと思うんですよね。......思うんですが、Mackerel の CRE としては「どういうところがイケていないと思っているのか」がヒジョ〜〜〜に気になるので、Mackerelを今後イケてるものにしていくためにも、その方とぜひ一度直接お話がしてみたいです！！ロケーションにもよりますが、直接お会いしたい！

その場で、Mackerelの（Zabbixと比べたときの）良さ・課題みたいなところもお話できるかと思ってます！ご連絡は Twitter DM にてお気軽にどうぞ！

Mackerelの主な競合サービスはなんですか？また、その競合サービスではなくMackerelを選ぶ理由はなんですか？

良い質問！ありがとうございます！！

Mackerel を作っている僕らからすると、その思想とかアプローチは違うと思っていて、そこも含めて全く一緒の競合プロダクト、というのはこの世に無いと思ってるんですが、まぁそういうのは置いておいてｗ、よく Mackerel と並行して検討していただくのはやはり Datadog とか Zabbix ですね。

で、Mackerel を選ぶ理由......はお客さまそれぞれで異なるからそこまでは言及しないとしても、他のサービスやツールに対して Mackerel を自信をもってオススメできる点としては、これはあくまで僕一個人としての意見ですが、「Mackerel は、はてなが開発・提供しているサーバー監視のフレームワークのようなものであること」かなっと思っています。

例えば、Mackerel では「サービス」「ロール」という単位にサーバー群をまとめて管理することを前提としているんですが、これははてなが従来から培ってきたサーバー管理における考え方のひとつなんですね。そういう管理の仕方をすることで、柔軟かつ効率的に管理・監視ができる。そういうはてなの経験、知見みたいなものを Mackerel にも注ぎ込み、それを使ってもらうことを通じて、ユーザーの皆さんにも、使っているうちに・知らず知らずのうちに、「はてな流」のフレームワークに則ったインフラ運用をしてもらえる。サービス/ロールは一例ですが、他にも、はてなが持つインフラオペレーションのノウハウを惜しむこと無く注ぎ込んでいて、こういうのは紛れもなく、Mackerel だけが提供できる価値だと思っています。もちろん、他のツールであってもサービス/ロールのようなインフラ設計はできると思いますが、"その設計をおこなうこと"も、ユーザーの方に委ねられている状態なのかな、と。「アプリケーションフレームワークなしでもアプリケーション開発はできるよね」、みたいなものと似てるのかなっと思ってます。

さらにより個人的なことをいうと、アプリケーションエンジニアの方であっても「見てみようかな」という気にさせてくれる、みたいなところも Mackerel にはあると思っています。という、これは元アプリケーションエンジニアからの意見として。ｗ

Mackerelのサービスとしての一番の課題はなんですか？また、それに対してどのような対策を検討なさっていますか？

課題なんか、アレもコレもありまくりですよー！　言っても、この業界ではまだまだ挑戦者だと思ってますし......！

個人的なところでいうと、界隈における Mackerel の盛り上がり具合、でしょうか。もちろん、ずっと愛していただいている方が多くいていただいているのは承知しているのですが、もっとワイワイしてるといいなぁ〜と！　なのでこうしてアドベントカレンダーを全部CREだけで書く、みたいな挑戦もやってるわけですが。ｗ

qiita.com

イベントとかもどんどんやっていきたいんですけどねー。多くの人が集まるイベントをオーガナイズするの、僕自身それほど得意じゃなくって(´・ω・｀)。「こうしたら盛り上がると思うよ！」ってアドバイス、お待ちしております！

Mackerel（システム監視）初心者が社内に増えてきてるんですが、（いいこと！）初心者が初級者にクラスチェンジするのに、いい事例、観点などまとまっているものがあれば教えていただきたいです。周辺まで監視しよう。などのつまづきから得る発見までのリードタイムが短くできるとうれしいとおもっています。

いいこと！

あいにくと いい事例、観点などまとまっているもの といったものはこれといってないのですが、こちら↓の記事でも言及しているように、僕らは普段から「監視を育てていきましょう」ということをお伝えしています。

mackerel.io

仮に、自分にとってシステムの特性・ワークロードの特性が全く未知のサービスを監視しなければならない、となったときのことを考えてみます。まずは、主要な項目に対して厳し目の監視を設定してみる。すると、ちょっとしたシステムリソース状況の変動でもアラートが上がってくるわけですが、そのときに、そのインフラの上で動いているサービスの状況を確認して、"障害" と呼べるような状況でなければ、監視設定の閾値を少し緩めてみる。それを繰り返す。

あと、本当に障害が発生したときには、「この類の障害が発生したときに、Mackerel で取られている項目のうち、どれが連動して変動するのか・しないのか」といった観点で眺めてみて、監視の設定が漏れているものがあれば追加して設定してみる。また、事後などにその障害について調査をしたりするとも思うんですが、そのときに「今はモニタリングできていなかったけど、しておくとよさそうな項目」みたいなものが発見できたら、プラグイン等によりモニタリングが可能なようにしておくのも良いですね。

もちろん、「監視対象項目がどんな項目なのか」という基礎的なところへの理解も重要です。初心者が初級者にクラスチェンジを、とのことですので、例えば以下のようなエントリから確認してみてもらえたらいいのかな、と思います（手前味噌で失礼！）。

blog.a-know.me

あと書籍でいうと、以下のようなものもオススメかなと思います（またもや手前味噌が混ざっている......）！