Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. To store metrics in Prometheus, enable the Cluster Observability Operator by using the redhat-operators CatalogSource:

   $ oc create -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: cluster-observability-operator
     namespace: openshift-operators
   spec:
     channel: development
     installPlanApproval: Automatic
     name: cluster-observability-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

3. Verify that the ClusterServiceVersion for Cluster Observability Operator has a status of Succeeded:

   $ oc wait --for jsonpath="{.status.phase}"=Succeeded csv --namespace=openshift-operators -l operators.coreos.com/cluster-observability-operator.openshift-operators
   
   clusterserviceversion.operators.coreos.com/observability-operator.v0.0.26 condition met

Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. Verify cert-manager is not already installed on the Red Hat OpenShift Container Platform cluster. If any results are returned, do not install another instance of cert-manager:

   $ oc get sub --all-namespaces -o json | jq '.items[] | select(.metadata.name | match("cert-manager")) | .metadata.name'

3. Create a namespace for the cert-manager Operator:

   $ oc create -f - <<EOF
   apiVersion: project.openshift.io/v1
   kind: Project
   metadata:
     name: cert-manager-operator
   spec:
     finalizers:
     - kubernetes
   EOF

4. Create an OperatorGroup for the cert-manager Operator:

   $ oc create -f - <<EOF
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: cert-manager-operator
     namespace: cert-manager-operator
   spec:
     targetNamespaces:
     - cert-manager-operator
     upgradeStrategy: Default
   EOF

5. Subscribe to the cert-manager Operator by using the redhat-operators CatalogSource:

   $ oc create -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-cert-manager-operator
     namespace: cert-manager-operator
     labels:
       operators.coreos.com/openshift-cert-manager-operator.cert-manager-operator: ""
   spec:
     channel: stable-v1
     installPlanApproval: Automatic
     name: openshift-cert-manager-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

6. Validate your ClusterServiceVersion. Ensure that cert-manager Operator displays a phase of Succeeded:

   oc wait --for jsonpath="{.status.phase}"=Succeeded csv --namespace=cert-manager-operator --selector=operators.coreos.com/openshift-cert-manager-operator.cert-manager-operator
   
   clusterserviceversion.operators.coreos.com/cert-manager-operator.v1.12.1 condition met

Procedure

1. Create a namespace to contain the STF components, for example, service-telemetry:

   $ oc new-project service-telemetry

2. Create an OperatorGroup in the namespace so that you can schedule the Operator pods:

   $ oc create -f - <<EOF
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: service-telemetry-operator-group
     namespace: service-telemetry
   spec:
     targetNamespaces:
     - service-telemetry
   EOF

   For more information, see OperatorGroups.

3. Create the Service Telemetry Operator subscription to manage the STF instances:

   $ oc create -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: service-telemetry-operator
     namespace: service-telemetry
   spec:
     channel: stable-1.5
     installPlanApproval: Automatic
     name: service-telemetry-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

4. Validate the Service Telemetry Operator and the dependent operators have their phase as Succeeded:

   $ oc wait --for jsonpath="{.status.phase}"=Succeeded csv --namespace=service-telemetry -l operators.coreos.com/service-telemetry-operator.service-telemetry ; oc get csv --namespace service-telemetry
   
   clusterserviceversion.operators.coreos.com/service-telemetry-operator.v1.5.1700688542 condition met
   
   NAME                                         DISPLAY                                  VERSION          REPLACES                             PHASE
   amq7-interconnect-operator.v1.10.17          Red Hat Integration - AMQ Interconnect   1.10.17          amq7-interconnect-operator.v1.10.4   Succeeded
   observability-operator.v0.0.26               Cluster Observability Operator           0.1.0                                                 Succeeded
   service-telemetry-operator.v1.5.1700688542   Service Telemetry Operator               1.5.1700688542                                        Succeeded
   smart-gateway-operator.v5.0.1700688539       Smart Gateway Operator                   5.0.1700688539                                        Succeeded

Procedure

1. Edit the ServiceTelemetry object:

   $ oc edit stf default

2. Set the value of the backends.metrics.prometheus.enabled parameter to true:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     [...]
     backends:
       metrics:
         prometheus:
           enabled: true

Procedure

1. List the available storage classes:

   $ oc get storageclasses
   NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   csi-manila-ceph      manila.csi.openstack.org   Delete          Immediate              false                  20h
   standard (default)   kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   20h
   standard-csi         cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   20h

2. Edit the ServiceTelemetry object:

   $ oc edit stf default

3. Set the value of the backends.metrics.prometheus.enabled parameter to true and the value of backends.metrics.prometheus.storage.strategy to persistent:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     [...]
     backends:
       metrics:
         prometheus:
           enabled: true
           storage:
             strategy: persistent
             persistent:
               storageClass: standard-csi
               pvcStorageRequest: 50G

Procedure

1. Edit the ServiceTelemetry object:

   $ oc edit stf default

2. Set the value of the backends.events.elasticsearch.enabled parameter to true and configure the hostUrl with the relevant Elasticsearch instance:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     [...]
     backends:
       events:
         elasticsearch:
           enabled: true
           forwarding:
             hostUrl: https://external-elastic-http.domain:9200
             tlsServerName: ""
             tlsSecretName: elasticsearch-es-cert
             userSecretName: elasticsearch-es-elastic-user
             useBasicAuth: true
             useTls: true

3. Create the secret named in the userSecretName parameter to store the basic auth credentials

   $ oc create secret generic elasticsearch-es-elastic-user --from-literal=elastic='<PASSWORD>'

