Service Telemetry Framework 1.5

Red Hat OpenStack Platform 17.1

安装和部署 Service Telemetry Framework 1.5

OpenStack Documentation Team

摘要

安装核心组件并部署 Service Telemetry Framework 1.5

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

在 JIRA 中提供文档反馈

使用 Create Issue 表单对文档提供反馈。JIRA 问题将在 Red Hat OpenStack Platform Jira 项目中创建，您可以在其中跟踪您的反馈进度。

  1. 确保您已登录到 JIRA。如果您没有 JIRA 帐户，请创建一个帐户来提交反馈。
  2. 点击以下链接打开 Create Issue 页面： Create Issue
  3. 完成 Summary 和 Description 字段。在 Description 字段中，包含文档 URL、章节或章节号以及问题的详细描述。不要修改表单中的任何其他字段。
  4. 点 Create。

第 1 章 Service Telemetry Framework 1.5 简介

Service Telemetry Framework (STF)从 Red Hat OpenStack Platform (RHOSP)或第三方节点收集监控数据。您可以使用 STF 执行以下任务：

  • 存储或归档监控数据以获取历史信息。
  • 在控制面板中以图形方式查看监控数据。
  • 使用监控数据来触发警报或警告。

监控数据可以是 metric 或 event：

指标
应用程序或系统的数字测量。
事件
系统中发生异常和离散性发生。

STF 的组件使用消息总线进行数据传输。接收和存储数据的其他模块化组件作为容器部署在 Red Hat OpenShift Container Platform 上。

重要

STF 与 Red Hat OpenShift Container Platform 版本 4.10 到 4.12 兼容。

其他资源

1.1. 支持 Service Telemetry Framework

红帽支持核心 Operator 和工作负载，包括 AMQ Interconnect、Service Telemetry Operator 和 Smart Gateway Operator。红帽不支持社区 Operator 或工作负载组件，如 Elasticsearch、Prometheus、Alertmanager、Grafana 及其 Operator。

您只能在完全连接的网络环境中部署 STF。您无法在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中部署 STF。

有关 STF 生命周期和支持状态的更多信息，请参阅 Service Telemetry Framework 支持的版本列表。

1.2. Service Telemetry Framework 架构

Service Telemetry Framework (STF)使用客户端-服务器架构，其中的 Red Hat OpenStack Platform (RHOSP)是客户端，Red Hat OpenShift Container Platform 是服务器。

STF 由以下组件组成：

  • 数据收集

    • collectd：收集基础架构指标和事件。
    • Ceilometer：收集 RHOSP 指标和事件。

  • 传输

    • AMQ Interconnect：一个 AMQP 1.x 兼容消息总线，提供快速可靠的数据传输，将指标传送到 STF 以进行存储。
    • 智能网关： Golang 应用从 AMQP 1.x 总线获取指标和事件，以发送到 Elasticsearch 或 Prometheus。

  • 数据存储

    • Prometheus：存储从智能网关接收的 STF 指标的时间序列数据存储。
    • Elasticsearch：存储从智能网关接收的 STF 事件的事件数据存储。

  • Observability （观察）

    • Alertmanager：使用 Prometheus 警报规则管理警报的警报工具。
    • Grafana：可用于查询、视觉化和探索数据的视觉化和分析应用程序。

下表描述了客户端和服务器组件的应用程序：

表 1.1. STF 的客户端和服务器组件

组件客户端Server

AMQP 1.x 兼容消息传递总线

是

是

智能网关

否

是

Prometheus

否

是

Elasticsearch

否

是

collectd

是

否

ilo

是

否

重要

为确保监控平台可以报告云中的操作问题，请不要在您监控的同一基础架构上安装 STF。

图 1.1. Service Telemetry Framework 架构概述

Service Telemetry Framework 架构概述

对于客户端侧指标，collectd 提供没有项目数据的基础架构指标，Ceilometer 根据项目或用户工作负载提供 RHOSP 平台数据。Ceilometer 和 collectd 通过使用 AMQ Interconnect 传输将数据提供给 Prometheus，并通过消息总线提供数据。在服务器端，名为 Smart Gateway 的 Golang 应用从总线获取数据流，并将其公开为 Prometheus 的本地提取端点。

如果您计划收集和存储事件，collectd 和 Ceilometer 使用 AMQ Interconnect 传输向服务器端发送事件数据。另一个智能网关将数据写入 Elasticsearch 数据存储。

服务器端 STF 监控基础架构由以下层组成：

  • Service Telemetry Framework 1.5
  • Red Hat OpenShift Container Platform 4.10 到 4.12
  • 基础架构平台

图 1.2. 服务器端 STF 监控基础架构

服务器端 STF 监控基础架构

1.3. Red Hat OpenShift Container Platform 的安装大小

Red Hat OpenShift Container Platform 安装的大小取决于以下因素：

  • 您选择的基础架构。
  • 要监控的节点数量。
  • 要收集的指标数量。
  • 指标的解析。
  • 要存储数据的时间长度。

Service Telemetry Framework (STF)的安装依赖于现有的 Red Hat OpenShift Container Platform 环境。

有关在裸机上安装 Red Hat OpenShift Container Platform 时最低资源要求的更多信息，请参阅在裸机上安装集群中的最低资源要求。有关您可以安装的各种公共和私有云平台的安装要求，请参阅您选择的云平台的相应安装文档。

第 2 章 为 Service Telemetry Framework 准备 Red Hat OpenShift Container Platform 环境

要为 Service Telemetry Framework (STF)准备 Red Hat OpenShift Container Platform 环境，您必须规划持久性存储、适当的资源、事件存储和网络注意事项：

2.1. Service Telemetry Framework 中的可观察性策略

Service Telemetry Framework (STF)不包括存储后端和警报工具。STF 使用社区操作器来部署 Prometheus、Alertmanager、Grafana 和 Elasticsearch。STF 向这些社区操作器发出请求，以创建配置为使用 STF 的每个应用程序的实例。

除了让 Service Telemetry Operator 创建自定义资源请求外，您可以使用您自己的应用程序部署或其他兼容应用程序，并提取指标 智能网关以发送到您自己的 Prometheus 兼容系统以进行遥测存储。如果将 observabilityStrategy 设置为 none，则不会部署存储后端，因此 STF 不需要持久性存储。

2.2. 持久性卷（PV）

Service Telemetry Framework (STF)使用 Red Hat OpenShift Container Platform 中的持久性存储来请求持久性卷，以便 Prometheus 和 Elasticsearch 可以存储指标和事件。

当您通过 Service Telemetry Operator 启用持久性存储时，STF 部署中请求的持久性卷声明(PVC)会导致访问模式为 RWO (ReadWriteOnce)。如果您的环境包含预置备的持久性卷，请确保 Red Hat OpenShift Container Platform 默认配置的 storageClass 中提供了 RWO 卷。

其他资源

2.3. 资源分配

要启用在 Red Hat OpenShift Container Platform 基础架构中调度 pod，您需要运行的组件的资源。如果您没有分配足够的资源，pod 会一直处于 Pending 状态，因为它们无法调度。

运行 Service Telemetry Framework (STF)所需的资源数量取决于您的环境以及要监控的节点数量。

其他资源

2.4. Service Telemetry Framework 的网络注意事项

您只能在完全连接的网络环境中部署 Service Telemetry Framework (STF)。您无法在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中部署 STF。

第 3 章 安装 Service Telemetry Framework 的核心组件

您可以使用 Operator 加载 Service Telemetry Framework (STF)组件和对象。Operator 管理以下每个 STF 内核和社区组件：

  • cert-manager
  • AMQ Interconnect
  • 智能网关
  • Prometheus 和 AlertManager
  • Elasticsearch
  • Grafana

先决条件

  • 一个 Red Hat OpenShift Container Platform 版本（包含 4.10 到 4.12）正在运行。
  • 您已准备了 Red Hat OpenShift Container Platform 环境，并确保有持久性存储和充足的资源可在 Red Hat OpenShift Container Platform 环境上运行 STF 组件。如需更多信息，请参阅 服务 Telemetry Framework 性能和扩展。
  • 您的环境已完全连接。STF 在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中无法正常工作。
重要

STF 与 Red Hat OpenShift Container Platform 版本 4.10 到 4.12 兼容。

其他资源

3.1. 在 Red Hat OpenShift Container Platform 环境中部署 Service Telemetry Framework

部署 Service Telemetry Framework (STF)以收集、存储和监控事件：

流程

  1. 创建一个命名空间来包含 STF 组件，如 service-telemetry ： 

    $ oc new-project service-telemetry

  2. 在命名空间中创建 OperatorGroup，以便您可以调度 Operator pod： 

    $ 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

    如需更多信息，请参阅 OperatorGroup。

  3. 为 cert-manager Operator 创建命名空间： 

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

  4. 为 cert-manager Operator 创建 OperatorGroup： 

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

  5. 使用 redhat-operators CatalogSource 订阅 cert-manager Operator： 

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

  6. 验证您的 ClusterServiceVersion。确保 cert-manager Operator 显示 Succeeded 的阶段： 

    $ oc get csv --namespace openshift-cert-manager-operator --selector=operators.coreos.com/openshift-cert-manager-operator.openshift-cert-manager-operator

NAME                            DISPLAY                                       VERSION   REPLACES   PHASE
openshift-cert-manager.v1.7.1   cert-manager Operator for Red Hat OpenShift   1.7.1-1              Succeeded

  7. 使用 redhat-operators CatalogSource 订阅 AMQ Interconnect Operator： 

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

  8. 验证您的 ClusterServiceVersion。确保 amq7-interconnect-operator.v1.10.x 显示 Succeeded 的阶段： 

    $ oc get csv --selector=operators.coreos.com/amq7-interconnect-operator.service-telemetry

NAME                                  DISPLAY                                  VERSION   REPLACES                             PHASE
amq7-interconnect-operator.v1.10.15   Red Hat Integration - AMQ Interconnect   1.10.15   amq7-interconnect-operator.v1.10.4   Succeeded

  9. 要在 Prometheus 中存储指标，您必须使用 community-operators CatalogSource 启用 Prometheus Operator：

    警告

    社区 Operator 是尚未被红帽审查或验证的 Operator。社区 Operator 应谨慎使用，因为其稳定性未知。红帽不支持社区 Operator。

    了解更多有关红帽的第三方软件支持政策 

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

  10. 验证 Prometheus Succeeded 的 ClusterServiceVersion: 

    $ oc get csv --selector=operators.coreos.com/prometheus.service-telemetry

NAME                        DISPLAY               VERSION   REPLACES                    PHASE
prometheusoperator.0.56.3   Prometheus Operator   0.56.3    prometheusoperator.0.47.0   Succeeded

  11. 要在 Elasticsearch 中存储事件，您必须使用 certified-operators CatalogSource 在 Kubernetes (ECK) Operator 上启用 Elastic Cloud：

    警告

    认证的 Operator 是来自主要独立软件供应商(ISV)的 Operator。红帽与 ISV 合作打包并提供，但不支持经过认证的 Operator。支持由 ISV 提供。

    了解更多有关红帽的第三方软件支持政策 

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

  12. 验证 Kubernetes Succeeded 上 Elastic Cloud 的 ClusterServiceVersion : 

    $ oc get csv --selector=operators.coreos.com/elasticsearch-eck-operator-certified.service-telemetry

NAME                                          DISPLAY                        VERSION   REPLACES                                      PHASE
elasticsearch-eck-operator-certified.v2.8.0   Elasticsearch (ECK) Operator   2.8.0     elasticsearch-eck-operator-certified.v2.7.0   Succeeded

  13. 创建 Service Telemetry Operator 订阅来管理 STF 实例： 

    $ 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

  14. 验证 Service Telemetry Operator 和依赖 Operator 的阶段为 Succeeded ： 

    $ oc get csv --namespace service-telemetry

NAME                                          DISPLAY                                       VERSION          REPLACES                                      PHASE
amq7-interconnect-operator.v1.10.15           Red Hat Integration - AMQ Interconnect        1.10.15          amq7-interconnect-operator.v1.10.4            Succeeded
elasticsearch-eck-operator-certified.v2.8.0   Elasticsearch (ECK) Operator                  2.8.0            elasticsearch-eck-operator-certified.v2.7.0   Succeeded
openshift-cert-manager.v1.7.1                 cert-manager Operator for Red Hat OpenShift   1.7.1-1                                                        Succeeded
prometheusoperator.0.56.3                     Prometheus Operator                           0.56.3           prometheusoperator.0.47.0                     Succeeded
service-telemetry-operator.v1.5.1680516659    Service Telemetry Operator                    1.5.1680516659                                                 Succeeded
smart-gateway-operator.v5.0.1680516659        Smart Gateway Operator                        5.0.1680516659                                                 Succeeded

