Chapter 5. Using operational features of Service Telemetry Framework

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. Deploy the 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

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

   $ oc get csv --selector operators.coreos.com/grafana-operator.service-telemetry
   
   NAME                       DISPLAY            VERSION   REPLACES                   PHASE
   grafana-operator.v3.10.3   Grafana Operator   3.10.3    grafana-operator.v3.10.2   Succeeded

5. To launch a Grafana instance, create or modify the ServiceTelemetry object. Set graphing.enabled and graphing.grafana.ingressEnabled to true:

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

6. Verify that the Grafana instance deployed:

   $ oc get pod -l app=grafana
   
   NAME                                  READY   STATUS    RESTARTS   AGE
   grafana-deployment-7fc7848b56-sbkhv   1/1     Running   0          1m

7. Verify that the Grafana data sources installed correctly:

   $ oc get grafanadatasources
   
   NAME                    AGE
   default-datasources     20h

8. Verify that the Grafana route exists:

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

Procedure

1. Ensure that you have the correct version of Grafana:

   $ oc get pod -l "app=grafana" -ojsonpath='{.items[0].spec.containers[0].image}'
   docker.io/grafana/grafana:7.3.10

2. If the running image is older than 8.1.0, patch the ServiceTelemetry object to update the image. Service Telemetry Operator updates the Grafana manifest, which restarts the Grafana deployment:

   $ oc patch stf/default --type merge -p '{"spec":{"graphing":{"grafana":{"baseImage":"docker.io/grafana/grafana:8.1.5"}}}}'

3. Verify that a new Grafana pod exists and has a STATUS value of Running:

   $ oc get pod -l "app=grafana"
   NAME                                 READY     STATUS    RESTARTS   AGE
   grafana-deployment-fb9799b58-j2hj2   1/1       Running   0          10s

4. Verify that the new instance is running the updated image:

   $ oc get pod -l "app=grafana" -ojsonpath='{.items[0].spec.containers[0].image}'
   docker.io/grafana/grafana:8.1.0

Procedure

1. Import the infrastructure dashboard:

   $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-dashboard.yaml
   
   grafanadashboard.integreatly.org/rhos-dashboard-1.3 created

2. Import the cloud dashboard:

   Warning

   For some panels in the cloud dashboard, you must set the value of the collectd virt plugin parameter hostname_format to name uuid hostname in the stf-connectors.yaml file. If you do not configure this parameter, affected dashboards remain empty. For more information about the virt plugin, see collectd plugins.

   $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloud-dashboard.yaml
   
   grafanadashboard.integreatly.org/rhos-cloud-dashboard-1.3 created

3. Import the cloud events dashboard:

   $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloudevents-dashboard.yaml
   
   grafanadashboard.integreatly.org/rhos-cloudevents-dashboard created

4. Import the virtual machine dashboard:

   $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/virtual-machine-view.yaml
   
   grafanadashboard.integreatly.org/virtual-machine-view-1.3 configured

5. Import the memcached dashboard:

   $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/memcached-dashboard.yaml
   
   grafanadashboard.integreatly.org/memcached-dashboard-1.3 created

6. Verify that the dashboards are available:

   $ oc get grafanadashboards
   
   NAME                   AGE
   memcached-dashboard-1.3      115s
   rhos-cloud-dashboard-1.3     2m12s
   rhos-cloudevents-dashboard   2m6s
   rhos-dashboard-1.3           2m17s
   virtual-machine-view-1.3     2m

7. Retrieve the Grafana route address:

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

8. In a web browser, navigate to https://<grafana_route_address>. Replace <grafana_route_address> with the value that you retrieved in the previous step.
9. To view the dashboard, click Dashboards and Manage.

Procedure

1. Log in to Red Hat OpenShift Container Platform.

2. Change to the service-telemetry namespace:

   $ oc project service-telemetry

3. To retrieve the default username and password, describe the Grafana object:

   $ oc describe grafana default

4. To modify the default values of the Grafana administrator username and password through the ServiceTelemetry object, use the graphing.grafana.adminUser and graphing.grafana.adminPassword parameters.

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: stf-default
     namespace: service-telemetry
   spec:
     ...
     backends:
       metrics:
         prometheus:
           enabled: true
           storage:
             strategy: persistent
             retention: 7d
       ...