4. Copy the CA certificate into a file named EXTERNAL-ES-CA.pem, then create the secret named in the tlsSecretName parameter to make it available to STF

   $ cat EXTERNAL-ES-CA.pem
   -----BEGIN CERTIFICATE-----
   [...]
   -----END CERTIFICATE-----
   
   $ oc create secret generic elasticsearch-es-cert --from-file=ca.crt=EXTERNAL-ES-CA.pem

Procedure

1. View a list of available certificates in STF:

   $ oc get secrets

2. Retrieve and note the content of the default-interconnect-selfsigned Secret:

   $ oc get secret/default-interconnect-selfsigned -o jsonpath='{.data.ca\.crt}' | base64 -d

Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. Change to the service-telemetry project:

   $ oc project service-telemetry

3. Retrieve the AMQ Interconnect password:

   $ oc get secret default-interconnect-users -o json | jq -r .data.guest | base64 -d

Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. Change to the service-telemetry project:

   $ oc project service-telemetry

3. Retrieve the AMQ Interconnect route address:

   $ oc get routes -ogo-template='{{ range .items }}{{printf "%s\n" .spec.host }}{{ end }}' | grep "\-5671"
   default-interconnect-5671-service-telemetry.apps.infra.watch

Procedure

1. Log in to the undercloud host as the stack user.

2. Create a configuration file called enable-stf.yaml in the /home/stack directory.

   Important

   Setting PipelinePublishers to an empty list results in no metric data passing to RHOSP telemetry components, such as Gnocchi or Panko. If you need to send data to additional pipelines, the Ceilometer polling interval of 30 seconds, that you specify in ExtraConfig, might overwhelm the RHOSP telemetry components. You must increase the interval to a larger value, such as 300, which results in less telemetry resolution in STF.

Procedure

1. Log in to the undercloud host as the stack user.
2. Create a configuration file called stf-connectors.yaml in the /home/stack directory.

3. In the stf-connectors.yaml file, configure the MetricsQdrConnectors address to connect the AMQ Interconnect on the overcloud to the STF deployment. You configure the topic addresses for Sensubility, Ceilometer, and collectd in this file to match the defaults in STF. For more information about customizing topics and cloud configuration, see Section 4.3, “Configuring multiple clouds”.

   stf-connectors.yaml

   resource_registry:
     OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml
   
   parameter_defaults:
       ExtraConfig:
           qdr::router_id: "%{::hostname}.cloud1"
   
       MetricsQdrConnectors:
           - host: default-interconnect-5671-service-telemetry.apps.infra.watch
             port: 443
             role: edge
             verifyHostname: false
             sslProfile: sslProfile
             saslUsername: guest@default-interconnect
             saslPassword: pass:<password_from_stf>
   
       MetricsQdrSSLProfiles:
           - name: sslProfile
             caCertFileContent: |
               -----BEGIN CERTIFICATE-----
               <snip>
               -----END CERTIFICATE-----
   
       CeilometerQdrMetricsConfig:
           driver: amqp
           topic: cloud1-metering
   
       CollectdAmqpInstances:
           cloud1-telemetry:
               format: JSON
               presettle: false
   
       CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry

   • The qdr::router_id configuration is to override the default value which uses the fully-qualified domain name (FQDN) of the host. In some cases the FQDN can result in a router ID length of greater than 61 characters which results in failed QDR connections. For deployments with shorter FQDN values this is not necessary.
   • The resource_registry configuration directly loads the collectd service because you do not include the collectd-write-qdr.yaml environment file for multiple cloud deployments.
   • Replace the host sub-parameter of MetricsQdrConnectors with the value that you retrieved in Section 4.1.3, “Retrieving the AMQ Interconnect route address”.
   • Replace the <password_from_stf> portion of the saslPassword sub-parameter of MetricsQdrConnectors with the value you retrieved in Section 4.1.2, “Retrieving the AMQ Interconnect password”.
   • Replace the caCertFileContent parameter with the contents retrieved in Section 4.1.1, “Getting CA certificate from Service Telemetry Framework for overcloud configuration”.
   • Set topic value of CeilometerQdrMetricsConfig.topic to define the topic for Ceilometer metrics. The value is a unique topic identifier for the cloud such as cloud1-metering.
   • Set CollectdAmqpInstances sub-parameter to define the topic for collectd metrics. The section name is a unique topic identifier for the cloud such as cloud1-telemetry.
   • Set CollectdSensubilityResultsChannel to define the topic for collectd-sensubility events. The value is a unique topic identifier for the cloud such as sensubility/cloud1-telemetry.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Add your data collection and AMQ Interconnect environment files to the stack with your other environment files and deploy the overcloud:

   (undercloud)$ openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \
    -e /home/stack/enable-stf.yaml \
    -e /home/stack/stf-connectors.yaml

   • Include the ceilometer-write-qdr.yaml file to ensure that Ceilometer telemetry is sent to STF.
   • Include the qdr-edge-only.yaml file to ensure that the message bus is enabled and connected to STF message bus routers.
   • Include the enable-stf.yaml environment file to ensure that the defaults are configured correctly.
   • Include the stf-connectors.yaml environment file to define the connection to STF.

Procedure

1. Log in to an overcloud node, for example, controller-0.

2. Ensure that the metrics_qdr and collection agent containers are running on the node:

   $ sudo podman container inspect --format '{{.State.Status}}' metrics_qdr collectd ceilometer_agent_notification ceilometer_agent_central
   running
   running
   running
   running

   Note

   Use this command on compute nodes:

   $ sudo podman container inspect --format '{{.State.Status}}' metrics_qdr collectd ceilometer_agent_compute

3. Return the internal network address on which AMQ Interconnect is running, for example, 172.17.1.44 listening on port 5666:

   $ sudo podman exec -it metrics_qdr cat /etc/qpid-dispatch/qdrouterd.conf
   
   listener {
       host: 172.17.1.44
       port: 5666
       authenticatePeer: no
       saslMechanisms: ANONYMOUS
   }