3.2. 在 Red Hat OpenShift Container Platform 中创建 ServiceTelemetry 对象

在 Red Hat OpenShift Container Platform 中创建 ServiceTelemetry 对象，以便 Service Telemetry Operator 为 Service Telemetry Framework (STF)部署创建支持组件。更多信息请参阅 第 3.2.1 节 “ServiceTelemetry 对象的主要参数”。

流程

  1. 要创建一个会生成使用默认值的 STF 部署的 ServiceTelemetry 对象，创建一个带有空 spec 参数的 ServiceTelemetry 对象： 

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

    使用空 spec 参数创建 ServiceTelemetry 对象会导致带有以下默认设置的 STF 部署： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  alerting:
    alertmanager:
      receivers:
        snmpTraps:
          alertOidLabel: oid
          community: public
          enabled: false
          port: 162
          retries: 5
          target: 192.168.24.254
          timeout: 1
          trapDefaultOid: 1.3.6.1.4.1.50495.15.1.2.1
          trapDefaultSeverity: ''
          trapOidPrefix: 1.3.6.1.4.1.50495.15
      storage:
        persistent:
          pvcStorageRequest: 20G
        strategy: persistent
    enabled: true
  backends:
    events:
      elasticsearch:
        certificates:
          caCertDuration: 70080h
          endpointCertDuration: 70080h
        storage:
          persistent:
            pvcStorageRequest: 20Gi
          strategy: persistent
        enabled: false
        version: 7.16.1
    logs:
      loki:
        storage:
          objectStorageSecret: test
          storageClass: standard
        enabled: false
        flavor: 1x.extra-small
        replicationFactor: 1
    metrics:
      prometheus:
        storage:
          persistent:
            pvcStorageRequest: 20G
          retention: 24h
          strategy: persistent
        enabled: true
        scrapeInterval: 10s
  clouds:
    - events:
        collectors:
          - bridge:
              ringBufferCount: 15000
              ringBufferSize: 16384
              verbose: false
            collectorType: collectd
            debugEnabled: false
            subscriptionAddress: collectd/cloud1-notify
          - bridge:
              ringBufferCount: 15000
              ringBufferSize: 16384
              verbose: false
            collectorType: ceilometer
            debugEnabled: false
            subscriptionAddress: anycast/ceilometer/cloud1-event.sample
      metrics:
        collectors:
          - bridge:
              ringBufferCount: 15000
              ringBufferSize: 16384
              verbose: false
            collectorType: collectd
            debugEnabled: false
            subscriptionAddress: collectd/cloud1-telemetry
          - bridge:
              ringBufferCount: 15000
              ringBufferSize: 16384
              verbose: false
            collectorType: ceilometer
            debugEnabled: false
            subscriptionAddress: anycast/ceilometer/cloud1-metering.sample
          - bridge:
              ringBufferCount: 15000
              ringBufferSize: 16384
              verbose: false
            collectorType: sensubility
            debugEnabled: false
            subscriptionAddress: sensubility/cloud1-telemetry
      name: cloud1
  graphing:
    grafana:
      adminPassword: secret
      adminUser: root
      disableSignoutMenu: false
      ingressEnabled: false
    enabled: false
  highAvailability:
    enabled: false
  transports:
    qdr:
      certificates:
        caCertDuration: 70080h
        endpointCertDuration: 70080h
      web:
        enabled: false
      enabled: true
  observabilityStrategy: use_community

    要覆盖这些默认值，请将配置添加到 spec 参数中。

  2. 在 Service Telemetry Operator 中查看 STF 部署日志： 

    $ oc logs --selector name=service-telemetry-operator

...
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=90   changed=0    unreachable=0    failed=0    skipped=26   rescued=0    ignored=0

验证

  • 要确定所有工作负载是否都正常运行，请查看 pod 和每个 pod 的状态。

    注意

    如果将 backend. events.elasticsearch.enabled 参数设置为 true，则通知 Smart Gateways 会在 Elasticsearch 启动前报告 Error 和 CrashLoopBackOff 错误消息。 

    $ oc get pods

NAME                                                      READY   STATUS    RESTARTS   AGE
alertmanager-default-0                                    3/3     Running   0          4m7s
default-cloud1-ceil-meter-smartgateway-669c6cdcf9-xvdvx   3/3     Running   0          3m46s
default-cloud1-coll-meter-smartgateway-585855c59d-858rf   3/3     Running   0          3m46s
default-cloud1-sens-meter-smartgateway-6f8dffb645-hhgkw   3/3     Running   0          3m46s
default-interconnect-6994ff546-fx7jn                      1/1     Running   0          4m18s
elastic-operator-9f44cdf6c-csvjq                          1/1     Running   0          19m
interconnect-operator-646bfc886c-gx55n                    1/1     Running   0          25m
prometheus-default-0                                      3/3     Running   0          3m33s
prometheus-operator-54d644d8d7-wzdlh                      1/1     Running   0          20m
service-telemetry-operator-54f6f7b6d-nfhwx                1/1     Running   0          18m
smart-gateway-operator-9bbd7c56c-76w67                    1/1     Running   0          18m

3.2.1. ServiceTelemetry 对象的主要参数

ServiceTelemetry 对象由以下主要配置参数组成：

  • 警报
  • 后端
  • 云
  • 图表
  • HighAvailability
  • 传输

您可以配置每个配置参数，以在 STF 部署中提供不同的功能。

backend 参数

使用 backend 参数控制可用于指标和事件的存储后端，并控制 clouds 参数定义的智能网关的启用。如需更多信息，请参阅 “clouds 参数”一节。

您可以使用 Prometheus 作为指标存储后端，Elasticsearch 作为事件存储后端。您可以使用 Service Telemetry Operator 创建 Prometheus Operator 和 Kubernetes Operator 上的 Elastic Cloud 的其他自定义资源对象，以创建 Prometheus 和 Elasticsearch 工作负载。

将 Prometheus 启用为指标的存储后端

要将 Prometheus 启用为指标的存储后端，您必须配置 ServiceTelemetry 对象。

流程

  1. 编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  2. 将 backends.metrics.prometheus.enabled 参数的值设置为 true ： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  [...]
  backends:
    metrics:
      prometheus:
        enabled: true
为 Prometheus 配置持久性存储

使用 backend. metrics.prometheus.storage.persistent 中定义的附加参数为 Prometheus 配置持久性存储选项，如存储类和卷大小。

使用 storageClass 定义后端存储类。如果没有设置此参数，Service Telemetry Operator 将使用 Red Hat OpenShift Container Platform 集群的默认存储类。

使用 pvcStorageRequest 参数定义满足存储请求的最低要求大小。如果静态定义了卷，则使用大于请求的卷大小。默认情况下，Service Telemetry Operator 请求大小为 20G (20 Gigabytes)。

流程

  1. 列出可用的存储类： 

    $ 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. 编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  3. 将 backends.metrics.prometheus.enabled 参数的值设置为 true，将 backends.metrics.prometheus.storage.strategy 的值设置为 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
为事件启用 Elasticsearch 作为存储后端

要将 Elasticsearch 作为事件的存储后端启用，您必须配置 ServiceTelemetry 对象。

流程

  1. 编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  2. 将 backends.events.elasticsearch.enabled 参数的值设置为 true ： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  [...]
  backends:
    events:
      elasticsearch:
        enabled: true
为 Elasticsearch 配置持久性存储

使用 backend. events.elasticsearch.storage.persistent 中定义的附加参数为 Elasticsearch 配置持久性存储选项，如存储类和卷大小。

使用 storageClass 定义后端存储类。如果没有设置此参数，Service Telemetry Operator 将使用 Red Hat OpenShift Container Platform 集群的默认存储类。

使用 pvcStorageRequest 参数定义满足存储请求的最低要求大小。如果静态定义了卷，则使用大于请求的卷大小。默认情况下，Service Telemetry Operator 请求大小为 20Gi (20 Gibibytes)。

流程

  1. 列出可用的存储类： 

    $ 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. 编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  3. 将 backends.events.elasticsearch.enabled 参数的值设置为 true，将 backends.events.elasticsearch.storage.strategy 的值设置为 persistent ： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  [...]
  backends:
    events:
      elasticsearch:
        enabled: true
        version: 7.16.1
        storage:
          strategy: persistent
          persistent:
            storageClass: standard-csi
            pvcStorageRequest: 50G
clouds 参数

使用 clouds 参数定义部署哪个智能网关对象，从而为多个监控云环境提供接口，以连接到 STF 实例。如果支持后端可用，则创建用于默认云配置的指标和事件智能网关。默认情况下，Service Telemetry Operator 为 cloud1 创建智能网关。

您可以创建一个云对象列表来控制为定义的云创建哪个智能网关。每个云都由数据类型和收集器组成。数据类型是 指标 或 事件。每种数据类型由一个收集器列表、消息总线订阅地址和一个参数组成，以启用调试。可用的指标收集器有 collectd、ceilometer 和 sensubility。适用于事件的可用收集器是 collectd 和 ceilometer。确保每个收集器的订阅地址对于每个云、数据类型和收集器组合都是唯一的。

默认 cloud1 配置由以下 ServiceTelemetry 对象表示，它为特定云实例提供 collectd、Ceilometer 和 Sensubility 数据收集器的指标和数据存储： 

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

clouds 参数的每个项目代表一个云实例。云实例包含三个顶级参数： 名称、指标 和事件。metrics 和 events 参数代表该数据类型存储的对应后端。collectors 参数指定由两个所需参数( collectorType 和 subscriptionAddress )组成的对象列表，它们代表智能网关的实例。collectorType 参数指定 collectd、Ceilometer 或 Sensubility 收集的数据。subscriptionAddress 参数提供智能网关订阅的 AMQ Interconnect 地址。

您可以使用 collectors 参数中的一个可选布尔值参数 debugEnabled 在运行的 Smart Gateway pod 中启用额外的控制台调试功能。

其他资源

警报参数

使用 alerting 参数来控制 Alertmanager 实例的创建以及存储后端的配置。默认情况下启用 警报。更多信息请参阅 第 5.3 节 “Service Telemetry Framework 中的警报”。

graphing 参数

使用 graphing 参数来控制 Grafana 实例的创建。默认情况下禁用 图形。更多信息请参阅 第 5.1 节 “Service Telemetry Framework 中的仪表板”。

highAvailability 参数

使用 highAvailability 参数控制 STF 组件的多个副本的实例化，以减少失败或被重新调度的组件恢复时间。默认情况下禁用 highAvailability。更多信息请参阅 第 5.6 节 “高可用性”。

transports 参数

使用 transports 参数来控制为 STF 部署启用消息总线。目前唯一支持的传输是 AMQ Interconnect。默认情况下启用 qdr 传输。

3.3. 访问 STF 组件的用户界面

在 Red Hat OpenShift Container Platform 中，应用程序通过路由公开给外部网络。有关路由的更多信息，请参阅配置入口集群流量。

在 Service Telemetry Framework (STF)中，会为每个基于 Web 的界面的服务公开 HTTPS 路由。这些路由受 Red Hat OpenShift Container Platform RBAC 和具有 ClusterRoleBinding 的任何用户进行保护，以便可以查看 Red Hat OpenShift Container Platform 命名空间可以登录。有关 RBAC 的更多信息，请参阅使用 RBAC 定义和应用权限。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 列出 service-telemetry 项目中的可用 Web UI 路由： 

    $ oc get routes | grep web
default-alertmanager-proxy   default-alertmanager-proxy-service-telemetry.apps.infra.watch          default-alertmanager-proxy   web     reencrypt/Redirect   None
default-prometheus-proxy     default-prometheus-proxy-service-telemetry.apps.infra.watch            default-prometheus-proxy     web     reencrypt/Redirect   None
  4. 在网页浏览器中，进入到 https://<route_address& gt; 以访问相应服务的 Web 界面。

3.4. 配置备用可观察性策略

要将 STF 配置为跳过存储、视觉化和警报后端的部署，请将 observabilityStrategy: none 添加到 ServiceTelemetry spec 中。在这个模式中，只部署 AMQ Interconnect 路由器和指标智能网关，您必须配置与 Prometheus 兼容的外部系统，以便从 STF 智能网关收集指标。

注意

目前，当您将 observabilityStrategy 设置为 none 时，只支持指标。事件智能网关不会被部署。

