OTelを置き換え、wide eventsでオブザーバビリティプラットフォームを拡張する

• ClickHouseの社内LogHouseは、1年で19PiB・約40兆行から、100PB超の非圧縮ログと約500兆行を保存する規模に拡大
• 従来のOpenTelemetry中心の収集経路は、JSON、OTelフォーマット、ClickHouse Nativeフォーマットを行き来し、CPUコストとログドロップのリスクを増大させていた
• ClickHouseはSysEx(System Tables Exporter)により、システムテーブルをLogHouseへバイト単位でコピーし、37M logs/sを70 CPUコアで処理
• OTelはstdout・stderrベースの障害ログやベンダー中立の標準フォーマットとして引き続き有用だが、中核となるClickHouseテレメトリはSysExとwide events中心へ移行
• HyperDX導入後は、ClickHouseネイティブUI、Lucene構文検索、SQL分析、スキーマ非依存の探索を組み合わせ、GrafanaベースのカスタムUIの一部を置き換えている

---

LogHouseが100PBと500兆行規模に拡大

• LogHouseはClickHouse Cloud監視のために構築された社内ロギングプラットフォームで、以前は増大するDatadogコストの代替という役割も担っていた
• 1年前は19PiBの非圧縮データと37兆行を処理していたが、現在は100PB超の非圧縮データと約500兆行を保存している
• 現在の保存データの主な内訳は次の通り
  • SysEx: 93.6PB、431兆行
  • OTel: 14.5PB、16.7兆行
• 以前はすべてのテレメトリがOpenTelemetryを通過していたが、現在は大半のデータがClickHouse製の用途特化exporterであるSysExから入っている

OpenTelemetryパイプラインの限界

• OpenTelemetryは、Kubernetes環境のすべてのPodログをClickHouseへ送る初期の標準パイプラインとして適していた
• ClickHouseのstdoutテキストログだけでは運用分析に不十分で、実際の分析にはsystemテーブルの構造化ログ、メトリクス、実行詳細、ディスクI/O、バックグラウンドジョブの状態が必要だった
• 既存のOTelログ経路は複数の変換段階を経ていた
  • 顧客のClickHouseインスタンスがログをJSONでstdoutに書き出す
  • kubeletが/var/log/…にログを保存する
  • OTel collectorがディスクからログを読み、JSONをパースしてメモリ表現へ変換する
  • collectorがそれをOTelログフォーマットへ再変換する
  • ClickHouse Go clientがさらにClickHouse Nativeフォーマットへ再変換してLogHouseへ挿入する
• 実際のOTelパイプラインには、edge collector、OTLP転送、gateway collector、追加処理まで含まれ、各段階がオーバーヘッド・遅延・複雑性を増やしていた
• 規模拡大に伴い、2つの問題が目立つようになった
  • ClickHouse Native型がJSONとOTelフォーマットを経由することでCPUを浪費し、データ忠実度も低下する
  • Kubernetesノード上のOTel agentがCPU・メモリ制限に達し、トラフィック急増時にログ行をドロップする
• OTelベースで20M rows/sを損失なく処理するには、agentとcollector全体で約8,000 CPUコアが必要と推定される

SysEx: ClickHouse-to-ClickHouse転送に特化した収集機

• ClickHouseはSystem Tables Exporter(SysEx) を開発し、顧客Pod内のClickHouseシステムテーブルからLogHouseテーブルへデータを直接転送している
• SysExはソースと宛先の間でバイト単位のコピーを行い、ClickHouse Native型を保持したまま中間変換を排除する
• この構造により、エンジニアがlive instanceのデバッグに使っていたクエリを、LogHouse上のフリート全体の過去データクエリへ簡単に置き換えられる
  • テーブルスキーマは同一で、Pod名やClickHouseバージョンなどのenrichmentカラムだけが追加される
• アーキテクチャはSysEx scraperプールとhash ringで構成される
  • hash ringが顧客Podを特定のscraper replicaへ割り当て、負荷を分散する
  • scraperはソースPodのsystem tableにSELECTを実行し、データをLogHouseへストリーミングする
  • scraperは逆シリアライズせず、ソースと宛先間のバイト転送を調整する
• システムテーブルのバッファflush漏れを避けるため、SysExはスライディング時間ウィンドウを使い、通常はリアルタイムより5分遅らせてクエリする
• Go ClickHouse clientのデフォルト動作はデータをGo native typeへ変換するため、ClickHouseは内部marshallingをバイパスする機能をclickhouse-goに貢献した
• SysExはpullベースのモデルのため、OTelのような重いバッファリングが不要で、LogHouseが一時的に利用不能になったりソーステレメトリが急増したりしても、過去ウィンドウを再scrapeしてバックフィルできる

