syslog-ngの事を書きたかったんですが、「まず現状をまとめて・・・」とかってはじめたら結構なボリュームになってしまったので、今日はまず現状だけをまとめました。
もちろん、これがベストプラクティスであるとはおもってません。ただこういった運用の土台の話は意外に表に出てこないので参考までに晒してみます。
「他のところではこんな事してるんだ。」という１つの事例と考えてください。
実際にやった事があるのは以下の様な環境
ネットワークデバイスとサーバあわせて200台ほどのシスログを１つのシスログサーバに集めて集中管理する。
クライアント側
・被監視サーバはWindowsとUn*x系が半々。
・Windowsのイベントログをsyslogサーバへ飛ばすためntsyslogを使う。
・Un*x系のサーバは標準のsyslogdを使用。
サーバ側
一般的にswatch等が有名だがGUIがあったほうがいいだろうという理由からsl4ntを採用。
・シェアウェアだが1万円位で使い勝手がよく、安い買い物だったとおもう。
・作っているのは（多分）ドイツかオーストリアの個人でタイムゾーンに関するバグをレポートしたら翌日には直してくれた。
・sl4ntに警告を発する条件をあらかじめ仕込んでおく。するとその条件を満たすメッセージが発生した場合に管理者に通報される仕組み。
問題点と現在の対応
・クライアント→サーバ間は所詮はUDP。メッセージの到達が保障されていない。
対応：特になにもせず。
TCPで送る、十分な帯域を確保する等の対策はあるが、今のところ「ロストしたらごめんね」というスタンス。
UDP以外にもこんな解析結果もあり少なくともlinuxのsyslogdも「ロストしたらごめんね」というスタンスで作られているらしい。
この辺は「100%信頼できる訳ではない」というのをチームとして認識した上で、そのまま使うのが一般的な企業における現実的な対応ではないかとおもう。
・溜まったシスログデータのハンドル
結構シリアスな問題。
データがデータベースに収まる場合バックアップ、削除、検索等の作業はデータベースの機能やSQLで簡単にできる。
そんな環境になれているとプレーンテキストで書き出されるログってのが扱いにくくてしょーがない。
対応：
日毎にディレクトリ・ファイルを分け検索を高速化
削除はオリジナルのスクリプトを使用
バックアップは○eritasのツールを使用（差分バックアップ可能）
・データ量が多い
上とも関連するが、syslogはもともとデータの圧縮なんて考慮していないのでクライアントからサーバーへの通信量・サーバのデータ保存スペースが肥大化する。
対応：
サーバーへ転送するログのPriority、Facilityを細かく設定し転送量削減。
サーバ上の古いシスログデータは圧縮する。
（元がプレーンテキストなので10分の1以下に圧縮可能）
・sl4ntの日本語対応が不十分
日本語のシスログメッセージが化けて届く
対応：
日本語OSはほとんど使っていないので放置。
些細な点だけど
・アプリケーションによっては重要ではないメッセージのプライオリティが全てErrorだったり、大事なメッセージがinfoであがってきたりする。
もちろんメッセージの中身を精査すればいいんですが「精査が必要＝シスログサーバに転送しないといけない」な訳で。
・クライアントの時刻同期は必須
unix系,ネットワーク機器ならntpdate、Windowsならnet timeで
・ntsyslogのバグ？
Windowsのシステムログの内容がサーバに転送されないケースがちらほら。
・Windowsのシステムログでディスクフルがあがらない？
ディスク領域がフルに近いのにシステムログにエラーがあがらないのを目撃。
（まぁディスクフルの状態なのでロギングが出来てなくても文句は言えませんね）
まぁそんなこんなで色々考え出すとsyslogの長所である手軽さが薄れていってしまうというのが、ここ最近の印象です。