流程

  1. 在 spec 参数中，使用属性 observabilityStrategy: none 创建一个 ServiceTelemetry 对象。清单显示会导致 STF 的默认部署，该部署适合从具有所有指标收集器类型的单个云接收遥测。 

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

  2. 删除由社区操作器管理的对象上的左侧 

    $ for o in alertmanager/default prometheus/default elasticsearch/elasticsearch grafana/default; do oc delete $o; done

  3. 要验证所有工作负载是否都正常运行，请查看 pod 和每个 pod 的状态： 

    $ oc get pods
NAME                                                      READY   STATUS    RESTARTS   AGE
default-cloud1-ceil-meter-smartgateway-59c845d65b-gzhcs   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

其他资源

有关配置附加云或更改支持的收集器集合的更多信息，请参阅 第 4.3.2 节 “部署智能网关”

第 4 章 为 Service Telemetry Framework 配置 Red Hat OpenStack Platform director

要收集指标、事件或两者，并将它们发送到 Service Telemetry Framework (STF)存储域，您必须配置 Red Hat OpenStack Platform (RHOSP) overcloud 以启用数据收集和传输。

STF 可以同时支持单云和多个云。为单个云安装设置 RHOSP 和 STF 中的默认配置。

4.1. 使用 director 为 Service Telemetry Framework 部署 Red Hat OpenStack Platform overcloud

作为使用 director 的 Red Hat OpenStack Platform (RHOSP) overcloud 部署的一部分，您必须配置数据收集器和数据传输到 Service Telemetry Framework (STF)。

流程

  1. 第 4.1.1 节 “从 Service Telemetry Framework 获取用于 overcloud 配置的 CA 证书”
  2. 检索 AMQ Interconnect 路由地址
  3. 为 STF 创建基本配置
  4. 为 overcloud 配置 STF 连接
  5. 部署 overcloud
  6. 验证客户端安装

其他资源

4.1.1. 从 Service Telemetry Framework 获取用于 overcloud 配置的 CA 证书

要将 Red Hat OpenStack Platform (RHOSP) overcloud 连接到 Service Telemetry Framework (STF)，检索在 STF 中运行的 AMQ Interconnect 的 CA 证书，并在 RHOSP 配置中使用证书。

流程

  1. 查看 STF 中的可用证书列表： 

    $ oc get secrets

  2. 检索并记录 default-interconnect-selfsigned Secret 的内容： 

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

4.1.2. 检索 AMQ Interconnect 路由地址

当您为 Service Telemetry Framework (STF)配置 Red Hat OpenStack Platform (RHOSP) overcloud 时，您必须在 STF 连接文件中提供 AMQ Interconnect 路由地址。

流程

  1. 登录到托管 STF 的 Red Hat OpenShift Container Platform 环境。

  2. 进入 service-telemetry 项目： 

    $ oc project service-telemetry

  3. 检索 AMQ Interconnect 路由地址： 

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

4.1.3. 为 STF 创建基本配置

要配置基本参数，以便为 Service Telemetry Framework (STF)提供兼容数据收集和传输，您必须创建一个定义默认数据收集值的文件。

流程

  1. 以 stack 用户身份登录 undercloud 主机。

  2. 在 /home/stack 目录中创建一个名为 enable-stf.yaml 的配置文件。

    重要

    将 EventPipelinePublishers 和 PipelinePublishers 设置为空列表会导致没有事件或指标数据传递给 RHOSP 遥测组件，如 Gnocchi 或 Panko。如果您需要将数据发送到其他管道，Ceilometer 轮询间隔为 30 秒，您在 ExtraConfig 中指定，可能会认为 RHOSP 遥测组件。您必须将间隔增加到较大的值，如 300，这会减少 STF 中的遥测解析。

enable-stf.yaml

parameter_defaults:
    # only send to STF, not other publishers
    EventPipelinePublishers: []
    PipelinePublishers: []

    # manage the polling and pipeline configuration files for Ceilometer agents
    ManagePolling: true
    ManagePipeline: true

    # enable Ceilometer metrics and events
    CeilometerQdrPublishMetrics: true
    CeilometerQdrPublishEvents: 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: 5
    CollectdDefaultPollingInterval: 5
    CollectdExtraPlugins:
    - vmem

    # set standard prefixes for where metrics and events 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
        - disk.*
        - ip.*
        - image.*
        - memory
        - memory.*
        - network.services.vpn.*
        - network.services.firewall.*
        - perf.*
        - port
        - port.*
        - switch
        - switch.*
        - storage.*
        - volume.*

        # 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::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

4.1.4. 为 overcloud 配置 STF 连接

要配置 Service Telemetry Framework (STF)连接，您必须创建一个文件，其中包含 overcloud 到 STF 部署的 AMQ Interconnect 的连接配置。启用 STF 中事件和存储的集合，并部署 overcloud。默认配置是用于具有默认消息总线主题的单个云实例。有关多个云部署的配置，请参阅 第 4.3 节 “配置多个云”。

先决条件

流程

  1. 以 stack 用户身份登录 undercloud 主机。
  2. 在 /home/stack 目录中创建一个名为 stf-connectors.yaml 的配置文件。

  3. 在 stf-connectors.yaml 文件中，配置 MetricsQdrConnectors 地址，以将 overcloud 上的 AMQ Interconnect 连接到 STF 部署。您可以在此文件中配置 Sensubility、Ceilometer 和 collectd 的主题地址，以匹配 STF 中的默认值。有关自定义主题和云配置的详情，请参考 第 4.3 节 “配置多个云”。

    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.infra.watch
          port: 443
          role: edge
          verifyHostname: false
          sslProfile: sslProfile

    MetricsQdrSSLProfiles:
        - name: sslProfile
          caCertFileContent: |
            -----BEGIN CERTIFICATE-----
            <snip>
            -----END CERTIFICATE-----

    CeilometerQdrEventsConfig:
        driver: amqp
        topic: cloud1-event

    CeilometerQdrMetricsConfig:
        driver: amqp
        topic: cloud1-metering

    CollectdAmqpInstances:
        cloud1-notify:
            notify: true
            format: JSON
            presettle: false
        cloud1-telemetry:
            format: JSON
            presettle: false

    CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry

    • resource_registry 配置直接加载 collectd 服务，因为您没有为多个云部署包含 collectd-write-qdr.yaml 环境文件。
    • 将 host 参数替换为您在 第 4.1.2 节 “检索 AMQ Interconnect 路由地址” 中检索的值。
    • 将 caCertFileContent 参数替换为 第 4.1.1 节 “从 Service Telemetry Framework 获取用于 overcloud 配置的 CA 证书” 中检索的内容。
    • 将 MetricsQdrConnectors 的主机 子参数替换为您在 第 4.1.2 节 “检索 AMQ Interconnect 路由地址” 中检索的值。
    • 设置 CeilometerQdrEventsConfig 的主题 值，以定义 Ceilometer 事件的主题。该值是云的唯一主题限定符，如 cloud1-event。
    • 设置 CeilometerQdrMetricsConfig.topic 的 topic 值，以定义 Ceilometer 指标的主题。该值是云的唯一标识符，如 cloud1-metering。
    • 设置 CollectdAmqpInstances 子参数，以定义 collectd 事件的主题。部分名称是云的唯一标识符，如 cloud1-notify。
    • 设置 CollectdAmqpInstances 子参数，以定义 collectd 指标的主题。部分名称是云的唯一标识符，如 cloud1-telemetry。
    • 设置 CollectdSensubilityResultsChannel，以定义 collectd-sensubility 事件的主题。该值是云的唯一主题标识符，如 sensubility/cloud1-telemetry。
注意

当您为 collectd 和 Ceilometer 定义主题时，您提供的值将转换为智能网关客户端用于侦听消息的完整主题。

Ceilometer 主题值被转换为主题地址 anycast/ceilometer/<TOPIC>.sample，collectd 主题值被转换为主题地址 collectd/<TOPIC>。sensubility 的值是完整主题路径，且没有从主题值转换为主题地址。

有关 ServiceTelemetry 对象中的云配置示例，请参阅 “clouds 参数”一节。

4.1.5. 部署 overcloud

使用所需的环境文件部署或更新 overcloud，以便收集数据并传输到 Service Telemetry Framework (STF)。

流程

  1. 以 stack 用户身份登录 undercloud 主机。

  2. 查找 stackrc undercloud 凭证文件： 

    $ source ~/stackrc

  3. 使用其他环境文件将数据收集和 AMQ Interconnect 环境文件添加到堆栈中，并部署 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
    • 包含 ceilometer-write-qdr.yaml 文件，以确保 Ceilometer 遥测和事件发送到 STF。
    • 包含 qdr-edge-only.yaml 文件，以确保消息总线已启用并连接到 STF 消息总线路由器。
    • 包含 enable-stf.yaml 环境文件，以确保正确配置了默认值。
    • 包含 stf-connectors.yaml 环境文件以定义与 STF 的连接。

4.1.6. 验证客户端安装

要验证来自 Service Telemetry Framework (STF)存储域的数据收集，请查询数据源以获取交付数据。要验证 Red Hat OpenStack Platform (RHOSP)部署中的单个节点，请使用 SSH 连接到控制台。

提示

只有在 RHOSP 有活跃工作负载时，一些遥测数据才可用。

流程

  1. 登录 overcloud 节点，如 controller-0。

  2. 确保 metrics_qdr 和集合代理容器在节点上运行： 

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

    在计算节点上使用此命令： 

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

  3. 返回运行 AMQ Interconnect 的内部网络地址，例如 172.17.1.44 侦听端口 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. 返回到本地 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

    有四个连接：

    • 到 STF 的出站连接
    • 来自 ceilometer 的入站连接
    • 来自 collectd 的入站连接

    • 来自 qdstat 客户端的入站连接

      出站 STF 连接提供给 MetricsQdrConnectors 主机参数，是 STF 存储域的路由。其他主机是连接到这个 AMQ Interconnect 的客户端连接的内部网络地址。

  5. 要确保传递消息，列出链接，并查看 deliv 列中用于传递消息的 _edge 地址： 

    $ 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. 要列出 RHOSP 节点到 STF 的地址，连接到 Red Hat OpenShift Container Platform 以检索 AMQ Interconnect pod 名称并列出连接。列出可用的 AMQ Interconnect pod: 

    $ oc get pods -l application=default-interconnect

NAME                                    READY   STATUS    RESTARTS   AGE
default-interconnect-7458fd4d69-bgzfb   1/1     Running   0          6d21h

  7. 连接到 pod 并列出已知的连接。在本例中，有来自 RHOSP 节点的三个 边缘 连接，其连接 id 为 22, 23, 和 24。 

    $ oc exec -it default-interconnect-7458fd4d69-bgzfb -- 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. 要查看网络发送的消息数量，请使用每个地址与 oc exec 命令： 

    $ oc exec -it default-interconnect-7458fd4d69-bgzfb -- 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

4.2. 禁用用于 Service Telemetry Framework 的 Red Hat OpenStack Platform 服务

禁用部署 Red Hat OpenStack Platform (RHOSP)时使用的服务，并将其连接到 Service Telemetry Framework (STF)。没有删除日志或生成的配置文件，作为服务禁用的一部分。

流程

  1. 以 stack 用户身份登录 undercloud 主机。

  2. 查找 stackrc undercloud 凭证文件： 

    $ source ~/stackrc

  3. 创建 disable-stf.yaml 环境文件： 

    $ cat > ~/disable-stf.yaml <<EOF
---
resource_registry:
  OS::TripleO::Services::CeilometerAgentCentral: OS::Heat::None
  OS::TripleO::Services::CeilometerAgentNotification: OS::Heat::None
  OS::TripleO::Services::CeilometerAgentIpmi: OS::Heat::None
  OS::TripleO::Services::ComputeCeilometerAgent: OS::Heat::None
  OS::TripleO::Services::Redis: OS::Heat::None
  OS::TripleO::Services::Collectd: OS::Heat::None
  OS::TripleO::Services::MetricsQdr: OS::Heat::None
EOF

  4. 从 RHOSP director 部署中删除以下文件：

    • ceilometer-write-qdr.yaml
    • qdr-edge-only.yaml
    • enable-stf.yaml
    • stf-connectors.yaml

  5. 更新 RHOSP overcloud。确保在环境文件列表早期使用 disable-stf.yaml 文件。通过在列表早期添加 disable-stf.yaml，其他环境文件可能会覆盖禁用该服务的配置： 

    (undercloud)$ openstack overcloud deploy --templates \
-e /home/stack/disable-stf.yaml \
-e [your environment files]

