流程

1. 编辑 ConfigMap 对象。

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 将您的配置以键值对 <component_name>: <component_configuration> 的形式添加到 data/config.yaml 下：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          <component>:
            <configuration_for_the_component>

      相应地替换 <component> 和 <configuration_for_the_component>。

      以下示例 ConfigMap 对象为 Prometheus 配置数据保留周期和最低容器资源请求。这与仅监控用户定义的项目的 Prometheus 实例相关：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus: 1
            retention: 24h 2
            resources:
              requests:
                cpu: 200m 3
                memory: 2Gi 4

      1

      定义 Prometheus 组件，后面几行则定义其配置。

      2

      为监控用户定义的项目的 Prometheus 实例配置 24 小时的数据保留周期。

      3

      为 Prometheus 容器定义最低 200 毫秒的资源请求。

      4

      为 Prometheus 容器定义最低 2 GiB 内存的 Pod 资源请求。

2. 保存文件以将更改应用到 ConfigMap 对象。受新配置影响的 Pod 会自动重启。

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

流程

1. 编辑 ConfigMap 对象：

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 为组件指定 tolerations：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          <component>:
            tolerations:
              <toleration_specification>

      相应地替换 <component> 和 <toleration_specification>。

      例如，oc adm taint nodes node1 key1=value1:NoSchedule 会将一个键为 key1 且值为 value1 的污点添加到 node1。这会防止监控组件在 node1 上部署 Pod，除非为该污点配置了容限。以下示例将 thanosRuler 组件配置为容许示例污点：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          thanosRuler:
            tolerations:
            - key: "key1"
              operator: "Equal"
              value: "value1"
              effect: "NoSchedule"

2. 保存文件以使改变生效。这样就会自动应用新组件放置配置。

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

流程

1. 编辑 ConfigMap 对象：

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 在 data/config.yaml/prometheus 下添加一个 remoteWrite: 部分。

   3. 在本节中添加端点 URL 和身份验证凭证：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            remoteWrite:
            - url: "https://remote-write-endpoint.example.com" 1
              <endpoint_authentication_credentials> 2

      1

      远程写入端点的 URL。

      2

      端点的身份验证方法和凭据。目前支持的身份验证方法有 AWS 签名版本 4，使用 HTTP Authorization 请求标头、基本身份验证、OAuth 2.0 和 TLS 客户端进行身份验证。有关支持的身份验证方法示例配置，请参见以下支持的远程写入身份验证设置。

   4. 在身份验证凭证后添加 write relabel 配置值：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            remoteWrite:
            - url: "https://remote-write-endpoint.example.com"
              <endpoint_authentication_credentials>
              <write_relabel_configs> 1

      1

      写入重新标记配置设置。

      对于 <write_relabel_configs>，请替换您要发送到远程端点的指标写入重新标记配置列表。

      以下示例演示了如何转发名为 my_metric 的单个指标：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            remoteWrite:
            - url: "https://remote-write-endpoint.example.com"
              writeRelabelConfigs:
              - sourceLabels: [__name__]
                regex: 'my_metric'
                action: keep

      有关写入重新标记配置选项的详情，请查看 Prometheus relabel_config 文档。

2. 保存文件以使改变生效。受新配置重启影响的 Pod 会自动重启。

   警告

   保存对监控 ConfigMap 对象的更改可能会重新部署相关项目中的 pod 和其他资源。保存更改还可能在该项目中重新启动正在运行的监控进程。

流程

1. 编辑 ConfigMap 对象。

   1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 使用以下配置，在 data/config.yaml/alertmanager/secrets 下添加一个 secrets: 部分：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          alertmanager:
            secrets: 1
            - <secret_name_1> 2
            - <secret_name_2>

      1

      本节包含要挂载到 Alertmanager 中的 secret。secret 必须位于与 Alertmanager 对象相同的命名空间中。

      2

      包含接收器身份验证凭证的 Secret 对象的名称。如果您添加多个 secret，请将每个 secret 放在新行中。

      以下示例配置映射设置将 Alertmanager 配置为使用名为 test-secret 和 test-secret-api-token 的两个 Secret 对象：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          alertmanager:
            enabled: true
            secrets:
            - test-secret
            - test-api-receiver-token

