ミツバチワークスで技術責任者をしています、stoneと申します。
先駆けてブログを開設・投稿してくれていたhiroshiが、
ハンドルネームで名乗っているので、自分もハンドルネームで名乗ってみることにしました。
なかなかに気恥ずかしいですね、これ。(笑)
さて、とても幸運なことに、ここ数年というもの、DECOLOGというサービスは、
ユーザー数／トラフィックともに順調に伸びて行っている状態で、
その要求に応える為に、サーバーの増設も毎月のようにおこなっています。
当初、DECOLOGは、たった１台のサーバーで運営されていました。
現在では、300台以上のサーバーで構成されています。
もちろん、それ以前に、その規模のサーバー群を扱ったこともないですし、
まさか、自分が100台以上のサーバーで構成されるサービスに関わるなんて、
夢にも思ってませんでした。
台数が増えるにつれ、数台での運用していた頃には想像できなかったことが、
いろいろ出てくるのですが、今回は、そんな「想像できなかったこと」のうちの
１つを紹介したいと思います。
現在、DECOLOGを構成するサーバー群のログの監視には、LogWatchを利用しています。
ご存知のようにLogWatchは、dailyでレポートメールを送ってきてくれるのですが、
10数台ぐらいまでは、毎朝、異常がないか、目視でレポートメールを確認をしていました。
が、これが、台数がふえるにつれ、LogWatchのチェックだけで、
かなりの時間が必要になってきてしまうんですね。
そして、ついには、もう、目視では、チェックしきれないほどの量になってしまいました。
連休明けや、夏休み／冬休み明けともなると、LogWatchだけで、
1000通を超えることもありました。
問題に直面してみれば、至極当然の結果なのですが、自分には、想像の範囲外の問題でした。
もう、チェックし切れないなら、レポートを切ってしまえばいいのですが、
「もし何か見落としがあったら。。。」と思うと、バチンと切ってしまう勇気も持てませんでした。
そこで、考えたのが、今、ウチで使っている「LogWatch Watch」(笑)です。
だいたい、こんな↓流れで動いてます。
- LogWatchのレポートメールをLogWatch Watchが動いているサーバーにも送信
- メールを受けると、フィルタリングプログラムが起動
- フィルタリングプログラムには、あらかじめ、無視していい記述を登録しておき、
それから漏れた記述をデータベースに保存
- Webインターフェースを用意して、登録外の記述をチェック
- Cron: run-parts /etc/cron.(hourly|weekly|daily)を無視
- Diskspace: 90%以上になったら、データベースに登録
- sshd: "SFTP subsystem requests"を無視
これを作って、実際に使ってみると、思った以上に便利でした。
１日数百行のチェックから、１日50項目以下のチェックですみます。
実際の画面は、こんな↓感じです。
現在は、時間の合間を見つけて、改良を進めて、キーボードショートカットで動くようになっています。
j: 下へ
k: 上へ
x: 項目を削除
m: 項目を保護(削除できないように)
とviライクな操作感で、サクサクとチェック・削除をしています。
DECOLOG本体での機能追加や修正のプログラミングは、
バグを仕込んでしまうと影響がとても大きいから、
一定以上の緊張感をもって臨んでいるのですが、
こういう「まかない」的なプログラムを書いてるときは、
その緊張感から解放されて、本当にプログラミングが楽しく感じられます。
自分勝手にイメージして、自分勝手に実装できますしね。(笑)
他にも、問題に直面するまで想像できなかったことに、
- クラスCのIPアドレスが足りなくなる
- L2/L3のスイッチの限界値に行き当たる
では、また次回に