動的スキーマと状態スナップショット

• SysExはソースとターゲットのスキーマ一致が必要だが、ClickHouseのsystem tableスキーマは新しいメトリクスやカラム追加で頻繁に変わる
• これに対応するため、SysExはsystem tableを検出するとスキーマを検査してハッシュ化し、LogHouseに同じスキーマのテーブルがあるか確認する
  • あれば既存テーブルへ挿入する
  • なければtext_log_6のような新しいスキーマバージョンを作成する
• クエリ時には、ClickHouseのMerge table engineを使って、複数のスキーマ反復を1つの論理ビューにまとめる
• Merge table engineは互換カラムだけを選択したり、要求カラムを持つテーブルにクエリを限定したりできるため、スキーマ変化があっても手動管理なしで参照できる
• ClickHouseはsystem.processesのようなインメモリsystem tableも定期的にスナップショットとして取得し、LogHouseへ保存している
• このスナップショットは、特定時点のクラスター状態、テーブルスキーマ、クラスター設定を過去時点ベースで分析するために使われる

フリート全体分析と効率指標

• SysExのおかげで、顧客が個別のClickHouseインスタンス監視に使うAdvanced Dashboard queriesを、顧客インスタンスのフリート全体に対して同時実行できる
• リリース分析では、デプロイ前後に診断クエリを実行し、クエリ性能パターン、リソース使用傾向、エラー率の変化をフリート規模でリアルタイム確認する
• サポートダッシュボードは、Advanced Dashboardクエリとともに、ネットワークログ、Kubernetesイベント、data plane・control planeイベントを同じインターフェースで相関分析する
• LogHouse基準の効率比較は次の通り
  • OTel Collectors: 800 CPUコア超で2M logs/sを転送
  • LogHouse Scrapers(SysEx): 70 CPUコアで37M logs/sを転送
• SysExは、最重要データソースのイベント量を20倍に増やしながら、CPUフットプリントを従来の10%未満に削減し、edgeでのイベントドロップも防いだ

OpenTelemetryが依然として必要な領域

• OpenTelemetryは、標準化されたベンダー中立フォーマットと新規ユーザーのオンボーディング体験を提供するため、ClickStackの基本選択肢として残っている
• SysExはClickHouse内部と強く結びついており、live system tableをクエリするpullベース構造のため、サービスがcrash loop中またはdown状態だとデータをscrapeできない
• OpenTelemetryはstdoutとstderrにemitされたログを受動的にキャプチャするため、サービスが完全にhealthyでなくても障害中のログを収集できる
• ClickHouseは、すべてのClickHouseサービスでOpenTelemetryを継続利用しつつ、収集範囲を変更している
  • 以前はtrace-levelログまですべてingestしていた
  • 現在はinfo-level以上のみ収集している
• この変更後、OTel collectorとgatewayははるかに少ないリソースで動作し、前述の2M log lines/s規模の小さなパイプラインとして維持されている

HyperDXとClickHouseネイティブの探索体験

• LogHouseの最初のUIはGrafana上に構築したカスタムオブザーバビリティ体験だったが、SysExとwide-columnテレメトリの増加により、ClickHouseへより深く統合されたUIが必要になった
• HyperDXはClickHouseネイティブUIとして、ログ・トレース探索、相関分析、大規模分析を支援する
• Lucene構文でクエリできるためデータ探索が簡単になり、複雑なイベント分析には引き続きSQLを使える
• HyperDX v2.0のスキーマ非依存アプローチは、単一の固定ログテーブル構造を要求しない
  • OpenTelemetryパイプラインの標準化されているが変化し続けるデータフォーマットに対応する
  • SysExや他のcustom exporterによるspecialized wide-column tableも、事前のスキーマ知識や複雑なgrok patternなしで扱える
• Grafanaも依然としてLogHouseで役割を持つ
  • 社内のGrafanaベースアプリはnamespace指定によりサービスごとのデータ位置を把握し、適切なClickHouseインスタンスへクエリをルーティングする
  • Prometheusメトリクスベースの既存ダッシュボードとアラートは今もGrafanaに残っている
  • kube_state_metricsのような高水準メトリクスは、深い調査には不向きでもalertingには適している

Wide eventsと高カーディナリティなオブザーバビリティ