2. 保存文件以将更改应用到 ConfigMap 对象。新的配置会被自动应用。

流程

1. 编辑 ConfigMap 对象：

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 在 data/config.yaml 下定义每个指标要添加的标签映射:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            externalLabels:
              <key>: <value> 1

      1

      使用键值对替换 <key>: <value>，其中 <key> 是新标签的唯一名称，<value> 是它的值。

      警告

      不要使用 prometheus 或 prometheus_replica 作为键的名称，因为它们是保留的并会被覆盖。

      注意

      在 openshift-user-workload-monitoring 项目中，Prometheus 负责处理指标，而 Thanos Ruler 负责处理警报和记录规则。在 user-workload-monitoring-config ConfigMap 中为 prometheus 设置 externalLabels 只会为指标配置外部标签，而不会为任何规则配置外部标签。

      例如，要将关于区域和环境的元数据添加到与用户定义的项目相关所有时间序列和警报中，请使用：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            externalLabels:
              region: eu
              environment: prod

2. 保存文件以使改变生效。新的配置会被自动应用。

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

流程

1. 编辑 openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射：

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 在 data/config.yaml/thanosRuler 下添加以下设置的值来配置 pod 拓扑分布限制：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         topologySpreadConstraints:
         - maxSkew: 1 1
           topologyKey: monitoring 2
           whenUnsatisfiable: ScheduleAnyway 3
           labelSelector:
             matchLabels: 4
               app.kubernetes.io/name: thanos-ruler

   1

   为 maxSkew 指定数字值，它定义了允许不均匀分布 pod 的程度。此字段是必需的，值必须大于零。指定的值会根据您为 whenUnsatisfiable 指定的值的不同而有所不同。

   2

   为 topologyKey 指定节点标签键。此字段是必需的。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。

   3

   为 whenUnsatisfiable 指定一个值。此字段是必需的。可用选项包括 DoNotSchedule 和 ScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值，则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod，但为可能降低 skew 的节点赋予更高的优先级，请指定 ScheduleAnyway。

   4

   为 matchLabels 指定一个值。这个值用于标识要应用约束的匹配 pod 的集合。

3. 保存文件以自动应用更改。

   警告

   当您将更改保存到 user-workload-monitoring-config 配置映射时，可能会重新部署 openshift-user-workload-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程可能会重启。

流程

1. 编辑 ConfigMap 对象：

   1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 在 data/config.yaml 下为组件添加 logLevel: <log_level>：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          <component>: 1
            logLevel: <log_level> 2

      1

      您要为其设置日志级别的监控堆栈组件。对于用户工作负载监控，可用组件值有 alertmanager、prometheus、prometheusOperator 和 thanosRuler。

      2

      应用到组件的日志级别。可用值为 error、warn、info 和 debug。默认值为 info。

2. 保存文件以使改变生效。应用日志级别更改时，组件的 Pod 会自动重启。

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

3. 通过查看相关项目中的部署或 Pod 配置来确认已应用了日志级别。以下示例检查 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署中的日志级别：

   $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"

   输出示例

           - --log-level=debug

4. 检查组件的 Pod 是否正在运行。以下示例列出了 openshift-user-workload-monitoring 项目中 Pod 的状态：

   $ oc -n openshift-user-workload-monitoring get pods

   注意

   如果 ConfigMap 中包含了一个未识别的 logLevel 值，则组件的 pod 可能无法成功重启。

流程

1. 在 openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象：

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 在 data/config.yaml 下为 prometheus 添加 queryLogFile: <path> ：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         queryLogFile: <path> 1

   1

   将在其中记录查询的文件的路径。

3. 保存文件以使改变生效。

   警告

   当您将更改保存到监控配置映射时，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

4. 验证组件的 pod 是否正在运行。以下示例命令列出了 openshift-user-workload-monitoring 项目中的 pod 状态：

   $ oc -n openshift-user-workload-monitoring get pods

