1.2. Service Telemetry Framework アーキテクチャー
Service Telemetry Framework (STF) は、クライアント/サーバーアーキテクチャーを使用します。Red Hat OpenStack Platform (RHOSP) はクライアントであり、Red Hat OpenShift Container Platform はサーバーです。
STF は、以下のコンポーネントで設定されます。
データ収集
- collectd:インフラストラクチャーメトリクスおよびイベントを収集します。
- Ceilometer:RHOSP メトリクスおよびイベントを収集します。
トランスポート
- AMQ Interconnect:AMQP 1.x と互換性のあるメッセージングバスは、高速で信頼性の高いデータトランスポートを提供し、ストレージのためにメトリクスを STF に転送します。
- Smart Gateway:ElasticSearch または Prometheus に提供するために、AMQP 1.x バスからメトリクスおよびイベントを取得する Golang アプリケーション。
データストレージ
- Prometheus:Smart Gateway から受信する STF メトリクスを保存する時系列データストレージ。
- ElasticSearch:Smart Gateway から受信した STF イベントを保存するイベントデータストレージ。
観察
- Alertmanager:Prometheus アラートルールを使用してアラートを管理するアラートツール。
- Grafana:データのクエリー、可視化、および検証に使用できる可視化および解析アプリケーション。
以下の表は、クライアントおよびサーバーコンポーネントのアプリケーションについて説明しています。
表1.1 STF のクライアントおよびサーバーコンポーネント
Component | クライアント | Server |
---|---|---|
AMQP 1.x と互換性のあるメッセージングバス | はい | はい |
Smart Gateway | いいえ | はい |
Prometheus | いいえ | はい |
ElasticSearch | いいえ | はい |
collectd | はい | いいえ |
Ceilometer | はい | いいえ |
モニターリングプラットフォームがクラウドで動作する問題を報告できるようにするには、監視しているものと同じインフラストラクチャーに STF をインストールしないでください。
図1.1 Service Telemetry Framework アーキテクチャー概要
クライアント側のメトリクスの場合、collectd はプロジェクトデータなしでインフラストラクチャーメトリクスを提供し、Ceilometer はプロジェクトまたはユーザーのワークロードに基づいて RHOSP プラットフォームデータを提供します。Ceilometer も collectd も、AMQ Interconnect トランスポートを使用して、メッセージバスを介してデータを Prometheus に配信します。サーバー側では、Smart Gateway と呼ばれる Golang アプリケーションがバスからのデータストリームを受け取り、それを Prometheus のローカルスクレイプエンドポイントとして公開します。
イベントを収集して保存する予定の場合は、collectd および Ceilometer が AMQ Interconnect トランスポートを使用し、イベントデータをサーバー側に渡します。別の Smart Gateway が ElasticSearch データストアにデータを書き込みます。
サーバー側の STF 監視インフラストラクチャーは、以下のレイヤーで設定されています。
- Service Telemetry Framework 1.5
- Red Hat OpenShift Container Platform 4.10 から 4.10
- インフラストラクチャープラットフォーム
図1.2 サーバーサイドの STF 監視インフラストラクチャー