5. Save your changes and close the object.

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.coreos.com/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 1
   EOF

   1

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

4. To verify that the Operator loaded the rules into Prometheus, create a pod with access to curl:

   $ oc run curl --image=radial/busyboxplus:curl -i --tty

5. Run the curl command to access the prometheus-operated service to return the rules loaded into memory:

   [ root@curl:/ ]$ curl prometheus-operated:9090/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 rate is zero","query":"rate(sg_total_collectd_msg_received_count[1m]) == 0","duration":0,"labels":{},"annotations":{},"alerts":[],"health":"ok","evaluationTime":0.000525886,"lastEvaluation":"2022-02-01T17:42:52.161007803Z","type":"alerting"}],"interval":30,"limit":0,"evaluationTime":0.000541524,"lastEvaluation":"2022-02-01T17:42:52.161000138Z"}]}}

6. To verify that the output shows the rules loaded into the PrometheusRule object, for example the output contains the defined ./openstack.rules, exit the pod:

   [ root@curl:/ ]$ exit

7. Clean up the environment by deleting the curl pod:

   $ oc delete pod curl
   
   pod "curl" deleted

Procedure

1. Use the oc edit command:

   $ oc edit prometheusrules 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. To verify the configuration is loaded into Alertmanager, create a pod with access to curl:

   $ oc run curl --image=radial/busyboxplus:curl -i --tty

7. Run the curl command against the alertmanager-operated service to retrieve the status and configYAML contents, and verify that the supplied configuration matches the configuration in Alertmanager:

   [ root@curl:/ ]$ curl alertmanager-operated:9093/api/v1/status
   
   {"status":"success","data":{"configYAML":"...",...}}

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

9. Exit the pod:

   [ root@curl:/ ]$ exit

10. To clean up the environment, delete the curl pod:

    $ oc delete pod curl
    
    pod "curl" 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 for your STF deployment:

   $ oc edit stf default

4. To deploy a custom Alertmanager route with STF, you must pass an alertmanagerConfigManifest parameter to the Service Telemetry Operator that results in an updated secret that is managed by the Prometheus Operator:

   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
       data:
         alertmanager.yaml: Z2xvYmFsOgogIHJlc29sdmVfdGltZW91dDogMTBtCiAgc2xhY2tfYXBpX3VybDogPHNsYWNrX2FwaV91cmw+CnJlY2VpdmVyczoKICAtIG5hbWU6IHNsYWNrCiAgICBzbGFja19jb25maWdzOgogICAgLSBjaGFubmVsOiAjc3RmLWFsZXJ0cwogICAgICB0aXRsZTogfC0KICAgICAgICAuLi4KICAgICAgdGV4dDogPi0KICAgICAgICAuLi4Kcm91dGU6CiAgZ3JvdXBfYnk6IFsnam9iJ10KICBncm91cF93YWl0OiAzMHMKICBncm91cF9pbnRlcnZhbDogNW0KICByZXBlYXRfaW50ZXJ2YWw6IDEyaAogIHJlY2VpdmVyOiAnc2xhY2snCg==

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
     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. To verify that the configuration loaded into Alertmanager, create a pod with access to the curl command:

   $ oc run curl --image=radial/busyboxplus:curl -i --tty

7. Run the curl command against the alertmanager-operated service to retrieve the status and configYAML contents, and verify that the supplied configuration matches the configuration in Alertmanager:

   [ root@curl:/ ]$ curl alertmanager-operated:9093/api/v1/status
   
   {"status":"success","data":{"configYAML":"...",...}}

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

9. Exit the pod:

   [ root@curl:/ ]$ exit

10. To clean up the environment, delete the curl pod:

    $ oc delete pod curl
    
    pod "curl" deleted

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. 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 the ...storage.strategy: ephemeral parameter to the spec section of the relevant component:

   apiVersion: infra.watch/v1beta1
   kind: ServiceTelemetry
   metadata:
     name: stf-default
     namespace: service-telemetry
   spec:
     alerting:
       enabled: true
       alertmanager:
         storage:
           strategy: ephemeral
     backends:
       metrics:
         prometheus:
           enabled: true
           storage:
             strategy: ephemeral
       events:
         elasticsearch:
           enabled: true
           storage:
             strategy: ephemeral

5. Save your changes and close the object.

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.4, “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.4, “Deploying the overcloud”.