4. Return a list of connections to the local AMQ Interconnect:

   $ sudo podman exec -it metrics_qdr qdstat --bus=172.17.1.44:5666 --connections
   
   Connections
     id   host                                                                  container                                                                                                  role    dir  security                            authentication  tenant
     ============================================================================================================================================================================================================================================================================================
     1    default-interconnect-5671-service-telemetry.apps.infra.watch:443      default-interconnect-7458fd4d69-bgzfb                                                                      edge    out  TLSv1.2(DHE-RSA-AES256-GCM-SHA384)  anonymous-user
     12   172.17.1.44:60290                                                     openstack.org/om/container/controller-0/ceilometer-agent-notification/25/5c02cee550f143ec9ea030db5cccba14  normal  in   no-security                         no-auth
     16   172.17.1.44:36408                                                     metrics                                                                                                    normal  in   no-security                         anonymous-user
     899  172.17.1.44:39500                                                     10a2e99d-1b8a-4329-b48c-4335e5f75c84                                                                       normal  in   no-security                         no-auth

   There are four connections:

   • Outbound connection to STF
   • Inbound connection from ceilometer
   • Inbound connection from collectd

   • Inbound connection from our qdstat client

     The outbound STF connection is provided to the MetricsQdrConnectors host parameter and is the route for the STF storage domain. The other hosts are internal network addresses of the client connections to this AMQ Interconnect.

5. To ensure that messages are delivered, list the links, and view the _edge address in the deliv column for delivery of messages:

   $ sudo podman exec -it metrics_qdr qdstat --bus=172.17.1.44:5666 --links
   Router Links
     type      dir  conn id  id    peer  class   addr                  phs  cap  pri  undel  unsett  deliv    presett  psdrop  acc  rej  rel     mod  delay  rate
     ===========================================================================================================================================================
     endpoint  out  1        5           local   _edge                      250  0    0      0       2979926  0        0       0    0    2979926 0    0      0
     endpoint  in   1        6                                              250  0    0      0       0        0        0       0    0    0       0    0      0
     endpoint  in   1        7                                              250  0    0      0       0        0        0       0    0    0       0    0      0
     endpoint  out  1        8                                              250  0    0      0       0        0        0       0    0    0       0    0      0
     endpoint  in   1        9                                              250  0    0      0       0        0        0       0    0    0       0    0      0
     endpoint  out  1        10                                             250  0    0      0       911      911      0       0    0    0       0    911    0
     endpoint  in   1        11                                             250  0    0      0       0        911      0       0    0    0       0    0      0
     endpoint  out  12       32          local   temp.lSY6Mcicol4J2Kp       250  0    0      0       0        0        0       0    0    0       0    0      0
     endpoint  in   16       41                                             250  0    0      0       2979924  0        0       0    0    2979924 0    0      0
     endpoint  in   912      1834        mobile  $management           0    250  0    0      0       1        0        0       1    0    0       0    0      0
     endpoint  out  912      1835        local   temp.9Ok2resI9tmt+CT       250  0    0      0       0        0        0       0    0    0       0    0      0

6. To list the addresses from RHOSP nodes to STF, connect to Red Hat OpenShift Container Platform to retrieve the AMQ Interconnect pod name and list the connections. List the available AMQ Interconnect pods:

   $ oc get pods -l application=default-interconnect
   
   NAME                                    READY   STATUS    RESTARTS   AGE
   default-interconnect-7458fd4d69-bgzfb   1/1     Running   0          6d21h

7. Connect to the pod and list the known connections. In this example, there are three edge connections from the RHOSP nodes with connection id 22, 23, and 24:

   $ oc exec -it deploy/default-interconnect -- qdstat --connections
   
   2020-04-21 18:25:47.243852 UTC
   default-interconnect-7458fd4d69-bgzfb
   
   Connections
     id  host               container                                                      role    dir  security                                authentication  tenant  last dlv      uptime
     ===============================================================================================================================================================================================
     5   10.129.0.110:48498  bridge-3f5                                                    edge    in   no-security                             anonymous-user          000:00:00:02  000:17:36:29
     6   10.129.0.111:43254  rcv[default-cloud1-ceil-meter-smartgateway-58f885c76d-xmxwn]  edge    in   no-security                             anonymous-user          000:00:00:02  000:17:36:20
     7   10.130.0.109:50518  rcv[default-cloud1-coll-event-smartgateway-58fbbd4485-rl9bd]  normal  in   no-security                             anonymous-user          -             000:17:36:11
     8   10.130.0.110:33802  rcv[default-cloud1-ceil-event-smartgateway-6cfb65478c-g5q82]  normal  in   no-security                             anonymous-user          000:01:26:18  000:17:36:05
     22  10.128.0.1:51948   Router.ceph-0.redhat.local                                     edge    in   TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384)  anonymous-user          000:00:00:03  000:22:08:43
     23  10.128.0.1:51950   Router.compute-0.redhat.local                                  edge    in   TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384)  anonymous-user          000:00:00:03  000:22:08:43
     24  10.128.0.1:52082   Router.controller-0.redhat.local                               edge    in   TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384)  anonymous-user          000:00:00:00  000:22:08:34
     27  127.0.0.1:42202    c2f541c1-4c97-4b37-a189-a396c08fb079                           normal  in   no-security                             no-auth                 000:00:00:00  000:00:00:00