4.3. 配置多个云

您可以配置多个 Red Hat OpenStack Platform (RHOSP)云以单一 Service Telemetry Framework (STF)实例为目标。当您配置多个云时，每个云都必须在其自己唯一的消息总线主题上发送指标和事件。在 STF 部署中，智能网关实例侦听这些主题，以将信息保存到通用数据存储中。在数据存储域中由智能网关存储的数据通过利用每个智能网关创建的元数据进行过滤。

图 4.1. 两个 RHOSP 云连接到 STF

连接到 STF 的两个 RHOSP 云示例

要为多个云场景配置 RHOSP overcloud，请完成以下任务：

  1. 规划您要为每个云使用的 AMQP 地址前缀。更多信息请参阅 第 4.3.1 节 “规划 AMQP 地址前缀”。
  2. 为每个云部署指标和事件使用者智能网关，以侦听对应的地址前缀。更多信息请参阅 第 4.3.2 节 “部署智能网关”。
  3. 使用唯一的域名配置每个云。更多信息请参阅 第 4.3.4 节 “设置唯一的云域”。
  4. 为 STF 创建基础配置。更多信息请参阅 第 4.1.3 节 “为 STF 创建基本配置”。
  5. 配置每个云，使其指标和事件发送到正确地址上的 STF。更多信息请参阅 第 4.3.5 节 “为多个云创建 Red Hat OpenStack Platform 环境文件”。

4.3.1. 规划 AMQP 地址前缀

默认情况下，Red Hat OpenStack Platform (RHOSP)节点通过两个数据收集器接收数据： collectd 和 Ceilometer。collectd-sensubility 插件需要唯一的地址。这些组件将遥测数据或通知发送到对应的 AMQP 地址，如 collectd/telemetry。STF 智能网关侦听这些用于数据的 AMQP 地址。要支持多个云并识别哪个云生成监控数据，请配置每个云以将数据发送到唯一的地址。将云标识符前缀添加到地址的第二部分。以下列表显示了一些地址和标识符示例：

  • collectd/cloud1-telemetry
  • collectd/cloud1-notify
  • sensubility/cloud1-telemetry
  • anycast/ceilometer/cloud1-metering.sample
  • anycast/ceilometer/cloud1-event.sample
  • collectd/cloud2-telemetry
  • collectd/cloud2-notify
  • sensubility/cloud2-telemetry
  • anycast/ceilometer/cloud2-metering.sample
  • anycast/ceilometer/cloud2-event.sample
  • collectd/us-east-1-telemetry
  • collectd/us-west-3-telemetry

4.3.2. 部署智能网关

您必须为每个云的每个数据收集类型部署智能网关；一个用于 collectd 指标，一个用于 collectd 指标，一个用于 Ceilometer 指标，一个用于 Ceilometer 事件，另一个用于 collectd-sensubility 指标。将每个智能网关配置为侦听您为对应云定义的 AMQP 地址。要定义智能网关，请在 ServiceTelemetry 清单中配置 clouds 参数。

当您首次部署 STF 时，会创建智能网关清单，以定义单个云的初始智能网关。当您为多个云支持部署智能网关时，您可以为处理指标和每个云的事件数据的每个数据收集类型部署多个智能网关。初始智能网关在 cloud1 中定义，包括以下订阅地址：

collector

type

默认订阅地址

collectd

metrics

collectd/telemetry

collectd

Events

collectd/notify

collectd-sensubility

metrics

sensubility/telemetry

ilo

metrics

anycast/ceilometer/metering.sample

ilo

Events

anycast/ceilometer/event.sample

前提条件

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 编辑默认 ServiceTelemetry 对象，并使用您的配置添加 clouds 参数：

    警告

    较长的节点名称可能会超过最大 pod 名称 63 个字符。确保 ServiceTelemetry 名称 default 和 clouds.name 的组合没有超过 19 个字符。云名称不能包含任何特殊字符，如 -。将云名称限制为字母数字(a-z、0-9)。

    主题地址没有字符限制，可以与 clouds.name 值不同。 

    $ 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. 保存 ServiceTelemetry 对象。

  5. 验证每个智能网关是否正在运行。这可能需要几分钟，具体取决于智能网关的数量： 

    $ 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

4.3.3. 删除默认智能网关

为多个云配置 Service Telemetry Framework (STF)后，如果不再使用它们，您可以删除默认的智能网关。Service Telemetry Operator 可以删除创建的 SmartGateway 对象，但不再列在 ServiceTelemetry 云 对象列表中。要启用删除由 clouds 参数定义的 SmartGateway 对象，您必须在 ServiceTelemetry 清单中将 cloudsRemoveOnMissing 参数设置为 true。

提示

如果您不想部署任何智能网关，请使用 clouds: [] 参数定义空云列表。

警告

cloudsRemoveOnMissing 参数默认为禁用。如果启用了 cloudsRemoveOnMissing 参数，您可以在当前命名空间中删除所有手动创建的 SmartGateway 对象，而无需恢复。

流程

  1. 使用您要管理 Service Telemetry Operator 的云对象列表定义您的 clouds 参数。更多信息请参阅 “clouds 参数”一节。

  2. 编辑 ServiceTelemetry 对象并添加 cloudsRemoveOnMissing 参数： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  ...
spec:
  ...
  cloudsRemoveOnMissing: true
  clouds:
    ...
  3. 保存修改。

  4. 验证 Operator 是否删除了 Smart Gateways。Operator 协调更改时可能需要几分钟时间： 

    $ oc get smartgateways

4.3.4. 设置唯一的云域

为确保从 Red Hat OpenStack Platform (RHOSP)到 Service Telemetry Framework (STF)的 AMQ Interconnect 路由器连接是唯一的，且不会冲突，请配置 CloudDomain 参数。

警告

确保您不会在现有部署中更改主机或域名。只有新的云部署支持主机和域名配置。

流程

  1. 创建新的环境文件，如 hostname .yaml。

  2. 在环境文件中设置 CloudDomain 参数，如下例所示：

    hostnames.yaml

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

  3. 将新的环境文件添加到您的部署中。

其他资源

4.3.5. 为多个云创建 Red Hat OpenStack Platform 环境文件

要根据原始云标记流量，您必须使用特定于云的实例名称创建配置。创建一个 stf-connectors.yaml 文件，并调整 CeilometerQdrEventsConfig、CeilometerdrMetricsConfig 和 CollectdAmqpInstances 的值，以匹配 AMQP 地址前缀方案。

注意

如果启用了容器健康和 API 状态监控，还必须修改 CollectdSensubilityResultsChannel 参数。更多信息请参阅 第 5.9 节 “Red Hat OpenStack Platform API 状态和容器化服务健康状况”。

先决条件