5. 读取查询日志：

   $ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>

   重要

   在检查了记录的查询信息后，恢复配置映射的设置。

流程

1. 在 OpenShift Cluster Manager Hybrid Cloud Console 中选择一个集群。
2. 点 Settings 选项卡。

3. 单击 Enable user workload monitoring 复选框，以取消选择 选项，然后单击 Save。

   禁用用户工作负载监控。Prometheus、Prometheus Operator 和 Thanos Ruler 组件在 openshift-user-workload-monitoring 项目中停止。

流程

1. 将标签添加到项目命名空间：

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. 要重新启用监控，请从命名空间中删除该标签：

   $ oc label namespace my-project 'openshift.io/user-monitoring-'

   注意

   如果项目有任何活跃的监控目标，Prometheus 可能需要几分钟时间在添加标签后停止提取它们。

流程

1. 编辑 user-workload-monitoring-config ConfigMap 对象：

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 在 data/config.yaml 下，添加 alertmanager 部分的 enabled: true 和 enableAlertmanagerConfig: true ：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   将 enabled 值设为 true，为集群中的用户定义的项目启用 Alertmanager 专用实例。将值设为 false 或省略键可完全为用户定义的项目禁用 Alertmanager。如果将此值设置为 false，或者如果省略了密钥，则用户定义的警报会路由到默认平台 Alertmanager 实例。

   2

   将 enableAlertmanagerConfig 值设置为 true，以便用户使用 AlertmanagerConfig 对象定义自己的警报路由配置。

3. 保存文件以使改变生效。用于用户定义的项目的 Alertmanager 专用实例会自动启动。

流程

1. 在 Administrator 视角中，选择 Observe → Targets。此时会打开 Metrics targets 页面，其中包含为指标提取的所有服务端点目标的列表。

   本页显示了 Red Hat OpenShift Service on AWS 和用户定义的项目的目标详情。本页列出了每个目标的以下信息：

   • 正在提取的服务端点 URL
   • 被监控的 ServiceMonitor 组件
   • 目标的 up 或 down 状态
   • 命名空间
   • 最后提取时间
   • 最后一次提取的持续时间

2. 可选：指标目标列表可能比较长。要查找特定目标，请执行以下操作之一：

   选项	描述
   根据状态和源过滤目标。	在 Filter 列表中选择 filters。 可用的过滤选项如下： Status 过滤器： Up。目标当前已启动，正在主动抓取指标。 Down。目标当前已停机，没有提取指标。 Source 过滤器： Platform。平台级别的目标仅与 AWS 默认项目的 Red Hat OpenShift Service 相关。这些项目提供 Red Hat OpenShift Service on AWS 核心功能。 User。用户目标与用户定义的项目相关。这些项目是用户创建的，可以进行自定义。
   根据名称或标签搜索目标。	在搜索框旁边的 Text 或 Label 字段中输入搜索词。
   对目标进行排序。	点一个或多个 Endpoint Status,Namespace,Last Scrape, 和 Scrape Duration 列标头。

3. 单击目标的 Endpoint 列中的 URL，以导航到其 Target 详情页面。本页提供有关目标的信息，包括：

   • 为指标提取的端点 URL
   • 目标的当前 Up 或 Down 状态
   • 到命名空间的链接
   • 到 ServiceMonitor 详情的链接
   • 附加到目标的标签
   • 为指标提取目标的最长时间

1. 打开 Red Hat OpenShift Service on AWS web 控制台，进入到 Observe → Alerting → Alerts 页面。
2. 可选：使用搜索列表中的 Name 字段按名称搜索警报。
3. 可选：通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报。
4. 可选：点击 Name、Severity、State 和 Source 列标题中的一个或多个标题对警报进行排序。

5. 选择警报的名称以导航到其 Alert Details 页面。该页面包含一个说明警报时间序列数据的图形。它还提供与此警报相关的信息，包括：

   • 警报的描述
   • 与警报关联的消息
   • 附加到警报的标签
   • 其相关警报规则的链接
   • 警报的静默（如果存在）

