> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # ClickHouse をオブザーバビリティに活用する > ClickHouse をオブザーバビリティソリューションとして活用する export const Image = ({img, alt, size = "lg"}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; return
{alt}
; };
## はじめに
このガイドは、ClickHouse を使って、ログとトレースを中心とした独自の SQL ベースのオブザーバビリティソリューションを構築したい方向けに作成されています。インジェスト時の考慮事項、アクセスパターンに合わせたスキーマの最適化、非構造化ログからの構造化情報の抽出など、独自ソリューションを構築するうえで必要となるあらゆる側面を扱います。 ClickHouse 単体は、オブザーバビリティ向けのすぐに使えるソリューションではありません。しかし、比類のない圧縮率と超高速なクエリ応答時間を実現できる、オブザーバビリティデータ向けの非常に効率的なストレージエンジンとして活用できます。ClickHouse をオブザーバビリティソリューションの一部として利用するには、UI とデータ収集フレームワークの両方が必要です。現在は、オブザーバビリティシグナルの可視化には **Grafana**、データ収集には **OpenTelemetry** の利用を推奨しています (どちらも公式にサポートされているインテグレーションです) 。 シンプルなOTel
**OpenTelemetry だけではありません** データ収集には OpenTelemetry (OTel) プロジェクトの使用を推奨していますが、Vector や Fluentd など、ほかのフレームワークやツールを使って同様のアーキテクチャを構築することもできます (Fluent Bit を使った[例](https://clickhouse.com/blog/kubernetes-logs-to-clickhouse-fluent-bit)も参照してください) 。また、可視化ツールにも Superset や Metabase などの選択肢があります。
## なぜ ClickHouse を使うのか？
あらゆる集中型オブザーバビリティストアにおいて最も重要なのは、多様なソースから集められる膨大なログデータをすばやく集計、分析、検索できることです。この一元化によりトラブルシューティングが効率化され、サービス障害の根本原因を特定しやすくなります。 一方で、すぐに使えるこうした製品は、得られる価値に対してコストが高く、しかも予測しにくいと感じるユーザーが増えており、価格への感度も高まっています。そのため、クエリ性能が実用的な水準にありつつ、コスト効率が高く予測しやすいログストレージの価値は、これまで以上に高まっています。 その高い性能とコスト効率により、ClickHouse はオブザーバビリティ製品におけるログおよびトレーシング用ストレージエンジンの事実上の標準となっています。 より具体的には、以下の点から ClickHouse はオブザーバビリティデータの保存に最適です。 * **圧縮** - オブザーバビリティデータには通常、HTTP コードやサービス名のように、値が限られた集合から取られるフィールドが含まれます。値をソートして保持する ClickHouse のカラム指向ストレージにより、この種のデータは非常によく圧縮されます。特に、時系列データ向けの各種専用 codec と組み合わせると効果的です。一般に JSON 形式の元データと同程度のストレージ容量を必要とする他のデータストアとは異なり、ClickHouse はログとトレースを平均で最大 14 倍圧縮します。これは大規模なオブザーバビリティ環境で大きなストレージ削減効果をもたらすだけでなく、ディスクから読み出すデータ量が減るため、クエリの高速化にもつながります。 * **高速な集計** - オブザーバビリティソリューションでは通常、たとえばエラー率を示す折れ線グラフやトラフィックソースを示す棒グラフなど、グラフによるデータの可視化が大きな割合を占めます。集計、すなわち GROUP BY は、こうしたグラフを支える基本機能であり、問題診断のワークフローでフィルタを適用した場合でも、高速かつ応答性に優れている必要があります。ClickHouse のカラム指向フォーマットとベクトル化クエリ実行エンジンの組み合わせは高速な集計に最適であり、さらにスパースインデックスによって、ユーザー操作に応じた高速なデータのフィルタリングが可能になります。 * **高速な線形スキャン** - ログを高速にクエリするために転置索引に依存する代替技術もありますが、そのような方式は往々にしてディスク使用量とリソース消費が大きくなります。ClickHouse も追加の任意の索引タイプとして転置索引を提供していますが、線形スキャンは高度に並列化されており、マシン上の利用可能なすべてのコアを使用します (別途設定しない限り) 。これにより、[高度に最適化されたテキスト一致演算子](/docs/ja/reference/functions/regular-functions/string-search-functions)を用いて、1 秒あたり数十 GB (圧縮後) をスキャンして一致を検出できる可能性があります。 * **SQL への親しみやすさ** - SQL は、すべてのエンジニアになじみのある普遍的な言語です。50 年以上にわたる発展を経て、データ分析の事実上の標準言語としての地位を確立しており、現在も[3 番目に人気の高いプログラミング言語](https://clickhouse.com/blog/the-state-of-sql-based-observability#lingua-franca)であり続けています。オブザーバビリティもまた、SQL が理想的に適したデータの問題のひとつにすぎません。 * **分析関数** - ClickHouse は ANSI SQL を拡張し、SQL クエリをより簡潔で書きやすくする分析関数を提供しています。これは、データをさまざまな切り口で詳しく分析する必要がある根本原因分析において不可欠です。 * **セカンダリ索引** - ClickHouse は、ブルームフィルタなどのセカンダリ索引をサポートしており、特定のクエリプロファイルを高速化できます。これらはカラム単位で任意に有効化できるため、ユーザーはきめ細かく制御でき、コストと性能のトレードオフを評価できます。 * **オープンソースとオープン標準** - オープンソースデータベースとして、ClickHouse は OpenTelemetry のようなオープン標準を採用しています。ベンダーロックインの課題を回避しながら、プロジェクトに貢献し積極的に参加できる点も魅力です。
## どのような場合にオブザーバビリティで ClickHouse を使うべきか
オブザーバビリティデータに ClickHouse を使うには、SQL ベースのオブザーバビリティを受け入れる必要があります。SQL ベースのオブザーバビリティの歴史については [こちらのブログ記事](https://clickhouse.com/blog/the-state-of-sql-based-observability) をおすすめしますが、要点をまとめると次のとおりです。 次のような場合、SQL ベースのオブザーバビリティは適しています。 * あなたやチームメンバーが SQL に慣れている、または学びたいと考えている * ベンダーロックインを避け、拡張性を確保するために、OpenTelemetry のようなオープン標準に準拠したい * 収集から保存、可視化まで、オープンソースのイノベーションに支えられたエコシステムを運用する意思がある * 管理対象のオブザーバビリティデータが中規模から大規模、あるいは非常に大規模にまで増える可能性がある * TCO (総所有コスト) を自らコントロールし、オブザーバビリティのコストが際限なく膨らむのを避けたい * コストを抑えるためだけに、オブザーバビリティデータの保持期間を短くせざるを得ない状況を避けたい、またはそうしたくない 次のような場合、SQL ベースのオブザーバビリティは適していないかもしれません。 * SQL を学ぶこと (あるいは生成すること) に、あなたやチームメンバーが魅力を感じない * パッケージ化された、エンドツーエンドのオブザーバビリティ体験を求めている * オブザーバビリティデータ量が非常に少なく、目立った違いが出ない (例: \<150 GiB) うえ、今後の増加も見込まれない * ユースケースがメトリクス中心で、PromQL を必要としている。その場合でも、メトリクスには Prometheus を使い、ログとトレーシングには ClickHouse を併用し、Grafana のプレゼンテーション層で統合できます。 * エコシステムがさらに成熟し、SQL ベースのオブザーバビリティがもっとすぐに使えるようになるのを待ちたい
## ログとトレース
オブザーバビリティのユースケースは、ログ、トレース、メトリクスという3つの明確な柱で構成されています。それぞれで、データ型とアクセスパターンが異なります。 現在、ClickHouse は次の2種類のオブザーバビリティデータの保存先として推奨されています。 * **ログ** - ログは、システム内で発生するイベントをタイムスタンプ付きで記録したもので、ソフトウェア運用のさまざまな側面に関する詳細な情報を捉えます。ログ内のデータは通常、非構造化または半構造化されており、エラーメッセージ、ユーザーのアクティビティログ、システムの変更、その他のイベントを含むことがあります。ログは、トラブルシューティング、異常検知、そしてシステム内で問題に至るまでに発生した具体的なイベントを把握するうえで不可欠です。 ```response theme={null} 54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET /filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-" ``` * **トレース** - トレースは、分散システム内でリクエストがさまざまなサービスを横断する過程を捉え、それらの経路とパフォーマンスを詳細に示します。トレース内のデータは高度に構造化されており、タイミング情報を含むスパンとトレースによって、各リクエストがたどる各ステップが表現されます。トレースはシステムパフォーマンスに関する有用なインサイトを提供し、ボトルネックやレイテンシの問題の特定、さらにマイクロサービスの効率最適化に役立ちます。 **メトリクス** ClickHouseはメトリクスデータの保存にも使用できますが、この領域はClickHouseではまだ成熟度が低く、PrometheusデータフォーマットやPromQLのサポートなどの機能にはまだ十分対応していません。
### 分散トレーシング
分散トレーシングは、オブザーバビリティにおける重要な機能です。分散トレース (単にトレースとも呼ばれます) は、リクエストがシステム内をたどる経路を表します。リクエストはエンドユーザーまたはアプリケーションから発生し、システム全体へと波及していき、通常はマイクロサービス間で一連のアクションの流れを生み出します。この一連の流れを記録し、後続のイベントを相関付けられるようにすることで、オブザーバビリティの利用者や SRE は、アーキテクチャがどれほど複雑であっても、あるいはサーバーレスであっても、アプリケーションフロー内の問題を診断できるようになります。 各トレースはいくつかのスパンで構成され、リクエストに対応する最初のスパンはルートスパンと呼ばれます。このルートスパンは、リクエスト全体を開始から終了まで捉えます。ルートスパン配下の後続のスパンは、リクエスト中に発生するさまざまなステップや操作について詳細な情報を提供します。トレーシングがなければ、分散システムにおけるパフォーマンス上の問題を診断するのはきわめて困難です。トレーシングは、リクエストがシステム内を移動する際のイベントの流れを詳細に示すことで、分散システムのデバッグと理解を容易にします。 ほとんどのオブザーバビリティベンダーは、この情報をウォーターフォールとして可視化し、相対的なタイミングを長さに比例した横棒で示します。たとえば、Grafana では次のようになります。 トレースの例 ログやトレースの概念をより深く理解したい場合は、[OpenTelemetry のドキュメント](https://opentelemetry.io/docs/concepts/)を強くお勧めします。