• SysEx導入により、stdoutログ中心の収集から、system tableベースのwide eventsと高カーディナリティデータ中心のモデルへ移行した
• ClickHouseはこれをObservability 2.0ではなく、LogHouseとClickStackの組み合わせと呼んでいる
• このモデルでは、従来の3本柱モデルの代わりに、複数ソースからの高カーディナリティテレメトリを中央warehouseへ保存する
• 各rowはquery identifier、Pod名、version metadata、network detailのような豊富なコンテキストを含み、metric storeの制約に合わせるためにdimensionを事前集約したり捨てたりしない
• ingest時点では要約せず原文のまま保存し、集計はquery timeへ先送りする
• Prometheusとの違いは、すべてのdata pointを保存する点にある
  • insertDurationのようなフィールドを事前集約せず、各値を関連dimensionとともに保持する
  • Prometheusであらゆるlabel組み合わせのtimeseriesを保存すると、カーディナリティ爆発が起きる
  • histogramの事前集約はリソース使用を制御できるが、特定のスパイクがどのinstance、table、time windowのinsertなのかを問うのが難しくなる
• Elasticsearchもwide eventsと柔軟なdocument構造を推奨していたが、ClickHouseのcolumnar designは高カーディナリティ・高ボリュームのイベントデータを大規模に効率よく保存・クエリできる

データサイエンスツールとSQL分析

• 1つのwide eventから複数の特性を可視化でき、チャート上の特定点からraw logへ戻ることもできる
• ClickHouseはデータ可視化統合と言語クライアントを提供しており、Plotly、Jupyter notebook、Hex、Bokeh、EvidenceのようなSQLベースツールを使える
• HyperDXのLucene構文検索は高速な参照とフィルタリングに適しているが、複雑な問いにはSQLが必要になる
• ClickHouse SQLはjoin、時間ベース演算、変換を表現できる
  • 例として、Kubernetes event stream内で同じcontainerのKillingイベントとCreatedイベントをASOF JOINで対応付け、終了から再起動までの時間を計算する
  • 例のクエリは17.78M rowsと581.49MBを処理し、0.099秒で完了、ピークメモリは272.88MiBだった
• 必要なメトリクスをあらかじめcomponentとして作ってデプロイするのではなく、wide events warehouseからquery timeに導出できる

LogHouseに追加されたデータソース

• LogHouseは、エンジニアリング・サポートチームの要望に応じて、さらに多くのwide eventベースのデータsinkを追加している
• kubenetmon: Kubernetesネットワーク監視向けのオープンソースツールで、Linux conntrackを使ってL3/L4 connection dataとbyte・packet countを取得する
  • forensics、workload・pod attribution、cross-region egressのようなコスト追跡meteringを提供する
  • プロジェクト: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: 人気exporterをforkし、ClickHouse native sinkを追加してKubernetes APIイベントを大規模分析する
  • fork: ClickHouse/kubernetes-event-exporter
  • 今後はイベントだけでなくKubernetes object model全体をLogHouseへingestし、あらゆる変更時点のsnapshotを保存する計画が進んでいる
• Control Plane Data: これまでLogHouseにオンボードされていなかったControl Plane部門の運用データを収集する
• Real User Monitoring(RUM): 進行中のプロジェクトで、ユーザーブラウザのfrontend performance metricをpublic gateway経由でOTelパイプラインへ送る
• Istio Access Log: Istio service meshのHTTP-level traffic dataをingestし、request・response pattern、latency、routing decisionを取得する
  • system.query_log、kubenetmonのnetwork flowと組み合わせ、SQL query、HTTP request、packet flowを横断分析する

次のステップ: zero-impact scrapingとJSON

• SysExのscrapeクエリはstrict memory limitで制限されているが、顧客がログやメトリクスでこれを見ると懸念を招く可能性がある
• ClickHouseは、live systemにクエリを実行しないzero-impact scrapingを検討している
  • ClickHouseがservice logをすでに書き込んでいるS3上のplain rewritable diskを活用する方向が有望視されている
  • SysEx worker poolがdiskベースのlog tableを直接mountできれば、稼働中のClickHouse instanceへのクエリを回避できる
• このアプローチが成功すれば、native format、高忠実度、最小変換という現在の利点を維持しつつ、運用影響への認識まで減らせる
• ClickHouseのJSON型は25.3でGAに達し、新しいフィールド出現時に適切な型のカラムを動的に作成しつつ、複数型フィールドやschema explosionも処理する
• LogHouseは、JSONが大規模オブザーバビリティのアクセスパターンにどの程度適合するか評価中である
  • JSON blob全体から文字列を探すと、数千カラムをスキャンする可能性がある
  • 構造化データと一緒にraw string JSONを保存する回避策がある
  • 大半のlog・resource attributeは小さく安定しているため、Map typeも引き続き適している
  • HyperDXはmap accessをJSONExtract関数へ自動変換する