1.2. Service Telemetry Framework アーキテクチャー
Service Telemetry Framework (STF) は、クライアント/サーバーアーキテクチャーを使用します。Red Hat OpenStack Platform (RHOSP) はクライアントであり、Red Hat OpenShift Container Platform はサーバーです。
デフォルトでは、STF はメトリクス情報を収集、伝送、および保存します。
RHOSP イベントデータを収集し、それをメッセージバスで伝送し、Smart Gateway からユーザー提供の Elasticsearch に転送できますが、このオプションは非推奨です。
STF は、以下のコンポーネントで構成されます。
データ収集
- collectd: RHOSP 上のインフラストラクチャーメトリクスとイベントを収集します。
- Ceilometer: RHOSP 上のメトリクスとイベントを収集します。
伝送
- AMQ Interconnect: AMQP 1.x 互換のメッセージングバス。メトリクスを RHOSP から STF に転送して保存または伝送するための、高速で信頼性の高いデータ伝送を提供します。
- Smart Gateway: AMQP 1.x バスからメトリクスとイベントを取得して、Prometheus または外部 Elasticsearch に配信する Golang アプリケーション。
データストレージ
- Prometheus: Smart Gateway から受信される STF メトリクスを保存する時系列データストレージ。
- Alertmanager: Prometheus アラートルールを使用してアラートを管理するアラートツール。
ユーザー提供のコンポーネント
- Grafana: データのクエリー、視覚化、および管理に使用できる可視化アプリケーションおよび解析アプリケーション。
- Elasticsearch: Smart Gateway が受信および転送した RHOSP イベントを保存するイベントデータストレージ。
以下の表は、クライアントおよびサーバーコンポーネントのアプリケーションを説明しています。
| コンポーネント | クライアント | Server |
|---|---|---|
| AMQP 1.x と互換性のあるメッセージングバス | はい | はい |
| Smart Gateway | いいえ | はい |
| Prometheus | いいえ | はい |
| Elasticsearch | いいえ | はい |
| Grafana | いいえ | はい |
| 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 Extended Update Support (EUS) リリース 4.12 および 4.14
- インフラストラクチャープラットフォーム
Red Hat OpenShift Container Platform EUS リリースの詳細は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
図1.2 サーバーサイドの STF 監視インフラストラクチャー
1.2.1. STF アーキテクチャーの変更
1.5.3 より前の STF のリリースでは、Service Telemetry Operator は Elastic Cloud on Kubernetes (ECK) Operator に Elasticsearch のインスタンスを要求しました。現在、STF は転送モデルを使用するようになり、イベントが Smart Gateway インスタンスからユーザー提供の Elasticsearch インスタンスに転送されます。
Service Telemetry Operator による Elasticsearch インスタンスの管理は、非推奨になりました。
新しい ServiceTelemetry デプロイメントでは、observabilityStrategy パラメーターの値は use_redhat であり、ECK から Elasticsearch インスタンスを要求しません。STF バージョン 1.5.2 以前を使用し、1.5.3 に更新された ServiceTelemetry のデプロイメントでは、observabilityStrategy パラメーターが use_community に設定されます。これは、以前のアーキテクチャーと一致します。
ユーザーが以前に STF を使用して Elasticsearch インスタンスをデプロイしていた場合、Service Telemetry Operator は observabilityStrategy パラメーターが use_community になるように ServiceTelemetry カスタムリソースオブジェクトを更新し、以前のリリースと同様に機能するようにします。可観測性ストラテジーの詳細は、「Service Telemetry Framework の可観測性ストラテジー」 を参照してください。
STF のユーザーには、use_redhat 可観測性ストラテジーへの移行が推奨されます。use_redhat 可観測性ストラテジーへの移行の詳細は、Red Hat ナレッジベースの Migrating Service Telemetry Framework to fully supported operators を参照してください。
