質問: 大規模なログの転送と集約 unix/linuxマシンからのログファイルをどのように分析していますか?数百台のサーバーを実行しており、それらはすべて、直接またはsyslogを介して独自のログファイルを生成します。これらを集約し、重要なイベントを選択するための適切なソリューションを探しています。この問題は、次の3つの要素に分類されます。1)メッセージ転送古典的な方法は、syslogを使用してメッセージをリモートホストに記録することです。これは、syslogにログインするアプリケーションでは正常に機能しますが、ローカルファイルに書き込むアプリケーションではあまり役に立ちません。これに対する解決策には、syslogを使用してメッセージを送信するプログラムに接続されたfifoにアプリケーションをログインさせるか、ローカルファイルをgrepして出力を中央のsyslogに送信するものを書き込むことが含まれます。ホスト。ただし、syslogにメッセージを取り込むためのツールを作成する手間がかかる場合は、syslogよりも柔軟性と信頼性が高いfacebookの scribe のようなものに全体を置き換える方がよいでしょうか。2)メッセージの集約ログエントリは、ホストごととサービスごとの2つのタイプのいずれかに分類されるようです。ホストごとのメッセージは、1台のマシンで発生するメッセージです。ディスク障害または疑わしいログインを考えてください。サービスごとのメッセージは、サービスを実行しているほとんどまたはすべてのホストで発生します。たとえば、apacheがいつssiエラーを検出したかを知りたいのですが、100台のマシンで同じエラーが発生することは望ましくありません。すべての場合において、各タイプのメッセージの1つだけを表示する必要があります。同じディスクに障害が発生したことを示す10個のメッセージは必要ありません。また、壊れたssiがヒットするたびにメッセージを表示する必要もありません。これを解決するための1つのアプローチは、同じタイプの複数のメッセージを各ホストで1つに集約し、メッセージを中央サーバーに送信してから、同じ種類のメッセージを1つの全体的なイベントに集約することです。 [〜#〜] ser [〜#〜] これは可能ですが、使用するのは面倒です。数日間いじった後でも、基本的な集計しか機能せず、serがイベントを関連付けるために使用するロジックを常に検索する必要がありました。それは強力ですがトリッキーなものです。同僚が最短時間で手に取って使用できるものが必要です。 serルールはその要件を満たしていません。3)アラートの生成何か面白いことが起こったとき、どうやって管理者に伝えるのですか?グループの受信トレイにメールを送信しますか? nagiosに注入しますか?では、この問題をどのように解決していますか?私は皿に答えを期待していません。私は自分で詳細を理解することができますが、確かに一般的な問題が何であるかについてのいくつかの高レベルの議論は素晴らしいでしょう。現時点では、cronジョブ、syslogのミッシュマッシュを使用しており、イベントを見つけるために他に何を知っているかを知っています。これは拡張性、保守性、柔軟性がないため、すべきではない多くのことを見逃しています。更新:監視にはすでにnagiosを使用しています。これは、検出されたダウンホスト/テストサービスなどには最適ですが、ログファイルのスクレイピングにはあまり役立ちません。 nagios用のログプラグインがあることは知っていますが、ホストごとのアラートよりもスケーラブルで階層的なものに興味があります。
回答: octopussy を見てください。それは完全にカスタマイズ可能であり、あなたのすべてのニーズに答えるようです...ps:私はこのソリューションの開発者です。