Nagiosの監視変更作業をGitHubを使って楽にした話

NetOpsCoding Advent Calendar 2015の7日目の記事です。

DeNAという会社のネットワークチームで働いています。ネットワーク機器の死活監視にNagiosを使っています。今日書くのは監視対象追加や閾値修正等の運用について、レガシーな従来の仕組みをGitHub(とpull request)と自動deployで改善した話しをします。

私の入社当時はNagiosの設定ファイルはCVSで設定ファイルを管理されてはいましたが、日々の作業(閾値変更など)は監視サーバへSSHログインして行う必要がありました。またNagiosサーバの数が複数台あり、どのサーバでどのネットワーク機器が監視されているか分かりにくかったとおもいます。

以下、改善したかった点です。

  1. 誰が作業してるか見える化したかった
  2. 閾値変更等に対して作業前にレビューを可能にしたかった(レビュー必須ではない)
  3. サーバログインレスにする。複数台のNagiosサーバのどれにログインするとか考えたくない

これらを実現するためにの仕組みは以下のようになりました。

nagios-integration

  • 設定ファイル管理はCVSからGitHubへ移行
    • nagios-etc みたいな名前で1プロジェクト作成。Nagiosサーバホスト名毎にディレクトリ切って1プロジェクトで全監視サーバ分入れる。
    • テンプレートエンジン等の自動生成の仕組みは不要だったので、素の設定をGitに突っ込むだけ
    • Git移行にあたりCVSの過去の履歴は捨てた。履歴見ることあまり無いし、いざ見たくなればCVSのログを見る
  • 変更はPull Requestで。いわゆるGitHub Flowで運用
    • 手元のMac等で監視項目追加、閾値変更等毎にトピックブランチを作りmasterブランチに対してpull request
    • レビューする(ケースバイケース)
    • masterブランチにマージされるとCIサーバがNagiosサーバへ設定ファイルをdeploy && Nagiosプロセスreload
    • GitHubからCIサーバへはwebhookで通知し連携
  • CIサーバ兼、撒き元サーバ
    • CIにはJenkinsを使う
    • CIサーバからNagiosサーバへはsshログイン可能にしておく
    • 撒きスクリプトはCapistrano + RSync(+ssh) で実装
    • 撒きスクリプトはJenkinsのbuildタスクとして登録しておく
    • 撒きの結果はSlackで通知

この改善により、pull requestベースで変更が全て行われるようになるので作業が見える化され、また閾値の妥当性などについてコメントで議論することもでき色々捗るようになりました。またmasterブランチへマージするとNagiosサーバのreloadまでが裏側で自動実施されるのでサーバログイン不要となりまた気軽に閾値変更できるようにもなりました。

実のところWebアプリケーションのCIとdeploy作業の自動化といったコンテキストでよく出てくるワークフローと同じです。また設定を撒くところはChefやPuppetで置き換えてもいいかもしれませんが、私の所ではテンプレートエンジン等も不要だったのでシンプルで早いRSyncにしました。

またこれにあたってはZabbixなど他の監視ミドルウェアへの移行も検討していましたが、最終的にはデータベースもいらず学習コストも低くメンバが仕組みにもなれたNagiosから別のミドルウェアに移行するほどのメリットが見いだせずNagiosを使って運用を改善することにしました。

最後にネットワーク機器の監視に関して少しだけ本音を言うと外形監視って面倒です。ルータがオンラインになったら(つまり設置されて火が入ったら)勝手に監視登録されるようになると嬉しい。そういう機能を持った機種もありますがマルチベンダで運用していると全部が全部そうはならないんですよね。最近のサーバ監視だとZabbixのagentだったりSensuだったりMackerelだったり、インスタンスが起動すると監視が登録されてる世界なので、ネットワーク機器も(標準的に、標準規格で)そうなると良い世界だなとおもったり。

実はこれやったのは結構前の話しだったりするのですが、ソフトウェアからのネットワーク機器操作によってネットワーク運用の自動化を志す人達のAdvent Calendar、という機会を得てようやく書けた次第でよかった。