Monitoring Casual #7に参加し，「30days Albumの裏側〜監視・インフラCI事情〜」というタイトルで発表しました．

主に監視周りの話で，ふっつーにNagios・Muninを使ってるんですけど，Muninについてはちょっと変わってるのでそれの紹介． あと，インフラCIは，モニカジに間に合わせようと奮闘してたんですが間に合わなかったので，出来たところまでを紹介する感じになってます．

発表中にいただいた意見・コメント

munin

muninが黒背景になってる理由を説明している時の様子． （導入した本人である）黒田さんに変わって，背景を黒くした中二ムニンの紹介をしてました．

あと独り言．

sensu

Sensuの「うーん」といったところを喋ってたんですが，他の方も似たような感想を持っていたことが発覚．

Nagiosは単体でちゃんと動いてくれるので，Sensuのようなサーバ・クライアント型と比べて導入はそう難しくないと思う． 設定ファイル書くのがめんどくさいけど，SensuはSensuでめんどくさいところはあるので，正直イーブンかなーというのがイマココの気持ち．

インフラCI

最近話題になっただけあって，皆さんそれぞれ意見があった印象．

「インフラCIはroleの単体テストに近い」という感覚は非常によく分かります．

ところで，オンプレ環境だと1サーバに複数のコンポーネント (role) が混ざることもあり，その組み合わせが予期せぬ現象を引き起こす可能性もあったりする． なので，インフラCIでは「少なくとも単体roleあたりがちゃんと動いてるか」ぐらいを自動テストしてくれればいいと思ってます．

「インフラCIでどこまでテストすべきか」という観点からすると，やりようによっては非常に大仰なインフラCIになりかねないなーとは危惧しています．

今のところ，「単体RoleのコンテナにServerspecを実行する」ぐらいなら良いかと思っているのですが，まだ分かっていないことが多いので，回答は留保させてください．

しかしながら，「単体RoleのコンテナにServerspecを実行する」にあたって問題になるのは，テストのカバレッジです． 「Dockerでテスト出来ない項目への扱い」については社内でも議論になりました．

Docker環境でもサービスが動くようにパラメタを変えすぎてしまうと，最早何をテストしてるのか分からなくなるので，そういうのは避けたほうがいいかもしれません． それこそ，先ほど出た「大仰」が過ぎると思います．

発表資料にも書いたとおり，「Dockerは妥協点としては上々」であって，その妥協点たる本番の運用対象とDockerとの微妙な差分は，最早インフラCIでは捨てる他ありません． この「微妙な差分」の塩梅は難しく，いずれまた知見として皆さんへ共有出来ればと考えています．

終わりに

インフラCI周りについては，今後もちょくちょくとアウトプットをしていきたいと思います．

モニカジでの皆さんの発表を聞いていると，やはりMackerelやDataDog, ConsulといったツールがMonitoring関連の中心にいることに気付かされます．

ちょうど社内でもうづらさん(@udzura)がConsulをガッツリ触っていたりしていて，僕もそのへんのツールに明るくなりたいなあと思ったのでした．