Show HN: Trifle – イベントではなく回答を保存するオープンソース分析

Trifleは、生のイベントを保存するのではなく、ネストされたカウンターを集計するオープンソースの時系列分析ライブラリです。すべて、すでに持っているデータベース内で行います。10年間で2回再構築した後、現在では1日あたり約10億イベントを追跡しています。 これは2015年に私自身のRails APMとして始まりました。ActiveSupport::Notificationsに接続し、少数の小さなユーザーと、スクレイピングアプリがすべてを壊した大きなユーザーを1人獲得しました。それがコアアイデアを sparkさせました：イベントを事前定義された時間バケットに集計し、単一の書き込みが複数のバケットを一度にインクリメントするようにします。APMは、あまりトラクションを得られずに最終的に廃れました。 その後、2021年に私は日中の仕事で分析が必要になりました。既存のものに頼るのではなく、Trifleのアイデアを、データウェアハウスのアイデアをいくつか取り入れた、より汎用的な分析ライブラリとして改訂しました。最初にRedisを使用し、次にPostgres、最終的にMongoDBを使用しました。そのため、Trifle::Statsには、ストレージレイヤーがニーズに合わせて変化する間、DSLを統一する複数のドライバーが付属しています。私たちのケース（巨大な書き込み量、一部の読み取り）では、PGは読み取りは速かったですが、大きな書き込みでは遅くなりました。 ネストされた値がこのトリックのすべてです。単一の: ```ruby Trifle::Stats.track( key: 'requests::aws::s3_uploads', values: { count: 1, status: { request.response_code => 1 }, size: payload.bytes, duration: { sum: request.duration, count: 1 } } ) ``` は、リクエスト、成功率、結果ステータスコード、複数の時間バケットに対する期間のカウントを一度に構築します。午前2時の単一バケットは次のようになります。 ```ruby { count: 14, status: { 200: 12, 500: 2 }, size: 5628341, duration: { sum: 43, count: 14 } } ``` request.durationが秒単位の場合、durationの下に保存されたsumも秒単位になります。 成功率は保存されませんが、200sをリクエスト総数で割ることで計算されます。平均期間も同様です：sum / count。メトリックキー、粒度、時間範囲を要求すると、各時点での集計値が返されます。チャートの準備ができているか、「過去30日間の平均応答時間」という質問に答えることができます。 チャート用の値を簡単な呼び出しで集計およびフォーマットするためのSeriesラッパーがあります。そして、ダッシュボードの構築は他の開発者にとって私が思ったほど楽しくないので、ダッシュボード、スケジュールされたダイジェスト、アラートを備えたビジュアルレイヤーであるTrifle Appを構築しました。これはElixirで書かれているため、ライブラリもElixirに移植しました。そして後にCLIのためにGoにも移植しました。3つすべてが互換性があり、1つに書き込み、別のものから読み取ることができます。 今日、私たちは1日あたり1億件以上のバックグラウンドジョブのアクティビティを追跡しており、これは約10億イベントになります。安全性をある程度犠牲にする（Mongoでジャーナリングと書き込み確認をオフにする）ことを厭えば、驚くほど安価に動作します。プライマリが20%の利用率である3ノードのHetzner MongoDBクラスターは、月額約1000ドルかかります。 限界もあります。ペイロードは数万のキーを持つことはできません。ドキュメントは効率的に更新するには大きすぎます。ある程度の計画が必要です。そして、ディメンションがありません。時にはそれらをネストすることができます（国 - 国はそれほど多くありません）、時にはディメンションごとに専用のメトリックキーを持つ方が良い（顧客 - 永遠に成長する）場合があります。これにより、追跡されるイベントが倍増します。したがって、1億件のジョブから10億イベントになります。 ライブラリはMITライセンスです。AppはELv2の下でソース利用可能で、セルフホストは無料、管理されたい場合は有料クラウドがあります。私は投資家の資金を無料サービスに費やすことなく、これをサイドで構築しました。 アーキテクチャ、ストレージモデル、私の失敗、またはなぜ私がまだこれを諦めなかったかについて、喜んでお答えします。