イベントログメトリックのデータアーキテクチャ？

私のサービスには多数のユーザーイベントが継続しており、「日付D以降のイベントタイプTの発生をカウントする」などの処理を行いたいと考えています。

私たちは2つの基本的な決定をしようとしています：

1. 何を保存しますか？すべてのイベントの保存と集約のみの保存

   • （イベントログスタイル）すべてのイベントを記録し、後でカウントします。
   • （時系列スタイル）毎日の単一の集約された「日付DのイベントEのカウント」を保存する

2. データを保存する場所

   • リレーショナルデータベース（特にMySQL）
   • 非リレーショナル（NoSQL）データベース内
   • フラットログファイル（ネットワーク経由で集中的に収集されるsyslog-ng）

標準的な慣行とは何ですか/さまざまなタイプのシステムの比較に関する詳細はどこで読むことができますか？

追加の詳細：

• 合計イベントストリームは大きく、潜在的に1日あたり数十万のエントリ
• しかし、私たちの現在のニーズは、その中の特定の種類のイベントを数えることだけです
• 生データや集計結果にリアルタイムでアクセスする必要は必ずしもありません

私見、「すべてのイベントをファイルに記録し、後でクロールしてストリームをフィルタリングおよび集約する」は、かなり標準的なUNIXの方法ですが、私のRails-yの同胞は、MySQLでない限り、現実はないと考えているようです。

それは常に依存します、私はあなたに新しい視点を提供するために私のアドバイスをします

何を保存しますか？すべてのイベントの保存と集約のみの保存

（イベントログスタイル）すべてのイベントを記録し、後でカウントします。

たとえ詳細が見当たらないとしても、見当たらない場合でも、最良のアプローチである私の目には、結果が出たときに、XまたはYにとっては関係のない他のイベントを見つけることがあるためです、または追加情報をもたらさなかったが、何らかの分析の後、それは単純に行われ、それを追跡する必要があります。記録されたが説明されていないため、写真に追加する前に時間がかかります。

（時系列スタイル）毎日の単一の集約された「日付DのイベントEのカウント」を保存する

明日実装して使用したい場合は機能しますが、新しい要件がある場合、または何らかの理由で省略した別のイベントとの相関関係が見つかった場合は、この新しいイベントを追加してから待機する必要があります素晴らしい集約レベルを持つための長い時間

データを保存する場所

リレーショナルデータベース（特にMySQL）

すべてのイベントを記録する場合、最初のオプションはDBにとって重くなる可能性があるため、MySQLは小さくなりすぎる可能性があります。RDBMSソリューションを使用する場合は、PostgreSQLやOracleやDB2などのプロプライエタリのように大きく考えるかもしれません。

ただし、生成された負荷に応じて、コードで集計し、それらの集計をDBに挿入することができます。

非リレーショナル（NoSQL）データベース内

このソリューションに行く場合は、ウィキペディアで読みたいどのアプローチに従うのが役立つかを確認する必要があります。私は単に十分な経験がないため、そのトピックについてはあまり助けられません。主にrdbmsを使用しています。

フラットログファイル（syslog-ng経由でネットワーク経由で集中的に収集）

私は個人的にそのオプションを選ぶことを勧めます。ファイルが大きくなりすぎると解析が難しくなりますが、それでも主な目的はわかりません。システムをフォローアップするか、単にログをチェックするだけです。ファイル...

それが役に立てば幸い！

ログを解析し、結果をカウントしてDBに保存するというアイデアは有効だと思います。とにかく、DBのすべての生ログが必要かどうかはわかりません（同胞が提案していると言っていることだと思います）。あなたはすでにファイルにログを持っています、正しいですか？それらをアーカイブするだけで済みます。私はそのビットがあなたのユースケースに本当に依存していると思います。

また、「コメントの回答」を質問に移動することについて、@ThorbjørnRavn Andersenに同意してください。

使用目的に依存します。集計値を示す標準のグラフまたはレポートがある場合は、イベントを受信したときにフィルター処理し、適切なバケットに集計するだけです。特定のイベントにドリルダウンする必要がある場合、または後で戻ってイベントを再分析/再分類したい場合は、個々のイベントを保存する必要があります。

時間とスペースがある場合、私は通常、データを集計しますが、詳細を（圧縮された）ファイルに保存します。私はほとんど必要ないので、詳細に簡単にアクセスできる必要はありませんが、分類基準が変更された場合、一括再処理に使用できます。

アーキテクチャの決定は、ビジネスニーズによって決定される必要があります。あなたの場合、ログシステムからどの情報を取得したいか、そして保存方法、この情報が必要になる頻度、結果を得るまでにどれだけの時間を待つかを決定するために、より明確な考えが必要です。 。これが、ログコレクター、イベント相関器、および同様のアプリケーションの設計を推進するものです。

私に意見を述べるのではなく、開発しようとしているものに似たアプリケーションをいくつか見ることをお勧めします。それらのいくつかは、あなたが開発するふりをするよりもはるかに強力かもしれませんが、従うアーキテクチャとストレージポリシーを見ても害はありません。プロフェッショナル側には、RSAやArcsightなどのSIEMアプリケーションがあり、オープンソース側には、KiwiやOSSIM（プロフェッショナルアプライアンスベースのバージョンもある）などのイニシアチブがあります。

考慮すべきもう1つのことは、ツールによって得られた結果の使用を開始すると、管理者からより多くの情報とより詳細な要求を受け取る可能性が非常に高くなることです。だから...それを慎重に使用し、地平線であなたのビューで計画してください。それはあなたにより多くの仕事を与えるかもしれませんが、間違いなくあなたは多くのサポートと可視性を得るかもしれません（パッケージに圧力がかかります）....