Clickhouseを使うたびに頭が爆発しそうになるよ、特にPostgresがあるって知ってるから。Clickhouseに場所がないとは言わないし、PostgresがClickhouseのすべてをできるとも思わない。ただ、Clickhouseでの作業がすごく嫌いなんだ、変な足元の銃が多すぎて。特定の、私の意見では限られた使い方をしない限り、あらゆる面でPostgresよりも悪く感じる。

私がやったOTelはすべてアクティブだったから、あんまり注目すべきことじゃないと思う。むしろ、間違った情報か不完全な情報だね。

パーティーでは楽しそうだね。

スケールとコストの問題。私の職場ではログのスケールに直面しているんだ。「jsonをsplunkにプッシュする」だけだと、年間600万ドル以上かかるけど、承認されるのはせいぜい5〜10%くらい。記事では、彼らのjsonログを処理するのに8kのCPUが必要だと言っているけど、その後は90CPUだけで済むって。

「このボリュームでログデータを検索できますか？」（文脈: 私はこのスケールで働いています）はい。ただ、想像できるように、処理コストはかなり大きくなる可能性があります。インデックス作成や順序付け、クラスタリングの戦略がうまく設定されていないと、「この文字列を含むレコードを探す」みたいな単純なクエリでも、1ドルから10ドルかかることが簡単にあります。私の経験も彼らと一致していて、ペタバイトのデータを移動するスケールでは、最良の最適化は「できるだけ少ないデータに触れること」と「できるだけ少ないデータを移動すること」だよね。シリアライズやデシリアライズを行うたび、ディスクやネットワークI/Oを行うたびに、パフォーマンスコストが増えて、結果的に財布へのコストも増える。だから、OTelは効率と真っ向から対立することがある。OTelコレクターは追加のI/Oとシリアライズのホップだからね。でも、ペタバイトスケールで運用しているなら、1つのホップを捨てることで節約できる金額は、シリアライザーやデシリアライザーのロジックを書くエンジニアの給料を十分にカバーできるかもしれない。

数年前、ClickHouseはフルテキスト検索があまり得意じゃなかったから、それが最大の欠点だったと思う。確かに速いし、ESスケールも扱えるけど、ユースケースによっては、事前にインデックスを作らずにFTSやグルーピングをする場合、ESをクエリする方がずっと速いよ。

なんでログデータを歴史的なログデータとしてJSONファイルに保存する代わりにClickHouseを使うの？理由はいくつかあるよ。1. ログに最適化されたデータベース（ClickHouseやVictoriaLogsなど）は、ログを圧縮された形で保存するんだ。各ログフィールドの値がグループ化されて個別に圧縮される（いわゆるカラム指向ストレージ）。これにより、JSONログのプレーンファイルと比べてストレージスペースが小さくなるんだ。たとえ圧縮してもね。2. ログに最適化されたデータベースは、JSONファイルに対するgrepよりもずっと速く典型的なクエリを実行できる。パフォーマンスの向上は1000倍以上になることもあるよ。これらのデータベースは不要なデータを読み飛ばすからね。詳細はここを見てね：https://chronicles.mad-scientist.club/tales/grepping-logs-re... 3. 100ペタバイトのJSONファイルをgrepするつもりなの？ログに最適化されたデータベースは、ストレージノードを追加して水平スケーリングできるから、そんなに大量のログをクエリできるんだ。

確かに、でもデータがすでにあるなら、それは選別と整理の問題で、必要なら取り込んだ後にやればいいことだよね。全データを持っていて、必要ない方がいいのは、必要なのに持ってないよりもマシだから。最初に取り込むリソースがある前提だけど、それが彼らの最適化作業の焦点みたいだね。

俺は逆の意見だな。全部取り込んでから、オブザーバビリティプラットフォームで不要なものをフィルタリングする方がいいと思う。デバッグログをフィルタリングする問題は、必要ないと思っても、いざ必要になると困るってことだよね。そして、デバッグできないイベントを再現しようとするのは、しばしば不可能だから。だから、隠れているけどすでにあるデバッグログを取り出す方が簡単だと思う。

トレースレベルの混乱なんて、プロダクションが燃えてない限り誰も読まないよ。神様、なんでこんな消火器を置いてるんだろう、99.999%の時間使われてないのに。

そのログ取得、送信側では無料じゃないからね。特に、プログラムがクラッシュした理由を知るためにディスクにログを急いで書き込む言語では。あと、スキャンの盲点も多いし。余計なデータが多すぎると、他のログエントリとの相関関係が隠れちゃうんだよね。バグがすでに解決された後のログの価値は半減期があって、結構短いし。統計の方が好きだな、集約されるから。ただ、GIL言語のモデルの中にはOTELみたいにオーバーヘッドが高すぎるものもあるけど。

いろんな会社で、ログを減らしてメトリクスや限られたイベントにシフトしようとする動きがあったよ。だいたい「データドッグ使ってるし、契約更新の時期だし、数字がすごいから」って理由で。問題は、何がうまくいかないか分かってたら、もう直してるってこと。だから、何かが正しく動かなかったって報告があった時に、何が起こったのか知りたいとき、詳細なログが役立つけど、再発する問題がないとどのログが役立つか分からないんだよね。

誰も見たことのないログを自動的に剪定するって、どこかで誰かが、過去に見られたログに基づいて、特定のログが見られる可能性を予測するAIを作ってるに違いない。24時間は全て保存して、7日間は少し少なめに、データが古くなるにつれてもっと積極的に剪定していけば、1年後にはストーリーが薄くなる―大惨事だけが残る。

「注意重視の保持」って概念、すごくいいね。ログパターンごとにクエリやアラートのヒット数を追跡するシンプルなカウンターを使って、ほとんどの可観測性プラットフォームでTTLポリシーに活用できる。これで、全てのアクション可能なデータを保持しつつ、ストレージコストを70%削減できたよ。

大企業で働いてると、たくさんの開発チームがいろんな製品をサポートしてるから、「何が実際にログを取る価値があるのか分からない」ってのは、そのチームの開発者のインセンティブ（機能を早く出す、問題をもっと早く解決する、そんな無駄なことに時間はない）や運用のインセンティブ（サーバーが燃えてるのに、開発者が十分にログを取ってない）から切り離されてるんだよね。FinOpsは最後に来るし、可観測性スイートでチームごとのコスト追跡があるかも怪しい。データドッグが440億ドルの時価総額を持ってる理由が分からないんだね。クラウドへの移行で、すべてのエンジニアに企業クレジットカードが与えられて、支出管理もできないし、ファイナンスがその流れを止める方法もないっていう、また別のファイナンスの不満の例だよ。

え、何それ？ > 下で読むと、これで年間数百万ドルの節約ができて、観測コストを気にせずにClickHouse Cloudサービスをスケールアウトできるんだ。ログデータの保持について妥協する必要もないしね。https://clickhouse.com/blog/building-a-logging-platform-with...

やあ！ClickHouseで働いてるよ。ちょっと説明すると、100PBの大半は構造化されたイベントなんだ。うちの場合、ログは補足的なものだよ。

まあ、未知の未知を調査したいなら、あまり選択肢はないよね。

問題を出しておいて、月額料金で解決してくれるなんて面白いよね。

180日間保存してるよ。

幅広いイベントって、そんなにスペースを取る必要あるの？100PBは、フルリテンション期間（180日）の生の未圧縮データの総量だよ。圧縮がコスト効率を良くしてるんだ。このデータセットでは約15倍の圧縮が見られるから、実際には約6.5PBだけ保存してるよ。