1.4. 定制可观察性配置


启用可观察性后,根据环境的具体需求自定义可观察性配置。管理并查看可观察性服务收集的集群团队数据。

需要的访问权限:集群管理员

1.4.1. 创建自定义规则

通过在可观察性资源中添加 Prometheus 记录规则警报规则,为可观察性安装创建自定义规则。

要预先计算昂贵的表达式,请使用记录规则功能。结果保存为一组新的时间序列。使用警报规则,您可以根据如何将警报发送到外部服务来指定警报条件。

注: 当您更新自定义规则时,observability-thanos-rule pod 会自动重启。

使用 Prometheus 定义自定义规则来创建警报条件,并将通知发送到外部消息服务。查看以下自定义规则示例:

  • 创建自定义警报规则。在 open-cluster-management-observability 命名空间中创建一个名为 thanos-ruler-custom-rules 的配置映射。您必须命名键 custom_rules.yaml,如下例所示。您可以在配置中创建多个规则。

    • 创建自定义警报规则,在 CPU 使用量通过定义的值时通知您。您的 YAML 可能类似以下内容:

      data:
        custom_rules.yaml: |
          groups:
            - name: cluster-health
              rules:
              - alert: ClusterCPUHealth-jb
                annotations:
                  summary: Notify when CPU utilization on a cluster is greater than the defined utilization limit
                  description: "The cluster has a high CPU usage: {{ $value }} core for {{ $labels.cluster }} {{ $labels.clusterID }}."
                expr: |
                  max(cluster:cpu_usage_cores:sum) by (clusterID, cluster, prometheus) > 0
                for: 5s
                labels:
                  cluster: "{{ $labels.cluster }}"
                  prometheus: "{{ $labels.prometheus }}"
                  severity: critical
    • 默认警报规则位于 open-cluster-management-observability 命名空间的 thanos-ruler-default-rules 配置映射中。
  • thanos-ruler-custom-rules 配置映射中创建自定义记录规则。创建一个记录规则,以便您获取 pod 的容器内存缓存总和。您的 YAML 可能类似以下内容:

    data:
      custom_rules.yaml: |
        groups:
          - name: container-memory
            rules:
            - record: pod:container_memory_cache:sum
              expr: sum(container_memory_cache{pod!=""}) BY (pod, container)

    注: 在修改了配置映射后,配置会自动重新载入。由于 observability-thanos-ruler sidecar 中的 config-reload,因此配置会重新载入。

  • 要验证警报规则是否正常工作,进入 Grafana 仪表板,选择 Explore 页面并查询 ALERTS。只有在创建了警报时,Grafana 才会在 Grafana 中提供警报。

1.4.2. 添加自定义指标