8. To view the number of messages delivered by the network, use each address with the oc exec command:

   $ oc exec -it deploy/default-interconnect -- qdstat --address
   
   2020-04-21 18:20:10.293258 UTC
   default-interconnect-7458fd4d69-bgzfb
   
   Router Addresses
     class   addr                                phs  distrib    pri  local  remote  in           out          thru  fallback
     ==========================================================================================================================
     mobile  anycast/ceilometer/event.sample     0    balanced   -    1      0       970          970          0     0
     mobile  anycast/ceilometer/metering.sample  0    balanced   -    1      0       2,344,833    2,344,833    0     0
     mobile  collectd/notify                     0    multicast  -    1      0       70           70           0     0
     mobile  collectd/telemetry                  0    multicast  -    1      0       216,128,890  216,128,890  0     0

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Edit the default ServiceTelemetry object and add a clouds parameter with your configuration:

   Warning

   Long cloud names might exceed the maximum pod name of 63 characters. Ensure that the combination of the ServiceTelemetry name default and the clouds.name does not exceed 19 characters. Cloud names cannot contain any special characters, such as -. Limit cloud names to alphanumeric (a-z, 0-9).

   Topic addresses have no character limitation and can be different from the clouds.name value.

   $ oc edit stf default

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     ...
   spec:
     ...
     clouds:
     - name: cloud1
       events:
         collectors:
         - collectorType: collectd
           subscriptionAddress: collectd/cloud1-notify
         - collectorType: ceilometer
           subscriptionAddress: anycast/ceilometer/cloud1-event.sample
       metrics:
         collectors:
         - collectorType: collectd
           subscriptionAddress: collectd/cloud1-telemetry
         - collectorType: sensubility
           subscriptionAddress: sensubility/cloud1-telemetry
         - collectorType: ceilometer
           subscriptionAddress: anycast/ceilometer/cloud1-metering.sample
     - name: cloud2
       events:
         ...

4. Save the ServiceTelemetry object.

5. Verify that each Smart Gateway is running. This can take several minutes depending on the number of Smart Gateways:

   $ oc get po -l app=smart-gateway
   NAME                                                      READY   STATUS    RESTARTS   AGE
   default-cloud1-ceil-event-smartgateway-6cfb65478c-g5q82   2/2     Running   0          13h
   default-cloud1-ceil-meter-smartgateway-58f885c76d-xmxwn   2/2     Running   0          13h
   default-cloud1-coll-event-smartgateway-58fbbd4485-rl9bd   2/2     Running   0          13h
   default-cloud1-coll-meter-smartgateway-7c6fc495c4-jn728   2/2     Running   0          13h
   default-cloud1-sens-meter-smartgateway-8h4tc445a2-mm683   2/2     Running   0          13h

Procedure

1. Define your clouds parameter with the list of cloud objects that you want the Service Telemetry Operator to manage. For more information, see the section called “The clouds parameter”.

2. Edit the ServiceTelemetry object and add the cloudsRemoveOnMissing parameter:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     ...
   spec:
     ...
     cloudsRemoveOnMissing: true
     clouds:
       ...

3. Save the modifications.

4. Verify that the Operator deleted the Smart Gateways. This can take several minutes while the Operators reconcile the changes:

   $ oc get smartgateways

Procedure

1. Create a new environment file, for example, hostnames.yaml.

2. Set the CloudDomain parameter in the environment file, as shown in the following example:

   hostnames.yaml

   parameter_defaults:
       CloudDomain: newyork-west-04
       CephStorageHostnameFormat: 'ceph-%index%'
       ObjectStorageHostnameFormat: 'swift-%index%'
       ComputeHostnameFormat: 'compute-%index%'

3. Add the new environment file to your deployment.

Procedure

1. Log in to the undercloud host as the stack user.
2. Create a configuration file called stf-connectors.yaml in the /home/stack directory.

3. In the stf-connectors.yaml file, configure the MetricsQdrConnectors address to connect to the AMQ Interconnect on the overcloud deployment. Configure the CeilometerQdrMetricsConfig, CollectdAmqpInstances, and CollectdSensubilityResultsChannel topic values to match the AMQP address that you want for this cloud deployment.

   stf-connectors.yaml

   resource_registry:
     OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml
   
   parameter_defaults:
       ExtraConfig:
           qdr::router_id: %{::hostname}.cloud1
   
       MetricsQdrConnectors:
           - host: default-interconnect-5671-service-telemetry.apps.infra.watch
             port: 443
             role: edge
             verifyHostname: false
             sslProfile: sslProfile
   
       MetricsQdrSSLProfiles:
           - name: sslProfile
             caCertFileContent: |
               -----BEGIN CERTIFICATE-----
               <snip>
               -----END CERTIFICATE-----
   
       CeilometerQdrMetricsConfig:
           driver: amqp
           topic: cloud1-metering
   
       CollectdAmqpInstances:
           cloud1-telemetry:
               format: JSON
               presettle: false
   
       CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry

   • The qdr::router_id configuration is to override the default value which uses the fully-qualified domain name (FQDN) of the host. In some cases the FQDN can result in a router ID length of greater than 61 characters which results in failed QDR connections. For deployments with shorter FQDN values this is not necessary.
   • The resource_registry configuration directly loads the collectd service because you do not include the collectd-write-qdr.yaml environment file for multiple cloud deployments.
   • Replace the host parameter with the value that you retrieved in Section 4.1.3, “Retrieving the AMQ Interconnect route address”.
   • Replace the caCertFileContent parameter with the contents retrieved in Section 4.1.1, “Getting CA certificate from Service Telemetry Framework for overcloud configuration”.
   • Replace the host sub-parameter of MetricsQdrConnectors with the value that you retrieved in Section 4.1.3, “Retrieving the AMQ Interconnect route address”.
   • Set topic value of CeilometerQdrMetricsConfig.topic to define the topic for Ceilometer metrics. The value is a unique topic identifier for the cloud such as cloud1-metering.
   • Set CollectdAmqpInstances sub-parameter to define the topic for collectd metrics. The section name is a unique topic identifier for the cloud such as cloud1-telemetry.

   • Set CollectdSensubilityResultsChannel to define the topic for collectd-sensubility events. The value is a unique topic identifier for the cloud such as sensubility/cloud1-telemetry.

     Note

     When you define the topics for collectd and Ceilometer, the value you provide is transposed into the full topic that the Smart Gateway client uses to listen for messages.

     Ceilometer topic values are transposed into the topic address anycast/ceilometer/<TOPIC>.sample and collectd topic values are transposed into the topic address collectd/<TOPIC>. The value for sensubility is the full topic path and has no transposition from topic value to topic address.

     For an example of a cloud configuration in the ServiceTelemetry object referring to the full topic address, see the section called “The clouds parameter”.

