オープンソースの可観測性

第4章 コレクション層の実装 コレクション層の実装

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

オープンソースの収集レイヤーの実装はオプションだが、特にスケールで演算子する場合には推奨されるステップだ。開発を始めたばかりであったり、小規模で仕事をしているのであれば、コレクションを完全にスキップして、テレメトリをデータリポジトリに直接書き込むこともできる。しかし、システムのフリートを管理するような大企業では、最初からスケールを計画する必要がある。

そのために、エージェントからのテレメトリを集約してデータリポジトリにエクスポートできるOpenTelemetryのCollectorのような単なるコレクターを実装することもできるし、データストリーミングテクノロジーを追加して、より良いスケールとボリュームでのデータ管理ができるようにすることもできる。

収集の実装には、1 つ以上のコレクタが管理対象システムからデータを収集するファンアウトアーキテクチャと、コレクタがプロデューサとして機能し、収集したテレメトリをダウンストリームのコンシューマに送信して、保存、処理、分析できるデータストリーミング（またはメッセージキューイング）ソリューションが必要である（図 4-1）。幸運なことに、この機能は OTel コレクターに組み込まれており、Kafka Exporter として動作する。

図4-1. エージェントは理論的にはテレメトリを直接データリポジトリに送ることができるが、より大規模なファンアウトアーキテクチャに拡張するために、エージェントからのデータを集約するコレクターが追加される。さらに大規模になると、大量のテレメトリを処理するためにデータストリーミングテクノロジーが追加される。

エージェントモードでは、コレクターはサイドカーのように密結合され、テレメトリーを収集するアプリケーションと同じホストに置かれる。ゲートウェイモードでは、コレクターは分離しており、複数のエージェントから流れてくるテレメトリを処理する。そのため、ロードバランシング、処理、集中ポリシー管理など、異なるアーキテクチャをサポートすることができる（Villela 2024）。 必要に応じて独立してスケールアップ（またはスケールダウン）したり、異なるタイプのテレメトリを処理するために、複数のコレクタが必要になることがある（OpenTelemetry 2025 "Scaling the Collector"）。

データ量と多様性を管理する

遠隔測定を管理する際の第一の防御行は、メトリックを削除したり、フィルタリングや集約などでカーディナリティを最小化することで、単純に作業を減らすことである。

遠隔測定量を管理する際の次の行はサンプリングである（Dogan 2018; OTel 2024）。すべての詳細なイベントを中央リポジトリに送る必要があるのか、それとも代表的なサブセットだけで十分なのか？サンプリングには、ヘッドサンプリングやテールサンプリングだけでなく、ダウンサンプリングなど、さまざまな戦略が存在する。ダウンサンプリングは、解像度を犠牲にしてメトリックの量を減らすために使用される。トレースは、ヘッド・サンプリングと ...