Mackerelのグラフボードとダッシュボードについて思っていること。
フィードバックを投げようかなと思ったのですが、まずは自分用にメモとして。
ダッシュボードのよいところ
- Markdownが書けるので、「ここを見て欲しい」とか「こういう意図で配置しているグラフです」とかそういう補足が書ける。監視のニューカマーに優しい。
- テキストベースで編集できるので、編集が全体的に軽い。URLを直接編集して、同じメトリックだけど、ロールが違うやつ、とかを量産しやすい。
- 式のグラフが表示できる。
あと、多分サービスにまたがってグラフを配置できる、みたいなのも本来はある気がするけど、いまのところ1サービスで運用しているのでそれは実感できていないメリット。
ダッシュボードのもう一歩なところ
- グラフアノテーションが表示されない
- 編集用の画面（タブ/ウィンドウ）と、グラフを探してURLを取得するための画面を行き来しないとうまく作れない。
グラフボードの良いところ。
グラフボードのもう一歩なところ
- 式のグラフは表示できない。
- グラフの追加手順がつらい。
- GUIで操作できて試行錯誤ができそうに見えて、実際には作り始める前に追加するメトリックを絞り込んでおかないと途中で嫌になってしまう。
- ロールの選択状態とか、メトリックの絞り込み状態とかが一時的に保存されるとかでもだいぶ体験が改善されるような気がしています。（この辺で自分のやっていることは開発チームの想定の使い方と違うのかな？と思ったりもしました。）
あと、どちらも共通ですが調子に乗ってグラフを追加しすぎると重くなってしまいますね。 いずれにせよ、あまり縦横に長いページは見づらいので、見やすい範囲で作成するのを心がければこれは問題ないとは思っています。
結局
今はダッシュボードメインで使っています。
Mackerel User Group Meeting Vol.3 に 参加しました。
LTもさせていただきました。
初心者枠というか、自分自身が、「Mackerelの初期設定を始める前に知っておきたかったなー」と思った事についてです。
TL;DR
- AWS インテグレーションの設定は複数できるので、ロール毎くらいの粒度で設定するつもりで準備したほうがよい。
- インテグレーションの設定をする前に、監視対象のAWSインスタンスにタグをつけておくこと。
- 除外条件には頼らずに、監視対象にピンポイントにタグをつけた方がよい。
上記をまもらなかったことで起きた悲しみ。
「アカウントの設定しただけでインスタンスが片っ端から登録されて便利！」
→ 不要なホストも登録されるし、サービス・ロールの設定を手動でする必要があり、まったく便利ではない。
「ところで、どれが不要でどれが必要なのかインスタンIDだとわかんないんだけど」（ホスト名はインスタンスIDで表示されている）
「マネジメントコンソールを見ながら、必要なやつにサービスとロールを設定して、あまったやつ退役させれば良いか。」
→ ぜんぜんよくない
- 退役させてもAWSインテグレーションの抽出条件に適合していれば無限によみがえってくる。
- 除外条件をつけてAWSインテグレーションの設定を更新したらすべてのホストが新規登録状態に
- がんばってつけたサービス・ロールが水泡に :orz:
「除外条件をたくさん設定して、もう余計なホストはいないぞ！」
「これで安心してスタンダードプランを使い続けられる」
→ そうはいくかな？
- 事情を知らない人がなんのタグもつけずにインスタンスを作成する
- 「なんか知らないホストが監視対象になってるんだけど？」
悲しみを繰り返さないために。
御利益
- デフォルトロールで抽出すれば手作業なしで快適に監視できる
- タグなしのインスタンスが突然増えても勝手に監視対象になったりしない
- （ここはケースバイケースで、こういうのを監視しなければいけない人たちもいるとは思う。その場合には既存インスタンスに除外タグを一括でつけて、既知のタグがついていないものだけ引っかかるようなインテグレーション設定を追加するのかな。）
LT を終えて
こんな感じのことを話そうと思っていたのですが、準備不足の極みで完全にテンパってしまい、ここに書いてある事の半分くらいの話しかできなかったなーという感じなので、反省しています。 こういうのはきっと場数も大事！いままであまり外に出ていかないタイプのエンジニアだったので、登壇とかブログとかをもっとやっていきたいという気持ちです。
Mackerelのメタデータプラグインを書いてみた。
こちらのイベントに参加してきました。
Mackerel歴3ヶ月ほど、Go言語未経験（Hello, World程度は一応やったことがある）、 日々の監視について、「これで完璧」とも思っていないが、具体的に何が不足というほどの考えもまとまっていない。 という状況で、ほぼノーアイディア丸腰でのエントリーをしたので、幾分不安ではありました。
どんなイベントだったか。
ほぼconnpassに書かれているスケジュールの通りで、約3時間みんながもくもくとコードを書いていました。 自分はHackathonと銘打つようなイベントには初参加だったのですが、「Hackathonというよりはもくもく会っぽいね」というような声も聞こえました。
なぜ、メタデータプラグイン？
事前の説明や、アイディアソンの時間で、なんとなくメタデータプラグインをこれから推して行こうとしているのかな、という空気を感じたこと。 サーバー監視については素人なので、新しくプラグインをかいて何を監視すれば良いのかノーアイディアだったこと、などから、「じゃあなにか一つメタデータプラグインを書いてみよう」と手段先行で決めてしまいました。何しろ3時間しかないので悩んでいる時間はありません。
何を書いたか。
メタデータプラグインの例として紹介されたものが「サーバーにインストールされているモジュールの一覧をメタデータとして登録する」というもので、「そういえば、自分でデプロイしているアプリのモジュールのバージョンとか登録されていると便利かもしれない」という思いつきを得ました。
以下は、当日に書いたメモ書きほぼそのままです。 自分はTomcat上にwarファイルを配備するというデプロイをしているのでこういう情報をとることにしました。 （META-INF.MFがちゃんとしていないことがばれる←）
# 配備されているアプリケーションを登録するメタデータプラグイン ホストに対して、配備されているアプリケーションモジュールを登録する。 まずは業務で使っている構成で。 - デプロイ先 - `/hogehoge/censored/webapps` - デプロイ物 - hogehoge.war - 取得メータデータ - md5sum - 更新日 とりあえず、自分の業務に使えることを最優先でパスや取得物のパラメータ化とかはしてない。 むしろ、どういう切り出し方をしたら世の中に出せるのかという観点を学びたい。 パスを引数にする。 正規表現で引っかかったものを対象にする？ railsとかphpとかだと1つのモジュールというのがない。 ブランチのコミットハッシュとかが対象になるのだろうか。 git pull とかで更新しているのかな？ アプリのデプロイをしたときに、mkrコマンドを使ってアノテーションをしているが、1分待ってからこれで取得した値でアノテーションのdescriptionをつけるとかすると良さそう。
何で書いたか。
とりあえずシェルスクリプトでそれっぽいものができたようなので、この後はgolangを学ぶことにしよう。#mackerelio
— donsan (@_donsan_) 2017年8月19日
ということで、まずはシェルスクリプトで動くものを書いて、それからGOで調べながら書き直していました。 時間内にGOでもそれなりに動く状態になったので個人的にはちょっとした充足感が得られました。
パスとか、取得する情報とかを引数で与えるなど多少の柔軟性を持たせるところまで進めようという気持ちでいます。
今夜中に公開しないと、一生下書きのままのような気がしたのでいったんここで公開にします。
