监控

流程

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 对象。

   警告

   ConfigMap 对象的不同配置更改会导致不同的结果：

   • Pod 不会重新部署。因此，没有服务中断。

   • 受影响的 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: 部分，如下例所示：

      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 客户端进行身份验证。有关支持的身份验证方法示例配置，请参见以下支持的远程写入身份验证设置。

   3. 在身份验证凭证后添加 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>
              writeRelabelConfigs:
              - <your_write_relabel_configs> 1

      1

      为您要发送到远程端点的指标添加配置。

      转发名为 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

      在 my_namespace 命名空间中转发名为 my_metric_1 和 my_metric_2 的指标示例

      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__,namespace]
                regex: '(my_metric_1|my_metric_2);my_namespace'
                action: keep

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

流程

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. 保存文件以使改变生效。新的配置会被自动应用。

流程

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 作为键的名称，因为它们是保留的并会被覆盖。
      • 不要使用 cluster 或 managed_cluster 作为密钥名称。使用它们可能会导致您无法在开发人员仪表板中看到数据的问题。
      注意

      在 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

   3. 保存文件以使改变生效。受新配置影响的 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 字段中添加以下设置来配置 pod 拓扑分布限制：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 1
         topologySpreadConstraints:
         - maxSkew: <n> 2
           topologyKey: <key> 3
           whenUnsatisfiable: <value> 4
           labelSelector: 5
             <match_option>

   1

   指定您要为其设置 pod 拓扑分布限制的组件名称。

   2

   为 maxSkew 指定数字值，它定义了允许不均匀分布 pod 的程度。

   3

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

   4

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

   5

   指定 labelSelector 来查找匹配的 pod。与此标签选择器匹配的 Pod 被计算，以确定其对应拓扑域中的 pod 数量。

   Thanos Ruler 的配置示例

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

3. 保存文件以使改变生效。受新配置影响的 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 会自动重新部署。

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. 编辑 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 和 Creator 栏上面的标头来对静默进行排序。

5. 选择静默的名称来查看其 Silence 详情页面。该页面包括以下详情：

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

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

4. 选择警报规则的名称来查看其 Alerting 规则详情页面。该页面提供有关警报规则的以下详情：

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

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

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

   • 可以通过在警报名称旁边点大于符号(>)来查看警报详情，然后从列表中选择警报。

   • 可以通过在 Alert details 页面的 Silenced by 部分点静默详情来查看静默详情。Silence details 页面包括以下信息：

     • 警报指定条件
     • 开始时间
     • 结束时间
     • 静默状态
     • 触发警报的数目和列表
   • 可以通过在 Alerts 页面中点警报旁的 菜单来查看 警报规则详情，然后点 View Alerting Rule。

流程

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. 运行以下命令来提取身份验证令牌：

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令提取 alertmanager-main API 路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.status.ingress[].host})

3. 运行以下命令，查询 Alertmanager 的服务 API 接收器：

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v2/receivers"

流程

1. 运行以下命令来检索 bearer 令牌：

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令来获取 Prometheus 联邦路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath={.status.ingress[].host})

3. 查询 /federate 路由的指标。以下示例命令 查询指标 ：

   $ curl -G -k -H "Authorization: Bearer $TOKEN" https://$HOST/federate --data-urlencode 'match[]=up'

   输出示例

   # 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. 运行以下命令，提取身份验证令牌以连接到 Prometheus：

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令，提取 thanos-querier API 路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.status.ingress[].host})

3. 使用以下命令，将命名空间设置为运行服务的命名空间：

   $ NAMESPACE=ns1

4. 运行以下命令，在命令行中查询您自己的服务的指标：

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}"

   输出显示 Prometheus 提取的每个应用程序 pod 的状态：

   格式的示例输出

   {
     "status": "success",
     "data": {
       "resultType": "vector",
       "result": [
         {
           "metric": {
             "__name__": "up",
             "endpoint": "web",
             "instance": "10.129.0.46:8080",
             "job": "prometheus-example-app",
             "namespace": "ns1",
             "pod": "prometheus-example-app-68d47c4fb6-jztp2",
             "service": "prometheus-example-app"
           },
           "value": [
             1591881154.748,
             "1"
           ]
         }
       ],
     }
   }

   注意
   • 格式的示例输出使用过滤工具（如 jq ）来提供格式化的缩进 JSON。有关使用 jq 的更多信息，请参阅 jq Manual ( jq 文档)。
   • 命令请求 Thanos Querier 服务的即时查询端点，它会一次评估选择器。

流程

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, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))

   • 通过运行以下查询，您可以通过识别在上一小时内创建了最多时间序列数据的十个作业，从而找出相关的时间序列：

     topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))

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

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

4. 以 dedicated-admin 身份登录时，按照以下步骤使用 Prometheus HTTP API 查看 TSDB 状态：

   1. 运行以下命令来获取 Prometheus API 路由 URL：

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.status.ingress[].host})

   2. 运行以下命令来提取身份验证令牌：

      $ TOKEN=$(oc whoami -t)

   3. 运行以下命令，查询 Prometheus 的 TSDB 状态：

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      输出示例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...

流程

1. 运行以下命令，列出所有 TSDB 块的大小，从最旧的到最新排序：

   $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
   -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
   -- sh -c 'cd /prometheus/;du -hs $(ls -dt */ | grep -Eo "[0-9|A-Z]{26}")'

   1 2

   将 <prometheus_k8s_pod_name> 替换为 KubePersistentVolumeFillingUp 警报描述中提到的 pod。

   输出示例

   308M    01HVKMPKQWZYWS8WVDAYQHNMW6
   52M     01HVK64DTDA81799TBR9QDECEZ
   102M    01HVK64DS7TRZRWF2756KHST5X
   140M    01HVJS59K11FBVAPVY57K88Z11
   90M     01HVH2A5Z58SKT810EM6B9AT50
   152M    01HV8ZDVQMX41MKCN84S32RRZ1
   354M    01HV6Q2N26BK63G4RYTST71FBF
   156M    01HV664H9J9Z1FTZD73RD1563E
   216M    01HTHXB60A7F239HN7S2TENPNS
   104M    01HTHMGRXGS0WXA3WATRXHR36B

2. 确定可以删除哪些块以及多少块，然后删除块。以下示例命令从 prometheus-k8s-0 pod 中删除三个最旧的 Prometheus TSDB 块：

   $ oc debug prometheus-k8s-0 -n openshift-monitoring \
   -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
   -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
   while read BLOCK; do rm -r /prometheus/$BLOCK; done'

3. 运行以下命令，验证挂载的 PV 的使用并确保有足够的可用空间：

   $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
   --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/

   1 2

   将 <prometheus_k8s_pod_name> 替换为 KubePersistentVolumeFillingUp 警报描述中提到的 pod。

   以下示例显示了由 prometheus-k8s-0 pod 声明的挂载的 PV，该 pod 剩余 63%：

   输出示例

   Starting pod/prometheus-k8s-0-debug-j82w4 ...
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
   
   Removing debug pod ...