1. 进入到 Observe → Alerting → Silences 页面。
2. 可选：使用 Search by name 字段按名称过滤静默。
3. 可选：通过选择 Filter 列表中的过滤器来按状态过滤静默。默认情况下会应用 Active 和 Pending 过滤器。
4. 可选：点击 Name、Firing alerts 和 State 列标题中的一个或多个标题对静默进行排序。

5. 选择静默的名称以导航到其 Silence Details 页面。该页面包括以下详情：

   • 警报指定条件
   • 开始时间
   • 结束时间
   • 静默状态
   • 触发警报的数目和列表

1. 进入到 Observe → Alerting → Alerting Rules 页面。
2. 可选：通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报规则。
3. 可选：点击 Name、Severity、Alert State 和 Source 列标题中的一个或多个标题对警报规则进行排序。

4. 选择警报规则的名称以导航到其 Alerting Rule Details 页面。该页面提供有关警报规则的以下详情：

   • 警报规则名称、严重性和描述
   • 定义触发此警报的条件的表达式
   • 触发警报的条件得到满足的时间
   • 受警报规则约束的各个警报的图形，其中显示了触发该警报的值
   • 受警报规则约束的所有警报的列表

1. 进入到 Observe → <project_name> → Alerts 页面。

2. 查看警报、静默或警报规则的详情：

   • 要查看 Alert Details，可选择警报名称左侧的 >，然后在列表中选择警报。

   • 要查看 Silence Details，可在 Alert Details 页面的 Silenced By 部分中选择静默。Silence Details 页面包括以下信息：

     • 警报指定条件
     • 开始时间
     • 结束时间
     • 静默状态
     • 触发警报的数目和列表
   • 要查看 Alerting Rule Details，可在 Alerts 页面中警告右侧的 菜单中选择 View Alerting Rule。

流程

1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件：

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. 编辑 alertmanager.yaml 中的配置：

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   指定与路由匹配的警报。本例显示具有 service="prometheus-example-monitor" 标签的所有警报。

   2

   指定用于警报组的接收器。

3. 应用文件中的新配置：

   $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

流程

1. 在 Red Hat OpenShift Service on AWS web 控制台的 Administrator 视角中，进入到 Observe → Dashboards。
2. 在 Dashboard 列表中选择一个仪表板。有些仪表板（如 etcd 和 Prometheus 仪表板）在被选中时会生成额外的子菜单。

3. 可选：在 Time Range 列表中为图形选择一个时间范围。

   • 选择预定义的时间段。

   • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

     1. 输入或选择 From 和 To date and time。
     2. 单击 Save 以保存自定义时间范围。
4. 可选：选择一个 Refresh Interval。
5. 将鼠标悬停在仪表板中的每个图形上，以显示具体项目的详细信息。

流程

1. 在 Red Hat OpenShift Service on AWS web 控制台的 Developer 视角中，进入到 Observe → Dashboard。
2. 从 Project: 下拉列表中选择一个项目。

3. 从 Dashboard 下拉列表中选择一个仪表板，以查看过滤的指标。

   注意

   选择时，所有仪表板会生成额外的子菜单，但 Kubernetes / Compute Resources / Namespace(Pods) 除外。

4. 可选：在 Time Range 列表中为图形选择一个时间范围。

   • 选择预定义的时间段。

   • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

     1. 输入或选择 From 和 To date and time。
     2. 单击 Save 以保存自定义时间范围。
5. 可选：选择一个 Refresh Interval。
6. 将鼠标悬停在仪表板中的每个图形上，以显示具体项目的详细信息。

流程

1. 检索 bearer 令牌：

   $ token=`oc whoami -t`

2. 查询 /federate 路由的指标。以下示例查询 up 指标 ：

   $ curl -G -s -k -H "Authorization: Bearer $token" \
       'https://<federation_host>/federate' \ 1
       --data-urlencode 'match[]=up'

   1

   对于 <federation_host>，替换为路由的主机 URL。

   输出示例

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

流程

