はてなの Mackerel は気になっていたので登録はしていたのですが、ウチのお母さんがこのイベントに参加することになり、その勢いで俺と息子(4歳0ヶ月)もいくことになりました。
そのため、あわてて実際に Mackerel を使ってみて感想をメモっておくとかしておいたのですが、懇親会ではずっと息子と遊んでいたので、こちらに考えたことを書くことにします。
イベントの内容
これについては早くもまとめてくれている方々がいるので、こちらをどうぞ。Mackerelの利用を検討するか
現状とロードマップをみるに、（費用はまだ不明だけど） 利用する価値は十分にある、とは感じました。導入が簡潔であり、最低限＋はてならしい機能があるから、というのが理由です。スタートアップのような小規模かつ速度重視にはクリーンヒットしそうですし、今でも新パブリッククラウドに小さな人柱サービスをぶっこむ時はちょうどよさそうです。ただ、既存の監視システムから移行するかというと、それはNOです。ウチは中の上規模くらいとはいえ、監視は重要事項として長く扱ってきており、アラート系とグラフ系それぞれで自分たちに合った内容に仕上げてあります。それを最低限、同じ内容を保つためのカスタマイズコストを容認し、移行したくなるだけのプラスアルファがあるかというと、さすがに悩むまでもなく現状維持が優勢です。
既存の監視ソフトウェアってよく出来ていて、監視項目・スケールアウト・導入の簡易化などが一度整理できてしまえば、10年は言い過ぎでも5年は使い続けられちゃうんですよね。監視 as a Service を使うより費用が安く済むであろうことはもちろんですが、OSSを選定／構築／運用するのはインフラエンジニアにとっては良い実力向上機会なので、中規模以上のメイン環境は自前でやりたい、やって欲しい、というのが本音です。
ただ、本当にしっかりした監視ができるようになるまで、それなりの規模のサービスと時間が必要なので、Mackerel が小～大規模までの色んな企業の知見をまとめてイィとこどりしたような仕上がりにしてくれたら、もうこれ一択でいいじゃんってなって皆が幸せになれそうですね。
──ということから、Mackerelとかウチの監視がこんな風になったらなーってのを書いてってみます。
グラフとアラートの融合
アラートはCRITICALな状況を知らせたり、そろそろWARNINGな状況を知らせてくれ、グラフは時系列変化からWARNING, CRITICAL予測を行う、と社内講義などで説明することがあります。で、なぜこの項目を採っているのか、どうなったらヤバいのか、という説明もしていきます。が、よくよく考えると、人間がグラフを見て具体的な数値から予測を行っているのに、グラフの項目とアラートの項目って一致していないんですよ。つまり判断の自動化ができていないんですね。
グラフにもアラートにもある項目って、ディスク容量・メモリ容量・LoadAverage のような、ある瞬間に数値をとって判断できるものだけで、CPU利用率・IOwait・ネットワークトラフィック など、カウンター値を1秒平均に計算する項目はアラートに向いていないんですよね。頑張ったらできますけども。
なので、AutoScallingがCPU利用率条件をトリガーとするように、あらゆるグラフに対してアラート条件を設定できれば良いですね。そしてできれば最初からWARNING, CRITICALの閾値が決まってれば良いな、と思うわけです。もちろん変更も可で。
ウチのCPU利用率グラフだと、100％換算で40％に黄色、70％に赤色の線が引かれています。黄色は次の増設を考え始める時期、赤色はいい加減にしろよこの野郎って目安になっています。IOwaitは30％の50％、LAはvCPU数とその倍。HTTPレスポンスタイムは1000ms, 2000ms とかですね。
人間が見て危なっかしさはわかるようにしていても、仕組み上アラートにできていないので、グラフの意味を時系列変化の確認だけでなくキャパシティアラートとしてもキッチリ機能させたいところです。
ただ、DiskIOPSのように分母が計測しないとわからないモノが厳しいし、トラブルシューティングでは1つ1つのグラフではなく全体のグラフを見て、何が起きたか感覚をつかむことも多いので、全自動警告ってのは無理があるとは思いますけども・・・
基準値を超えたグラフのピックアップ
全てのグラフにWARNING, CRITICALのような基準値を設けられたとしたら、基準値を超えているグラフだけピックアップして確認できますよね。それによって管理者が日々確認するグラフの数や回数が激減するのではないかと思います。
グラフの生成は重要ですし、日々見まわるのも大切なんですけど、そのリソース軽減をもっとできないのかと最近考えるようになりました。
Recommend Graphs とか名づけて、”オススメ!!” アイコンとか角に付くといい感じです。
ロール内比較
WEB/APサーバのようなロールは通常、スペックが同じなら平均的なバランシングになるのですが、オペレーションミスや何らかの事象によって、数十台のうち1～2台が働いていなかったり、逆に異常に処理を受けているかもしれません。同ロール内でサーバ間比較をして、グラフの値や形が異常なホストをピックアップし、アラートもしてくれると、このあまり起きなく気づきづらい事象に即対応できそうです。
日単位比較
ある一定値を超えた場合、というのでは次の準備が間に合わないかもしれません。もっと早く変化を知るために、日単位で、例えば前日から20％利用率がアップしていたらピックアップ＆アラートなど。極端な例では、20％ -> 40％ -> 60％ と日毎に負荷が増えた場合、閾値が50％だと3日目にようやく気づけるところを、2日目に気づけると。
…って考えると、ロール平均値での日毎変化率ってのがあると、負荷の増減がわかりやすいかもですね。
CMとかイベントのように計画的なモノに対してはアレですけども、閾値だけでなく変化量に対しても自動検出したいものです。
AWSのフルマネージドサービスの監視
AWSでOSS監視を使う場合、RDSやElastiCacheのようなSSHログイン出来ないインスタンスに対しては、CloudWatchのAPIからとってこなくてはいけません。こういうフルマネージドサービスのグラフを手軽に作れるようになったら、相当クールな気がします。
ロール独自の監視
MackerelのロードマップにMySQLやNginx用途のプラグインが出ていましたが、基本項目以外のミドルウェア別の項目がサラリと利用できるとよいですね。ウチだとMySQLで採りたい監視項目は10以上あります。4種クエリのQPSや、デッドロック数/s、InnoDB Buffer状況、TMP Tables利用状況など、です。人によっては何十種類も採っているかもしれません。
Nginxだと、Requests per second や 平均レスポンスタイム などを採っています。
こういうのがプラグインで簡単に追加できるようになって、閾値も設定できると良いですね。
外部からの監視
内部での監視状況がどうなっていようとも、極論、パブリックサービスが活きて速いレスポンスを返せている間は何も問題ないわけです。逆に言うと、内部から見てどれだけ正常でも、WANから見てダメならアウトなわけです。
なので、パブリックサービスをWAN経由で、本番ユーザがアクセスする時と同じ処理をするヘルスチェックURLに対して監視するような、ことがMackerel側からできると良いですね。
1サービスにつき1つで十分なものですし。
色々書いてみましたが、まとめると、グラフの生成を楽にするだけでなく、グラフの運用もより楽にしていきたいってことです。グラフをしっかり作って、毎日しっかり確認していれば障害発生度をかなり減らせるわけですが、管理者が日に30分見つめるのが10分になるだけでも他のことが色々できるようになりますゆえ。
最近は社内の監視ツールやリファクタリングツールが充実してきて、数年前に比べてサービス品質が格段に向上していて、いい感じです。監視よければ全て良しって言っても過言ではないでしょう。
さて最後になりましたが、イベント会場にいた子供は私の息子でございます。
だいぶ空気が読める子なので終始静かでしたが（途中、母と散歩にいかせたけど）、
パタパタと走る足音自体が周りに響いているというのは、まだ認識できていないようで
たびたび和みSEを発生させてしまい、申し訳ありませんでした。
最近、マウスだけのネットサーフィンができるようになってきたので、
もう少しで外道倅(?)として二代目デビューすると思いますのでよろしくお願いします。
