OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。
「Red Hat OpenStack Platform 13と16の機能差分」という記事で、RHOSP 16から従来どおりのTelemetryがデフォルトでdisableになりService Telemetry Frameworkが推奨されていることを記載しました。今回はこのService Telemetry Frameworkについて説明いたします。
Service Telemetry Framework
Service Telemetry FrameworkはRed Hat OpenShift Container Platform(以降OCP)上で稼働します。このOCPは、Telemetryの対象となるRHOSPとは独立している必要があります。
RHOSPのTelemetryの話なのに、いきなりOCPなのか?とツッコミたくなるかもしれませんが、将来的にはService Telemetry Frameworkを利用して複数のクラウド環境を集中管理したいという考えがあり、OCPではスケーラブルなモニタリング環境を稼働させることが可能なため、これを利用する方向になっています。OCPとRHOSPの環境は弊社のラボ環境を使用しています。宣伝になりますが、OpenShiftのコンセプトと基本的なクラスタ管理方法を学べる「Containers and Cloud-Native Roadshow 2021」が5月末頃に開催されますので、興味があればご利用ください(ただしSTFは含まれません)。今回はOCPの環境が既にある前提でSTF導入・設定を行います。
環境および導入するコンポーネント
RHOSPとOCP環境と導入するコンポーネントは以下です。Service Telemetry Frameworkのデータ収集コンポーネントであるcollectd・Ceilometer、トランスポート用コンポーネント AMQ InterconnectとSmart GatewayはRed Hatがサポートします。PrometheusとElasticSearch、可視化コンポーネントGrafanaはコミュニティでサポートされているものを使用します。データ収集にcollectdとCeilometer両方利用するのは、collectdだけではOpenStackのメトリックを収集できないためです。
Red Hat OpenShift Container Platform 4.6
- AMQ Certificate Manager Operator
- Elastic Cloud on Kubernetes Operator
- Service Telemetry Operator(Service Telemetry Framework 1.2)
- Grafana operator
Red Hat OpenStack Platform 16.1
- AMQ Interconnect
- Ceilometer
- Collectd
公式ドキュメント:Service Telemetry Framework 1.2
実施する内容
- OCP環境にService Telemetry Frameworkをデプロイ
- OCP内にServiceTelemetry objectを作成
- RHOSPをService Telemetry Frameworkを利用するように構成
- 動作確認
OCP環境にService Telemetry Frameworkをデプロイ
まずservice-telemetryのnamespaceを作成します。
$ oc new-project service-telemetry
OperatorGroupを作成します。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: service-telemetry-operator-group namespace: service-telemetry spec: targetNamespaces: - service-telemetry EOF
ElasticSearchやGrafanaなどコミュニティのOperatorを利用するため、OperatorHub.io Community Catalog Sourceを有効にします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-operators namespace: openshift-marketplace spec: sourceType: grpc image: quay.io/operator-framework/upstream-community-operators:latest displayName: OperatorHub.io Operators publisher: OperatorHub.io EOF
Service Telemetry Frameworkを利用するためにRed Hat STF Operators CatalogSourceを有効にします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: redhat-operators-stf namespace: openshift-marketplace spec: displayName: Red Hat STF Operators image: quay.io/redhat-operators-stf/stf-catalog:v4.6 publisher: Red Hat sourceType: grpc updateStrategy: registryPoll: interval: 30m EOF
AMQ Certificate Manager Operatorをデプロイします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq7-cert-manager-operator namespace: openshift-operators spec: channel: alpha installPlanApproval: Automatic name: amq7-cert-manager-operator source: redhat-operators-stf sourceNamespace: openshift-marketplace targetNamespaces: global EOF
ClusterServiceVersionを確認して「Succeeded」になっていることを確認します。
$ oc get --namespace openshift-operators csv NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.0 Red Hat Integration - AMQ Certificate Manager 1.0.0 Succeeded
Kubernetes OperatorのElastic Cloudをデプロイします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: elastic-cloud-eck namespace: service-telemetry spec: channel: stable installPlanApproval: Automatic name: elastic-cloud-eck source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
Service Telemetry Operatorをデプロイします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: service-telemetry-operator namespace: service-telemetry spec: channel: stable-1.2 installPlanApproval: Automatic name: service-telemetry-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
公式ドキュメントの中では後のステップで行っていますが、Dashboradを利用するためにGrafana Operatorをデプロイします。
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana-operator namespace: service-telemetry spec: channel: alpha installPlanApproval: Automatic name: grafana-operator source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
必要なコンポーネントがすべて正常にデプロイされているか確認します。
$ oc get csv --namespace service-telemetry NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.0 Red Hat Integration - AMQ Certificate Manager 1.0.0 Succeeded amq7-interconnect-operator.v1.2.3 Red Hat Integration - AMQ Interconnect 1.2.3 amq7-interconnect-operator.v1.2.2 Succeeded elastic-cloud-eck.v1.4.0 Elasticsearch (ECK) Operator 1.4.0 elastic-cloud-eck.v1.3.1 Succeeded grafana-operator.v3.9.0 Grafana Operator 3.9.0 grafana-operator.v3.8.1 Succeeded prometheusoperator.0.37.0 Prometheus Operator 0.37.0 prometheusoperator.0.32.0 Succeeded service-telemetry-operator.v1.2.1 Service Telemetry Operator 1.2.1 Succeeded smart-gateway-operator.v2.2.1 Smart Gateway Operator 2.2.1 Succeeded
CLIで操作を行ってきましたが、OpenShift コンソールで見るとProject: service-telemetryの「Installed Operators」に表示されています。
OCP内にServiceTelemetry objectを作成
ServiceTelemetry objectの主要なパラメーターは以下になります。
- alerting
- Prometheusにアラートのルールを作成し、Alertmanagerにアラートを送信します。
- backends
- メトリックとイベントを保存するためのストレージの有効化とストレージの指定を行います。現時点ではメトリックのバックエンドはPrometheus、イベントのバックエンドはElasticSearchです。
- clouds
- STFに接続するクラウドを定義し、メトリックとイベントのcollectorを指定します。
- graphing
- collectdで収集されたメトリックをGrafanaを使って可視化する設定を行います。
- highAvailability
- STFのコンポーネントの冗長設定を行います。現状ではSTFは完全なfault tolerant systemではなく、リカバー中のメトリックやイベントは保証されません。
- transports
- STFのメッセージバスの有効化と設定を行います。現状ではAMQ Interconnectのみがサポートされます。
alertingやgraphingなど使いたいサービスをenabled:trueに設定してServiceTelemetry objectを作成します。OpenStackのメトリックやイベント収集のためにclouds parameter を指定します。(以下の内容は一例です、必要に応じて編集してください)
apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default spec: alerting: enabled: true alertmanager: storage: strategy: persistent persistent: storageSelector: {} pvcStorageRequest: 20G backends: metrics: prometheus: enabled: true scrapeInterval: 10s storage: strategy: persistent retention: 24h persistent: storageSelector: {} pvcStorageRequest: 20G events: elasticsearch: enabled: true storage: strategy: persistent persistent: pvcStorageRequest: 20Gi graphing: enabled: true grafana: ingressEnabled: false adminPassword: secret adminUser: root disableSignoutMenu: false transports: qdr: enabled: true web: enabled: false highAvailability: enabled: false clouds: - name: cloud1 metrics: collectors: - collectorType: collectd subscriptionAddress: collectd/telemetry - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/metering.sample events: collectors: - collectorType: collectd subscriptionAddress: collectd/notify - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/event.sample
ServiceTelemetry objectが作成されると、設定された内容に従ってPodが稼働します。
$ oc get pods NAME READY STATUS RESTARTS AGE alertmanager-default-0 2/2 Running 0 2d5h default-cloud1-ceil-event-smartgateway-5f8ff46bfb-bdbzd 1/1 Running 3 2d4h default-cloud1-ceil-meter-smartgateway-5ff6cd4bbb-gl6kf 1/1 Running 0 2d5h default-cloud1-coll-event-smartgateway-54fc6cd9b4-zlb8f 1/1 Running 3 2d4h default-cloud1-coll-meter-smartgateway-8446fc88d9-wwvzr 2/2 Running 0 2d5h default-interconnect-668d5bbcd6-dtxd4 1/1 Running 0 2d5h elastic-operator-6dd57fb74b-746pw 1/1 Running 0 2d9h elasticsearch-es-default-0 1/1 Running 0 2d4h grafana-deployment-76dccbcfcd-r45d6 1/1 Running 0 43h grafana-operator-7456f8c54f-zfrzd 1/1 Running 0 2d9h interconnect-operator-69df6b9cb6-j7868 1/1 Running 0 2d9h prometheus-default-0 3/3 Running 1 2d5h prometheus-operator-7fcbb6dbc9-qlxt7 1/1 Running 0 2d9h service-telemetry-operator-86764c5c44-874qt 2/2 Running 0 2d9h smart-gateway-operator-5c44c5947b-wr9bf 2/2 Running 0 2d9h
CLIだけでなく、OpenShift コンソールの[Developer]→[Toplogy]でも確認できます。
RHOSPをService Telemetry Frameworkを利用するように構成
OCP側の準備ができたところでRHOSPのデプロイを行います。既にundercloudのインストール、overcloudのデプロイの準備、STF以外のTemplateの準備は済んでる前提です。
OCP環境のCLIでservice-telemetryのAMQ Interconnect route addressを調べます。この環境では「default-interconnect-5671-service-telemetry.apps.cluster-5224.5224.sandbox605.opentlc.com」が結果として表示されています。
$ oc get routes -ogo-template='{{ range .items }}{{printf "%s\n" .spec.host }}{{ end }}' | grep "\-5671" default-interconnect-5671-service-telemetry.apps.cluster-5224.5224.sandbox605.opentlc.com
RHOSPでAMQ Interconnect route addressを指定するstf-connectors.yamlを作成し、STFを有効化するyamlファイルを指定してovercloudをデプロイします。
- stf-connectors.yaml作成
- 環境ファイルceilometer-write-qdr.yamlを指定
- 環境ファイルenable-stf.yaml
stf-connectors.yaml
[stack@undercloud ~]$ source ./stackrc (undercloud) [stack@undercloud ~]$ cat templates/stf-connectors.yaml parameter_defaults: EventPipelinePublishers: [] MetricPipelinePublishers: [] CeilometerQdrPublishEvents: true CeilometerQdrPublishMetrics: true MetricsQdrConnectors: - host: default-interconnect-5671-service-telemetry.apps.cluster-5224.5224.sandbox605.opentlc.com ←ここに先程の結果を記載 port: 443 role: edge sslProfile: sslProfile verifyHostname: false ExtraConfig: ceilometer::agent::polling::polling_interval: 5
ceilometer-write-qdr.yaml
(undercloud) [stack@undercloud environments]$ cat metrics/ceilometer-write-qdr.yaml ## This environment serves the purpose of enabling ceilometer to send telemetry and notification data ## through QPID dispatch routers. resource_registry: OS::TripleO::Services::CeilometerAgentCentral: ../../deployment/ceilometer/ceilometer-agent-central-container-puppet.yaml OS::TripleO::Services::CeilometerAgentNotification: ../../deployment/ceilometer/ceilometer-agent-notification-container-puppet.yaml OS::TripleO::Services::CeilometerAgentIpmi: ../../deployment/ceilometer/ceilometer-agent-ipmi-container-puppet.yaml OS::TripleO::Services::ComputeCeilometerAgent: ../../deployment/ceilometer/ceilometer-agent-compute-container-puppet.yaml OS::TripleO::Services::Redis: ../../deployment/database/redis-pacemaker-puppet.yaml parameter_defaults: CeilometerEnablePanko: false CeilometerQdrPublish: true (undercloud) [stack@undercloud environments]$
enable-stf.yaml
(undercloud) [stack@undercloud environments]$ cat enable-stf.yaml # This heat environment can be used to enable STF client side resource_registry: OS::TripleO::Services::Collectd: ../deployment/metrics/collectd-container-puppet.yaml OS::TripleO::Services::MetricsQdr: ../deployment/metrics/qdr-container-puppet.yaml OS::TripleO::Services::Redis: ../deployment/database/redis-pacemaker-puppet.yaml # We want these when smartgateway is able to process ceilometer messages # OS::TripleO::Services::CeilometerAgentCentral: ../deployment/ceilometer/ceilometer-agent-central-container-puppet.yaml # OS::TripleO::Services::CeilometerAgentNotification: ../deployment/ceilometer/ceilometer-agent-notification-container-puppet.yaml # OS::TripleO::Services::ComputeCeilometerAgent: ../deployment/ceilometer/ceilometer-agent-compute-container-puppet.yaml parameter_defaults: # Uncomment when smartgateway can handle ceilometer messages # CeilometerQdrPublish: true EnableSTF: true CollectdConnectionType: amqp1 CollectdAmqpInterval: 5 CollectdDefaultPollingInterval: 5 CollectdAmqpInstances: notify: notify: true format: JSON presettle: false telemetry: format: JSON presettle: true MetricsQdrAddresses: - prefix: collectd distribution: multicast MetricsQdrSSLProfiles: - name: sslProfile # The snippet below should be added to a separate yaml file, edited, and # passed in at deploy time. #MetricsQdrConnectors: # - host: qdr-normal-sa-telemetry.apps.remote.tld # port: 443 # role: edge # sslProfile: sslProfile # verifyHostname: false (undercloud) [stack@undercloud environments]$
上記3ファイルを指定してデプロイするshを作ってデプロイします。
#!/bin/bash THT=/usr/share/openstack-tripleo-heat-templates/ CNF=/home/stack/templates/ openstack overcloud deploy --templates $THT \ -r $CNF/roles_data.yaml \ -n $CNF/network_data.yaml \ -e ~/containers-prepare-parameter.yaml \ -e $CNF/environments/node-info.yaml \ -e $THT/environments/network-isolation.yaml \ -e $CNF/environments/network-environment.yaml \ -e $CNF/environments/ips-from-pool-all.yaml \ -e $CNF/scheduler-hints.yaml \ -e $CNF/environments/fix-nova-reserved-host-memory.yaml \ -e $THT/environments/metrics/ceilometer-write-qdr.yaml \ -e $THT/environments/enable-stf.yaml \ -e $CNF/stf-connectors.yaml
動作確認
RHOSP側
デプロイされたovercloudのノードで該当するコンテナのAMQの設定内容を確認することができます。
(undercloud) [stack@undercloud ~]$ openstack server list +--------------------------------------+-------------------------+--------+---------------------+----------------+-----------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------------------+--------+---------------------+----------------+-----------+ | 19247b16-d920-411a-8885-67949b85e4d6 | overcloud-controller-2 | ACTIVE | ctlplane=192.0.2.12 | overcloud-full | baremetal | | 08a228bb-6190-46ce-b4c4-81b594c99667 | overcloud-controller-0 | ACTIVE | ctlplane=192.0.2.20 | overcloud-full | baremetal | | 2c45ccd4-3777-478d-9a6c-918e25853415 | overcloud-controller-1 | ACTIVE | ctlplane=192.0.2.16 | overcloud-full | baremetal | | a402a393-61b7-4036-a865-728c0984ffa3 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.0.2.23 | overcloud-full | baremetal | | b83d7e27-fbc3-4a8e-8f27-d35c01cb3490 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.0.2.11 | overcloud-full | baremetal | +--------------------------------------+-------------------------+--------+---------------------+----------------+-----------+ (undercloud) [stack@undercloud ~]$ ssh heat-admin@192.0.2.20 [heat-admin@overcloud-controller-0 ~]$ sudo podman container inspect --format '{{.State.Status}}' metrics_qdr running [heat-admin@overcloud-controller-0 ~]$ sudo podman exec -it metrics_qdr cat /etc/qpid-dispatch/qdrouterd.conf router { mode: edge id: Router.overcloud-controller-0.localdomain workerThreads: 2 debugDump: /var/log/qdrouterd saslConfigPath: /etc/sasl2 saslConfigName: qdrouterd } sslProfile { name: sslProfile } listener { host: 172.17.0.201 port: 5666 authenticatePeer: no saslMechanisms: ANONYMOUS } connector { host: default-interconnect-5671-service-telemetry.apps.cluster-5224.5224.sandbox605.opentlc.com port: 443 role: edge sslProfile: sslProfile verifyHostname: false } (略) address { distribution: multicast prefix: collectd }
コネクションの確認。以下の4つのコネクションがあることがわかります。
- Outbound connection to STF
- Inbound connection from ceilometer
- Inbound connection from collectd
- Inbound connection from our qdstat client
[heat-admin@overcloud-controller-0 ~]$ sudo podman exec -it metrics_qdr qdstat --bus=172.17.0.201:5666 --connections Connections id host container role dir security authentication tenant ================================================================================================================================================================================================================================================================================================== 2 172.17.0.201:44718 metrics normal in no-security anonymous-user 3 172.17.0.201:53288 openstack.org/om/container/overcloud-controller-0/ceilometer-agent-notification/23/164c3ee60fe54e0e85afcf7ba3f52166 normal in no-security no-auth 273 default-interconnect-5671-service-telemetry.apps.cluster-5224.5224.sandbox605.opentlc.com:443 default-interconnect-668d5bbcd6-dtxd4 edge out TLSv1.2(DHE-RSA-AES256-GCM-SHA384) anonymous-user 309 172.17.0.201:49654 10931bbe-0af8-448e-b92b-cacc9b8de4c7 normal in no-security no-auth
OCP側
AMQ Interconnect podの名前を元にしてコネクションの確認ができます。
$ oc get pods -l application=default-interconnect NAME READY STATUS RESTARTS AGE default-interconnect-668d5bbcd6-dtxd4 1/1 Running 0 2d6h $ oc exec -it default-interconnect-668d5bbcd6-dtxd4 -- qdstat --connections 2021-03-19 10:36:10.872461 UTC default-interconnect-668d5bbcd6-dtxd4 Connections id host container role dir security authentication tenant last dlv uptime ============================================================================================================================================================================================== 1 10.128.2.99:40234 bridge-36d edge in no-security anonymous-user 000:00:00:01 002:06:03:50 2 10.131.1.182:47508 rcv[default-cloud1-ceil-meter-smartgateway-5ff6cd4bbb-gl6kf] edge in no-security anonymous-user - 002:06:03:28 3 10.129.2.49:33336 rcv[default-cloud1-coll-event-smartgateway-54fc6cd9b4-zlb8f] normal in no-security anonymous-user - 002:05:32:19 4 10.129.2.50:47392 rcv[default-cloud1-ceil-event-smartgateway-5f8ff46bfb-bdbzd] normal in no-security anonymous-user 000:09:48:02 002:05:32:15 94 10.129.2.11:55704 Router.overcloud-controller-1.localdomain edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:01 000:03:16:02 95 10.128.2.6:53364 Router.overcloud-controller-2.localdomain edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:02 000:03:16:02 96 10.129.2.11:55762 Router.overcloud-controller-0.localdomain edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:01 000:03:15:59 98 127.0.0.1:57040 62680fcf-e316-4d03-8ddb-5a34010ed2e3 normal in no-security no-auth 000:00:00:00 000:00:00:00 $ oc exec -it default-interconnect-668d5bbcd6-dtxd4 -- qdstat --address 2021-03-19 10:39:13.304383 UTC default-interconnect-668d5bbcd6-dtxd4 Router Addresses class addr phs distrib pri local remote in out thru fallback ============================================================================================================================= mobile anycast/ceilometer/event.sample 0 balanced - 1 0 107 107 0 0 mobile anycast/ceilometer/metering.sample 0 balanced - 1 0 0 0 0 0 mobile collectd/notify 0 multicast - 1 0 0 0 0 0 mobile collectd/telemetry 0 multicast - 1 0 7,824,586 7,824,586 0 0
Dashboard
Service Telemetry Framework objectを作成する際にgraphingを有効化してあるので、OpenStackのノードのcollectdで収集されたメトリックをGrafanaで確認することができます。
Service Telemetry Frameworkは、日々機能改善が行われています。collectdのpluginも機能改善が行われ、より使いやすくなると思われます。機会があれば、またご紹介いたします。