要开始从所有受管集群收集指标,请将指标添加到 metrics_list.yaml 文件中。完成以下步骤:

  1. 在添加自定义指标前,使用以下命令验证 mco observability 是否已启用:

    oc get mco observability -o yaml
  2. 检查 status.conditions.message 部分中的以下信息:

    Observability components are deployed and running
  3. 使用以下命令,在 open-cluster-management-observability 命名空间中创建 observability-metrics-custom-allowlist 配置映射:

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
  4. 将自定义指标名称添加到 metrics_list.yaml 参数。配置映射的 YAML 可能类似以下内容:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: observability-metrics-custom-allowlist
    data:
      metrics_list.yaml: |
        names: 1
          - node_memory_MemTotal_bytes
        rules: 2
        - record: apiserver_request_duration_seconds:histogram_quantile_90
          expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket{job=\"apiserver\",
            verb!=\"WATCH\"}[5m])) by (verb,le))
    1
    可选: 添加要从受管集群收集的自定义指标的名称。
    2
    可选:exprrecord 参数对输入一个值来定义查询表达式。指标作为来自受管集群的 record 参数中定义的名称来收集。返回的指标值是运行查询表达式后的结果。

    您可以使用其中一个或两个部分。对于用户工作负载指标,请参阅添加用户工作负载指标部分。

    注: 您还可以在自定义 metrics allowlist 中单独自定义每个受管集群,而不是在整个团队中应用它。您可以直接在受管集群中创建相同的 YAML 来自定义它。

  5. 通过 Grafana 仪表板 Explore 页面查询指标,从自定义指标验证数据收集。您也可以在您自己的仪表板中使用自定义指标。

1.4.2.1. 添加用户工作负载指标

从 OpenShift Container Platform 中的工作负载收集 OpenShift Container Platform 用户定义的指标,以显示来自 Grafana 仪表板的指标。完成以下步骤:

  1. 在 OpenShift Container Platform 集群上启用监控。请参阅附加资源部分中的 为用户定义的项目启用监控

    如果您有一个为用户定义的工作负载启用监控的受管集群,用户工作负载位于 test 命名空间中,并生成指标。Prometheus 从 OpenShift Container Platform 用户工作负载收集这些指标。

  2. observability-metrics-custom-allowlist 配置映射中添加用户工作负载指标,以收集 测试 命名空间中的指标。查看以下示例:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: observability-metrics-custom-allowlist
      namespace: test
    data:
      uwl_metrics_list.yaml: 1
        names: 2
          - sample_metrics
    1
    输入配置映射数据的密钥。
    2
    以 YAML 格式输入配置映射数据的值。name 部分包含您要从 test 命名空间收集的指标名称列表。创建配置映射后,observability 收集器会收集并将指标从目标命名空间推送到 hub 集群。

1.4.2.2. 删除默认指标

如果您不想从受管集群收集特定指标的数据,请从 observability-metrics-custom-allowlist.yaml 文件中删除指标。当您删除指标时,不会从受管集群收集指标数据。完成以下步骤以删除默认指标:

  1. 使用以下命令验证 mco observability 是否已启用:

    oc get mco observability -o yaml
  2. 您可以在 metrics 名称的开头使用连字符 - 将默认指标名称添加到 metrics_list.yaml 参数中。查看以下指标示例:

    -cluster_infrastructure_provider
  3. 使用以下命令,在 open-cluster-management-observability 命名空间中创建 observability-metrics-custom-allowlist 配置映射:

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
  4. 验证 observability 服务是否没有从受管集群收集特定的指标。当您从 Grafana 仪表板查询指标时,指标不会显示。

1.4.3. 为保留添加高级配置

要根据您的需要更新每个可观察性组件的保留,请添加 advanced configuration 部分。完成以下步骤:

  1. 使用以下命令编辑 MultiClusterObservability 自定义资源:

    oc edit mco observability -o yaml
  2. advanced 部分添加到 文件。您的 YAML 文件可能类似以下内容:

    spec:
      advanced:
        retentionConfig:
          blockDuration: 2h
          deleteDelay: 48h
          retentionInLocal: 24h
          retentionResolutionRaw: 365d
          retentionResolution5m: 365d
          retentionResolution1h: 365d
        receive:
          resources:
            limits:
              memory: 4096Gi
          replicas: 3

    备注:

    • 有关可添加到 高级配置 中的所有参数的描述,请参阅 Observability API 文档。
    • 保留所有分辨率级别的默认保留(如 retentionResolutionRawretentionResolution5mretentionResolution1h )是 365 天(365d)。您必须在 MultiClusterObservability spec.advanced.retentionConfig 参数中为解析保留设置一个显式值。
  3. 如果您从早期版本升级并希望保留该版本保留配置,请添加前面提到的配置。完成以下步骤:

    1. 运行以下命令来进入 MultiClusterObservability 资源:

      edit mco observability
    2. spec.advanced.retentionConfig 参数中,应用以下配置:
    spec:
      advanced:
        retentionConfig:
          retentionResolutionRaw: 365d
          retentionResolution5m: 365d
          retentionResolution1h: 365d

1.4.4. 单节点 OpenShift 集群的动态指标

动态指标收集根据特定条件支持自动指标收集。默认情况下,单节点 OpenShift 集群不会收集 pod 和容器资源指标。单节点 OpenShift 集群达到特定级别的资源消耗后,会动态收集定义的粒度指标。当集群资源消耗在一段时间内持续低于阈值时,细致的指标集合会停止。

这些指标会根据由集合规则指定的受管集群上的条件动态收集。由于这些指标是动态收集的,所以以下 Red Hat Advanced Cluster Management Grafana 仪表板不会显示任何数据。激活集合规则并收集相应指标时,以下面板会在启动集合规则的时间里显示数据:

  • Kubernetes/Compute Resources/Namespace (Pods)
  • Kubernetes/Compute Resources/Namespace (Workloads)
  • Kubernetes/Compute Resources/Nodes (Pods)
  • Kubernetes/Compute Resources/Pod
  • Kubernetes/Compute Resources/Workload A 集合规则包括以下条件:
  • 动态收集的一组指标。
  • 使用 PromQL 表达式定义的条件。
  • 集合的间隔,该集合必须设为 true
  • 一个匹配表达式,用于选择需要评估收集规则的集群。

默认情况下,集合规则每 30 秒或以特定时间间隔在受管集群上持续评估。集合间隔和时间间隔中的最低值具有高优先权。当收集规则条件在 for 属性指定的持续时间内保留后,收集规则将启动,由规则指定的指标会在受管集群上自动收集。指标集合会在受管集群上不再存在集合规则条件后自动停止,至少有 15 分钟。

集合规则分组为名为 gather_rules 的参数部分,该部分可启用或禁用作为组。Red Hat Advanced Cluster Management 安装包含集合规则组 SNOResourceUsage,它有两个默认集合规则: HighCPUUsageHighMemoryUsageHighCPUUsage 集合规则从节点 CPU 使用率超过 70% 时开始。如果单节点 OpenShift 集群的总内存使用率超过可用节点内存的 70%,则 HighMemoryUsage 集合规则开始。目前,前面提到的阈值是固定的,且无法更改。当集合规则开始超过 for 属性指定的间隔时,系统会自动开始收集 dynamic_metrics 中指定的指标。

在以下 YAML 文件中查看 collect_rules 部分的动态指标列表:

collect_rules:
  - group: SNOResourceUsage
    annotations:
      description: >
        By default, a {sno} cluster does not collect pod and container resource metrics. Once a {sno} cluster
        reaches a level of resource consumption, these granular metrics are collected dynamically.
        When the cluster resource consumption is consistently less than the threshold for a period of time,
        collection of the granular metrics stops.
    selector:
      matchExpressions:
        - key: clusterType
          operator: In
          values: ["{sno}"]
    rules:
    - collect: SNOHighCPUUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster cpu usage is constantly more than 70% for 2 minutes
      expr: (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - container_cpu_cfs_periods_total
          - container_cpu_cfs_throttled_periods_total
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
    - collect: SNOHighMemoryUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster memory usage is constantly more than 70% for 2 minutes
      expr: (1 - sum(:node_memory_MemAvailable_bytes:sum) / sum(kube_node_status_allocatable{resource=\"memory\"})) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
        matches:
          - __name__="container_memory_cache",container!=""
          - __name__="container_memory_rss",container!=""
          - __name__="container_memory_swap",container!=""
          - __name__="container_memory_working_set_bytes",container!=""

可以在 custom-allowlist 中禁用 collect_rules.group,如下例所示。当 collect_rules.group 禁用时,指标集合会恢复到之前的行为。这些指标定期收集,指定间隔:

collect_rules:
  - group: -SNOResourceUsage

只有在启动规则时,数据才会在 Grafana 中显示。

1.4.5. 从控制台更新 MultiClusterObservability 自定义资源副本

如果工作负载增加,增加可观察 pod 的副本数。从您的 hub 集群中进入到 Red Hat OpenShift Container Platform 控制台。找到 MultiClusterObservability 自定义资源,并更新您要更改副本的组件的 replicas 参数值。更新的 YAML 可能类似以下内容:

spec:
   advanced:
      receive:
         replicas: 6

有关 mco observability 自定义资源中的参数的更多信息,请参阅 Observability API 文档。

1.4.6. 增加和减少持久性卷和持久性卷声明

增加和减少持久性卷和持久性卷声明,以更改存储类中的存储量。完成以下步骤:

  1. 要增加持久性卷的大小,如果存储类支持扩展卷,请更新 MultiClusterObservability 自定义资源。
  2. 要缩小持久性卷的大小使用持久性卷删除 pod,请删除持久性卷并重新创建它们。您可能会遇到持久性卷中的数据丢失。完成以下步骤:

    1. 通过在 MultiClusterObservability 自定义资源中添加注解 mco-pause: "true" 来暂停 MultiClusterObservability operator。
    2. 查找所需组件的有状态集或部署。将其副本数更改为 0。这会启动关闭,这涉及在适用时上传本地数据以避免数据丢失。例如,Thanos Receive stateful 集名为 observability-thanos-receive-default,默认有三个副本。因此,您要查找以下持久性卷声明:

      • data-observability-thanos-receive-default-0
      • data-observability-thanos-receive-default-1
      • data-observability-thanos-receive-default-2
    3. 删除所需组件使用的持久性卷和持久性卷声明。
    4. MultiClusterObservability 自定义资源中,在存储大小字段中编辑组件的存储大小。使用组件名称作为前缀。
    5. 通过删除之前添加的注解来取消暂停 MultiClusterObservability operator。
    6. 要在 Operator 暂停后启动协调,请删除 multicluster-observability-operatorobservatorium-operator pod。pod 会立即重新创建和协调。
  3. 通过检查 MultiClusterObservability 自定义资源来验证持久性卷和卷声明是否已更新。

1.4.7. 自定义路由证书

如果要自定义 OpenShift Container Platform 路由认证,则必须在 alt_names 部分添加路由。要确保 OpenShift Container Platform 路由可以访问,请添加以下信息:alertmanager.apps.<domainname>, observatorium-api.apps.<domainname>, rbac-query-proxy.apps.<domainname>

如需了解更多详细信息,请参阅监管文档中的 替换 alertmanager 路由的证书。

注意 :用户负责证书轮转和更新。

1.4.8. 自定义用于访问对象存储的证书

您可以通过创建一个包含证书颁发机构并配置 MultiClusterObservability 自定义资源的 Secret 资源来配置与 observability 对象存储的安全连接。完成以下步骤:

  1. 要验证对象存储连接,请使用以下命令在包含证书颁发机构的文件中创建 Secret 对象:

    oc create secret generic <tls_secret_name> --from-file=ca.crt=<path_to_file> -n open-cluster-management-observability
    1. 另外,您可以应用以下 YAML 来创建 secret:
    apiVersion: v1
    kind: Secret
    metadata:
      name: <tls_secret_name>
      namespace: open-cluster-management-observability
    type: Opaque
    data:
      ca.crt: <base64_encoded_ca_certificate>

    可选: 如果要启用 mutual TLS,则需要在上一个 secret 中添加 public.crtprivate.key 密钥。

  2. 使用以下命令在 metricObjectStorage 部分添加 TLS secret 详情:

    oc edit mco observability -o yaml

    您的文件可能类似以下 YAML:

    metricObjectStorage:
      key: thanos.yaml
      name: thanos-object-storage
      tlsSecretName: tls-certs-secret 1
      tlsSecretMountPath: /etc/minio/certs 2
    1
    tlsSecretName 的值是之前创建的 Secret 对象的名称。
    2
    tlsSecretMountPath 参数定义的 /etc/minio/certs/ 路径指定证书在 Observability 组件中挂载的位置。下一步需要此路径。
  3. 使用证书详情添加 http_config.tls_config 部分,更新 thanos-object-storage secret 中的 thanos.yaml 定义。查看以下示例:

    thanos.yaml: |
       type: s3
       config:
         bucket: "thanos"
         endpoint: "minio:9000"
         insecure: false 1
         access_key: "minio"
         secret_key: "minio123"
         http_config:
           tls_config:
             ca_file: /etc/minio/certs/ca.crt 2
             insecure_skip_verify: false
    1
    insecure 参数设置为 false 以启用 HTTPS。
    2
    ca_file 参数的路径必须与 MultiClusterObservability 自定义资源中的 tlsSecretMountPath 匹配。ca.crt 必须与 < tls_secret_name> Secret 资源中的 键匹配。

    可选: 如果要启用 mutual TLS,您需要将 cert_filekey_file 密钥添加到 tls_config 部分。请参见以下示例:

     thanos.yaml: |
        type: s3
        config:
          bucket: "thanos"
          endpoint: "minio:9000"
          insecure: false
          access_key: "minio"
          secret_key: "minio123"
          http_config:
            tls_config:
              ca_file: /etc/minio/certs/ca.crt 1
              cert_file: /etc/minio/certs/public.crt
              key_file: /etc/minio/certs/private.key
              insecure_skip_verify: false
    1
    ca_filecert_filekey_file 的路径必须与 MultiClusterObservability 自定义资源的 tlsSecretMountPath 匹配。ca.crtpublic.crtprivate.crt 必须与 tls_secret_name > Secret 资源中的对应密钥匹配。
  4. 要验证您可以访问对象存储,请检查是否部署了 pod。运行以下命令:

    oc -n open-cluster-management-observability get pods -l app.kubernetes.io/name=thanos-store

1.4.9. 为可观察附加组件配置代理设置

配置代理设置,以允许与受管集群的通信通过 HTTP 和 HTTPS 代理服务器访问 hub 集群。通常,附加组件不需要任何特殊配置来支持 hub 集群和受管集群之间的 HTTP 和 HTTPS 代理服务器。但是,如果启用了可观察性附加组件,您必须完成代理配置。

1.4.10. 前提条件

  • 您有一个 hub 集群。
  • 您已在 hub 集群和受管集群间启用了代理设置。

完成以下步骤,为可观察附加组件配置代理设置:

  1. 进入 hub 集群上的集群命名空间。
  2. 通过添加 spec.proxyConfig 参数,使用代理设置创建 AddOnDeploymentConfig 资源。查看以下 YAML 示例:

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: AddOnDeploymentConfig
    metadata:
      name: <addon-deploy-config-name>
      namespace: <managed-cluster-name>
    spec:
      agentInstallNamespace: open-cluster-managment-addon-observability
      proxyConfig:
        httpsProxy: "http://<username>:<password>@<ip>:<port>" 1
        noProxy: ".cluster.local,.svc,172.30.0.1" 2
    1
    对于此字段,您可以指定 HTTP 代理或 HTTPS 代理。
    2
    包含 kube-apiserver 的 IP 地址。
  3. 要获取 IP 地址,请在受管集群中运行以下命令:

    oc -n default describe svc kubernetes | grep IP:
  4. 进入 ManagedClusterAddOn 资源,并通过引用您所做的 AddOnDeploymentConfig 资源来更新它。查看以下 YAML 示例:

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: observability-controller
      namespace: <managed-cluster-name>
    spec:
      installNamespace: open-cluster-managment-addon-observability
      configs:
      - group: addon.open-cluster-management.io
        resource: AddonDeploymentConfig
        name: <addon-deploy-config-name>
        namespace: <managed-cluster-name>
  5. 验证代理设置。如果您成功配置了代理设置,则由受管集群中可观察附加组件代理部署的指标收集器会将数据发送到 hub 集群。完成以下步骤:

    1. 进入 hub 集群,然后在 Grafana 仪表板中进入受管集群。
    2. 查看代理设置的指标。

1.4.11. 为可观察附加组件禁用代理设置

如果开发需要改变,您可能需要为 hub 集群和受管集群配置的 observability 附加组件禁用代理设置。您可以随时禁用 observability 附加组件的代理设置。完成以下步骤:

  1. 进入 ManagedClusterAddOn 资源。
  2. 删除引用的 AddOnDeploymentConfig 资源。

1.4.12. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.