流程

  1. 以 stack 用户身份登录 undercloud 主机。
  2. 在 /home/stack 目录中创建一个名为 stf-connectors.yaml 的配置文件。

  3. 在 stf-connectors.yaml 文件中，配置 MetricsQdrConnectors 地址，以连接到 overcloud 部署上的 AMQ Interconnect。配置 CeilometerQdrEventsConfig、CeilometerdrMetricsConfig、CollectdAmqpInstances 和 CollectdSensubilityResultsChannel 主题值，以匹配您想要用于此云部署的 AMQP 地址。

    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.infra.watch
          port: 443
          role: edge
          verifyHostname: false
          sslProfile: sslProfile

    MetricsQdrSSLProfiles:
        - name: sslProfile
          caCertFileContent: |
            -----BEGIN CERTIFICATE-----
            <snip>
            -----END CERTIFICATE-----

    CeilometerQdrEventsConfig:
        driver: amqp
        topic: cloud1-event

    CeilometerQdrMetricsConfig:
        driver: amqp
        topic: cloud1-metering

    CollectdAmqpInstances:
        cloud1-notify:
            notify: true
            format: JSON
            presettle: false
        cloud1-telemetry:
            format: JSON
            presettle: false

    CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry

    • resource_registry 配置直接加载 collectd 服务，因为您没有为多个云部署包含 collectd-write-qdr.yaml 环境文件。
    • 将 host 参数替换为您在 第 4.1.2 节 “检索 AMQ Interconnect 路由地址” 中检索的值。
    • 将 caCertFileContent 参数替换为 第 4.1.1 节 “从 Service Telemetry Framework 获取用于 overcloud 配置的 CA 证书” 中检索的内容。
    • 将 MetricsQdrConnectors 的主机 子参数替换为您在 第 4.1.2 节 “检索 AMQ Interconnect 路由地址” 中检索的值。
    • 设置 CeilometerQdrEventsConfig 的主题 值，以定义 Ceilometer 事件的主题。该值是云的唯一主题限定符，如 cloud1-event。
    • 设置 CeilometerQdrMetricsConfig.topic 的 topic 值，以定义 Ceilometer 指标的主题。该值是云的唯一标识符，如 cloud1-metering。
    • 设置 CollectdAmqpInstances 子参数，以定义 collectd 事件的主题。部分名称是云的唯一标识符，如 cloud1-notify。
    • 设置 CollectdAmqpInstances 子参数，以定义 collectd 指标的主题。部分名称是云的唯一标识符，如 cloud1-telemetry。

    • 设置 CollectdSensubilityResultsChannel，以定义 collectd-sensubility 事件的主题。该值是云的唯一主题标识符，如 sensubility/cloud1-telemetry。

      注意

      当您为 collectd 和 Ceilometer 定义主题时，您提供的值将转换为智能网关客户端用于侦听消息的完整主题。

      Ceilometer 主题值被转换为主题地址 anycast/ceilometer/<TOPIC>.sample，collectd 主题值被转换为主题地址 collectd/<TOPIC>。sensubility 的值是完整主题路径，且没有从主题值转换为主题地址。

      有关 ServiceTelemetry 对象中的云配置示例，请参阅 “clouds 参数”一节。

  4. 确保 stf-connectors.yaml 文件中的命名约定与 Smart Gateway 配置中的 spec.bridge.amqpUrl 字段一致。例如，将 CeilometerQdrEventsConfig.topic 字段配置为 cloud1-event 的值。
  5. 以 stack 用户身份登录 undercloud 主机。

  6. 查找 stackrc undercloud 凭证文件： 

    $ source stackrc

  7. 在 openstack overcloud deployment 命令中包含 stf-connectors.yaml 文件以及唯一域名环境文件 hostname.yaml，以及其他与您环境相关的环境文件：

    警告

    如果您使用带有自定义 CollectdAmqpInstances 参数的 collectd-write-qdr.yaml 文件，数据会发布到自定义和默认主题。在多个云环境中，stf-connectors.yaml 文件中的 resource_registry 参数的配置会加载 collectd 服务。 

    (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. 部署 Red Hat OpenStack Platform overcloud。

4.3.5.1. 基于 Ansible 的 Service Telemetry Framework 部署

警告

这个功能的内容在此发行版本中作为 文档预览 提供，因此红帽不会完全验证。仅用于测试，不要在生产环境中使用。

从 Red Hat OpenStack Platform 17.1-Beta 开始，您可以预览使用 Ansible 而不是 Puppet 部署 Service Telemetry Framework (STF)组件。Ansible 的使用有以下优点：

  • 将配置整合到单个特定于服务的 THT 变量下(MetricsQdrVars 和 CollectdVars)
  • 将 QDR 模式从 mesh-mode 切换到 edge-only 的能力
  • 部署堆栈中使用的较少技术，从而简化调试过程

要使用基于 Ansible 的部署，请替换 stf-connectors.yaml 文件的 resource_registry 部分中的 "puppet" 一词： 

    OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-ansible.yaml
    OS::TripleO::Services::MetricsQdr: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/qdr-container-ansible.yaml

要设置配置，请使用特定于服务的 THT 变量，如下例所示： 

parameter_defaults:
  MetricsQdrVars:
    tripleo_metrics_qdr_deployment_mode: edge-only
  CollectdVars:
    tripleo_collectd_amqp_host: stf.mycluster.example.com

支持的配置参数的完整列表可在上面引用的部署文件中找到。https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/deployment/metrics/qdr-container-ansible.yaml#L172

https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/deployment/metrics/collectd-container-ansible.yaml#L307

其他资源

4.3.6. 从多个云查询指标数据

Prometheus 中存储的数据根据从中提取的智能网关具有 服务 标签。您可以使用此标签从特定云查询数据。

要查询特定云的数据，请使用与 service 标签相关的匹配的 Prometheus promql 查询 ; 例如： collectd_uptime{service="default-cloud1-coll-meter"}。

第 5 章 使用 Service Telemetry Framework 的操作功能

您可以使用以下操作功能为 Service Telemetry Framework (STF)提供额外的功能：

5.1. Service Telemetry Framework 中的仪表板

使用第三方应用程序 Grafana 来视觉化数据收集器为各个主机节点收集的系统级指标。

有关配置数据收集器的更多信息，请参阅 第 4.1 节 “使用 director 为 Service Telemetry Framework 部署 Red Hat OpenStack Platform overcloud”。

您可以使用仪表板来监控云：

基础架构仪表板
使用基础架构仪表板查看单个节点的指标。从控制面板的左上角选择一个节点。
Cloud view 仪表板

使用云视图仪表板查看面板，以监控服务资源使用情况、API 统计和云事件。您必须启用 API 健康监控和服务监控，以便为此仪表板提供数据。在 STF 基础配置中默认启用 API 健康监控。更多信息请参阅 第 4.1.3 节 “为 STF 创建基本配置”。

虚拟机视图仪表板
使用虚拟机视图仪表板查看面板，以监控虚拟机基础架构使用情况。从控制面板的左上角选择云和项目。如果要在此仪表板上启用事件注解，则必须启用事件存储。如需更多信息，请参阅 第 3.2 节 “在 Red Hat OpenShift Container Platform 中创建 ServiceTelemetry 对象”。
Memcached view 仪表板
使用 memcached 视图仪表板查看面板，以监控连接、可用性、系统指标和缓存性能。从控制面板的左上角选择云。

5.1.1. 配置 Grafana 以托管仪表板

Grafana 不包含在默认的 Service Telemetry Framework (STF)部署中，因此您必须从 community-operators CatalogSource 部署 Grafana Operator。如果使用 Service Telemetry Operator 部署 Grafana，它会生成 Grafana 实例，并配置本地 STF 部署的默认数据源。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 使用 community-operators CatalogSource 订阅 Grafana Operator：

    警告

    社区 Operator 是尚未被红帽审查或验证的 Operator。社区 Operator 应谨慎使用，因为其稳定性未知。红帽不支持社区 Operator。

    了解更多有关红帽的第三方软件支持政策 

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

  4. 验证 Operator 是否已成功启动。在命令输出中，如果 PHASE 列的值是 Succeeded，Operator 会成功启动： 

    $ oc get csv --selector operators.coreos.com/grafana-operator.service-telemetry

NAME                       DISPLAY            VERSION   REPLACES                   PHASE
grafana-operator.v4.10.1   Grafana Operator   4.10.1    grafana-operator.v4.10.0   Succeeded

  5. 要启动 Grafana 实例，请创建或修改 ServiceTelemetry 对象。将 graphing.enabled 和 graphing.grafana.ingressEnabled 设置为 true。另外，还可将 graphing.grafana.baseImage 的值设置为要部署的 Grafana 工作负载容器镜像： 

    $ oc edit stf default

apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
...
spec:
  ...
  graphing:
    enabled: true
    grafana:
      ingressEnabled: true
      baseImage: 'registry.redhat.io/rhel8/grafana:7'

  6. 验证 Grafana 实例是否已部署： 

    $ oc get pod -l app=grafana

NAME                                  READY   STATUS    RESTARTS   AGE
grafana-deployment-7fc7848b56-sbkhv   1/1     Running   0          1m

  7. 验证 Grafana 数据源是否已正确安装： 

    $ oc get grafanadatasources

NAME                    AGE
default-datasources     20h

  8. 验证 Grafana 路由是否存在： 

    $ 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

5.1.2. 覆盖默认的 Grafana 容器镜像

Service Telemetry Framework (STF)中的仪表板需要仅在 Grafana 版本 8.1.0 及更高版本中提供的功能。默认情况下，Service Telemetry Operator 会安装兼容版本。您可以使用 graphing.grafana.baseImage 指定到镜像 registry 的镜像路径来覆盖基本 Grafana 镜像。

流程

  1. 确保具有正确的 Grafana 版本： 

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

  2. 如果运行的镜像早于 8.1.0，请修补 ServiceTelemetry 对象以更新该镜像。Service Telemetry Operator 更新 Grafana 清单，它会重启 Grafana 部署： 

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

  3. 验证新 Grafana pod 是否存在，并且 STATUS 的值为 Running： 

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

  4. 验证新实例是否正在运行更新的镜像： 

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

5.1.3. 导入仪表板

Grafana Operator 可以通过创建 GrafanaDashboard 对象来导入和管理仪表板。您可以在 https://github.com/infrawatch/dashboards 查看示例仪表板。

流程

  1. 导入基础架构仪表板： 

    $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1/rhos-dashboard.yaml

grafanadashboard.integreatly.org/rhos-dashboard-1 created

  2. 导入云仪表板：

    警告

    在 enable-stf.yaml 文件中，确保将 collectd virt 插件参数 hostname_format 的值设置为 name uuid hostname，否则云仪表板上的一些面板没有显示任何信息。有关 virt 插件的更多信息，请参阅 collectd 插件。 

    $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1/rhos-cloud-dashboard.yaml

grafanadashboard.integreatly.org/rhos-cloud-dashboard-1 created

  3. 导入云事件仪表板： 

    $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1/rhos-cloudevents-dashboard.yaml

grafanadashboard.integreatly.org/rhos-cloudevents-dashboard created

  4. 导入虚拟机仪表板： 

    $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1/virtual-machine-view.yaml

grafanadashboard.integreatly.org/virtual-machine-view-1 configured

  5. 导入 memcached 仪表板： 

    $ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1/memcached-dashboard.yaml

grafanadashboard.integreatly.org/memcached-dashboard-1 created

  6. 验证仪表板是否可用： 

    $ oc get grafanadashboards

NAME                         AGE
memcached-dashboard-1        7s
rhos-cloud-dashboard-1       23s
rhos-cloudevents-dashboard   18s
rhos-dashboard-1             29s
virtual-machine-view-1       13s

  7. 检索 Grafana 路由地址： 

    $ oc get route grafana-route -ojsonpath='{.spec.host}'

grafana-route-service-telemetry.apps.infra.watch
  8. 在 Web 浏览器中，进入到 https://<grafana_route_address>。使用您在上一步中获得的值替换 <grafana_route_address>。
  9. 要查看仪表板，请点 Dashboards 和 Manage。

5.1.4. 检索和设置 Grafana 登录凭证

启用 Grafana 时，您可以使用 openshift 身份验证登录，或者 Grafana Operator 设置的默认用户名和密码。

您可以覆盖 ServiceTelemetry 对象中的凭证，使 Service Telemetry Framework (STF)设置 Grafana 的用户名和密码。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 从 STF 对象检索现有的用户名和密码： 

    $ oc get stf default -o jsonpath="{.spec.graphing.grafana['adminUser','adminPassword']}"

  4. 要通过 ServiceTelemetry 对象修改 Grafana 管理员用户名和密码的默认值，请使用 graphing.grafana.adminUser 和 graphing.grafana.adminPassword 参数。 

    $ oc edit stf default

  5. 等待 grafana pod 使用新凭证重启 

    $ oc get po -l app=grafana -w

5.2. Service Telemetry Framework 中的指标保留时间段

在 Service Telemetry Framework (STF)中存储的指标的默认保留时间为 24 小时，它为警报目的提供了足够的数据。

对于长期存储，请使用专为长期数据保留而设计的系统，例如 Thanos。

其他资源

5.2.1. 在 Service Telemetry Framework 中编辑指标保留时间段

您可以调整 Service Telemetry Framework (STF)以提供额外的指标保留时间。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  4. 将 retention: 7d 添加到 backends.metrics.prometheus.storage 的 storage 部分，将保留周期增加到 7 天：

    注意

    如果您设置了较长的保留周期，从大量填充的 Prometheus 系统检索数据可能会导致查询缓慢返回结果。 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  ...
  backends:
    metrics:
      prometheus:
        enabled: true
        storage:
          strategy: persistent
          retention: 7d
    ...
  5. 保存您的更改并关闭对象。

  6. 等待 prometheus 使用新设置重启。 

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

  7. 通过检查 pod 中使用的命令行参数来验证新的保留设置。 

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

其他资源

5.3. Service Telemetry Framework 中的警报

您可以在 Alertmanager 中的 Prometheus 和警报路由中创建警报规则。Prometheus 服务器中的警报规则将警报发送到管理警报的 Alertmanager。Alertmanager 可以静默、禁止或聚合警报，并使用电子邮件、调用通知系统或聊天平台发送通知。

要创建警报，请完成以下任务：

  1. 在 Prometheus 中创建警报规则。更多信息请参阅 第 5.3.1 节 “在 Prometheus 中创建警报规则”。

  2. 在 Alertmanager 中创建警报路由。您可以通过两种方式来创建警报路由：

其他资源

有关使用 Prometheus 和 Alertmanager 的警报或通知的更多信息，请参阅 https://prometheus.io/docs/alerting/overview/

要查看可与 Service Telemetry Framework (STF)搭配使用的警报示例集合，请参阅 https://github.com/infrawatch/service-telemetry-operator/tree/master/deploy/alerts

5.3.1. 在 Prometheus 中创建警报规则

Prometheus 评估警报规则以触发通知。如果规则条件返回空结果集，则条件为 false。否则，该规则为 true，它会触发警报。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 创建包含警报规则的 PrometheusRule 对象。Prometheus Operator 将规则加载到 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
EOF

    要更改规则，请编辑 expr 参数的值。

  4. 要验证 Operator 是否已将规则加载到 Prometheus 中，请使用基本身份验证针对 default-prometheus-proxy 路由运行 curl 命令： 

    $ curl -k --user "internal:$(oc get secret default-prometheus-htpasswd -ogo-template='{{ .data.password | base64decode }}')" 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"}]}}

其他资源

5.3.2. 配置自定义警报

您可以将自定义警报添加到您在 第 5.3.1 节 “在 Prometheus 中创建警报规则” 中创建的 PrometheusRule 对象中。

流程

  1. 使用 oc edit 命令： 

    $ oc edit prometheusrules prometheus-alarm-rules
  2. 编辑 PrometheusRules 清单。
  3. 保存并关闭清单。

其他资源

5.3.3. 在 Alertmanager 中创建标准警报路由

使用 Alertmanager 向外部系统发送警报，如电子邮件、IRC 或其他通知频道。Prometheus Operator 将 Alertmanager 配置作为 Red Hat OpenShift Container Platform secret 进行管理。默认情况下，Service Telemetry Framework (STF)部署了一个基本配置，它没有接收器： 

alertmanager.yaml: |-
  global:
    resolve_timeout: 5m
  route:
    group_by: ['job']
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 12h
    receiver: 'null'
  receivers:
  - name: 'null'

要使用 STF 部署自定义 Alertmanager 路由，您必须将 alertmanagerConfigManifest 参数添加到生成由 Prometheus Operator 管理的 Service Telemetry Operator 中。

注意

如果您的 alertmanagerConfigManifest 包含自定义模板，例如构建发送警报的标题和文本，则必须使用 base64 编码的配置部署 alertmanagerConfigManifest 的内容。如需更多信息，请参阅 第 5.3.4 节 “在 Alertmanager 中创建带有模板模板的警报路由”。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 编辑 STF 部署的 ServiceTelemetry 对象： 

    $ oc edit stf default

  4. 添加新参数 alertmanagerConfigManifest 和 Secret 对象内容，以定义 Alertmanager 的 alertmanager.yaml 配置：

    注意

    此步骤加载 Service Telemetry Operator 管理的默认模板。要验证更改是否已正确填充，更改值，返回 alertmanager-default secret，并验证新值是否已加载到内存中。例如，将参数 global.resolve_timeout 的值从 5m 改为 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. 验证配置是否已应用到 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. 针对 alertmanager-proxy 服务运行 prometheus pod 中的 wget 命令，以检索状态和 configYAML 内容，并验证提供的配置是否与 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. 验证 configYAML 字段是否包含您预期的更改。

  8. 要清理环境，请删除 curl pod： 

    $ oc delete pod curl

pod "curl" deleted

其他资源

5.3.4. 在 Alertmanager 中创建带有模板模板的警报路由

使用 Alertmanager 向外部系统发送警报，如电子邮件、IRC 或其他通知频道。Prometheus Operator 将 Alertmanager 配置作为 Red Hat OpenShift Container Platform secret 进行管理。默认情况下，Service Telemetry Framework (STF)部署了一个基本配置，它没有接收器： 

alertmanager.yaml: |-
  global:
    resolve_timeout: 5m
  route:
    group_by: ['job']
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 12h
    receiver: 'null'
  receivers:
  - name: 'null'

如果 alertmanagerConfigManifest 参数包含自定义模板，例如构建发送警报的标题和文本，则必须使用 base64 编码的配置部署 alertmanagerConfigManifest 的内容。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 在名为 alertmanager.yaml 的文件中创建所需的 alertmanager 配置，例如： 

    $ 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. 生成配置清单，并将其添加到 STF 部署的 ServiceTelemetry 对象中： 

    $ 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. 验证配置是否已应用到 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. 针对 alertmanager-proxy 服务运行 prometheus pod 中的 wget 命令，以检索状态和 configYAML 内容，并验证提供的配置是否与 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. 验证 configYAML 字段是否包含您预期的更改。

其他资源

5.4. 将警报作为 SNMP 陷阱发送

要启用 SNMP 陷阱，请修改 ServiceTelemetry 对象并配置 snmpTraps 参数。SNMP 陷阱使用版本 2c 发送。

5.4.1. snmpTraps 的配置参数

snmpTraps 参数包含以下子参数来配置警报接收器：

enabled
将此子参数的值设为 true 以启用 SNMP 陷阱警报接收器。默认值为 false。
target
发送 SNMP 陷阱的目标地址。value 是一个字符串。默认为 192.168.24.254。
端口
发送 SNMP 陷阱的目标端口。value 是一个整数。默认为 162。
community
将 SNMP 陷阱发送到的目标社区。value 是一个字符串。默认为 公共。
retries
SNMP 陷入重试交付限制。value 是一个整数。默认值为 5。
timeout
SNMP 陷阱交付超时（以秒为单位）。value 是一个整数。默认为 1。
alertOidLabel
警报中的标签名称，用于定义 OID 值以发送 SNMP 陷阱。value 是一个字符串。默认为 oid。
trapOidPrefix
SNMP 陷入变量绑定的 OID 前缀。value 是一个字符串。默认为 1.3.6.1.4.1.50495.15。
trapDefaultOid
如果没有通过警报指定警报 OID 标签，则 SNMP 陷阱 OID。value 是一个字符串。默认为 1.3.6.1.4.1.50495.15.1.2.1。
trapDefaultSeverity
如果没有设置警报严重性时，SNM 陷阱严重性。value 是一个字符串。默认为空字符串。

将 snmpTraps 参数配置为 ServiceTelemetry 对象中的 alert.alertmanager.receivers 定义的一部分： 

apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
  alerting:
    alertmanager:
      receivers:
        snmpTraps:
          alertOidLabel: oid
          community: public
          enabled: true
          port: 162
          retries: 5
          target: 192.168.25.254
          timeout: 1
          trapDefaultOid: 1.3.6.1.4.1.50495.15.1.2.1
          trapDefaultSeverity: ""
          trapOidPrefix: 1.3.6.1.4.1.50495.15
...

5.4.2. MIB 定义概述

SNMP 陷阱默认使用对象标识符(OID)值 1.3.6.1.4.1.50495.15.1.2.1。管理信息基础(MIB)模式位于 https://github.com/infrawatch/prometheus-webhook-snmp/blob/master/PROMETHEUS-ALERT-CEPH-MIB.txt。

OID 数量由以下组件值组成：* 值 1.3.6.1.4.1 是为私有企业定义的全局 OID。* 下一个标识符 50495 是 Ceph 机构的 IANA 分配的专用企业编号。* 其他值是父值的子 OID。

15
Prometheus 对象
15.1
Prometheus 警报
15.1.2
Prometheus 警报陷阱
15.1.2.1
Prometheus 警报陷阱默认

prometheus alert trap 默认是一个由几个其他子对象到 OID 1.3.6.1.4.1.50495.15 的对象，它由 alert. alertmanager.receivers.snmpTraps.trapOidPrefix 参数定义：

<trapOidPrefix>.1.1.1
警报名称
<trapOidPrefix>.1.1.2
status
<trapOidPrefix>.1.1.3
严重性
<trapOidPrefix>.1.1.4
实例
<trapOidPrefix>.1.1.5
job
<trapOidPrefix>.1.1.6
description
<trapOidPrefix>.1.1.7
labels
<trapOidPrefix>.1.1.8
timestamp
<trapOidPrefix>.1.1.9
rawdata

以下是输出一个简单的 SNMP 陷阱接收器的输出示例，该接收器将收到的陷阱输出到控制台： 

  SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.50495.15.1.2.1
  SNMPv2-SMI::enterprises.50495.15.1.1.1 = STRING: "TEST ALERT FROM PROMETHEUS PLEASE ACKNOWLEDGE"
  SNMPv2-SMI::enterprises.50495.15.1.1.2 = STRING: "firing"
  SNMPv2-SMI::enterprises.50495.15.1.1.3 = STRING: "warning"
  SNMPv2-SMI::enterprises.50495.15.1.1.4 = ""
  SNMPv2-SMI::enterprises.50495.15.1.1.5 = ""
  SNMPv2-SMI::enterprises.50495.15.1.1.6 = STRING: "TEST ALERT FROM "
  SNMPv2-SMI::enterprises.50495.15.1.1.7 = STRING: "{\"cluster\": \"TEST\", \"container\": \"sg-core\", \"endpoint\": \"prom-https\", \"prometheus\": \"service-telemetry/default\", \"service\": \"default-cloud1-coll-meter\", \"source\": \"SG\"}"
  SNMPv2-SMI::enterprises.50495.15.1.1.8 = Timeticks: (1676476389) 194 days, 0:52:43.89
  SNMPv2-SMI::enterprises.50495.15.1.1.9 = STRING: "{\"status\": \"firing\", \"labels\": {\"cluster\": \"TEST\", \"container\": \"sg-core\", \"endpoint\": \"prom-https\", \"prometheus\": \"service-telemetry/default\", \"service\": \"default-cloud1-coll-meter\", \"source\": \"SG\"}, \"annotations\": {\"action\": \"TESTING PLEASE ACKNOWLEDGE, NO FURTHER ACTION REQUIRED ONLY A TEST\"}, \"startsAt\": \"2023-02-15T15:53:09.109Z\", \"endsAt\": \"0001-01-01T00:00:00Z\", \"generatorURL\": \"http://prometheus-default-0:9090/graph?g0.expr=sg_total_collectd_msg_received_count+%3E+1&g0.tab=1\", \"fingerprint\": \"feefeb77c577a02f\"}"

5.4.3. 配置 SNMP 陷阱

先决条件

  • 确保您知道要将警报发送到的 SNMP 陷阱接收器的 IP 地址或主机名。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 要启用 SNMP 陷阱，修改 ServiceTelemetry 对象： 

    $ oc edit stf default

  4. 设置 alerting.alertmanager.receivers.snmpTraps 参数： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
...
spec:
  ...
  alerting:
    alertmanager:
      receivers:
        snmpTraps:
          enabled: true
          target: 10.10.10.10
  5. 确保将 target 的值设置为 SNMP 陷阱接收器的 IP 地址或主机名。

其它信息

有关 snmpTraps 可用参数的详情，请参考 第 5.4.1 节 “snmpTraps 的配置参数”。

5.4.4. 为 SNMP 陷阱创建警报

您可以通过添加由 prometheus-webhook-snmp 中间件解析的标签来创建由 SNMP 陷阱配置的警报，以定义陷阱信息和交付对象标识符(OID)。只有在需要更改特定警报定义的默认值时，才需要添加 oid 或 severity 标签。

注意
当您设置 oid 标签时，顶级 SNMP 陷阱 OID 更改，但 sub-OID 仍由全局 trapOidPrefix 值定义，加上子 OID 值 .1.1.1 到 .1.1.9。有关 MIB 定义的详情，请参考 第 5.4.2 节 “MIB 定义概述”。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 创建包含警报规则和包含 SNMP trap OID 覆盖值的 oid 标签的 PrometheusRule 对象： 

    $ oc apply -f - <<EOF
apiVersion: monitoring.coreos.com/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

附加信息

有关配置警报的更多信息，请参阅 第 5.3 节 “Service Telemetry Framework 中的警报”。

5.5. 为 TLS 证书配置持续时间

要配置用于与 Service Telemetry Framework (STF)中的 Elasticsearch 和 AMQ Interconnect 连接的 TLS 证书持续时间，请修改 ServiceTelemetry 对象并配置 证书 参数。

5.5.1. TLS 证书的配置参数

您可以使用 certificate 参数的以下子参数配置 证书 的持续时间：

endpointCertDuration
端点证书请求的持续时间或生命周期。最少接受的持续时间为 1 小时。值必须采用 Go time.ParseDuration https://golang.org/pkg/time/#ParseDuration 接受的单位。默认值为 70080h。
caCertDuration
CA 证书请求的 持续时间或生命周期。最少接受的持续时间为 1 小时。值必须采用 Go time.ParseDuration https://golang.org/pkg/time/#ParseDuration 接受的单位。默认值为 70080h。
注意
证书的默认持续时间比较长，因为在证书续订时，通常在 Red Hat OpenStack Platform 部署中复制部分证书。有关 QDR CA 证书续订过程的更多信息，请参阅 第 6 章 续订 AMQ Interconnect 证书

Elasticsearch 的 certificate 参数是 backends.events.elasticsearch 定义的一部分，并在 ServiceTelemetry 对象中配置： 

apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
...
  backends:
    ...
    events:
      elasticsearch:
        enabled: true
        version: 7.16.1
        certificates:
          endpointCertDuration: 70080h
          caCertDuration: 70080h
...

您可以为 QDR 配置 certificate 参数，它是 ServiceTelemetry 对象中的 transports.qdr 定义的一部分： 

apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
  name: default
  namespace: service-telemetry
spec:
...
  transports:
    ...
    qdr:
      enabled: true
      certificates:
        endpointCertDuration: 70080h
        caCertDuration: 70080h
...

5.5.2. 配置 TLS 证书持续时间

要配置与 Service Telemetry Framework (STF)一起使用的 TLS 证书的持续时间，请修改 ServiceTelemetry 对象并配置 certificate 参数。

先决条件

  • 您尚未部署 Service Telemetry Operator 实例。

    注意
    在创建 ServiceTelemetry 对象时，也会为 STF 创建所需的证书及其 secret。有关如何修改证书和 secret 的更多信息，请参阅： 第 6 章 续订 AMQ Interconnect 证书 对于新的 STF 部署有效。

流程

要编辑 TLS 证书的持续时间，您可以设置 Elasticsearch endpointCertDuration，例如 26280h 3 年，并设置 QDR caCertDuration，例如 87600h 为 10 年。您可以将默认值 8 年用于 Elasticsearch 和端点证书的 CA 证书：

+ 

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

验证

  1. 验证证书的到期日期是否正确： 

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

$ 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

5.6. 高可用性

借助高可用性，Service Telemetry Framework (STF)可从组件服务中的故障中快速恢复。虽然如果节点可用于调度工作负载，Red Hat OpenShift Container Platform 会重启一个失败的 pod，但这个恢复过程可能需要一分钟以上，在此期间事件和指标会丢失。高可用性配置包括 STF 组件的多个副本，这可将恢复时间缩短到大约 2 秒。要防止 Red Hat OpenShift Container Platform 节点失败，请使用三个或更多节点将 STF 部署到 Red Hat OpenShift Container Platform 集群中。

警告

STF 尚未是一个完全容错的系统。无法保证在恢复期间提供指标和事件。

启用高可用性有以下影响：

  • 三个 Elasticsearch Pod 运行而不是默认的 Pod。

  • 以下组件运行两个 pod，而不是默认的 pod：

    • AMQ Interconnect
    • Alertmanager
    • Prometheus
    • 事件智能网关
    • 指标智能网关
  • 恢复其中任何服务丢失的 pod 的时间会减少到大约 2 秒。

5.6.1. 配置高可用性

要配置 Service Telemetry Framework (STF)以实现高可用性，请将 highAvailability.enabled: true 添加到 Red Hat OpenShift Container Platform 中的 ServiceTelemetry 对象中。您可以在安装时设置此参数，或者如果您已经部署了 STF，请完成以下步骤：

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 使用 oc 命令编辑 ServiceTelemetry 对象： 

    $ oc edit stf default

  4. 将 highAvailability.enabled: true 添加到 spec 部分： 

    apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
...
spec:
  ...
  highAvailability:
    enabled: true
  5. 保存您的更改并关闭对象。

5.7. Service Telemetry Framework 中的可观察性策略

Service Telemetry Framework (STF)不包括存储后端和警报工具。STF 使用社区操作器来部署 Prometheus、Alertmanager、Grafana 和 Elasticsearch。STF 向这些社区操作器发出请求，以创建配置为使用 STF 的每个应用程序的实例。

除了让 Service Telemetry Operator 创建自定义资源请求外，您可以使用您自己的应用程序部署或其他兼容应用程序，并提取指标 智能网关以发送到您自己的 Prometheus 兼容系统以进行遥测存储。如果将 observabilityStrategy 设置为 none，则不会部署存储后端，因此 STF 不需要持久性存储。

5.7.1. 配置备用可观察性策略

要将 STF 配置为跳过存储、视觉化和警报后端的部署，请将 observabilityStrategy: none 添加到 ServiceTelemetry spec 中。在这个模式中，只部署 AMQ Interconnect 路由器和指标智能网关，您必须配置与 Prometheus 兼容的外部系统，以便从 STF 智能网关收集指标。

注意

目前，当您将 observabilityStrategy 设置为 none 时，只支持指标。事件智能网关不会被部署。

流程

  1. 在 spec 参数中，使用属性 observabilityStrategy: none 创建一个 ServiceTelemetry 对象。清单显示会导致 STF 的默认部署，该部署适合从具有所有指标收集器类型的单个云接收遥测。 

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

  2. 删除由社区操作器管理的对象上的左侧 

    $ for o in alertmanager/default prometheus/default elasticsearch/elasticsearch grafana/default; do oc delete $o; done

  3. 要验证所有工作负载是否都正常运行，请查看 pod 和每个 pod 的状态： 

    $ oc get pods
NAME                                                      READY   STATUS    RESTARTS   AGE
default-cloud1-ceil-meter-smartgateway-59c845d65b-gzhcs   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

其他资源

有关配置附加云或更改支持的收集器集合的更多信息，请参阅 第 4.3.2 节 “部署智能网关”

5.8. Red Hat OpenStack Platform 服务的资源使用

您可以通过显示没有计算功能的服务来监控 Red Hat OpenStack Platform (RHOSP)服务的资源使用情况，如 API 和其他基础架构进程，以识别 overcloud 中的瓶颈。默认启用资源使用情况监控。

其他资源

5.8.1. 禁用 Red Hat OpenStack Platform 服务的资源使用情况监控

要禁用 RHOSP 容器化服务资源使用情况的监控，您必须将 CollectdEnableLibpodstats 参数设置为 false。

前提条件

流程

  1. 打开 stf-connectors.yaml 文件，并添加 CollectdEnableLibpodstats 参数来覆盖 enable-stf.yaml 中的设置。在 enable-stf.yaml 后，确保从 openstack overcloud deploy 命令调用 stf-connectors.yaml ： 

      CollectdEnableLibpodstats: false
  2. 继续 overcloud 部署过程。更多信息请参阅 第 4.1.5 节 “部署 overcloud”。

5.9. Red Hat OpenStack Platform API 状态和容器化服务健康状况

您可以通过定期运行健康检查脚本，使用 OCI （开放容器项目）标准来评估每个 Red Hat OpenStack Platform (RHOSP)服务的容器健康状况。大多数 RHOSP 服务实施健康检查，用于记录问题并返回二进制状态。对于 RHOSP API，健康检查会查询根端点，并根据响应时间确定健康状况。

默认启用对 RHOSP 容器健康和 API 状态的监控。

其他资源

5.9.1. 禁用容器健康和 API 状态监控

要禁用 RHOSP 容器化服务健康和 API 状态监控，您必须将 CollectdEnableSensubility 参数设置为 false。

前提条件

流程

  1. 打开 stf-connectors.yaml，并添加 CollectdEnableSensubility 参数来覆盖 enable-stf.yaml 中的设置。在 enable-stf.yaml 后，确保从 openstack overcloud deploy 命令调用 stf-connectors.yaml ： 

    CollectdEnableSensubility: false
  2. 继续 overcloud 部署过程。更多信息请参阅 第 4.1.5 节 “部署 overcloud”。

其他资源

第 6 章 续订 AMQ Interconnect 证书

当证书过期时，您必须续订保护 Red Hat OpenStack Platform (RHOSP)和 Service Telemetry Framework (STF)之间的 AMQ Interconnect 连接的 CA 证书。续订由 Red Hat OpenShift Container Platform 中的 cert-manager 组件自动处理，但您必须手动将更新的证书复制到 RHOSP 节点。

6.1. 检查已过期的 AMQ Interconnect CA 证书

当 CA 证书过期时，AMQ Interconnect 连接会保留，但如果它们中断，则无法重新连接。最后，来自 Red Hat OpenStack Platform (RHOSP)分配路由器的一些或所有连接都失败，在两端显示错误，以及 CA 证书中的 expiry 或 Not After 字段。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 验证部分或所有分配路由器连接是否都失败： 

    $ oc exec -it $(oc get po -l application=default-interconnect -o jsonpath='{.items[0].metadata.name}') -- qdstat --connections | grep Router | wc
      0       0       0

  4. 检查 Red Hat OpenShift Container Platform-hosted AMQ Interconnect 日志中出现的这个错误： 

    $ oc logs -l application=default-interconnect | tail
[...]
2022-11-10 20:51:22.863466 +0000 SERVER (info) [C261] Connection from 10.10.10.10:34570 (to 0.0.0.0:5671) failed: amqp:connection:framing-error SSL Failure: error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure
  5. 登录到您的 RHOSP undercloud。

  6. 检查在带有失败连接的节点的 RHOSP 托管 AMQ Interconnect 日志中出现这个错误： 

    $ ssh controller-0.ctlplane -- sudo tail /var/log/containers/metrics_qdr/metrics_qdr.log
[...]
2022-11-10 20:50:44.311646 +0000 SERVER (info) [C137] Connection to default-interconnect-5671-service-telemetry.apps.mycluster.com:443 failed: amqp:connection:framing-error SSL Failure: error:0A000086:SSL routines::certificate verify failed

  7. 通过检查 RHOSP 节点上的文件来确认 CA 证书已过期： 

    $ ssh controller-0.ctlplane -- cat /var/lib/config-data/puppet-generated/metrics_qdr/etc/pki/tls/certs/CA_sslProfile.pem | openssl x509 -text | grep "Not After"
            Not After : Nov 10 20:31:16 2022 GMT

$ date
Mon Nov 14 11:10:40 EST 2022

6.2. 更新 AMQ Interconnect CA 证书

要更新 AMQ Interconnect 证书，您必须从 Red Hat OpenShift Container Platform 导出它，并将其复制到 Red Hat OpenStack Platform (RHOSP)节点。

流程

  1. 登录到 Red Hat OpenShift Container Platform。

  2. 进入 service-telemetry 命名空间： 

    $ oc project service-telemetry

  3. 将 CA 证书导出到 STFCA.pem ： 

    $ oc get secret/default-interconnect-selfsigned -o jsonpath='{.data.ca\.crt}' | base64 -d > STFCA.pem
  4. 将 STFCA.pem 复制到您的 RHOSP undercloud。
  5. 登录到您的 RHOSP undercloud。
  6. 编辑 stf-connectors.yaml 文件，使其包含新的 caCertFileContent。如需更多信息，请参阅 第 4.1.4 节 “为 overcloud 配置 STF 连接”。

  7. 将 STFCA.pem 文件复制到每个 RHOSP overcloud 节点： 

    [stack@undercloud-0 ~]$ ansible -i overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml allovercloud -b -m copy -a "src=STFCA.pem dest=/var/lib/config-data/puppet-generated/metrics_qdr/etc/pki/tls/certs/CA_sslProfile.pem"

  8. 重启每个 RHOSP overcloud 节点上的 metrics_qdr 容器： 

    [stack@undercloud-0 ~]$ ansible -i overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml allovercloud -m shell -a "sudo podman restart metrics_qdr"
    注意

    在复制 STFCA.pem 文件并重启 metrics_qdr 容器后，您不需要部署 overcloud。您可以编辑 stf-connectors.yaml 文件，以便将来的部署不会覆盖新的 CA 证书。

第 7 章 从 Red Hat OpenShift Container Platform 环境中删除 Service Telemetry Framework

如果您不再需要 STF 功能，从 Red Hat OpenShift Container Platform 环境中删除 Service Telemetry Framework (STF)。

要从 Red Hat OpenShift Container Platform 环境中删除 STF，您必须执行以下任务：

  1. 删除命名空间。
  2. 删除 cert-manager Operator。

7.1. 删除命名空间

要从 Red Hat OpenShift Container Platform 中删除 STF 的操作资源，请删除命名空间。

流程

  1. 运行 oc delete 命令： 

    $ oc delete project service-telemetry

  2. 验证资源是否已从命名空间中删除： 

    $ oc get all
No resources found.

7.2. 删除 cert-manager Operator

如果您没有将 cert-manager Operator 用于任何其他应用程序，请删除 Subscription、ClusterServiceVersion 和 CustomResourceDefinitions。

流程

  1. 从 openshift-cert-manager-operator 命名空间中删除订阅： 

    $ oc delete --namespace=openshift-cert-manager-operator subscription openshift-cert-manager-operator

subscription.operators.coreos.com "openshift-cert-manager-operator" deleted

  2. 检索已安装的 ClusterServiceVersion 的版本号： 

    $ oc get --namespace=openshift-cert-manager-operator subscription openshift-cert-manager-operator -oyaml | grep currentCSV

    输出示例： 

      currentCSV: openshift-cert-manager.v1.7.1

  3. 从 openshift-cert-manager-operator 命名空间中删除 ClusterServiceVersion ： 

    $ oc delete --namespace=openshift-cert-manager-operator csv openshift-cert-manager.v1.7.1

    输出示例： 

    clusterserviceversion.operators.coreos.com "openshift-cert-manager.v1.7.1" deleted

  4. 获取 Operator 提供的 CustomResourceDefinitions 的当前列表，以便在删除 ClusterServiceVersion 后删除它们： 

    $ oc get csv -n openshift-cert-manager-operator openshift-cert-manager.v1.7.1 -oyaml | grep "kind: CustomResourceDefinition" -A2 | grep name | awk '{print $2}'

    输出示例： 

    certificaterequests.cert-manager.io
certificates.cert-manager.io
certmanagers.config.openshift.io
certmanagers.operator.openshift.io
challenges.acme.cert-manager.io
clusterissuers.cert-manager.io
issuers.cert-manager.io
orders.acme.cert-manager.io

  5. 删除与 cert-manager Operator 相关的 CustomResourceDefinitions： 

    $ oc delete crd certificaterequests.cert-manager.io certificates.cert-manager.io certmanagers.config.openshift.io certmanagers.operator.openshift.io challenges.acme.cert-manager.io clusterissuers.cert-manager.io issuers.cert-manager.io orders.acme.cert-manager.io

    输出示例： 

    customresourcedefinition.apiextensions.k8s.io "certificaterequests.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "certificates.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "certmanagers.config.openshift.io" deleted
customresourcedefinition.apiextensions.k8s.io "certmanagers.operator.openshift.io" deleted
customresourcedefinition.apiextensions.k8s.io "challenges.acme.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "clusterissuers.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "issuers.cert-manager.io" deleted
customresourcedefinition.apiextensions.k8s.io "orders.acme.cert-manager.io" deleted

  6. 删除 cert-manager Operator 拥有的命名空间： 

    $ oc delete project openshift-cert-manager openshift-cert-manager-operator

    输出示例： 

    project.project.openshift.io "openshift-cert-manager" deleted
project.project.openshift.io "openshift-cert-manager-operator" deleted

附加信息

第 8 章 将 Service Telemetry Framework 升级到 1.5 版本

要将 Service Telemetry Framework (STF) 1.4 升级到 STF 1.5，您必须完成以下步骤：

  • 将 AMQ Certificate Manager 替换为证书管理器。
  • 在 Red Hat OpenShift Container Platform 环境中的 service-telemetry 命名空间中删除 Smart Gateway Operator 和 Service Telemetry Operator 的 ClusterServiceVersion 和 Subscription 对象。
  • 将 Red Hat OpenShift Container Platform 从 4.8 升级到 4.10。
  • 重新启用您移除的操作器。
  • 更新 Red Hat OpenStack Platform (RHOSP)上的 AMQ Interconnect CA 证书。

先决条件

  • 已备份了数据。Red Hat OpenShift Container Platform 升级过程中会出现停机。在 Operator 替换过程中，您无法重新配置 ServiceTelemetry 和 SmartGateway 对象。
  • 您已准备了从 Red Hat OpenShift Container Platform 4.8 升级到支持的版本 4.10 的环境。
  • Red Hat OpenShift Container Platform 集群是完全连接的。STF 不支持断开连接或受限网络集群。

8.1. 删除 Service Telemetry Framework 1.4 Operator

从 Red Hat OpenShift Container Platform 4.8 中删除 Service Telemetry Framework (STF) 1.4 Operator 和 AMQ Certificate Manager Operator。

流程

  1. 删除 Service Telemetry Operator。
  2. 删除 Smart Gateway Operator。
  3. 删除 AMQ Certificate Manager Operator。
  4. 删除 Grafana Operator。

其他资源

8.1.1. 删除 Service Telemetry Operator

作为升级 Service Telemetry Framework (STF)安装的一部分，您必须在 Red Hat OpenShift Container Platform 环境中的 service-telemetry 命名空间中删除 Service Telemetry Operator。

流程

  1. 进入 service-telemetry 项目： 

    $ oc project service-telemetry

  2. 删除 Service Telemetry Operator 订阅： 

    $ oc delete sub --selector=operators.coreos.com/service-telemetry-operator.service-telemetry

subscription.operators.coreos.com "service-telemetry-operator" deleted

  3. 删除 Service Telemetry Operator ClusterServiceVersion ： 

    $ oc delete csv --selector=operators.coreos.com/service-telemetry-operator.service-telemetry

clusterserviceversion.operators.coreos.com "service-telemetry-operator.v1.4.1669718959" deleted

验证

  1. 验证 Service Telemetry Operator 部署没有运行： 

    $ oc get deploy --selector=operators.coreos.com/service-telemetry-operator.service-telemetry

No resources found in service-telemetry namespace.

  2. 验证 Service Telemetry Operator 订阅不存在： 

    $ oc get sub --selector=operators.coreos.com/service-telemetry-operator.service-telemetry

No resources found in service-telemetry namespace.

  3. 验证 Service Telemetry Operator ClusterServiceVersion 不存在： 

    $ oc get csv --selector=operators.coreos.com/service-telemetry-operator.service-telemetry

No resources found in service-telemetry namespace.

8.1.2. 删除 Smart Gateway Operator

作为升级 Service Telemetry Framework (STF)安装的一部分，您必须在 Red Hat OpenShift Container Platform 环境中的 service-telemetry 命名空间中删除 Smart Gateway Operator。

流程

  1. 进入 service-telemetry 项目： 

    $ oc project service-telemetry

  2. 删除 Smart Gateway Operator 订阅： 

    $ oc delete sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry

subscription.operators.coreos.com "smart-gateway-operator-stable-1.4-redhat-operators-openshift-marketplace" deleted

  3. 删除 Smart Gateway Operator ClusterServiceVersion ： 

    $ oc delete csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry

clusterserviceversion.operators.coreos.com "smart-gateway-operator.v4.0.1669718962" deleted

验证

  1. 验证 Smart Gateway Operator 部署没有运行： 

    $ oc get deploy --selector=operators.coreos.com/smart-gateway-operator.service-telemetry

No resources found in service-telemetry namespace.

  2. 验证 Smart Gateway Operator 订阅是否不存在： 

    $ oc get sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry

No resources found in service-telemetry namespace.

  3. 验证 Smart Gateway Operator ClusterServiceVersion 不存在： 

    $ oc get csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry

No resources found in service-telemetry namespace.

8.1.3. 删除 AMQ Certificate Manager Operator

流程

  1. 删除 AMQ Certificate Manager Operator 订阅： 

    $ oc delete sub --namespace openshift-operators --selector=operators.coreos.com/amq7-cert-manager-operator.openshift-operators

subscription.operators.coreos.com "amq7-cert-manager-operator" deleted

  2. 删除 AMQ Certificate Manager Operator ClusterServiceVersion ： 

    $ oc delete csv --namespace openshift-operators --selector=operators.coreos.com/amq7-cert-manager-operator.openshift-operators

clusterserviceversion.operators.coreos.com "amq7-cert-manager.v1.0.11" deleted

验证

  1. 验证 AMQ Certificate Manager Operator 部署没有运行： 

    $ oc get deploy --namespace openshift-operators --selector=operators.coreos.com/amq7-cert-manager-operator.openshift-operators

No resources found in openshift-operators namespace.

  2. 验证 AMQ Certificate Manager Operator 订阅是否不存在： 

    $ oc get sub --namespace openshift-operators --selector=operators.coreos.com/amq7-cert-manager-operator.service-telemetry

No resources found in openshift-operators namespace.

  3. 验证 AMQ Certificate Manager Operator Cluster Service Version 是否不存在： 

    $ oc get csv --namespace openshift-operators --selector=operators.coreos.com/amq7-cert-manager-operator.openshift-operators

No resources found in openshift-operators namespace.

8.1.4. 删除 Grafana Operator

流程

  1. 删除 Grafana Operator 订阅： 

    $ oc delete sub --selector=operators.coreos.com/grafana-operator.service-telemetry

subscription.operators.coreos.com "grafana-operator" deleted

  2. 删除 Grafana Operator ClusterServiceVersion ： 

    $ oc delete csv --selector=operators.coreos.com/grafana-operator.service-telemetry

clusterserviceversion.operators.coreos.com "grafana-operator.v3.10.3" deleted

验证

  1. 验证 Grafana Operator 部署没有运行： 

    $ oc get deploy --selector=operators.coreos.com/grafana-operator.service-telemetry

No resources found in service-telemetry namespace.

  2. 验证 Grafana Operator 订阅不存在： 

    $ oc get sub --selector=operators.coreos.com/grafana-operator.service-telemetry

No resources found in service-telemetry namespace.

  3. 验证 Grafana Operator Cluster Service Version 不存在： 

    $ oc get csv --selector=operators.coreos.com/grafana-operator.service-telemetry

No resources found in service-telemetry namespace.

8.2. 将 Red Hat OpenShift Container Platform 升级到 4.10

Service Telemetry Framework (STF) 1.5 仅与 Red Hat OpenShift Container Platform 4.10 兼容。有关将 Red Hat OpenShift Container Platform 从 4.8 升级到 4.10 的更多信息，请参阅更新集群概述。

先决条件

  • 您已删除了 STF 1.4 Operator。
  • 您已删除了 AMQ Certificate Manager Operator 和 Grafana Operator。您必须在升级 Red Hat OpenShift Container Platform 前删除 Operator，因为 Operator API 与 4.10 不兼容。有关准备 Red Hat OpenShift Container Platform 从 4.8 升级到 4.10 的更多信息，请参阅了解 OpenShift Container Platform 更新。

  • 验证 Red Hat OpenShift Container Platform 升级是否可行： 

    $ oc adm upgrade

    如果您遇到以下出错信息，则无法升级集群： 

    Cluster operator operator-lifecycle-manager should not be upgraded between minor versions: ClusterServiceVersions blocking cluster upgrade: service-telemetry/grafana-operator.v3.10.3 is incompatible with OpenShift minor versions greater than 4.8,openshift-operators/amq7-cert-manager.v1.0.11 is incompatible with OpenShift minor versions greater than 4.8

8.3. 安装 Service Telemetry Framework 1.5 Operator

在 Red Hat OpenShift Container Platform 环境中为 OpenShift Operator 安装 Service Telemetry Framework (STF) 1.5 Operator 和 Certificate Manager。有关 STF 支持状态和生命周期的更多信息，请参阅 第 1.1 节 “支持 Service Telemetry Framework”。

注意

成功安装 STF 1.5 后，您必须检索 AMQ Interconnect CA 证书并将其应用到 Red Hat OpenStack Platform 环境，或者传输层和遥测数据不可用。

有关更新 AMQ Interconnect CA 证书的更多信息，请参阅 第 8.4 节 “在 Red Hat OpenStack Platform 上更新 AMQ Interconnect CA 证书”。

先决条件

流程

  1. 进入 service-telemetry 项目： 

    $ oc project service-telemetry

  2. 为 cert-manager Operator 创建命名空间 ： 

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

  3. 为 cert-manager Operator 创建 OperatorGroup ： 

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

  4. 使用 redhat-operators CatalogSource 订阅 cert-manager Operator： 

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

  5. 验证您的 ClusterServiceVersion。确保 cert-manager Operator 的阶段为 Succeeded ： 

    $ oc get csv --namespace openshift-cert-manager-operator --selector=operators.coreos.com/openshift-cert-manager-operator.openshift-cert-manager-operator

NAME                            DISPLAY                                       VERSION   REPLACES   PHASE
openshift-cert-manager.v1.7.1   cert-manager Operator for Red Hat OpenShift   1.7.1-1              Succeeded
  6. 可选：重新订阅 Grafana Operator。如需更多信息，请参阅：测试 第 5.1.1 节 “配置 Grafana 以托管仪表板”。

  7. 创建 Service Telemetry Operator 订阅来管理 STF 实例： 

    $ 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

  8. 验证 Service Telemetry Operator 和依赖的 Operator： 

    $ oc get csv --namespace service-telemetry

NAME                                          DISPLAY                                       VERSION          REPLACES                                      PHASE
amq7-interconnect-operator.v1.10.13           Red Hat Integration - AMQ Interconnect        1.10.13          amq7-interconnect-operator.v1.10.4            Succeeded
elasticsearch-eck-operator-certified.v2.5.0   Elasticsearch (ECK) Operator                  2.5.0            elasticsearch-eck-operator-certified.v2.4.0   Succeeded
openshift-cert-manager.v1.7.1                 cert-manager Operator for Red Hat OpenShift   1.7.1-1                                                        Succeeded
prometheusoperator.0.47.0                     Prometheus Operator                           0.47.0           prometheusoperator.0.37.0                     Succeeded
service-telemetry-operator.v1.5.1669950702    Service Telemetry Operator                    1.5.1669950702                                                 Succeeded
smart-gateway-operator.v5.0.1669950681        Smart Gateway Operator                        5.0.1669950681                                                 Succeeded

验证

  • 验证 Service Telemetry Operator 是否已成功协调。 

    $ oc logs -f --selector=name=service-telemetry-operator

[...]
----- Ansible Task Status Event StdOut (infra.watch/v1beta1, Kind=ServiceTelemetry, default/service-telemetry) -----


PLAY RECAP *********************************************************************
localhost                  : ok=115  changed=0    unreachable=0    failed=0    skipped=21   rescued=0    ignored=0


$ oc get pods
NAME                                                      READY   STATUS    RESTARTS        AGE
alertmanager-default-0                                    3/3     Running   0               20h
default-cloud1-ceil-event-smartgateway-6d57ffbbdc-5mrj8   2/2     Running   1 (3m42s ago)   4m21s
default-cloud1-ceil-meter-smartgateway-67684d88c8-62mp7   3/3     Running   1 (3m43s ago)   4m20s
default-cloud1-coll-event-smartgateway-66cddd5567-qb6p2   2/2     Running   1 (3m42s ago)   4m19s
default-cloud1-coll-meter-smartgateway-76d5ff6db5-z5ch8   3/3     Running   0               4m20s
default-cloud1-sens-meter-smartgateway-7b59669fdd-c42zg   3/3     Running   1 (3m43s ago)   4m20s
default-interconnect-845c4b647c-wwfcm                     1/1     Running   0               4m10s
elastic-operator-57b57964c5-6q88r                         1/1     Running   8 (17h ago)     20h
elasticsearch-es-default-0                                1/1     Running   0               21h
grafana-deployment-59c54f7d7c-zjnhm                       2/2     Running   0               20h
interconnect-operator-848889bf8b-bq2zx                    1/1     Running   0               20h
prometheus-default-0                                      3/3     Running   1 (20h ago)     20h
prometheus-operator-5d7b69fd46-c2xlv                      1/1     Running   0               20h
service-telemetry-operator-79fb664dfb-nj8jn               1/1     Running   0               5m11s
smart-gateway-operator-79557664f8-ql7xr                   1/1     Running   0               5m7s

8.4. 在 Red Hat OpenStack Platform 上更新 AMQ Interconnect CA 证书

升级到 Service Telemetry Framework (STF) v1.5 后，AMQ Interconnect 的 CA 证书会重新生成。在 STF v1.4 中，AMQ Interconnect 的 CA 证书在 3 个月内有效，必须在 Red Hat OpenStack Platform (RHOSP)中定期更新。在 STF v1.5 中，生成的证书在 RHOSP 生命周期的生命周期内有效，默认为 70080 小时。

先决条件

  • 您已成功安装了 STF v1.5，并为 AMQ Interconnect 更新 CA 证书。

流程

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.