ClickHouse/docs/ja/use-cases/observability/index.md

---
title: オブザーバビリティ
description: ClickHouse をオブザーバビリティソリューションとして使用する
slug: /ja/observability
keywords: [オブザーバビリティ, ログ, トレース, メトリクス, OpenTelemetry, Grafana, otel]
---

# オブザーバビリティのための ClickHouse の使用

## はじめに

このガイドは、ClickHouse を使用して独自の SQL ベースのオブザーバビリティソリューションを構築したいと考えているユーザー向けに設計されています。ログやトレースに焦点を当てています。 これには、インジェストの考慮事項、アクセスパターンに最適化されたスキーマ、および非構造化ログからの構造の抽出など、ソリューション構築のすべての側面をカバーしています。

ClickHouse はオブザーバビリティの即席ソリューションではありません。ただし、オブザーバビリティデータに対して比類のない圧縮率と高速なクエリ応答時間を提供できる非常に効率的なストレージエンジンとして使用できます。ユーザーが ClickHouse をオブザーバビリティソリューションとして使用するためには、ユーザーインターフェースとデータ収集フレームワークの両方が必要です。現在、オブザーバビリティシグナルの可視化には **Grafana** を、データ収集には **OpenTelemetry** を使用することを推奨しています（どちらも公式にサポートされている統合です）。

<img src={require('./images/observability-1.png').default}    
  class="image"
  alt="NEEDS ALT"
  style={{width: '800px'}} />

<br />

