Service Telemetry Framework 1.4
安装和部署 Service Telemetry Framework 1.4
OpenStack Documentation Team
rhos-docs@redhat.com摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。
使用直接文档反馈(DDF)功能
使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。
- 以 Multi-page HTML 格式查看文档。
- 请确定您看到文档右上角的 反馈 按钮。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点 添加反馈。
- 在添加反馈项中输入您的意见。
- 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
- 点 Submit。
第 1 章 Service Telemetry Framework {TargetVersion} 简介.
Service Telemetry Framework(STF)从 Red Hat OpenStack Platform(RHOSP)或第三方节点收集监控数据。您可以使用 STF 执行以下任务:
- 存储或存档监控数据以了解历史信息。
- 在仪表板中以图形方式查看监控数据。
- 使用监控数据触发警报或警告。
监控数据可以是指标或事件:
- 指标
- 应用程序或系统的数字测量。
- 事件
- 在系统中出现的不规范和离散发生。
STF 组件使用消息总线进行数据传输。接收和存储数据的其他模块化组件作为容器部署到 Red Hat OpenShift Container Platform 中。
Service Telemetry Framework (STF)与 Red Hat OpenShift Container Platform 版本 4.10 通过 4.10 兼容。
其他资源
- 有关如何部署 Red Hat OpenShift Container Platform 的更多信息,请参阅 Red Hat OpenShift Container Platform 产品文档。
- 您可以在云平台或裸机上安装 Red Hat OpenShift Container Platform。有关 STF 性能和可扩展性的更多信息,请参阅 https://access.redhat.com/articles/4907241。
- 您可以在裸机或其他支持的云平台上安装 Red Hat OpenShift Container Platform。有关安装 Red Hat OpenShift Container Platform 的更多信息,请参阅 OpenShift Container Platform 4.10 文档。
1.1. 支持服务 Telemetry Framework
红帽支持两个最新版本的服务 Telemetry Framework (STF)。不支持更早的版本。如需更多信息,请参阅 Service Telemetry Framework 支持的版本列表。
红帽支持核心 Operator 和工作负载,包括 AMQ Interconnect、AMQ Certificate Manager、Service Telemetry Operator 和 Smart Gateway Operator。红帽不支持社区 Operator 或工作负载组件,如 Elasticsearch、Prometheus、Alertmanager、Grafana 以及它们的 Operator。
您只能在完全连接的网络环境中部署 STF。您无法在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中部署 STF。
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 事件的事件数据存储。
影响
- Alertmanager:一个警报工具,它使用 Prometheus 警报规则来管理警报。
- Grafana:可用于查询、视觉化和探索数据的视觉化和分析应用程序。
下表描述了客户端和服务器组件的应用程序:
表 1.1. STF 的客户端和服务器组件
| 组件 | 客户端 | Server |
|---|---|---|
| AMQP 1.x 兼容消息传递总线 | 是 | 是 |
| 智能网关 | 否 | 是 |
| Prometheus | 否 | 是 |
| ElasticSearch | 否 | 是 |
| collectd | 是 | 否 |
| Ceilometer | 是 | 否 |
为确保监控平台可以报告云的操作问题,请不要在监控的同一基础架构上安装 STF。
图 1.1. Service Telemetry Framework 架构概述