1. 查询指标名称，并验证项目是否正确：

   1. 从 web 控制台中的 Developer 视角，选择 Observe → Metrics。
   2. 在 Project: 列表中选择您要查看指标的项目。

   3. 从 Select query 列表中选择查询，或通过选择 Show PromQL 运行自定义 PromQL 查询。

      指标显示在图表中。

      查询需要基于每个项目。显示的指标与您选择的项目相关。

2. 验证您要来自的 pod 是否活跃提供指标。在一个 pod 中运行以下 oc exec 命令，以 podIP、port, and /metrics 为目标。

   $ oc exec <sample_pod> -n <sample_namespace> -- curl <target_pod_IP>:<port>/metrics

   注意

   您必须在安装了 curl 的 pod 上运行命令。

   以下示例输出显示了具有有效版本指标的结果。

   输出示例

     % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
   # HELP version Version information about this binary-- --:--:-- --:--:--     0
   # TYPE version gauge
   version{version="v0.1.0"} 1
   100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:-- 51000

   无效的输出表示对应应用程序存在问题。

3. 如果使用 PodMonitor CRD，请验证 PodMonitor CRD 是否已配置为使用标签匹配指向正确的 pod。如需更多信息，请参阅 Prometheus Operator 文档。

4. 如果您使用 ServiceMonitor CRD，如果 pod 的 /metrics 端点显示指标数据，请按照以下步骤验证配置：

   1. 验证该服务是否已指向正确的 /metrics 端点。输出中的服务标签必须与服务监控标签和后续步骤中服务定义的 /metrics 端点匹配。

      $ oc get service

      输出示例

      apiVersion: v1
      kind: Service 1
      metadata:
        labels: 2
          app: prometheus-example-app
        name: prometheus-example-app
        namespace: ns1
      spec:
        ports:
        - port: 8080
          protocol: TCP
          targetPort: 8080
          name: web
        selector:
          app: prometheus-example-app
        type: ClusterIP

      1

      指定这是一个服务 API。

      2

      指定用于此服务的标签。

   2. 查询 serviceIP、port 和 /metrics 端点，以查看前面在 pod 上运行的 curl 命令中的相同指标：

      1. 运行以下命令来查找服务 IP：

         $ oc get service -n <target_namespace>

      2. 查询 /metrics 端点：

         $ oc exec <sample_pod> -n <sample_namespace> -- curl <service_IP>:<port>/metrics

         以下示例中返回有效指标。

         输出示例

         % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                        Dload  Upload   Total   Spent    Left  Speed
         100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:--   99k
         # HELP version Version information about this binary
         # TYPE version gauge
         version{version="v0.1.0"} 1

   3. 使用标签匹配来验证 ServiceMonitor 对象是否已配置为指向所需服务。为此，将 oc get service 输出中的 Service 对象与 oc get servicemonitor 中输出的 ServiceMonitor 对象进行比较。标签必须与要显示的指标匹配。

      例如，在前面的步骤中，注意 Service 对象如何具有 app: prometheus-example-app 标签，而 ServiceMonitor 对象具有相同的 app: prometheus-example-app 匹配标签。

5. 如果一切都有效且指标仍不可用，请联系支持团队以获得进一步的帮助。

流程

1. 在 Administrator 视角中，进入到 Observe → Metrics。

2. 在 Expression 字段中运行以下 Prometheus Query Language (PromQL) 查询。这会返回具有最高提取示例数的十个指标：

   topk(10,count by (job)({__name__=~".+"}))

3. 如果指标的提取示例数大于预期，请检查分配给指标的未绑定标签值数量。

   • 如果指标与用户定义的项目相关，请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
   • 如果指标与 Red Hat OpenShift Service on AWS 核心项目相关，请 在红帽客户门户网站上创建一个红帽支持问题单。

4. 运行以下命令，作为 dedicated-admin，使用 Prometheus HTTP API 查看 TSDB 状态：

   $ oc login -u <username> -p <password>

   $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   $ token=$(oc whoami -t)

   $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

   输出示例

   "status": "success",