イベントログメトリックのデータアーキテクチャ？
私のサービスには多数の継続的なユーザーイベントがあり、「イベントタイプの発生をカウントする[〜＃〜] t [〜＃〜]日付以降のようなことをしたい[〜＃〜] d [〜＃〜]。 "
私たちは2つの基本的な決定を下そうとしています：
何を保存しますか？すべてのイベントを保存するvs集計のみを保存する
- （イベントログスタイル）すべてのイベントをログに記録し、後でカウントする。
- （時系列スタイル）単一の集約された「イベント数[〜＃〜] e [〜＃〜]を日付[〜＃〜 ] d [〜＃〜] "毎日
データを保存する場所
- リレーショナルデータベース（特にMySQL）
- 非リレーショナル（NoSQL）データベース内
- フラットログファイル（
syslog-ng）
標準的なプラクティスとは何ですか/さまざまなタイプのシステムの比較に関する詳細はどこで読むことができますか？
さらなる詳細：
- 合計イベントストリームは大きく、1日あたり数十万のエントリになる可能性があります
- しかし、私たちの現在の必要性は、その中の特定のタイプのイベントを数えることだけです
- 生データや集計結果にリアルタイムでアクセスする必要は必ずしもありません
私見、「すべてのイベントをファイルに記録し、後でクロールしてストリームをフィルター処理して集約する」はかなり標準的なUNIXの方法ですが、私のRails-yの仲間は、MySQL以外に何もないことを考えているようです。
それは常に依存します、私はあなたに新しい視点を提供するためにあなたに私のアドバイスをします
何を保存しますか？すべてのイベントを保存するvs集計のみを保存する
（イベントログスタイル）すべてのイベントをログに記録し、後でカウントする。
詳細は見逃さないように計画しているのであれば、今は関係ありませんが、私の目には最善のアプローチです。時々、結果が出ると、XまたはYに関係のない他のイベントが見つかる場合があるためです。 、または追加の情報はありませんでしたが、いくつかの分析の後、それは単純に行われ、その情報も追跡する必要があります。それは、記録されているが、考慮されていないため、画像に追加する前に時間がかかるためです。 。
（時系列スタイル）毎日1つの集約された「日付Dのイベント数E」を格納します
明日実装して使用したい場合は機能しますが、新しい要件がある場合、または何らかの理由で省略した別のイベントとの相関関係が見つかった場合は、この新しいイベントを追加して、しばらく待つ必要があります。ニースの集計レベルを保持するのに長い時間がかかる
データを保存する場所
リレーショナルデータベース（特にMySQL）
最初のオプションは、すべてのイベントの記録に行く場合、DBにとって重い可能性があります。MySQLが小さすぎる可能性があることを懸念しています。RDBMSソリューションに移動したい場合、PostgreSQLやOracleやDB2のような独自仕様など、もっと大きく考えるかもしれません。 。
ただし、生成された負荷に応じて、コードで集計し、それらの集計をDBに挿入することをお勧めします。
非リレーショナル（NoSQL）データベース内
この解決策を講じる場合は、ニース のどのアプローチを採用するかを確認する必要があります（== --- ==）ウィキペディアで読む が役立つかもしれませんが、あまり役に立ちませんそのトピックについては、私は単に十分な経験がないため、ほとんどの場合rdbmsを使用します。
フラットログファイル（syslog-ngを介してネットワーク経由で中央で収集）
私は個人的にあなたにそのオプションに行くように勧めません、ファイルが大きくなりすぎると、解析するのが難しくなりますが、それでも主な目的はわかりません。システムをフォローアップするか、単にログを確認することですファイル...
それが役に立てば幸い！
使用目的によって異なります。集計値を示す標準のグラフまたはレポートがある場合は、イベントが発生したときにイベントをフィルターにかけ、適切なバケットに集計する必要があります。特定のイベントにドリルダウンする必要がある場合、または後で戻ってイベントを再分析/再分類したい場合は、個々のイベントを保存する必要があります。
時間とスペースがある場合、私が通常行うのはデータを集計することですが、詳細は（圧縮された）ファイルに保存します。ほとんど必要ないため、詳細に簡単にアクセスできる必要はありませんが、分類基準が変更された場合、一括再処理に使用できます。
アーキテクチャの決定は、ビジネスニーズに基づいて行う必要があります。あなたのケースでは、ログシステムからどのような情報を取得したいか、そしてどのように保存するか、どのくらいの頻度でこの情報を必要とするか、そして結果を得るために待つことができる時間を明確にする必要があります。 。これが、ログコレクタ、イベントコリレータ、および同様のアプリケーションの設計を推進するものです。
私の意見ではなく、あなたが開発しようとしているものに似たいくつかのアプリケーションを見ることをお勧めします。それらのいくつかは、あなたが開発するふりよりもはるかに強力かもしれませんが、あなたが従うアーキテクチャとストレージポリシーを見れば害はありません。プロフェッショナル側では、RSAやArcsightなどのSIEMアプリケーションがあり、オープンソース側では、KiwiやOSSIM（プロ用アプライアンスベースのバージョンもあります）などのイニシアチブがあります。
考慮すべきもう1つのことは、ツールによって取得された結果の使用を開始すると、より多くの情報やより詳細な要求について、経営陣から非常に多くの要求を受け取るようになることです。ですから...慎重に使用し、地平線の視点で計画してください。それはあなたにもっと仕事を与えるかもしれませんが、間違いなくあなたは多くのサポートと可視性を得るかもしれません（圧力はパッケージに含まれています）...
ログを解析し、結果をカウントしてDBに保存するというあなたの考えは有効だと思います。とにかく、DBにこれらすべての生のログが必要かどうかはわかりません（これは、同胞が示唆していることだと思います）。ログは既にファイルにありますよね？それらをアーカイブすることもできます。ビットは本当にあなたのユースケースに依存すると思います。
また、「コメントの回答」を質問に移動することについて、@ThorbjørnRavn Andersenにも同意してください。