对于客户端侧指标,collectd 提供没有项目数据的基础架构指标,Ceilometer 则根据项目或用户工作负载提供 RHOSP 平台数据。Ceilometer 和 collectd 使用 AMQ 互联传输向 Prometheus 提供数据,从而通过消息总线传输数据。在服务器端,名为 Smart Gateway 的 Golang 应用程序从总线获取数据流,并将其公开为 Prometheus 的本地提取端点。
如果您计划收集和存储事件,collectd 和 Ceilometer 通过使用 AMQ Interconnect 传输向服务器端发送事件数据。另一个智能网关会将数据写入 ElasticSearch 数据存储。
服务器端的 STF 监控基础架构由以下层组成:
- Service Telemetry Framework 1.5
- Red Hat OpenShift Container Platform 4.10 到 4.10
- 基础架构平台
图 1.2. 服务器端 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 环境
要为服务 Telemetry Framework (STF)准备 Red Hat OpenShift Container Platform 环境,您必须规划持久性存储、适当的资源、事件存储和网络注意事项:
- 确保 Red Hat OpenShift Container Platform 集群中有可用的持久性存储用于生产级部署。更多信息请参阅 第 2.2 节 “持久性卷(PV)”。
- 确保有足够的资源用于运行 Operator 和应用程序容器。更多信息请参阅 第 2.3 节 “资源分配”。
- 确定您有完全连接的网络环境。更多信息请参阅 第 2.4 节 “Service Telemetry Framework 的网络注意事项”。
2.1. Service Telemetry Framework 中的可观察性策略
Service Telemetry Framework(STF)不包括存储后端和警报工具。STF 使用社区操作器来部署 Prometheus、Alertmanager、Grafana 和 Elasticsearch。STF 向这些社区操作器发出请求,以创建配置为使用 STF 的每个应用程序的实例。
您可以使用您自己的应用程序部署这些应用程序或其他兼容应用程序,而不必让 Service Telemetry Operator 创建自定义资源,而是提取指标智能网关以传送到您自己的与 Prometheus 兼容的系统以进行遥测存储。如果将 observability 策略设置为使用备用后端,则 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 的卷。
其他资源
- 如需有关为 Red Hat OpenShift Container Platform 配置持久性存储的更多信息,请参阅了解持久性存储。
- 有关在 Red Hat OpenShift Container Platform 中推荐的可配置存储技术的更多信息,请参阅 推荐的可配置存储技术。
- 有关在 STF 中配置 Prometheus 持久性存储的更多信息,请参阅 “为 Prometheus 配置持久性存储”一节。
- 有关在 STF 中配置持久性存储的详情,请参考 “为 ElasticSearch 配置持久性存储”一节。
2.2.1. 临时存储
您可以使用临时存储来运行 Service Telemetry Framework(STF),而无需将数据存储到 Red Hat OpenShift Container Platform 集群中。
如果使用临时存储,则在 pod 重启、更新或重新调度到另一节点上时,可能会遇到数据丢失。仅将临时存储用于开发或测试,而不适用于生产环境。
2.3. 资源分配
要在 Red Hat OpenShift Container Platform 基础架构中调度 pod,您需要运行的组件资源。如果您没有分配充足的资源,pod 会保持 Pending 状态,因为它们无法调度。
运行 Service Telemetry Framework(STF)所需的资源量取决于您的环境以及要监控的节点和云数量。
其他资源
- 有关指标集合大小建议,请参阅服务 Telemetry Framework 性能和扩展。
- 有关 ElasticSearch 要求大小的详情,请参考 https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-managing-compute-resources.html。
2.4. Service Telemetry Framework 的网络注意事项
您只能在完全连接的网络环境中部署 Service Telemetry Framework (STF)。您无法在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中部署 STF。
第 3 章 安装 Service Telemetry Framework 的核心组件
您可以使用 Operator 来加载服务 Telemetry Framework(STF)组件和对象。Operator 管理以下每个 STF 内核和社区组件:
- AMQ Interconnect
- 智能网关
- Prometheus 和 AlertManager
- Elasticsearch
- Grafana
先决条件
- 一个包括了 4.10 到 4.10 的 Red Hat OpenShift Container Platform 版本正在运行。
- 您已准备好了 Red Hat OpenShift Container Platform 环境,并确保有足够的资源在 Red Hat OpenShift Container Platform 环境上运行 STF 组件。如需更多信息,请参阅 服务 Telemetry Framework 性能和扩展。
- 您的环境已完全连接。STF 无法在 Red Hat OpenShift Container Platform 断开连接环境或网络代理环境中工作。
STF 通过 4.10 与 Red Hat OpenShift Container Platform 版本 4.10 兼容。
其他资源
- 如需有关 Operator 的更多信息,请参阅了解 Operator 指南。
- 有关如何从 Red Hat OpenShift Container Platform 环境中删除 STF 的更多信息,请参阅 第 7 章 从 Red Hat OpenShift Container Platform 环境中删除 Service Telemetry Framework。
3.1. 在 Red Hat OpenShift Container Platform 环境中部署 Service Telemetry Framework
部署 Service Telemetry Framework(STF)以收集、存储和监控事件:
流程
创建一个命名空间,使其包含 STF 组件,如
service-telemetry:$ oc new-project service-telemetry
在命名空间中创建一个 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。
启用 OperatorHub.io 社区目录源来安装数据存储和视觉化 Operator:
警告红帽支持核心 Operator 和工作负载,包括 AMQ Interconnect、AMQ Certificate Manager、Service Telemetry Operator 和 Smart Gateway Operator。红帽不支持社区 Operator 或工作负载组件,包括 ElasticSearch、Prometheus、Alertmanager、Grafana 以及它们的 Operator。
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-operators namespace: openshift-marketplace spec: sourceType: grpc image: quay.io/operatorhubio/catalog:latest displayName: OperatorHub.io Operators publisher: OperatorHub.io EOF
使用 redhat-operators CatalogSource 订阅到 AMQ Certificate Manager Operator:
注意AMQ 证书管理器部署到
openshift-operators命名空间,然后供集群中的所有命名空间使用。因此,在有大量命名空间的集群上,Operator 在service-telemetry命名空间中可用可能需要几分钟。当 AMQ Certificate Manager Operator 与其他命名空间范围 Operator 一起使用时,它与 Operator Lifecycle Manager 的依赖项管理不兼容。$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq7-cert-manager-operator namespace: openshift-operators spec: channel: 1.x installPlanApproval: Automatic name: amq7-cert-manager-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
验证您的 ClusterServiceVersion。确保 amq7-cert-manager.v1.0.3 显示为
Succeeded:$ oc get csv --namespace openshift-operators --selector operators.coreos.com/amq7-cert-manager-operator.openshift-operators NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded
使用 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
验证您的 ClusterServiceVersion。确保 amq7-interconnect-operator.v1.10.4 显示
Succeeded中的一个阶段:$ oc get csv --selector=operators.coreos.com/amq7-interconnect-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE amq7-interconnect-operator.v1.10.4 Red Hat Integration - AMQ Interconnect 1.10.4 amq7-interconnect-operator.v1.10.3 Succeeded
如果您计划将指标存储在 Prometheus 中,您必须启用 Prometheus Operator。要启用 Prometheus Operator,请在 Red Hat OpenShift Container Platform 环境中创建以下清单:
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: prometheus namespace: service-telemetry spec: channel: beta installPlanApproval: Automatic name: prometheus source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
验证 Prometheus
Succeeded的 ClusterServiceVersion :$ oc get csv --selector=operators.coreos.com/prometheus.service-telemetry NAME DISPLAY VERSION REPLACES PHASE prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded
如果您计划将事件存储在 ElasticSearch 中,您必须在 Kubernetes(ECK)Operator 上启用 Elastic Cloud。要启用 ECK Operator,请在 Red Hat OpenShift Container Platform 环境中创建以下清单:
$ 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
验证 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.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded
创建 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.4 installPlanApproval: Automatic name: service-telemetry-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
验证 Service Telemetry Operator 和依赖 Operator:
$ oc get csv --namespace service-telemetry NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded amq7-interconnect-operator.v1.10.4 Red Hat Integration - AMQ Interconnect 1.10.4 amq7-interconnect-operator.v1.10.3 Succeeded elasticsearch-eck-operator-certified.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded service-telemetry-operator.v1.4.1641489191 Service Telemetry Operator 1.4.1641489191 Succeeded smart-gateway-operator.v4.0.1641489202 Smart Gateway Operator 4.0.1641489202 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 对象的主要参数”。
流程
要创建一个会生成使用默认值的 STF 部署的
ServiceTelemetry对象,创建一个带有空spec参数的ServiceTelemetry对象:$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: {} EOF要覆盖默认值,请定义您要覆盖的参数。在本例中,通过将
enabled设置为true来启用 ElasticSearch:$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: events: elasticsearch: enabled: true EOF使用空
spec参数创建ServiceTelemetry对象会导致使用以下默认设置的 STF 部署:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: alerting: alertmanager: receivers: snmpTraps: enabled: false target: 192.168.24.254 storage: persistent: pvcStorageRequest: 20G strategy: persistent enabled: true backends: events: elasticsearch: enabled: false storage: persistent: pvcStorageRequest: 20Gi strategy: persistent version: 7.16.1 logs: loki: enabled: false flavor: 1x.extra-small replicationFactor: 1 storage: objectStorageSecret: test storageClass: standard metrics: prometheus: enabled: true scrapeInterval: 10s storage: persistent: pvcStorageRequest: 20G retention: 24h strategy: persistent clouds: - events: collectors: - collectorType: collectd debugEnabled: false subscriptionAddress: collectd/cloud1-notify - collectorType: ceilometer debugEnabled: false subscriptionAddress: anycast/ceilometer/cloud1-event.sample metrics: collectors: - collectorType: collectd debugEnabled: false subscriptionAddress: collectd/cloud1-telemetry - collectorType: ceilometer debugEnabled: false subscriptionAddress: anycast/ceilometer/cloud1-metering.sample - collectorType: sensubility debugEnabled: false subscriptionAddress: sensubility/cloud1-telemetry name: cloud1 graphing: enabled: false grafana: adminPassword: secret adminUser: root baseImage: docker.io/grafana/grafana:latest disableSignoutMenu: false ingressEnabled: false highAvailability: enabled: false observabilityStrategy: use_community transports: qdr: enabled: true web: enabled: false要覆盖这些默认值,请在
spec参数中添加配置。查看 Service Telemetry Operator 中的 STF 部署日志:
$ oc logs --selector name=service-telemetry-operator ... --------------------------- Ansible Task Status Event StdOut ----------------- PLAY RECAP ********************************************************************* localhost : ok=57 changed=0 unreachable=0 failed=0 skipped=20 rescued=0 ignored=0
验证
要确定所有工作负载是否正确运行,请查看 pod 和每个 pod 的状态。
注意如果将
backends.events.elasticsearch.enabled参数设置为true,则通知智能网关会在 ElasticSearch 启动前报告Error和CrashLoopBackOff错误消息。$ oc get pods NAME READY STATUS RESTARTS AGE alertmanager-default-0 2/2 Running 0 17m default-cloud1-ceil-meter-smartgateway-6484b98b68-vd48z 2/2 Running 0 17m default-cloud1-coll-meter-smartgateway-799f687658-4gxpn 2/2 Running 0 17m default-cloud1-sens-meter-smartgateway-c7f4f7fc8-c57b4 2/2 Running 0 17m default-interconnect-54658f5d4-pzrpt 1/1 Running 0 17m elastic-operator-66b7bc49c4-sxkc2 1/1 Running 0 52m interconnect-operator-69df6b9cb6-7hhp9 1/1 Running 0 50m prometheus-default-0 2/2 Running 1 17m prometheus-operator-6458b74d86-wbdqp 1/1 Running 0 51m service-telemetry-operator-864646787c-hd9pm 1/1 Running 0 51m smart-gateway-operator-79778cf548-mz5z7 1/1 Running 0 51m
3.2.1. ServiceTelemetry 对象的主要参数
ServiceTelemetry 对象包含以下主要配置参数:
-
警报 -
backends -
云 -
图形 -
高可用性 -
传输
您可以配置每个配置参数,以在 STF 部署中提供不同的功能。
对 servicetelemetry.infra.watch/v1alpha1 的支持已从 STF 1.3 中删除。
backends 参数
使用 backends 参数控制哪些存储后端可用于存储指标和事件,并控制 云 参数定义的智能网关启用。更多信息请参阅 “clouds 参数”一节。
目前,您可以使用 Prometheus 作为指标存储后端,ElasticSearch 作为事件存储后端。
为指标启用 Prometheus 作为存储后端
要启用 Prometheus 作为指标的存储后端,您必须配置 ServiceTelemetry 对象。
流程
配置
ServiceTelemetry对象:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true
为 Prometheus 配置持久性存储
使用 backends.metrics.prometheus.storage.persistent 中定义的附加参数,为 Prometheus 配置持久性存储选项,如存储类和卷大小。
使用 storageClass 定义后端存储类。如果没有设置此参数,Service Telemetry Operator 会使用 Red Hat OpenShift Container Platform 集群的默认存储类。
使用 pvcStorageRequest 参数定义最低要求的卷大小,以满足存储请求。如果以静态方式定义卷,则可以使用大于请求的卷大小。默认情况下,Service Telemetry Operator 请求卷大小为 20G (20 千兆字节)。
流程
列出可用的存储类:
$ 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
配置
ServiceTelemetry对象: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 对象。
流程
配置
ServiceTelemetry对象:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: events: elasticsearch: enabled: true
为 ElasticSearch 配置持久性存储
使用 backends.events.elasticsearch.storage.persistent 中定义的附加参数来为 ElasticSearch 配置持久性存储选项,如存储类和卷大小。
使用 storageClass 定义后端存储类。如果没有设置此参数,Service Telemetry Operator 会使用 Red Hat OpenShift Container Platform 集群的默认存储类。
使用 pvcStorageRequest 参数定义最低要求的卷大小,以满足存储请求。如果以静态方式定义卷,则可以使用大于请求的卷大小。默认情况下,Service Telemetry Operator 请求卷大小为 20Gi (20 千兆字节)。
流程
列出可用的存储类:
$ 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
配置
ServiceTelemetry对象: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 参数
使用 cloud 参数来定义智能网关对象部署,从而为多个受监控的云环境提供接口,以连接至 STF 实例。如果支持后端可用,则会为默认云配置创建指标和事件智能网关。默认情况下,Service Telemetry Operator 为 cloud1 创建智能网关。
您可以创建一个云对象列表来控制为定义的云创建了哪些智能清单。每个云由数据类型和收集器组成。数据类型是 指标 或 事件。每种数据类型由收集器、消息总线订阅地址和参数组成,以启用调试。可用的指标收集器有 collectd、ceilometer 和 sensubility。事件的可用收集器有 collectd 和 ceilometer。确保每个收集器的订阅地址对于每一个云、数据类型和收集器组合都是唯一的。
默认的 cloud1 配置由以下 ServiceTelemetry 对象代表,它为特定的云实例提供指标和事件订阅和数据存储:
apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
name: stf-default
namespace: service-telemetry
spec:
clouds:
- name: cloud1
metrics:
collectors:
- collectorType: collectd
subscriptionAddress: collectd/telemetry
- collectorType: ceilometer
subscriptionAddress: anycast/ceilometer/metering.sample
- collectorType: sensubility
subscriptionAddress: sensubility/telemetry
debugEnabled: false
events:
collectors:
- collectorType: collectd
subscriptionAddress: collectd/notify
- collectorType: ceilometer
subscriptionAddress: anycast/ceilometer/event.sample
云 参数的每个项目代表云实例。云实例包含三个顶级参数: 名称、指标 和事件。指标 和事件 参数代表该数据类型的存储对应的后端。collectors 参数指定由两个所需参数组成的对象列表,collectorType 和 subscriptionAddress 组成,它们代表智能网关的实例。collectorType 参数指定 collectd、Ceilometer 或 Sensubility 收集的数据。subscriptionAddress 参数提供 Smart Gateway 订阅的 AMQ Interconnect 地址。
您可以使用 collectors 参数中的可选布尔值参数 debugEnabled 在运行的 Smart Gateway pod 中启用额外的控制台调试。
其他资源
- 有关删除默认智能网关的详情,请参考 第 4.4.3 节 “删除默认智能网关”。
- 有关如何配置多个云的详情,请参考 第 4.4 节 “配置多个云”。
警报参数
使用 警报 参数控制 Alertmanager 实例的创建以及存储后端的配置。默认情况下启用 警报。更多信息请参阅 第 5.3 节 “Service Telemetry Framework 中的警报”。
graphing 参数
使用 graphing 参数来控制 Grafana 实例的创建。默认情况下禁用 图表。更多信息请参阅 第 5.1 节 “Service Telemetry Framework 中的仪表板”。
highAvailability 参数
使用 highAvailability 参数控制 STF 组件的多个副本的实例化,以减少失败或重新调度的组件的恢复时间。默认情况下禁用 高可用性功能。更多信息请参阅 第 5.5 节 “高可用性”。
transports 参数
使用 transports 参数来控制为 STF 部署进行消息总线的启用。目前唯一支持的传输是 AMQ Interconnect。默认情况下启用 qdr 传输。
3.3. 访问 STF 组件的用户界面
在 Red Hat OpenShift Container Platform 中,应用程序通过路由公开给外部网络。有关路由的更多信息,请参阅配置集群流量。
在 Service Telemetry Framework(STF)中,HTTPS 路由针对具有基于 Web 的接口的每个服务公开。这些路由受 Red Hat OpenShift Container Platform RBAC 的保护,以及具有 ClusterRoleBinding 的任何用户,以便他们能够查看 Red Hat OpenShift Container Platform 命名空间可以登录。有关 RBAC 的更多信息,请参阅使用 RBAC 定义和应用权限。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
列出
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
- 在 Web 浏览器中,导航到 https://<route_address > 以访问相应服务的 Web 界面。
3.4. 配置备用可观察性策略
要配置 STF 来跳过存储、视觉化和警报后端的部署,请在 ServiceTelemetry spec 中添加 observabilityStrategy: none。在这个模式中,只会部署 AMQ Interconnect 路由器和指标智能网关,您必须配置外部 Prometheus 兼容系统,以便从 STF 智能网关收集指标。
目前,只有将 observabilityStrategy 设置为 none 时支持指标。事件智能网关没有部署。
流程
在
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
要验证所有工作负载是否正确运行,请查看 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.4.2 节 “部署智能网关”
第 4 章 为 Service Telemetry 框架配置 Red Hat OpenStack Platform
要收集指标、事件或两者,并将它们发送到 Service Telemetry Framework(STF)存储域,您必须配置 Red Hat OpenStack Platform(RHOSP)overcloud 以启用数据收集和传输。
STF 可支持单一和多个云。为单个云安装设置的 RHOSP 和 STF 中的默认配置。
- 有关使用默认配置的单个 RHOSP overcloud 部署,请参考 第 4.1 节 “部署 Red Hat OpenStack Platform overcloud for Service Telemetry Framework”。
- 要为多个云规划 RHOSP 安装和配置 STF,请参阅 第 4.4 节 “配置多个云”。
作为 RHOSP overcloud 部署的一部分,您可能需要在环境中配置附加功能:
- 要在使用路由的 L3 域(如分布式计算节点(DCN)或 spine-leaf)的 RHOSP 云节点上部署数据收集和传输到 STF,请参阅 第 4.3 节 “部署到非标准网络拓扑”。
- 要将指标发送到 Gnocchi 和 STF,请参阅 第 4.2 节 “将指标发送到 Gnocchi 和服务遥测框架”。
4.1. 部署 Red Hat OpenStack Platform overcloud for Service Telemetry Framework
作为 Red Hat OpenStack Platform(RHOSP)overcloud 部署的一部分,您必须配置数据收集器和到 Service Telemetry Framework(STF)的数据传输。
流程
其他资源
- 要通过 AMQ Interconnect 收集数据,请查看 amqp1 插件。
4.1.1. 从用于 overcloud 配置的 Service Telemetry Framework 获取 CA 证书
要将 Red Hat OpenStack Platform overcloud 连接到服务 Telemetry Framework (STF),可检索在 Service Telemetry Framework 中运行的 AMQ Interconnect 的 CA 证书,并使用 Red Hat OpenStack Platform 配置中的证书。
流程
在 Service Telemetry Framework 中查看可用证书列表:
$ oc get secrets
检索并记录
default-interconnect-selfsignedSecret 的内容:$ 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 路由地址。
流程
- 登录您的 Red Hat OpenShift Container Platform 环境。
在
service-telemetry项目中,检索 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 创建基本配置
要配置基础参数,以便为服务 Telemetry Framework(STF)提供兼容数据收集和传输,您必须创建一个定义默认数据收集值的文件。
流程
-
以
stack用户身份登录 Red Hat OpenStack Platform(RHOSP)undercloud。 在
/home/stack目录中创建一个名为enable-stf.yaml的配置文件。重要将
EventPipelinePublishers和PipelinePublishers设置为空列表会导致没有向 RHOSP 遥测组件传递的事件或指标数据,如 Gnocchi 或 Panko。如果需要将数据发送到额外的管道,Ceilometer 轮询间隔 30 秒(如ExtraConfig)可能会耗尽 RHOSP 遥测组件,并且您必须将间隔增加到较大的值,如300。将值增加到更长的轮询间隔,会导致在 STF 中遥测分辨率较低。要使用 STF 和 Gnocchi 启用遥测集合,请参阅 第 4.2 节 “将指标发送到 Gnocchi 和服务遥测框架”
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.*
- 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.4 节 “配置多个云”。
先决条件
- 从由 STF 部署的 AMQ Interconnect 检索 CA 证书。更多信息请参阅 第 4.1.1 节 “从用于 overcloud 配置的 Service Telemetry Framework 获取 CA 证书”。
- 检索 AMQ 互联路由地址。更多信息请参阅 第 4.1.2 节 “检索 AMQ Interconnect 路由地址”。
流程
-
以
stack用户身份登录到 RHOSP undercloud。 -
在
/home/stack目录中创建一个名为stf-connectors.yaml的配置文件。 在
stf-connectors.yaml文件中,配置MetricsQdrConnectors地址,以将 overcloud 上的 AMQ 互联连接到 STF 部署。您可以在此文件中为 Sensubility、Ceiloity、Cemeter 和 collectd 配置主题地址,以匹配 STF 中的默认值。有关自定义主题和云配置的详情,请参考 第 4.4 节 “配置多个云”。-
将
host参数替换为您在 第 4.1.2 节 “检索 AMQ Interconnect 路由地址” 中检索的HOST/PORT值。 将
caCertFileContent参数替换为 第 4.1.1 节 “从用于 overcloud 配置的 Service Telemetry Framework 获取 CA 证书” 中检索的内容。stf-connectors.yaml
resource_registry: OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml 1 parameter_defaults: MetricsQdrConnectors: - host: stf-default-interconnect-5671-service-telemetry.apps.infra.watch 2 port: 443 role: edge verifyHostname: false sslProfile: sslProfile MetricsQdrSSLProfiles: - name: sslProfile caCertFileContent: | ----BEGIN CERTIFICATE---- <snip> ----END CERTIFICATE---- CeilometerQdrEventsConfig: driver: amqp topic: cloud1-event 3 CeilometerQdrMetricsConfig: driver: amqp topic: cloud1-metering 4 CollectdAmqpInstances: cloud1-notify: 5 notify: true format: JSON presettle: false cloud1-telemetry: 6 format: JSON presettle: false CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry 7
- 1
- 直接载入 collectd 服务,因为您不包括用于多个云部署的
collectd-write-qdr.yaml环境文件。 - 2
- 3
- 定义 Ceilometer 事件的主题。这个值的格式为
anycast/ceilometer/cloud1-event.sample。 - 4
- 定义 Ceilometer 指标的主题。这个值的格式是'anycast/ceilometer/cloud1-metering.sample'。
- 5
- 定义 collectd 事件的主题。这个值的格式为
collectd/cloud1-notify。 - 6
- 定义 collectd 指标的主题。这个值的格式为
collectd/cloud1-telemetry。 - 7
- 定义 collectd-sensubility 事件的主题。该值是确切的字符串
sensubility/cloud1-telemetry。
-
将
4.1.5. 部署 overcloud
使用所需的环境文件部署或更新 overcloud,以便收集数据并将其传送到 Service Telemetry Framework(STF)。
流程
-
以
stack用户身份登录 Red Hat OpenStack Platform(RHOSP)undercloud。 查找身份验证文件:
[stack@undercloud-0 ~]$ source stackrc (undercloud) [stack@undercloud-0 ~]$
在 RHOSP director 部署中添加以下文件来配置数据收集和 AMQ 互联:
-
ceilometer-write-qdr.yaml文件,以确保 Ceilometer 遥测和事件发送到 STF -
qdr-edge-only.yaml文件,以确保消息总线被启用并连接到 STF 消息总线路由器 -
enable-stf.yaml环境文件以确保正确配置了默认值 -
stf-connectors.yaml环境文件以定义与 STF 的连接
-
部署 RHOSP overcloud:
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml
4.1.6. 验证客户端安装
要验证来自 Service Telemetry Framework(STF)存储域的数据收集,请查询数据源以获取数据。要验证 Red Hat OpenStack Platform(RHOSP)部署中的单个节点,请使用 SSH 连接到控制台。
只有在 RHOSP 具有活跃工作负载时才可以使用一些遥测数据。
流程
- 登录 overcloud 节点,例如 controller-0。
确保
metrics_qdr容器正在该节点上运行:$ sudo podman container inspect --format '{{.State.Status}}' metrics_qdr running返回到运行 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 }返回到本地 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 互联的内部网络地址。
要确保传递消息,请列出链接,并在
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
要列出 RHOSP 节点到 STF 的地址,连接到 Red Hat OpenShift Container Platform 以检索 AMQ 互联 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
连接到 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
要查看网络传输的消息数量,请使用
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. 将指标发送到 Gnocchi 和服务遥测框架
若要同时向服务遥测框架(STF)和 Gnocchi 发送指标,您必须在部署中包含一个环境文件,以启用额外的发布程序。
如果需要将数据发送到额外的管道,Ceilometer 轮询间隔 30 秒(如 ExtraConfig )可能会耗尽 RHOSP 遥测组件,并且您必须将间隔增加到较大的值,如 300。将值增加到更长的轮询间隔,会导致在 STF 中遥测分辨率较低。
先决条件
- 您已创建了文件,其中包含 overcloud 到 STF 的 AMQ 互联的连接配置。更多信息请参阅 第 4.1.4 节 “为 overcloud 配置 STF 连接”。
流程
在
/home/stack目录中创建一个名为gnocchi-connectors.yaml的环境文件。resource_registry: OS::TripleO::Services::GnocchiApi: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-api-container-puppet.yaml OS::TripleO::Services::GnocchiMetricd: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-metricd-container-puppet.yaml OS::TripleO::Services::GnocchiStatsd: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-statsd-container-puppet.yaml OS::TripleO::Services::AodhApi: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-api-container-puppet.yaml OS::TripleO::Services::AodhEvaluator: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-evaluator-container-puppet.yaml OS::TripleO::Services::AodhNotifier: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-notifier-container-puppet.yaml OS::TripleO::Services::AodhListener: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-listener-container-puppet.yaml parameter_defaults: CeilometerEnableGnocchi: true CeilometerEnablePanko: false GnocchiArchivePolicy: 'high' GnocchiBackend: 'rbd' GnocchiRbdPoolName: 'metrics' EventPipelinePublishers: ['gnocchi://?filter_project=service'] PipelinePublishers: ['gnocchi://?filter_project=service']将环境文件
gnocchi-connectors.yaml添加到部署命令中。将 <other_arguments > 替换为适用于您的环境的文件。$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/collectd-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml \ --environment-file /home/stack/gnocchi-connectors.yaml
为确保配置成功,请验证 Controller 节点上的
/var/lib/config-data/puppet-generated/ceilometer/etc/ceilometer/pipeline.yaml的内容。确保 文件的publishers部分包含notifier和Gnocchi的信息。sources: - name: meter_source meters: - "*" sinks: - meter_sink sinks: - name: meter_sink publishers: - gnocchi://?filter_project=service - notifier://172.17.1.35:5666/?driver=amqp&topic=metering
4.3. 部署到非标准网络拓扑
如果您的节点位于与默认 InternalApi 网络中的独立网络中,您必须进行配置调整,以便 AMQ Interconnect 可以将数据传送到 Service Telemetry Framework(STF)服务器实例。这种情境通常在 spine-leaf 或 DCN 拓扑中。有关 DCN 配置的更多信息,请参阅 Spine Leaf Networking 指南。
如果您将 STF 与 Red Hat OpenStack Platform (RHOSP) 17.0 一起使用,并计划监控您的 Ceph、块或 Object Storage 节点,您必须进行配置更改,这与您对 spine-leaf 和 DCN 网络配置类似的配置更改。要监控 Ceph 节点,请使用 CephStorageExtraConfig 参数定义要加载到 AMQ 互联和 collectd 配置文件的网络接口。
CephStorageExtraConfig:
tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('storage')}"
tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('storage')}"
tripleo::profile::base::ceilometer::agent::notification::notifier_host_addr: "%{hiera('storage')}"
同样,如果您的环境使用 Block 和 Object Storage 角色,您必须指定 BlockStorageExtraConfig 和 ObjectStorageExtraConfig 参数。
要部署 spine-leaf 拓扑,您必须创建角色和网络,然后将这些网络分配到可用的角色。当您为 RHOSP 部署配置 STF 数据收集和传输时,角色的默认网络为 InternalApi。对于 Ceph,块和对象存储角色是 Storage。因为 spine-leaf 配置可能会导致不同的网络被分配给不同的 Leaf 分组,因此这些名称通常是唯一的,所以 RHOSP 环境文件的 parameter_defaults 部分中需要额外的配置。
流程
- 记录下每个 Leaf 角色可用的网络。有关网络名称定义示例,请参阅 Spine Leaf Networking 指南中的 创建网络数据文件。有关创建 Leaf 分组(角色)并将网络分配给这些分组的更多信息,请参阅 Spine Leaf Networking 指南中的 角色数据文件。
将以下配置示例添加到每个 leaf 角色的
ExtraConfig部分。在本例中,internal_api_subnet是网络定义的name_lower参数中定义的值(带有_subnet附加到 Leaf 0 的名称)中,是计算Leaf0leaf role 所连接的网络。在本例中,网络标识 0 与 leaf 0 的 Compute 角色对应,它代表与默认内部 API 网络名称不同的值。对于
ComputeLeaf0leaf 角色,请指定额外的配置来执行层次结构查找,以确定特定网络的网络接口要分配给 collectd AMQP 主机参数。为 AMQ Interconnect 侦听器地址参数执行相同的配置。ComputeLeaf0ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('internal_api_subnet')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('internal_api_subnet')}"其他leaf 角色通常将
_subnet替换为_leafN。n代表 leaf 的唯一标识符。ComputeLeaf1ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('internal_api_leaf1')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('internal_api_leaf1')}"此示例配置位于 CephStorage leaf 角色中:
CephStorageLeaf0ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('storage_subnet')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('storage_subnet')}"
4.4. 配置多个云
您可以配置多个 Red Hat OpenStack Platform(RHOSP)云以作为单个 Service Telemetry Framework(STF)实例为目标。当您配置多个云时,每个云都必须在自己的唯一消息总线主题上发送指标和事件。在 STF 部署中,智能网关实例侦听这些主题,从而将信息保存到常见数据存储中。使用每个智能清单创建的元数据过滤在数据存储域中的智能网关存储的数据。
图 4.1. 两个 RHOSP 云连接到 STF