4. Ensure that the naming convention in the stf-connectors.yaml file aligns with the spec.bridge.amqpUrl field in the Smart Gateway configuration. For example, configure the CeilometerQdrMetricsConfig.topic field to a value of cloud1-metering.
5. Log in to the undercloud host as the stack user.

6. Source the stackrc undercloud credentials file:

   $ source stackrc

7. Include the stf-connectors.yaml file and unique domain name environment file hostnames.yaml in the openstack overcloud deployment command, with any other environment files relevant to your environment:

   Warning

   If you use the collectd-write-qdr.yaml file with a custom CollectdAmqpInstances parameter, data publishes to the custom and default topics. In a multiple cloud environment, the configuration of the resource_registry parameter in the stf-connectors.yaml file loads the collectd service.

   (undercloud)$ openstack overcloud deploy --templates \
   -e [your environment files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \
   -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \
   -e /home/stack/hostnames.yaml \
   -e /home/stack/enable-stf.yaml \
   -e /home/stack/stf-connectors.yaml

8. Deploy the Red Hat OpenStack Platform overcloud.

Procedure

1. View a list of available certificates in STF:

   $ oc get secrets

2. Retrieve and note the content of the default-interconnect-selfsigned Secret:

   $ oc get secret/default-interconnect-selfsigned -o jsonpath='{.data.ca\.crt}' | base64 -d

Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. Change to the service-telemetry project:

   $ oc project service-telemetry

3. Retrieve the AMQ Interconnect route address:

   $ oc get routes -ogo-template='{{ range .items }}{{printf "%s\n" .spec.host }}{{ end }}' | grep "\-5671"
   default-interconnect-5671-service-telemetry.apps.infra.watch

Procedure

1. Log in to the Red Hat OpenShift Container Platform environment where RHOSP director Operator is deployed and change to the project that hosts your RHOSP deployment:

   $ oc project openstack

2. Open the heat-env-config-deploy ConfigMap CR for editing:

   $ oc edit heat-env-config-deploy

3. Add the enable-stf.yaml configuration to the heat-env-config-deploy ConfigMap, save your edits and close the file:

   enable-stf.yaml

   apiVersion: v1
   data:
     [...]
     enable-stf.yaml: |
       parameter_defaults:
           # only send to STF, not other publishers
           PipelinePublishers: []
   
           # manage the polling and pipeline configuration files for Ceilometer agents
           ManagePolling: true
           ManagePipeline: true
           ManageEventPipeline: false
   
           # enable Ceilometer metrics and events
           CeilometerQdrPublishMetrics: true
   
           # enable collection of API status
           CollectdEnableSensubility: true
           CollectdSensubilityTransport: amqp1
   
           # enable collection of containerized service metrics
           CollectdEnableLibpodstats: true
   
           # set collectd overrides for higher telemetry resolution and extra plugins
           # to load
           CollectdConnectionType: amqp1
           CollectdAmqpInterval: 30
           CollectdDefaultPollingInterval: 30
           CollectdExtraPlugins:
           - vmem
   
           # set standard prefixes for where metrics are published to QDR
           MetricsQdrAddresses:
           - prefix: 'collectd'
             distribution: multicast
           - prefix: 'anycast/ceilometer'
             distribution: multicast
   
           ExtraConfig:
              ceilometer::agent::polling::polling_interval: 30
              ceilometer::agent::polling::polling_meters:
              - cpu
              - memory.usage
   
              # to avoid filling the memory buffers if disconnected from the message bus
              # note: this may need an adjustment if there are many metrics to be sent.
              collectd::plugin::amqp1::send_queue_limit: 5000
   
              # receive extra information about virtual memory
              collectd::plugin::vmem::verbose: true
   
              # provide name and uuid in addition to hostname for better correlation
              # to ceilometer data
              collectd::plugin::virt::hostname_format: "name uuid hostname"
   
              # provide the human-friendly name of the virtual instance
              collectd::plugin:ConfigMap :virt::plugin_instance_format: metadata
   
              # set memcached collectd plugin to report its metrics by hostname
              # rather than host IP, ensuring metrics in the dashboard remain uniform
              collectd::plugin::memcached::instances:
                local:
                  host: "%{hiera('fqdn_canonical')}"
                  port: 11211

Procedure

1. Log in to the Red Hat OpenShift Container Platform environment where RHOSP director Operator is deployed and change to the project that hosts your RHOSP deployment:

   $ oc project openstack

2. Open the heat-env-config-deploy ConfigMap for editing:

   $ oc edit configmap heat-env-config-deploy

3. Add your stf-connectors.yaml configuration to the heat-env-config-deploy ConfigMap, appropriate to your environment, save your edits and close the file:

   stf-connectors.yaml

   apiVersion: v1
   data:
     [...]
     stf-connectors.yaml: |
       resource_registry:
         OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml
   
       parameter_defaults:
           MetricsQdrConnectors:
               - host: default-interconnect-5671-service-telemetry.apps.ostest.test.metalkube.org
                 port: 443
                 role: edge
                 verifyHostname: false
                 sslProfile: sslProfile
                 saslUsername: guest@default-interconnect
                 saslPassword: pass:<password_from_stf>
   
           MetricsQdrSSLProfiles:
               - name: sslProfile
   
           CeilometerQdrMetricsConfig:
               driver: amqp
               topic: cloud1-metering
   
           CollectdAmqpInstances:
               cloud1-telemetry:
                   format: JSON
                   presettle: false
   
           CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry

Procedure

1. Log in to the Red Hat OpenShift Container Platform environment where RHOSP director Operator is deployed and change to the project that hosts your RHOSP deployment:

   $ oc project openstack

2. Open the OpenStackConfigGenerator custom resource for editing:

   $ oc edit OpenStackConfigGenerator

3. Add the metrics/ceilometer-write-qdr.yaml and metrics/qdr-edge-only.yaml environment files as values for the heatEnvs parameter. Save your edits, and close the OpenStackConfigGenerator custom resource:

   Note

   If you already deployed a Red Hat OpenStack Platform environment using director Operator, you must delete the existing OpenStackConfigGenerator and create a new object with the full configuration in order to re-generate the OpenStackConfigVersion.

   OpenStackConfigGenerator

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default
     namespace: openstack
   spec:
     heatEnvConfigMap: heat-env-config-deploy
     heatEnvs:
     - <existing_environment_file_references>
     - metrics/ceilometer-write-qdr.yaml
     - metrics/qdr-edge-only.yaml

4. If you already deployed a Red Hat OpenStack Platform environment using director Operator and generated a new OpenStackConfigVersion, edit the OpenStackDeploy object of your deployment, and set the value of spec.configVersion to the new OpenStackConfigVersion in order to update the overcloud deployment.

Procedure

1. Log in to your Red Hat OpenShift Container Platform environment where STF is hosted.

2. Subscribe to the Grafana Operator by using the community-operators CatalogSource:

   Warning

   Community Operators are Operators which have not been vetted or verified by Red Hat. Community Operators should be used with caution because their stability is unknown. Red Hat provides no support for community Operators.

   Learn more about Red Hat’s third party software support policy

   $ oc apply -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     labels:
       operators.coreos.com/grafana-operator.openshift-operators: ""
     name: grafana-operator
     namespace: openshift-operators
   spec:
     channel: v5
     installPlanApproval: Automatic
     name: grafana-operator
     source: community-operators
     sourceNamespace: openshift-marketplace
   EOF

3. Verify that the Operator launched successfully. In the command output, if the value of the PHASE column is Succeeded, the Operator launched successfully:

   $ oc wait --for jsonpath="{.status.phase}"=Succeeded csv --namespace openshift-operators -l operators.coreos.com/grafana-operator.openshift-operators
   
   clusterserviceversion.operators.coreos.com/grafana-operator.v5.6.0 condition met

4. To launch a Grafana instance, create or modify the ServiceTelemetry object. Set graphing.enabled and graphing.grafana.ingressEnabled to true. Optionally, set the value of graphing.grafana.baseImage to the Grafana workload container image that will be deployed:

   $ oc edit stf default
   
   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   ...
   spec:
     ...
     graphing:
       enabled: true
       grafana:
         ingressEnabled: true
         baseImage: 'registry.redhat.io/rhel8/grafana:9'

5. Verify that the Grafana instance deployed:

   $ oc wait --for jsonpath="{.status.phase}"=Running pod -l app=default-grafana --timeout=600s
   
   pod/default-grafana-deployment-669968df64-wz5s2 condition met

6. Verify that the Grafana data sources installed correctly:

   $ oc get grafanadatasources.grafana.integreatly.org
   
   NAME                        NO MATCHING INSTANCES   LAST RESYNC   AGE
   default-ds-stf-prometheus                           2m35s         2m56s

7. Verify that the Grafana route exists:

   $ oc get route default-grafana-route
   
   NAME                    HOST/PORT                                                   PATH   SERVICES                  PORT   TERMINATION   WILDCARD
   default-grafana-route   default-grafana-route-service-telemetry.apps.infra.watch           default-grafana-service   web    reencrypt     None

Procedure

1. To enable the managed dashboards, create or modify the ServiceTelemetry object. Set graphing.grafana.dashboards.enabled to true:

   $ oc edit stf default
   
   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   ...
   spec:
     ...
     graphing:
       enabled: true
       grafana:
         dashboards:
           enabled: true

2. Verify that the Grafana dashboards are created. The process of Service Telemetry Operator creating the dashboards might take some time.

   $ oc get grafanadashboards.grafana.integreatly.org
   
   NAME                          NO MATCHING INSTANCES   LAST RESYNC   AGE
   memcached-dashboard-1                                 38s           38s
   rhos-cloud-dashboard-1                                39s           39s
   rhos-dashboard-1                                      39s           39s
   virtual-machine-dashboard-1                           37s           37s

3. Retrieve the Grafana route address:

   $ oc get route default-grafana-route -ojsonpath='{.spec.host}'
   
   default-grafana-route-service-telemetry.apps.infra.watch

4. In a web browser, navigate to https://<grafana_route_address>. Replace <grafana_route_address> with the value that you retrieved in the previous step.
5. Log in with OpenShift credentials. For more information about logging in, see Section 3.3, “Accessing user interfaces for STF components”.
6. To view the dashboard, click Dashboards and Browse. The managed dashboards are available in the service-telemetry folder.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Create a new token secret for the stf-prometheus-reader service account

   $ oc create -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: my-prometheus-reader-token
     namespace: service-telemetry
     annotations:
       kubernetes.io/service-account.name: stf-prometheus-reader
   type: kubernetes.io/service-account-token
   EOF

4. Retrieve the token from the secret

   $ TOKEN=$(oc get secret my-prometheus-reader-token -o template='{{.data.token}}' | base64 -d)

5. Retrieve the Prometheus host name

   $ PROM_HOST=$(oc get route default-prometheus-proxy -ogo-template='{{ .spec.host }}')

6. Test the access token

   $ curl -k -H "Authorization: Bearer ${TOKEN}" https://${PROM_HOST}/api/v1/query?query=up
   
   {"status":"success",[...]

7. Configure your third-party tool with the PROM_HOST and TOKEN values from above

   $ echo $PROM_HOST
   $ echo $TOKEN

8. The token remains valid as long as the secret exists. You can revoke the token by deleting the secret.

   $ oc delete secret my-prometheus-reader-token
   secret "my-prometheus-reader-token" deleted

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Edit the ServiceTelemetry object:

   $ oc edit stf default

4. Add retention: 7d to the storage section of backends.metrics.prometheus.storage to increase the retention period to seven days:

   Note

   If you set a long retention period, retrieving data from heavily populated Prometheus systems can result in queries returning results slowly.

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     ...
     backends:
       metrics:
         prometheus:
           enabled: true
           storage:
             strategy: persistent
             retention: 7d
       ...

5. Save your changes and close the object.

6. Wait for prometheus to restart with the new settings.

   $ oc get po -l app.kubernetes.io/name=prometheus -w

7. Verify the new retention setting by checking the command line arguments used in the pod.

   $ oc describe po prometheus-default-0 | grep retention.time
         --storage.tsdb.retention.time=24h

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Create a PrometheusRule object that contains the alert rule. The Prometheus Operator loads the rule into Prometheus:

   $ oc apply -f - <<EOF
   apiVersion: monitoring.rhobs/v1
   kind: PrometheusRule
   metadata:
     creationTimestamp: null
     labels:
       prometheus: default
       role: alert-rules
     name: prometheus-alarm-rules
     namespace: service-telemetry
   spec:
     groups:
       - name: ./openstack.rules
         rules:
           - alert: Collectd metrics receive rate is zero
             expr: rate(sg_total_collectd_msg_received_count[1m]) == 0
   EOF

   To change the rule, edit the value of the expr parameter.

4. To verify that the Operator loaded the rules into Prometheus, run the curl command against the default-prometheus-proxy route with basic authentication:

   $ curl -k -H "Authorization: Bearer $(oc create token stf-prometheus-reader)" https://$(oc get route default-prometheus-proxy -ogo-template='{{ .spec.host }}')/api/v1/rules
   
   {"status":"success","data":{"groups":[{"name":"./openstack.rules","file":"/etc/prometheus/rules/prometheus-default-rulefiles-0/service-telemetry-prometheus-alarm-rules.yaml","rules":[{"state":"inactive","name":"Collectd metrics receive count is zero","query":"rate(sg_total_collectd_msg_received_count[1m]) == 0","duration":0,"labels":{},"annotations":{},"alerts":[],"health":"ok","evaluationTime":0.00034627,"lastEvaluation":"2021-12-07T17:23:22.160448028Z","type":"alerting"}],"interval":30,"evaluationTime":0.000353787,"lastEvaluation":"2021-12-07T17:23:22.160444017Z"}]}}

Procedure

1. Use the oc edit command:

   $ oc edit prometheusrules.monitoring.rhobs prometheus-alarm-rules

2. Edit the PrometheusRules manifest.
3. Save and close the manifest.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Edit the ServiceTelemetry object for your STF deployment:

   $ oc edit stf default

4. Add the new parameter alertmanagerConfigManifest and the Secret object contents to define the alertmanager.yaml configuration for Alertmanager:

   Note

   This step loads the default template that the Service Telemetry Operator manages. To verify that the changes are populating correctly, change a value, return the alertmanager-default secret, and verify that the new value is loaded into memory. For example, change the value of the parameter global.resolve_timeout from 5m to 10m.

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     backends:
       metrics:
         prometheus:
           enabled: true
     alertmanagerConfigManifest: |
       apiVersion: v1
       kind: Secret
       metadata:
         name: 'alertmanager-default'
         namespace: 'service-telemetry'
       type: Opaque
       stringData:
         alertmanager.yaml: |-
           global:
             resolve_timeout: 10m
           route:
             group_by: ['job']
             group_wait: 30s
             group_interval: 5m
             repeat_interval: 12h
             receiver: 'null'
           receivers:
           - name: 'null'

5. Verify that the configuration has been applied to the secret:

   $ oc get secret alertmanager-default -o go-template='{{index .data "alertmanager.yaml" | base64decode }}'
   
   global:
     resolve_timeout: 10m
   route:
     group_by: ['job']
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: 'null'
   receivers:
   - name: 'null'

6. Run the wget command from the prometheus pod against the alertmanager-proxy service to retrieve the status and configYAML contents, and verify that the supplied configuration matches the configuration in Alertmanager:

   $ oc exec -it prometheus-default-0 -c prometheus -- sh -c "wget --header \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status -q -O -"
   
   {"status":"success","data":{"configYAML":"...",...}}

7. Verify that the configYAML field contains the changes you expect.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Create the necessary alertmanager config in a file called alertmanager.yaml, for example:

   $ cat > alertmanager.yaml <<EOF
   global:
     resolve_timeout: 10m
     slack_api_url: <slack_api_url>
   receivers:
     - name: slack
       slack_configs:
       - channel: #stf-alerts
         title: |-
           ...
         text: >-
           ...
   route:
     group_by: ['job']
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: 'slack'
   EOF

4. Generate the config manifest and add it to the ServiceTelemetry object for your STF deployment:

   $ CONFIG_MANIFEST=$(oc create secret --dry-run=client generic alertmanager-default --from-file=alertmanager.yaml -o json)
   $ oc patch stf default --type=merge -p '{"spec":{"alertmanagerConfigManifest":'"$CONFIG_MANIFEST"'}}'

5. Verify that the configuration has been applied to the secret:

   Note

   There will be a short delay as the operators update each object

   $ oc get secret alertmanager-default -o go-template='{{index .data "alertmanager.yaml" | base64decode }}'
   
   global:
     resolve_timeout: 10m
     slack_api_url: <slack_api_url>
   receivers:
     - name: slack
       slack_configs:
       - channel: #stf-alerts
         title: |-
           ...
         text: >-
           ...
   route:
     group_by: ['job']
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: 'slack'

6. Run the wget command from the prometheus pod against the alertmanager-proxy service to retrieve the status and configYAML contents, and verify that the supplied configuration matches the configuration in Alertmanager:

   $ oc exec -it prometheus-default-0 -c prometheus -- /bin/sh -c "wget --header \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status -q -O -"
   
   {"status":"success","data":{"configYAML":"...",...}}

7. Verify that the configYAML field contains the changes you expect.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. To enable SNMP traps, modify the ServiceTelemetry object:

   $ oc edit stf default

4. Set the alerting.alertmanager.receivers.snmpTraps parameters:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   ...
   spec:
     ...
     alerting:
       alertmanager:
         receivers:
           snmpTraps:
             enabled: true
             target: 10.10.10.10

5. Ensure that you set the value of target to the IP address or hostname of the SNMP trap receiver.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Create a PrometheusRule object that contains the alert rule and an oid label that contains the SNMP trap OID override value:

   $ oc apply -f - <<EOF
   apiVersion: monitoring.rhobs/v1
   kind: PrometheusRule
   metadata:
     creationTimestamp: null
     labels:
       prometheus: default
       role: alert-rules
     name: prometheus-alarm-rules-snmp
     namespace: service-telemetry
   spec:
     groups:
       - name: ./openstack.rules
         rules:
           - alert: Collectd metrics receive rate is zero
             expr: rate(sg_total_collectd_msg_received_count[1m]) == 0
             labels:
               oid: 1.3.6.1.4.1.50495.15.1.2.1
               severity: critical
   EOF

Procedure

1. To edit the duration of the TLS certificate, you can set the QDR caCertDuration, for example 87600h for 10 years:

   $ oc apply -f - <<EOF
   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     transport:
       qdr:
         enabled: true
         certificates:
           caCertDuration: 87600h
   EOF

Verification

1. Verify that the expiry date for the certificate is correct:

   $ oc get secret  default-interconnect-selfsigned -o jsonpath='{.data.tls\.crt}' | base64 -d  | openssl x509 -in - -text | grep "Not After"
               Not After : Mar  9 21:00:16 2033 GMT

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Use the oc command to edit the ServiceTelemetry object:

   $ oc edit stf default

4. Add highAvailability.enabled: true to the spec section:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   ...
   spec:
     ...
     highAvailability:
       enabled: true

5. Save your changes and close the object.

Procedure

1. Create a ServiceTelemetry object with the property observabilityStrategy: none in the spec parameter. The manifest shows results in a default deployment of STF that is suitable for receiving telemetry from a single cloud with all metrics collector types.

   $ oc apply -f - <<EOF
   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: default
     namespace: service-telemetry
   spec:
     observabilityStrategy: none
   EOF

2. Delete the remaining objects that are managed by community operators

   $ for o in alertmanagers.monitoring.rhobs/default prometheuses.monitoring.rhobs/default elasticsearch/elasticsearch grafana/default-grafana; do oc delete $o; done

3. To verify that all workloads are operating correctly, view the pods and the status of each pod:

   $ oc get pods
   NAME                                                      READY   STATUS    RESTARTS   AGE
   default-cloud1-ceil-event-smartgateway-6f8547df6c-p2db5   3/3     Running   0          132m
   default-cloud1-ceil-meter-smartgateway-59c845d65b-gzhcs   3/3     Running   0          132m
   default-cloud1-coll-event-smartgateway-bf859f8d77-tzb66   3/3     Running   0          132m
   default-cloud1-coll-meter-smartgateway-75bbd948b9-d5phm   3/3     Running   0          132m
   default-cloud1-sens-meter-smartgateway-7fdbb57b6d-dh2g9   3/3     Running   0          132m
   default-interconnect-668d5bbcd6-57b2l                     1/1     Running   0          132m
   interconnect-operator-b8f5bb647-tlp5t                     1/1     Running   0          47h
   service-telemetry-operator-566b9dd695-wkvjq               1/1     Running   0          156m
   smart-gateway-operator-58d77dcf7-6xsq7                    1/1     Running   0          47h

Procedure

1. Open the stf-connectors.yaml file and add the CollectdEnableLibpodstats parameter to override the setting in enable-stf.yaml. Ensure that stf-connectors.yaml is called from the openstack overcloud deploy command after enable-stf.yaml:

     CollectdEnableLibpodstats: false

2. Continue with the overcloud deployment procedure. For more information, see Section 4.1.6, “Deploying the overcloud”.

Procedure

1. Open the stf-connectors.yaml and add the CollectdEnableSensubility parameter to override the setting in enable-stf.yaml. Ensure that stf-connectors.yaml is called from the openstack overcloud deploy command after enable-stf.yaml:

   CollectdEnableSensubility: false

2. Continue with the overcloud deployment procedure. For more information, see Section 4.1.6, “Deploying the overcloud”.