> データ収集には OpenTelemetry (OTeL) プロジェクトを使用することをお勧めしますが、同様のアーキテクチャは他のフレームワークやツール（例：Vector や Fluentd）を使用しても構築できます（[Fluent Bit を使用した例](https://clickhouse.com/blog/kubernetes-logs-to-clickhouse-fluent-bit)を参照）。また、Superset や Metabase を含む代替の可視化ツールも存在します。

## なぜ ClickHouse を使用するのか？

集中管理されたオブザーバビリティストアの最も重要な特徴は、多様なソースからの膨大な量のログデータを迅速に集約、分析、検索する能力です。この集中化により、トラブルシューティングが簡素化され、サービス中断の根本原因を特定しやすくなります。

ユーザーがますます価格に敏感になり、これらの即席ソリューションのコストが提供される価値と比較して高く予測不可能であると感じる中、クエリ性能が許容範囲内である場合のコスト効率の高い予測可能なログストレージの重要性が増しています。

その性能とコスト効率のため、ClickHouse はオブザーバビリティ製品におけるロギングおよびトレースのストレージエンジンの事実上の標準となっています。

より具体的には、以下の理由で ClickHouse はオブザーバビリティデータの保存に理想的です:

- **圧縮** - オブザーバビリティデータには通常、HTTP コードやサービス名などの異なるセットからの値が含まれるフィールドがあります。ClickHouse の列指向ストレージでは値がソートされて格納されるため、このデータは非常にうまく圧縮されます。特に、時系列データに特化した様々なコーデックと組み合わせることで、さらに効果が高まります。他のデータストアでは、データの元のサイズ（通常は JSON 形式）と同じだけのストレージが必要ですが、ClickHouse は平均で最大 14 倍にログとトレースを圧縮します。大規模なオブザーバビリティインストールにおいて大幅なストレージ節約をもたらすだけでなく、この圧縮によりディスクからの読み取りデータが少なくなるため、クエリを高速化します。
- **高速な集計** - オブザーバビリティソリューションは通常、エラーレートを示す線やトラフィックソースを示す棒グラフなどを通じてデータを可視化することに大きく依存しています。集計や GROUP BY はこれらのチャートを機能させるための基本であり、フィルタを適用した際に速く応答性がある必要があります。ClickHouse の列指向フォーマットとベクトル化されたクエリ実行エンジンは、高速な集計に理想的であり、スパースインデックスがユーザーのアクションに応じた迅速なデータフィルタリングを可能にします。
- **高速な線形スキャン** - 代替技術の多くはログの高速なクエリに転置インデックスを利用していますが、これによりディスク使用量やリソース使用量が高くなる傾向があります。ClickHouse は追加のオプションで反転インデックスを提供していますが、線形スキャンは非常に並列化されており（設定を変更しない限り）、利用可能なすべてのマシンコアを使用します。これにより、毎秒 10 GB/s（圧縮済み）以上のマッチングのためにスキャンが可能です。最適化されたテキストマッチングオペレータを参照してください。
- **SQL の親しみやすさ** - SQL はすべてのエンジニアにとってよく知られた言語であり、50年以上の開発を通じて、データ分析の事実上の標準言語としての地位を確立し続けています。オブザーバビリティは単なるデータ問題であり、SQL に最適です。
- **分析機能** - ClickHouse は ANSI SQL を拡張し、SQL クエリを簡単に書きやすくする分析機能を提供します。これらは、データを切り分けて分析する必要がある根本原因分析を行うユーザーにとって不可欠です。
- **二次インデックス** - ClickHouse はブルームフィルタなどの二次インデックスをサポートしており、特定のクエリプロファイルを高速化します。これらはカラムレベルで任意に有効にすることができ、コストと性能の利益を評価するための細かい制御をユーザーに提供します。
- **オープンソースとオープンスタンダード** - オープンソースデータベースとして、ClickHouse は OpenTelemetry などのオープンスタンダードを採用しています。プロジェクトに貢献し、積極的に参加する能力を提供する一方で、ベンダーロックインの課題を回避します。

## オブザーバビリティに ClickHouse を使用するべき時

オブザーバビリティデータに ClickHouse を使用するには、ユーザーが SQL ベースのオブザーバビリティを採用する必要があります。この歴史については [ブログ記事](https://clickhouse.com/blog/the-state-of-sql-based-observability)をお勧めしますが、要約すると：

SQL ベースのオブザーバビリティは次のようなユーザーに適しています：

- あなたまたはあなたのチームが SQL に親しんでいる（またはその習得を望んでいる）
- ロックインを回避し、拡張性を達成するために OpenTelemetry などのオープン標準を遵守することを好む
- コレクション、ストレージ、可視化のすべてでオープンソースの革新によって駆動されるエコシステムを運営する準備ができている
- 中規模または大規模（または非常に大規模な）オブザーバビリティデータの管理を視野に入れている
- TCO（総所有コスト）を管理し、オブザーバビリティコストの増加を避けたい
- コストを管理するためにオブザーバビリティデータの短い保持期間に縛られたくない

SQL ベースのオブザーバビリティが適さない場合：

- あなたやあなたのチームが SQL を学ぶ（または生成する）ことに興味がない
- パッケージ化されたエンドツーエンドのオブザーバビリティ体験を求めている
- オブザーバビリティデータの量が小さすぎて、何らかの重要な差別化を生み出せない（例：&lt;150 GiB）予測がされていない。
- モニターの使用例が主にメトリクスに依存しており、PromQL を必要としている。その場合でも、ClickHouse をログやトレースに使用し、Grafana でプレゼンテーションレイヤーを統一することができます。
- エコシステムが成熟するのを待ち、SQL ベースのオブザーバビリティがもっと簡単になるのを待ちたい

## ログとトレース

オブザーバビリティのユースケースには、ロギング、トレース、およびメトリクスの 3 つの明確な柱があります。それぞれが独自のデータタイプとアクセスパターンを持っています。

現在、ClickHouse は次の2種類のオブザーバビリティデータの保存を推奨しています：

- **ログ** - ログは、システム内で発生するイベントの時刻記録であり、ソフトウェア操作のさまざまな側面に関する詳細情報をキャプチャします。ログのデータは通常、非構造化または半構造化されており、エラーメッセージ、ユーザーアクティビティログ、システム変更、他のイベントを含むことができます。ログは、トラブルシューティング、異常検出、およびシステム内部で発生する問題の特定のイベントの理解に不可欠です。

```
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 はメトリクスデータの保存にも使用できますが、この柱はまだ成熟段階にあり、Prometheus データ形式および PromQL へのサポートが進行中です。

### 分散トレーシング

分散トレーシングは、オブザーバビリティの重要な機能です。分散トレース、単にトレースと呼ばれるものは、システムを通るリクエストの過程をマッピングします。リクエストはエンドユーザーまたはアプリケーションから起こり、通常はマイクロサービス間のアクションの流れにつながります。このシーケンスを記録し、後続のイベントを相関させることで、オブザーバビリティユーザーまたは SRE は、アプリケーションフローの問題を診断することができます。これにより、サーバーレスやアーキテクチャの複雑さに関わらず、理解が楽になります。

各トレースは複数のスパンで構成されており、リクエストに関連付けられた最初のスパンはルートスパンと呼ばれています。このルートスパンはリクエスト全体を最初から最後までキャプチャします。その下にあるスパンは、リクエスト中に発生する各ステップや操作の詳細な洞察を提供します。トレースがなければ、分散システム内のパフォーマンスの問題を診断することは非常に難しい場合があります。トレースは、リクエストがシステムを通過する際のイベントのシーケンスを詳細に示すことで、分散システムのデバッグを容易にし、理解を助けます。

ほとんどのオブザーバビリティベンダーは、この情報をウォーターフォールとして視覚化しており、相対的なタイミングを水平棒や比例サイズで示しています。Grafanaの例：

<img src={require('./images/observability-2.png').default}    
  class="image"
  alt="NEEDS ALT"
  style={{width: '1000px'}} />

<br />

ログとトレースの概念に深く慣れ親しむ必要があるユーザーには、[OpenTelemetry ドキュメント](https://opentelemetry.io/docs/concepts/)を強くお勧めします。