要为多个云场景配置 RHOSP overcloud,请完成以下任务:
- 规划您要用于每个云的 AMQP 地址前缀。更多信息请参阅 第 4.4.1 节 “规划 AMQP 地址前缀”。
- 部署各个云的指标和事件消费者智能网关,以侦听对应的地址前缀。更多信息请参阅 第 4.4.2 节 “部署智能网关”。
- 使用唯一域名配置每个云。更多信息请参阅 第 4.4.4 节 “设置唯一的云域”。
- 为 STF 创建基本配置。更多信息请参阅 第 4.1.3 节 “为 STF 创建基本配置”。
- 配置每个云,以针对正确的地址将其指标和事件发送到 STF。更多信息请参阅 第 4.4.5 节 “为多个云创建 Red Hat OpenStack Platform 环境文件”。
4.4.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.4.2. 部署智能网关
您必须为每个云部署智能网关类型;一个用于 collectd 指标,一个用于 collectd 事件,一个用于 Ceilometer 指标,一个用于 Ceilometer 事件,一个用于 collectd-sensubity 指标。配置每个智能网关,以侦听您为相应云定义的 AMQP 地址。要定义智能网关,请在 ServiceTelemetry 清单中配置 cloud 参数。
首次部署 STF 时,会创建智能网关清单,为单个云定义初始智能网关。当您为多个云支持部署智能网关时,您可以为每个处理指标和事件数据的数据收集类型部署多个智能网关。在 cloud1 中使用以下订阅地址定义初始智能清单:
| collector( collector) | type | 默认订阅地址 |
| collectd | metrics | collectd/telemetry |
| collectd | 事件 | collectd/notify |
| collectd-sensubility | metrics | sensubility/telemetry |
| Ceilometer | metrics | anycast/ceilometer/metering.sample |
| Ceilometer | 事件 | anycast/ceilometer/event.sample |
先决条件
- 您已确定了云命名方案。有关确定您的命名方案的更多信息,请参阅 第 4.4.1 节 “规划 AMQP 地址前缀”。
-
您已创建了云对象列表。有关为
cloud参数创建内容的更多信息,请参阅 “clouds 参数”一节。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
编辑默认ServiceTelemetry 对象,并使用您的配置添加clouds参数:警告长云名称可能会超过 63 个字符的最大 pod 名称。确保
ServiceTelemetry名称的组合默认,cloud.name不超过 19 个字符。云名称不能包含任何特殊字符,如-。将云名称限制为字母数字(a-z、0-9)。主题地址没有字符限制,可以与
cloud.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: ...- 保存 ServiceTelemetry 对象。
验证每个智能清单都在运行。这可能需要几分钟,具体要看智能清单的数量:
$ 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.4.3. 删除默认智能网关
为多个云配置 Service Telemetry Framework(STF)后,如果不再使用,可以删除默认的智能网关。Service Telemetry Operator 可以删除创建的 SmartGateway 对象,但不再列在对象的 ServiceTelemetry 云 列表中。要启用删除由 cloud 参数定义的 SmartGateway 对象,您必须在 ServiceTelemetry 清单中将 cloudRemoveOn Misssing 参数设置为 true。
如果您不想部署任何智能网关,请使用云 :[] 参数定义一个空云 列表。
默认情况下禁用 cloudRemoveOnMissing 参数。如果启用 cloudRemoveOnMissing 参数,则删除所有当前命名空间中的手动创建的 SmartGateway 对象,而无需恢复。
流程
-
使用您希望 Service Telemetry Operator 管理的云对象列表定义
clouds参数。更多信息请参阅 “clouds 参数”一节。 编辑 ServiceTelemetry 对象并添加
cloudsRemoveOnMissing参数:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: ... spec: ... cloudsRemoveOnMissing: true clouds: ...- 保存修改。
验证 Operator 是否删除了 Smart Gateway。Operator 协调更改可能需要几分钟:
$ oc get smartgateways
4.4.4. 设置唯一的云域
为确保 AMQ 从 Red Hat OpenStack Platform(RHOSP)到 Service Telemetry Framework(STF)的 AMQ 间路由器连接是唯一的,且不要冲突,请配置 CloudDomain 参数。
流程
-
创建新的环境文件,如 hostname
.yaml。 在环境文件中设置
CloudDomain参数,如下例所示:hostnames.yaml
parameter_defaults: CloudDomain: newyork-west-04 CephStorageHostnameFormat: 'ceph-%index%' ObjectStorageHostnameFormat: 'swift-%index%' ComputeHostnameFormat: 'compute-%index%'- 添加新环境文件到部署中。
其他资源
- 第 4.4.5 节 “为多个云创建 Red Hat OpenStack Platform 环境文件”
- Overcloud 参数 指南中的核心 Overcloud 参数
4.4.5. 为多个云创建 Red Hat OpenStack Platform 环境文件
要根据原始云标记流量,您必须创建带有特定云实例名称的配置。创建 stf-connectors.yaml 文件并调整 CeilometerQdrEventsConfig、CeilometerQdrMetricsConfig 和 CollectdAmqpInstances 的值以匹配 AMQP 地址前缀方案。
如果启用了容器健康和 API 状态监控,还必须修改 CollectdSensubilityResultsChannel 参数。更多信息请参阅 第 5.9 节 “Red Hat OpenStack Platform API 状态和容器化服务健康状态”。
先决条件
- 您已从 STF 部署的 AMQ Interconnect 获取 CA 证书。更多信息请参阅 第 4.1.1 节 “从用于 overcloud 配置的 Service Telemetry Framework 获取 CA 证书”。
- 您已创建了云对象列表。有关为 clouds 参数创建内容的更多信息,请参阅 云配置参数。
- 您已检索 AMQ Interconnect 路由地址。更多信息请参阅 第 4.1.2 节 “检索 AMQ Interconnect 路由地址”。
- 您已为 STF 创建基本配置。更多信息请参阅 第 4.1.3 节 “为 STF 创建基本配置”。
- 您已创建了唯一的域名环境文件。更多信息请参阅 第 4.4.4 节 “设置唯一的云域”。
流程
-
以
stack用户身份登录 Red Hat OpenStack Platform undercloud。 -
在
/home/stack目录中创建一个名为stf-connectors.yaml的配置文件。 在
stf-connectors.yaml文件中,配置MetricsQdrConnectors地址,以连接到 overcloud 部署上的 AMQ Interconnect。配置CeilometerQdrEventsConfig、CeilometerMetricsConfig、CollectdAmqpInstances和CollectdSensubilityResultsChannel主题值以匹配用于此云部署的 AMQP 地址。将
caCertFileContent参数替换为 第 4.1.1 节 “从用于 overcloud 配置的 Service Telemetry Framework 获取 CA 证书” 中检索的内容。stf-connectors.yaml
resource_registry: OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml 1 parameter_defaults: MetricsQdrConnectors: - host: stf-default-interconnect-5671-service-telemetry.apps.infra.watch 2 port: 443 role: edge verifyHostname: false sslProfile: sslProfile MetricsQdrSSLProfiles: - name: sslProfile caCertFileContent: | ----BEGIN CERTIFICATE---- <snip> ----END CERTIFICATE---- CeilometerQdrEventsConfig: driver: amqp topic: cloud1-event 3 CeilometerQdrMetricsConfig: driver: amqp topic: cloud1-metering 4 CollectdAmqpInstances: cloud1-notify: 5 notify: true format: JSON presettle: false cloud1-telemetry: 6 format: JSON presettle: false CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry 7
- 1
- 直接载入 collectd 服务,因为您不包括用于多个云部署的
collectd-write-qdr.yaml环境文件。 - 2
- 3
- 定义 Ceilometer 事件的主题。这个值是任何cast
/ceilometer/cloud1-event.sample的地址格式。 - 4
- 定义 Ceilometer 指标的主题。这个值是任何cast
/ceilometer/cloud1-metering.sample的地址格式。 - 5
- 定义 collectd 事件的主题。这个值是
collectd/cloud1-notify的格式。 - 6
- 定义 collectd 指标的主题。这个值是
collectd/cloud1-telemetry的格式。 - 7
- 定义 collectd-sensubility 事件的主题。确保这个值是确切的字符串格式
sensubility/cloud1-telemetry
-
确保
stf-connectors.yaml文件中的命名规则与智能网关配置中的spec.bridge.amqpUrl字段一致。例如,将CeilometerQdrEventsConfig.topic字段配置为cloud1-event的值。 查找身份验证文件:
[stack@undercloud-0 ~]$ source stackrc (undercloud) [stack@undercloud-0 ~]$
在
openstack overcloud deployment命令中包含stf-connectors.yaml文件以及唯一域名环境文件hostname.yaml,以及其他与您环境相关的环境文件:警告如果您使用带有自定义
CollectdAmqpInstances参数的collectd-write-qdr.yaml文件,数据会发布到自定义和默认主题。在多个云环境中,stf-connectors.yaml文件中的resource_registry参数配置会加载 collectd 服务。(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/hostnames.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml
- 部署 Red Hat OpenStack Platform overcloud。
4.4.5.1. 基于 Ansible 的 Service Telemetry Framework 部署
该功能在此发行版本中作为技术预览提供,因此不享有红帽的全面支持。它只应用于测试,不应部署在生产环境中。有关技术预览功能的更多信息,请参阅覆盖范围详细信息。
从 wallaby/OSP17.0 开始,您可以预览使用 Ansible 而不是 Puppet 部署服务 Telemetry Framework(STF)组件。Ansible 的使用具有以下优点:
- 将配置整合到单一特定于服务的 THT 变量(MetricsQdrVars 和 CollectdVars)
- 能够将 QDR 模式从网格模式切换到 edge-only 和 back
- 部署堆栈中使用的技术更少,从而简化调试过程
要使用基于 Ansible 的部署,请将"ansible"一词替换在 stf-connectors.yaml 文件的 resource_registry 部分中:
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
其他资源
- 有关如何验证部署的详情,请参考 第 4.1.6 节 “验证客户端安装”。
4.4.6. 从多个云查询指标数据
Prometheus 中存储的数据根据智能网关从中提取的数据具有 服务 标签。您可以使用此标签从特定云查询数据。
要查询特定云的数据,请使用与 service 标签相关的匹配的 Prometheus promql 查询 ; 例如: collectd_uptime{service="default-cloud1-coll-meter"}。
第 5 章 使用 Service Telemetry Framework 的操作功能
您可以使用以下操作功能为服务 Telemetry Framework(STF)提供额外功能:
5.1. Service Telemetry Framework 中的仪表板
使用第三方应用程序 Grafana 视觉化了 collectd 和 Ceilometer 为每一主机节点收集的系统级指标。
有关配置 collectd 的详情,请参考 第 4.1 节 “部署 Red Hat OpenStack Platform overcloud for Service Telemetry Framework”。
您可以使用两个仪表板来监控云:
- 基础架构仪表板
- 使用基础架构仪表板查看单个节点的指标。从控制面板的左上角选择节点。
- Cloud view dashboard
使用云视图仪表板查看面板来监控服务资源使用情况、API 统计数据和云事件。您必须启用 API 健康监控和服务监控,才能为这个仪表板提供数据。在 STF 基本配置中默认启用 API 健康监控。更多信息请参阅 第 4.1.3 节 “为 STF 创建基本配置”。
- 有关 API 健康监控的更多信息,请参阅 第 5.9 节 “Red Hat OpenStack Platform API 状态和容器化服务健康状态”。
- 有关 RHOSP 服务监控的更多信息,请参阅 第 5.8 节 “Red Hat OpenStack Platform 服务的资源使用”。
5.1.1. 将 Grafana 配置为托管仪表板
Grafana 不包含在默认的 Service Telemetry Framework(STF)部署中,因此您必须从 OperatorHub.io 部署 Grafana Operator。当使用 Service Telemetry Operator 部署 Grafana 时,它会生成 Grafana 实例并为本地 STF 部署的默认数据源配置。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
部署 Grafana Operator:
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana-operator namespace: service-telemetry spec: channel: alpha installPlanApproval: Automatic name: grafana-operator source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
验证 Operator 是否已成功启动。在命令输出中,如果
PHASE列的值为Succeeded,Operator 会成功启动:$ oc get csv --selector operators.coreos.com/grafana-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE grafana-operator.v3.10.3 Grafana Operator 3.10.3 grafana-operator.v3.10.2 Succeeded
要启动 Grafana 实例,请创建或修改
ServiceTelemetry对象。将graphing.enabled和graphing.grafana.ingressEnabled设置为true:$ oc edit stf default apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... graphing: enabled: true grafana: ingressEnabled: true验证 Grafana 实例是否已部署:
$ oc get pod -l app=grafana NAME READY STATUS RESTARTS AGE grafana-deployment-7fc7848b56-sbkhv 1/1 Running 0 1m
验证 Grafana 数据源是否已正确安装:
$ oc get grafanadatasources NAME AGE default-datasources 20h
验证 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 镜像。
流程
请确定您具有正确的 Grafana 版本:
$ oc get pod -l "app=grafana" -ojsonpath='{.items[0].spec.containers[0].image}' docker.io/grafana/grafana:7.3.10如果运行的镜像早于 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"}}}}'验证新 Grafana pod 是否存在,并且
STATUS的值为Running:$ oc get pod -l "app=grafana" NAME READY STATUS RESTARTS AGE grafana-deployment-fb9799b58-j2hj2 1/1 Running 0 10s
验证新实例是否正在运行更新的镜像:
$ 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 的示例仪表板。
流程
导入基础架构仪表板:
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-dashboard.yaml grafanadashboard.integreatly.org/rhos-dashboard-1.3 created
导入云仪表板:
警告对于云仪表板中的一些面板,您必须在
stf-connectors.yaml文件中将 collectdvirt插件参数hostname_format设置为name uuid hostname。如果您没有配置此参数,受影响的仪表板会保持为空。有关virt插件的更多信息,请参阅 collectd 插件。$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloud-dashboard.yaml grafanadashboard.integreatly.org/rhos-cloud-dashboard-1.3 created
导入云事件仪表板:
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloudevents-dashboard.yaml grafanadashboard.integreatly.org/rhos-cloudevents-dashboard created
导入虚拟机仪表板:
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/virtual-machine-view.yaml grafanadashboard.integreatly.org/virtual-machine-view-1.3 configured
导入 memcached 仪表板:
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/memcached-dashboard.yaml grafanadashboard.integreatly.org/memcached-dashboard-1.3 created
验证仪表板是否可用:
$ oc get grafanadashboards NAME AGE memcached-dashboard-1.3 115s rhos-cloud-dashboard-1.3 2m12s rhos-cloudevents-dashboard 2m6s rhos-dashboard-1.3 2m17s virtual-machine-view-1.3 2m
检索 Grafana 路由地址:
$ oc get route grafana-route -ojsonpath='{.spec.host}' grafana-route-service-telemetry.apps.infra.watch- 在 Web 浏览器中,进入到 https://<grafana_route_address>。使用您在上一步中获得的值替换 <grafana_route_address>。
- 要查看仪表板,请点 Dashboards 和 Manage。
5.1.4. 检索和设置 Grafana 登录凭证
Service Telemetry Framework(STF)在启用了 Grafana 时设置默认登录凭证。您可以覆盖 ServiceTelemetry 对象中的凭证。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
从 STF 对象检索默认用户名和密码:
$ oc get stf default -o jsonpath="{.spec.graphing.grafana['adminUser','adminPassword']}"-
要通过 ServiceTelemetry 对象修改 Grafana 管理员用户名和密码的默认值,请使用
graphing.grafana.adminUser和graphing.grafana.adminPassword参数。
5.2. Service Telemetry Framework 中的指标保留时间
存储在 Service Telemetry Framework(STF)中的指标的默认保留时间为 24 小时,为警报用途开发提供足够的数据。
对于长期存储,请使用专为长期数据保留而设计的系统,例如 Thanos。
其他资源
- 要调整 STF 的额外指标保留时间,请参阅 第 5.2.1 节 “编辑 Service Telemetry Framework 中的指标保留时间”。
- 有关 Prometheus 数据存储和估算存储空间的建议,请参考 https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects
- 有关 Thanos 的更多信息,请参阅 https://thanos.io/
5.2.1. 编辑 Service Telemetry Framework 中的指标保留时间
您可以调整 Service Telemetry Framework(STF)以了解额外的指标保留时间。
流程
- 登录 Red Hat OpenShift Container Platform。
进入 service-telemetry 命名空间:
$ oc project service-telemetry
编辑 ServiceTelemetry 对象:
$ oc edit stf default
将
retention: 7d添加到 backends.metrics.prometheus.storage 的 storage 部分,将保留周期增加到 7 天:注意如果您设置了较长的保留周期,从大量填充的 Prometheus 系统中检索数据可能会导致查询返回结果较慢。
apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: stf-default namespace: service-telemetry spec: ... backends: metrics: prometheus: enabled: true storage: strategy: persistent retention: 7d ...- 保存您的更改并关闭对象。
其他资源
- 有关指标保留时间的详情,请参考 第 5.2 节 “Service Telemetry Framework 中的指标保留时间”。
5.3. Service Telemetry Framework 中的警报
您可以在 Alertmanager 中的 Prometheus 和警报路由中创建警报规则。Prometheus 服务器中的警报规则将警报发送到 Alertmanager,后者管理警报。Alertmanager 可以静默、禁止或聚合警报,并使用电子邮件、实时通知系统或聊天平台发送通知。
要创建警报,请完成以下任务:
- 在 Prometheus 中创建警报规则。更多信息请参阅 第 5.3.1 节 “在 Prometheus 中创建警报规则”。
在 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,它会触发警报。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
创建包含警报规则的
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 1 EOF- 1
- 要更改规则,请编辑
expr参数的值。
要验证 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 对象。
流程
使用
oc edit命令:$ oc edit prometheusrules prometheus-alarm-rules
-
编辑
PrometheusRules清单。 - 保存并关闭清单。
其他资源
- 有关如何配置警报规则的更多信息,请参阅 https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/。
- 有关 PrometheusRules 对象的更多信息,请参阅 https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/alerting.md
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 参数传递给 Service Telemetry Operator,这会导致由 Prometheus Operator 管理的 secret。
如果您的 alertmanagerConfigManifest 包含自定义模板,以构造所发送警报的标题和文本,请使用 base64 编码的配置部署 alertmanagerConfigManifest 的内容。更多信息请参阅 第 5.3.4 节 “在 Alertmanager 中使用模板创建警报路由”。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
编辑 STF 部署的
ServiceTelemetry对象:$ oc edit stf default
添加新参数
alertmanagerConfigManifest和Secret对象内容,以定义 Alertmanager 的alertmanager.yaml配置:注意此步骤加载 Service Telemetry Operator 所管理的默认模板。要验证更改是否正确填充,请更改值,返回
alertmanager-defaultsecret,并验证新值是否已加载到内存中。例如,将参数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'验证配置是否已应用到 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'针对
alertmanager-proxy服务运行curl命令,以检索 status 和configYAML内容,并验证提供的配置是否与 Alertmanager 中的配置匹配:$ oc run curl -it --serviceaccount=prometheus-k8s --restart='Never' --image=radial/busyboxplus:curl -- sh -c "curl -k -H \"Content-Type: application/json\" -H \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status" {"status":"success","data":{"configYAML":"...",...}}-
验证
configYAML字段是否包含您预期的更改。 要清理环境,请删除
curlpod:$ oc delete pod curl pod "curl" deleted
其他资源
- 如需有关 Red Hat OpenShift Container Platform secret 和 Prometheus operator 的更多信息,请参阅 Prometheus 用户有关警报的指南。
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 的内容。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
编辑 STF 部署的
ServiceTelemetry对象:$ oc edit stf default
要使用 STF 部署自定义 Alertmanager 路由,您必须将
alertmanagerConfigManifest参数传递给 Service Telemetry Operator,这会导致由 Prometheus Operator 管理的 secret:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true alertmanagerConfigManifest: | apiVersion: v1 kind: Secret metadata: name: 'alertmanager-default' namespace: 'service-telemetry' type: Opaque data: alertmanager.yaml: Z2xvYmFsOgogIHJlc29sdmVfdGltZW91dDogMTBtCiAgc2xhY2tfYXBpX3VybDogPHNsYWNrX2FwaV91cmw+CnJlY2VpdmVyczoKICAtIG5hbWU6IHNsYWNrCiAgICBzbGFja19jb25maWdzOgogICAgLSBjaGFubmVsOiAjc3RmLWFsZXJ0cwogICAgICB0aXRsZTogfC0KICAgICAgICAuLi4KICAgICAgdGV4dDogPi0KICAgICAgICAuLi4Kcm91dGU6CiAgZ3JvdXBfYnk6IFsnam9iJ10KICBncm91cF93YWl0OiAzMHMKICBncm91cF9pbnRlcnZhbDogNW0KICByZXBlYXRfaW50ZXJ2YWw6IDEyaAogIHJlY2VpdmVyOiAnc2xhY2snCg==验证配置是否已应用到 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'针对
alertmanager-proxy服务运行curl命令,以检索 status 和configYAML内容,并验证提供的配置是否与 Alertmanager 中的配置匹配:$ oc run curl -it --serviceaccount=prometheus-k8s --restart='Never' --image=radial/busyboxplus:curl -- sh -c "curl -k -H \"Content-Type: application/json\" -H \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status" {"status":"success","data":{"configYAML":"...",...}}-
验证
configYAML字段是否包含您预期的更改。 要清理环境,请删除
curlpod:$ oc delete pod curl pod "curl" deleted
其他资源
- 如需有关 Red Hat OpenShift Container Platform secret 和 Prometheus operator 的更多信息,请参阅 Prometheus 用户有关警报的指南。
5.4. 配置 SNMP 陷阱
您可以将 Service Telemetry Framework(STF)与通过 SNMP 陷阱接收通知的现有基础架构监控平台集成。要启用 SNMP 陷阱,请修改 ServiceTelemetry 对象并配置 snmpTraps 参数。
有关配置警报的详情请参考 第 5.3 节 “Service Telemetry Framework 中的警报”。
先决条件
- 知道 SNMP 陷入接收器的 IP 地址或主机名,您要在其中发送警报
流程
要启用 SNMP 陷阱,请修改
ServiceTelemetry对象:$ oc edit stf default
设置 alert
.alertmanager.receivers.snmpTraps参数:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... alerting: alertmanager: receivers: snmpTraps: enabled: true target: 10.10.10.10-
确保将
target值设置为 SNMP 陷入接收器的 IP 地址或主机名。
5.5. 高可用性
通过高可用性,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 而不是默认值:
- AMQ Interconnect
- Alertmanager
- Prometheus
- 事件智能网关
- 指标智能网关
- 从任何这些服务中出现丢失的 pod 恢复时间会减少到大约 2 秒。
5.5.1. 配置高可用性
要配置 Service Telemetry Framework(STF)以实现高可用性,请向 Red Hat OpenShift Container Platform 中的 ServiceTelemetry 对象添加 highAvailability.enabled: true。您可以在安装时设置此参数,或者已经部署了 STF,请完成以下步骤:
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
使用 oc 命令编辑 ServiceTelemetry 对象:
$ oc edit stf default
在
spec部分添加highAvailability.enabled: true:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... highAvailability: enabled: true- 保存您的更改并关闭对象。
5.6. 临时存储
您可以使用临时存储来运行 Service Telemetry Framework(STF),而无需将数据存储到 Red Hat OpenShift Container Platform 集群中。
如果使用临时存储,则在 pod 重启、更新或重新调度到另一节点上时,可能会遇到数据丢失。仅将临时存储用于开发或测试,而不适用于生产环境。
5.6.1. 配置临时存储
要为临时存储配置 STF 组件,请将 ...storage.strategy: ephemeral 添加到对应的参数。例如,要为 Prometheus 后端启用临时存储,请设置 backends.metrics.prometheus.storage.strategy: ephemeral。支持临时存储配置的组件包括 alert .alertmanager、backends.metrics.prometheus 和 backends.events.elasticsearch。您可以在安装时添加临时存储配置,或者如果您已经部署了 STF,请完成以下步骤:
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
编辑 ServiceTelemetry 对象:
$ oc edit stf default
将
...storage.strategy: ephemeral参数添加到相关组件的spec部分:apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: stf-default namespace: service-telemetry spec: alerting: enabled: true alertmanager: storage: strategy: ephemeral backends: metrics: prometheus: enabled: true storage: strategy: ephemeral events: elasticsearch: enabled: true storage: strategy: ephemeral- 保存您的更改并关闭对象。
5.7. Service Telemetry Framework 中的可观察性策略
Service Telemetry Framework(STF)不包括存储后端和警报工具。STF 使用社区操作器来部署 Prometheus、Alertmanager、Grafana 和 Elasticsearch。STF 向这些社区操作器发出请求,以创建配置为使用 STF 的每个应用程序的实例。
您可以使用您自己的应用程序部署这些应用程序或其他兼容应用程序,而不必让 Service Telemetry Operator 创建自定义资源,而是提取指标智能网关以传送到您自己的与 Prometheus 兼容的系统以进行遥测存储。如果将 observability 策略设置为使用备用后端,则 STF 不需要持久性或临时存储。
5.7.1. 配置备用可观察性策略
要配置 STF 来跳过存储、视觉化和警报后端的部署,请在 ServiceTelemetry spec 中添加 observabilityStrategy: none。在这个模式中,只会部署 AMQ Interconnect 路由器和指标智能网关,您必须配置外部 Prometheus 兼容系统,以便从 STF 智能网关收集指标。
目前,只有将 observabilityStrategy 设置为 none 时支持指标。事件智能网关没有部署。
流程
在
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
要验证所有工作负载是否正确运行,请查看 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.4.2 节 “部署智能网关”
5.8. Red Hat OpenStack Platform 服务的资源使用
您可以通过显示运行计算机器的服务来监控 Red Hat OpenStack Platform(RHOSP)服务(如 API 和其他基础架构进程)的资源使用情况,以识别 overcloud 中的瓶颈。默认启用资源使用量监控。
其他资源
- 要禁用资源使用量监控,请参阅 第 5.8.1 节 “禁用 Red Hat OpenStack Platform 服务的资源使用监控”。
5.8.1. 禁用 Red Hat OpenStack Platform 服务的资源使用监控
要禁用 RHOSP 容器化服务资源使用情况的监控,您必须将 CollectdEnableLibpodstats 参数设置为 false。
先决条件
-
您已创建了
stf-connectors.yaml文件。更多信息请参阅 第 4.1 节 “部署 Red Hat OpenStack Platform overcloud for Service Telemetry Framework”。 - 您使用最新版本的 Red Hat OpenStack Platform (RHOSP) 17.0。
流程
打开
stf-connectors.yaml文件,并添加CollectdEnableLibpodstats参数来覆盖enable-stf.yaml中的设置。在enable-stf.yaml后,确保openstack overcloud deploy命令中调用stf-connectors.yaml:CollectdEnableLibpodstats: false
- 继续浏览 overcloud 部署过程。更多信息请参阅 第 4.1.5 节 “部署 overcloud”。
5.9. Red Hat OpenStack Platform API 状态和容器化服务健康状态
您可以通过定期运行健康检查脚本,使用 OCI(开放容器项目)标准来评估每个 Red Hat OpenStack Platform(RHOSP)服务的容器健康状况。大多数 RHOSP 服务都实现了日志问题并返回二进制状态的健康检查。对于 RHOSP API,健康检查会查询根端点,并根据响应时间确定健康状况。
监控 RHOSP 容器健康状况和 API 状态默认为启用。
其他资源
- 要禁用 RHOSP 容器健康和 API 状态监控,请参阅 第 5.9.1 节 “禁用容器健康和 API 状态监控”。
5.9.1. 禁用容器健康和 API 状态监控
要禁用 RHOSP 容器化服务健康状态和 API 状态监控,您必须将 CollectdEnableSensubility 参数设置为 false。
先决条件
-
您已在 templates 目录中创建了
stf-connectors.yaml文件。更多信息请参阅 第 4.1 节 “部署 Red Hat OpenStack Platform overcloud for Service Telemetry Framework”。 - 您使用最新版本的 Red Hat OpenStack Platform (RHOSP) 17.0。
流程
打开
stf-connectors.yaml并添加CollectdEnableSensubility参数,以覆盖enable-stf.yaml中的设置。在enable-stf.yaml后,确保openstack overcloud deploy命令中调用stf-connectors.yaml:CollectdEnableSensubility: false
- 继续浏览 overcloud 部署过程。更多信息请参阅 第 4.1.5 节 “部署 overcloud”。
其他资源
- 有关多个云地址的更多信息,请参阅 第 4.4 节 “配置多个云”。
第 6 章 将 Service Telemetry Framework 升级到 1.4
要从 Service Telemetry Framework(STF)v1.3 迁移到 STF v1.4,您必须替换 Red Hat OpenShift Container Platform 环境中的 service-telemetry 命名空间中的 ClusterServiceVersion 和 Subscription 对象。
先决条件
- 您已将 Red Hat OpenShift Container Platform 环境升级到 v4.8。STF v1.4 在小于 v4.8 的 Red Hat OpenShift Container Platform 版本上运行。
-
已备份了数据。将 STF v1.3 升级到 v1.4 会导致在智能网关和其他组件更新时短暂停机。另外,在 Operator 被替换时,对
ServiceTelemetry和SmartGateway对象的更改没有影响。
要从 STF v1.3 升级到 v1.4,请完成以下步骤:
6.1. 删除 STF 1.3 智能网关 Operator
从 STF 1.3 移除智能网关 Operator。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
检索 Smart Gateway Operator
的订阅名称。如果与 default 命名空间不同,将选择器中的service-telemetry替换为托管 STF 实例的命名空间。验证只有一个订阅是否已返回:$ oc get sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry NAME PACKAGE SOURCE CHANNEL smart-gateway-operator-stable-1.3-redhat-operators-openshift-marketplace smart-gateway-operator redhat-operators stable-1.3
删除 Smart Gateway Operator 订阅:
$ oc delete sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry subscription.operators.coreos.com "smart-gateway-operator-stable-1.3-redhat-operators-openshift-marketplace" deleted
检索 Smart Gateway Operator ClusterServiceVersion,验证是否只返回一个 ClusterServiceVersion:
$ oc get csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE smart-gateway-operator.v3.0.1635451893 Smart Gateway Operator 3.0.1635451893 Succeeded
删除 Smart Gateway Operator ClusterServiceVersion:
$ oc delete csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry clusterserviceversion.operators.coreos.com "smart-gateway-operator.v3.0.1635451893" deleted
删除 SmartGateway 自定义资源定义(CRD)。删除 CRD 后,直到升级完成且智能网关实例被重新实例化前,不会向 STF 传输数据:
$ oc delete crd smartgateways.smartgateway.infra.watch customresourcedefinition.apiextensions.k8s.io "smartgateways.smartgateway.infra.watch" deleted
6.2. 将 Service Telemetry Operator 更新至 1.4
您必须将管理 STF 实例的 Service Telemetry Operator 的订阅频道改为 stable-1.4 频道。
流程
- 登录 Red Hat OpenShift Container Platform。
进入
service-telemetry命名空间:$ oc project service-telemetry
对 Service Telemetry Operator 订阅进行补丁以使用 stable-1.4 频道。如果与 default 命名空间不同,将选择器中的
service-telemetry替换为托管 STF 实例的命名空间:$ oc patch $(oc get sub --selector=operators.coreos.com/service-telemetry-operator.service-telemetry -oname) --patch $'spec:\n channel: stable-1.4' --type=merge subscription.operators.coreos.com/service-telemetry-operator patched
监控
oc get csv命令的输出,直到安装了 Smart Gateway Operator 和 Service Telemetry Operator 整个更新阶段为止。当阶段变为Succeeded时,Service Telemetry Operator 已完成更新:$ watch -n5 oc get csv NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded amq7-interconnect-operator.v1.10.5 Red Hat Integration - AMQ Interconnect 1.10.5 amq7-interconnect-operator.v1.10.4 Succeeded elasticsearch-eck-operator-certified.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded service-telemetry-operator.v1.4.1641504218 Service Telemetry Operator 1.4.1641504218 service-telemetry-operator.v1.3.1635451892 Succeeded smart-gateway-operator.v4.0.1641504216 Smart Gateway Operator 4.0.1641504216 Succeeded
验证所有 Pod 已准备并正在运行。您的环境可能与以下示例输出不同:
$ oc get pods NAME READY STATUS RESTARTS AGE alertmanager-default-0 3/3 Running 0 162m default-cloud1-ceil-event-smartgateway-5599bcfc9d-wp48n 2/2 Running 1 160m default-cloud1-ceil-meter-smartgateway-c8fdf579c-955kt 3/3 Running 0 160m default-cloud1-coll-event-smartgateway-97b54b7dc-5zz2v 2/2 Running 0 159m default-cloud1-coll-meter-smartgateway-774b9988b8-wb5vd 3/3 Running 0 160m default-cloud1-sens-meter-smartgateway-b98966fbf-rnqwf 3/3 Running 0 159m default-interconnect-675dd97bc4-dcrzk 1/1 Running 0 171m default-snmp-webhook-7854d4889d-wgmgg 1/1 Running 0 171m elastic-operator-c54ff8cc-jcg8d 1/1 Running 6 3h55m elasticsearch-es-default-0 1/1 Running 0 160m interconnect-operator-6bf74c4ffb-hkmbq 1/1 Running 0 3h54m prometheus-default-0 3/3 Running 1 160m prometheus-operator-fc64987d-f7gx4 1/1 Running 0 3h54m service-telemetry-operator-68d888f767-s5kzh 1/1 Running 0 163m smart-gateway-operator-584df7959-llxgl 1/1 Running 0 163m
第 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,您必须执行以下任务:
- 删除命名空间。
- 删除目录源。
- 删除 AMQ Cert Manager Operator。
7.1. 删除命名空间
要从 Red Hat OpenShift Container Platform 中删除 STF 的操作资源,请删除该命名空间。
流程
运行
oc delete命令:$ oc delete project service-telemetry
验证资源是否已从命名空间中删除:
$ oc get all No resources found.
7.2. 删除 CatalogSource
如果您不应该再次安装 Service Telemetry Framework(STF),请删除 CatalogSource。当您删除 CatalogSource 时,与 STF 相关的 PackageManifests 会自动从 Operator Lifecycle Manager 目录中删除。
流程
如果您在安装过程中启用了 OperatorHub.io Community Catalog Source,且不再需要这个目录源,请删除它:
$ oc delete --namespace=openshift-marketplace catalogsource operatorhubio-operators catalogsource.operators.coreos.com "operatorhubio-operators" deleted
7.3. 删除 AMQ Certificate Manager Operator
如果您不将 AMQ 证书管理器用于任何其他应用程序,请删除 Subscription、ClusterServiceVersion 和 CustomResourceDefinitions。
流程
检索您安装的 ClusterServiceVersion 的版本号:
$ oc get --namespace=openshift-operators subscription amq7-cert-manager-operator -oyaml | grep currentCSV
输出示例:
currentCSV: amq7-cert-manager.v1.0.6
从
openshift-operators命名空间中删除订阅:$ oc delete --namespace=openshift-operators subscription amq7-cert-manager-operator subscription.operators.coreos.com "amq7-cert-manager-operator" deleted
获取 Operator 提供的 CustomResourceDefinitions 的当前列表,以便在删除 ClusterServiceVersion 后删除它们:
$ oc get csv -nopenshift-operators amq7-cert-manager.v1.0.6 -oyaml | grep "kind: CustomResourceDefinition" -A2 | grep name | awk '{print $2}'输出示例:
certificates.certmanager.k8s.io challenges.certmanager.k8s.io clusterissuers.certmanager.k8s.io issuers.certmanager.k8s.io orders.certmanager.k8s.io
从
openshift-operators命名空间中删除 ClusterServiceVersion:$ oc delete --namespace=openshift-operators csv amq7-cert-manager.v1.0.6
输出示例:
clusterserviceversion.operators.coreos.com "amq7-cert-manager.v1.0.6" deleted
删除与 AMQ Cert Manager Operator 相关的 CustomResourceDefinitions:
$ oc delete crd certificates.certmanager.k8s.io challenges.certmanager.k8s.io clusterissuers.certmanager.k8s.io issuers.certmanager.k8s.io orders.certmanager.k8s.io
输出示例:
customresourcedefinition.apiextensions.k8s.io "certificates.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "challenges.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "clusterissuers.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "issuers.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "orders.certmanager.k8s.io" deleted
附加信息
有关从 Red Hat OpenShift Container Platform 中删除 Operator 的更多信息,请参阅 https://docs.openshift.com/container-platform/4.10/operators/admin/olm-deleting-operators-from-cluster.html