可观测性问题排查

本文档提供了问题排查过程和预定义系统提醒的参考说明，可帮助您识别部署失败问题，并解决 Google Distributed Cloud (GDC) 网闸隔离设备中日志记录和监控组件的运维突发事件。您可以使用这些过程和提醒定义来验证日志记录和监控堆栈是否正在运行、检查流水线配置以及排查组件问题。

识别可观测性组件

可观测性平台会将其组件部署到组织基础设施集群中的 obs-system 命名空间。

基础设施运营商 (IO) 的 Grafana 实例提供对组织级指标的访问权限，以便监控 CPU 利用率和存储空间消耗等基础设施组件。它还提供对操作日志和审核日志的访问权限。此外，它还提供对 GDC 可操作组件的提醒、日志和指标的访问权限。

GDC 监控和日志记录堆栈使用开源解决方案作为可观测性平台的一部分。这些组件会从 Kubernetes Pod、裸机、网络交换机、存储空间和托管式服务中收集日志和指标。

下表介绍了集成可观测性平台的所有组件：

组件 说明
Prometheus Prometheus 是一个时序数据库，用于收集和存储指标以及评估提醒。Prometheus 会将指标存储在组织基础设施集群的 Cortex 实例中，以便长期存储。Prometheus 会以键值对的形式添加标签，并从 Kubernetes 节点、Pod、裸机、网络交换机和存储设备收集指标。
Alertmanager Alertmanager 是一个用户定义的管理器系统，当日志或指标指示系统组件发生故障或无法正常运行时，该系统会发送提醒。它负责管理 Prometheus 提醒的路由、静音和汇总。
Loki Loki 是一个时序数据库，用于存储和汇总来自各种来源的日志。它会为日志编制索引，以便高效查询。
Grafana Grafana 提供了一个界面，用于查看 Prometheus 收集的指标，以及查询相应 Loki 实例中的审核日志和操作日志。该界面可让您直观呈现指标和提醒的信息中心。
Fluent Bit Fluent Bit 是一种处理器，可从各种组件或位置拉取日志，并将其发送到 Loki。它在所有集群的每个节点上运行。

识别部署失败

如果您的部署正在运行且运行状况良好，则组件会以 READY 状态运行。

请按照以下步骤找出部署失败的原因：

  1. 确认组件的当前状态：

    kubectl get -n obs-system TYPE/COMPONENT

    替换以下内容：

    • TYPE：组件类型
    • COMPONENT：组件名称

    您将看到类似于以下内容的输出：

    NAME       READY  AGE
COMPONENT  1/1    23h

    如果组件运行状况良好，则输出的 READY 列会显示 N/N 作为值。如果 READY 列未显示值，并不一定表示失败。该服务可能需要更多时间来处理。

  2. 检查每个组件中的 Pod：

    kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'

    将 COMPONENT 替换为组件名称。

    您将看到类似于以下内容的输出：

    NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h

    验证 READY 列是否显示 N/N 作为值，STATUS 列是否显示 Running 值，以及 RESTARTS 的数量是否不超过 2。

    重启次数过多表示存在以下问题：

    • Pod 发生故障，Kubernetes 会重启它们。
    • STATUS 列会显示 CrashLoopBackoff 值。

    如需解决失败状态，请查看 Pod 的日志。

    如果 Pod 处于 PENDING 状态，则表示存在以下一种或多种症状：

    • Pod 正在等待网络访问权限，以便下载必要的容器。
    • 配置问题导致 Pod 无法启动。例如，缺少 Pod 所需的 Secret 值。
    • 您的 Kubernetes 集群已耗尽资源，无法调度 Pod。如果集群上运行了许多应用，就会发生这种情况。

  3. 确定 PENDING 状态的原因：

    kubectl describe -n obs-system pod/POD_NAME

    将 POD_NAME 替换为显示 PENDING 状态的 Pod 的名称。

    输出会显示有关 Pod 的更多详细信息。

  4. 前往输出的 Events 部分，查看列出 Pod 近期事件的表格，以及 PENDING 状态原因的摘要。

    以下输出显示了 Grafana StatefulSet 对象的 Events 部分示例：

    Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

    如果您的 Pod 或任何其他资源在很长一段时间内没有任何事件，您会收到以下输出：

      Events:         <none>

检查可观测性日志记录堆栈是否正在运行

请按照以下步骤验证日志记录堆栈是否正在运行：

  1. 验证所有 Loki 实例或 Pod 是否都已注入 Istio Sidecar。验证名为 anthos-audit-logs-forwarder-SUFFIX 和 anthos-log-forwarder-SUFFIX 的所有 Fluent Bit Pod 是否都已注入 Istio Sidecar。

  2. 检查所有 Loki 实例是否在组织基础架构集群中正常运行，未出现错误。

  3. 检查 anthos-audit-logs-forwarder 和 anthos-log-forwarder DaemonSet 对象的状态，以验证所有实例是否都在所有节点中运行且没有错误。

  4. 验证您是否获得了所有集群中过去五分钟内来自 kube-apiserver-SUFFIX 容器的操作日志和来自 Kubernetes API 服务器的审核日志。为此，请在 Grafana 实例中运行以下查询：

    • 操作日志：sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
    • 审核日志：sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

    您必须为组织基础架构集群中的所有控制平面节点获取非零值。

检查可观测性监控堆栈是否正在运行

请按照以下步骤验证监控堆栈是否正在运行：

  1. 检查 Grafana 实例是否在组织基础设施集群中运行。grafana-0 pod 必须在以下命名空间中运行，且不出现错误：

    • obs-system
    • infra-obs-obs-system
    • platform-obs-obs-system

  2. 确保所有监控组件都位于 Istio 服务网格中。按照识别部署失败部分中的步骤操作。以下每个 Pod 都必须在 READY 列中显示所有容器均已就绪。例如，值为 3/3 表示三个容器中有三个已就绪。此外，Pod 必须具有 istio-proxy 容器。如果 Pod 不符合这些条件，请重启 Pod：

    Pod 名称 就绪的容器数量
    cortex- 2/2
    cortex-etcd-0 2/2
    cortex-proxy-server- 2/2
    cortex-tenant- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server- 2/2
    meta-prometheus-0 4/4
    cortex-alertmanager- 2/2
    cortex-compactor- 2/2
    cortex-distributor- 2/2
    cortex-etcd-0 2/2
    cortex-ingester- 2/2
    cortex-querier- 2/2
    cortex-query-frontend- 2/2
    cortex-query-scheduler- 2/2
    cortex-ruler- 2/2
    cortex-store-gateway- 2/2
    cortex-tenant- 2/2
    grafana-proxy-server- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server-* 2/2
    meta-prometheus-0 4/4

  3. 确保 Cortex 运行正常，没有错误。

检索可观测性日志

下表包含您必须运行的命令，以便检索可观测性平台部署的每个组件的日志。

组件 日志检索命令
grafana kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator kubectl logs -n obs-system deployment/logmon-operator

如需查看组件上一个实例的日志，请在每个命令的末尾添加 -p 标志。添加 -p 标志后，您可以查看之前失败的实例（而不是当前正在运行的实例）的日志。

查看配置

可观测性堆栈使用 Kubernetes API 自定义资源来配置监控和日志记录流水线。

LoggingPipeline 自定义资源部署在组织基础设施集群中，用于配置 Loki 实例。

以下命令显示了您可以对日志记录流水线执行的操作：

  • 查看日志记录流水线部署的当前配置：

    kubectl get loggingpipeline -n obs-system default -o yaml

  • 更改日志记录流水线部署的配置：

    kubectl edit loggingpipeline -n obs-system default

GDC 使用名为 logmon-operator 的日志记录和监控 Operator 来管理 Prometheus 和 Fluent Bit 等可观测性组件的部署。logmon-operator 组件的 API 是 logmon 自定义资源定义。logmon 自定义资源定义会指示 logmon-operator 如何为您的部署配置可观测性。此自定义资源定义包括用于存储指标的卷属性、Alertmanager 的提醒规则、用于收集指标的 Prometheus 配置以及用于信息中心的 Grafana 配置。

以下命令显示了您可以对 logmon 自定义资源定义执行的可用操作：

  • 查看 Observability 部署的当前配置：

    kubectl get logmon -n obs-system logmon-default -o yaml

  • 更改可观测性部署的配置：

    kubectl edit logmon -n obs-system logmon-default

运行任一命令的输出都可能会引用多个 Kubernetes ConfigMap 对象，以进行进一步配置。例如，您可以在单独的 ConfigMap 对象中配置 Alertmanager 规则，该对象在 logmon 自定义资源定义中按名称引用。您可以通过名为 gpc-alertmanager-config 的 logmon 自定义资源定义来更改和查看 Alertmanager 配置。

如需查看 Alertmanager 配置，请运行以下命令：

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

常见问题

本部分包含您在部署可观测性平台时可能会遇到的常见问题。

您无法访问 Grafana

默认情况下，Grafana 不会向 Kubernetes 集群外部的机器公开。如需从组织基础架构集群外部临时访问 Grafana 界面，您可以将 Service 端口转发到 localhost。如需对 Service 进行端口转发，请运行以下命令：

kubectl port-forward -n gpc-system service/grafana 33000\:3000

在网络浏览器中，前往 http://localhost:33000 以查看部署的 Grafana 信息中心。如需结束该过程，请按 Control+C 键。

Grafana 运行缓慢

Grafana 运行缓慢表示：

  • 对 Prometheus 或 Loki 的查询返回的数据过多。
  • 查询返回的数据量超出了在单个图表上合理显示的数据量。

如需解决 Grafana 中的速度缓慢问题，请检查自定义 Grafana 信息中心上的查询。如果查询返回的数据量超出了单个图表上合理显示的数据量，请考虑减少显示的数据量，以提高信息中心性能。

Grafana 信息中心未显示任何指标或日志

Grafana 未显示任何指标或日志可能是由以下原因造成的：

  • Grafana 数据源设置不正确。
  • 系统与监控或日志记录数据源存在连接性问题。
  • 系统未在收集指标或日志。

如需查看日志和指标，请按以下步骤操作：

  1. 在 Grafana 界面中，点击 信息中心设置。
  2. 选择数据源。
  3. 在数据源页面上，确保您看到以下数据源：
名称 组织 网址
Audit Logs All http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs Root http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs Org http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus http://anthos-prometheus-k8s.obs-system.svc:9090

缺少这些数据源表示可观测性堆栈未能正确配置 Grafana。

如果您正确配置了数据源，但未显示任何数据，则可能表示收集指标或日志以馈送到 Prometheus 或 Loki 的 Service 对象存在问题。

Prometheus 收集指标时，会遵循拉取模型，定期查询 Service 对象以获取指标并存储找到的值。为了让 Prometheus 发现您的 Service 对象以进行指标收集，必须满足以下条件：

  • Service 对象的所有 Pod 都会带有 'monitoring.gke.io/scrape: "true"' 注解。

  • Prometheus 指标格式通过 HTTP 公开 Pod 指标。默认情况下，Prometheus 会在端点 http://POD_NAME:80/metrics 查找这些指标。如果需要，您可以通过注解替换端口、端点和架构。

Fluent Bit 负责收集日志，旨在运行于 Kubernetes 集群的每个节点上。Fluent Bit 会将日志发送到 Loki 进行长期存储。

如果 Grafana 中没有日志，请尝试以下解决方法：

  • 检查 Loki 实例的日志，确保其运行正常，未出现错误。

  • 如果 Loki 实例运行正常，但日志未显示，请检查 Fluent Bit 中的日志，确保服务按预期运行。如需了解如何提取日志，请参阅检索可观测性日志。

Alertmanager 未打开提醒

如果 Alertmanager 无法打开提醒，请按照以下步骤操作：

  1. 在 gpc-system 命名空间内的 configMap 对象中，确保存在标签 logmon: system_metrics。
  2. 验证 configMap 数据部分是否包含名为 alertmanager.yml 的密钥。alertmanager.yml 键的值必须是有效的 Alertmanager 配置文件中包含的提醒规则。

  3. 确保 gpc-system 命名空间中名为 logmon-default 的 logmon 自定义资源定义包含对 configMap 对象的引用。logmon-default 自定义资源定义必须包含 configMap 对象的名称，如以下示例所示：

    apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config

    示例中的 alerts-config 值是 configMap 对象的名称。

Alertmanager 未向配置的通知渠道发送提醒

即使 Alertmanager 在 Grafana 实例中生成了提醒，配置错误也可能会导致您无法在配置为通知渠道的外部软件（例如 Slack）中收到通知。

如需在外部软件中接收提醒，请按以下步骤操作：

  1. 检查 Alertmanager 配置文件中的值是否格式正确。当 Alertmanager 触发提醒时，它会查询外部软件上的网络钩子。

  2. 确保连接到外部软件的网络钩子网址正确无误。 如果网址正确，请确保软件已配置为接受网络钩子。 您可能需要生成 API 密钥才能访问外部服务 API，或者您当前的 API 密钥可能已过期，您需要刷新该密钥。

  3. 如果外部服务位于 GDC 网闸隔离配置之外，请确保您的组织基础设施集群已配置出站流量规则。此配置允许 Alertmanager 向内部 Kubernetes 网络外部的服务发送请求。如果未能验证出站流量规则，可能会导致 Alertmanager 无法找到外部软件。

您无法查看项目级工作负载的指标

请按照以下步骤应用解决方法并从工作负载中获取指标：

  1. 确保 MonitoringTarget 自定义资源的状态为 Ready。
  2. 如需抓取工作负载，您必须在工作负载 Pod 规范中声明为 MonitoringTarget 指定的所有目标信息。例如，如果您声明指标在端口 8080 上可用，则工作负载 Pod 必须向 Kubernetes 声明端口 8080 已打开。否则，Prometheus 会忽略该工作负载。
  3. Prometheus 运行多个分片，这意味着并非所有 Prometheus Pod 都会抓取您的 Pod。您可以在每个 Prometheus pod 的名称中找到分片编号。例如，primary-prometheus-shard0-replica0-0 是分片 0 的一部分。检查要从每个 Prometheus 分片中爬取的 Pod：
    1. 对 obs-system 命名空间中 Prometheus 的 primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod 进行端口转发，以访问 Prometheus 界面。每次检查新分片时，将 Pod 名称中的 SHARD_NUMBER 替换为递增的数字。
    2. 在网络浏览器中前往 Prometheus 界面，然后按照以下步骤操作：
      1. 依次点击 Status（状态）> Targets（目标）。
      2. 确保您要抓取的 Pod 位于列表中。如果不是，请检查下一个分片。如果没有更多分片需要检查，请重新验证 Prometheus 是否有足够的信息来发现它。
    3. 验证 Prometheus 的 primary-prometheus-shardSHARD_NUMBER-replica0-0 pod 是否在 obs-system 命名空间中记录了错误。
  4. 验证 obs-system 命名空间中的 cortex-tenant pod 日志错误。

未创建信息中心

请按照以下步骤应用解决方法，并找出未创建信息中心的原因：

  1. 查看 Dashboard 自定义资源的状态，检查是否存在任何错误。自定义资源必须具有 Ready 状态。
  2. 确保您检查的是正确的 Grafana 实例。例如，如果您在名为 my-namespace 的项目命名空间中部署了信息中心，则该信息中心必须位于 https://GDCH_URL/my-namespace/grafana 端点的 Grafana 实例中。
  3. 检查 gpc-system 命名空间中 fleet-admin-controller 的日志。在日志中搜索信息中心名称，查找与该信息中心相关的任何错误。如果您发现错误，则说明 configMap 对象中的 JSON 文件格式不正确，您必须更正该文件。
  4. 检查 PROJECT_NAME-obs-system 命名空间中的 Grafana 日志，查看是否存在任何错误。信息中心会查询 Grafana REST API，因此 Grafana 必须正常运行才能创建信息中心。

您的提醒无法打开

请按照以下步骤应用解决方法，并找出提醒无法打开的原因：

  1. 确保 Cortex 和 Loki 均处于存储桶存储模式。除非后端由存储桶存储空间提供支持，否则规则不起作用。
  2. 验证 MonitoringRule 和 LoggingRule 自定义资源的状态是否为 Ready。
  3. 检查以下提醒发出条件：
    • PromQL 和 LogQL 表达式：将您使用的所有函数与创建提醒规则文档进行比较，确保您的规则已按预期配置。确保表达式返回 true 或 false 值。
    • 时长：自定义资源的 for 字段定义了条件必须满足的时长。interval 字段定义了评估条件的频率。请检查这些字段的值是否相互冲突，并确保您的条件符合逻辑。
  4. 使用 Alerts 页面查看 Grafana 界面，了解提醒是否已打开。
  5. 如果 Grafana 显示提醒处于打开状态，请检查您的通知渠道，并确保 Alertmanager 可以联系这些渠道以生成提醒。

预期的日志不可用

如果您没有看到组件的操作日志，请执行以下步骤：

  1. 检查组件是否正在运行并生成日志。
  2. 检查是否应将组件日志作为内置功能进行收集。如果没有，请确保您已部署具有有效规范和 Ready 状态的 LoggingTarget 自定义资源。

如果您没有看到组件的审核日志，请执行以下步骤：

  1. 如果您的组件将日志写入文件，请确保该文件确实存在于节点的文件系统中，路径为 /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log。
  2. 验证同一节点上的 anthos-audit-logs-forwarder-SUFFIX pod 没有错误。
  3. 如果您的组件使用 syslog 端点接收日志，请确保您已部署具有有效规范和 Ready 状态的 AuditLoggingTarget 自定义资源。

识别预定义的提醒规则

本部分介绍了可观测性组件中存在的预定义提醒规则，这些规则会在系统发生故障时通知您。

Loki 中的预定义提醒规则

下表提供了 Loki 中针对审核日志记录失败的预安装提醒规则：

Loki 中预安装的审核日志记录失败提醒规则
名称 类型 说明
FluentBitAuditLoggingWriteFailure 严重 Fluent Bit 在过去 5 分钟内未能转发审核日志。
LokiAuditLoggingWriteFailure 严重 Loki 未能将审核日志写入后端存储。

如果显示其中一个或多个提醒，则表示系统至少丢失了一条审核记录。

Prometheus 中的预定义提醒规则

下表提供了 Prometheus 中针对 Kubernetes 组件预安装的提醒规则：

Prometheus 中预安装的提醒规则
名称 类型 说明
KubeAPIDown 严重 Kube API 已从 Prometheus 目标发现中消失 15 分钟。
KubeClientErrors 警告 Kubernetes API 服务器客户端的错误率已连续 15 分钟大于 0.01。
KubeClientErrors 严重 Kubernetes API 服务器客户端的错误率已连续 15 分钟大于 0.1。
KubePodCrashLooping 警告 Pod 处于崩溃循环状态的时间超过 15 分钟。
KubePodNotReady 警告 Pod 处于未就绪状态的时间超过 15 分钟。
KubePersistentVolumeFillingUp 严重 声明的 PersistentVolume 对象的可用字节数小于 0.03。
KubePersistentVolumeFillingUp 警告 声明的 PersistentVolume 对象的可用字节数小于 0.15。
KubePersistentVolumeErrors 严重 永久性卷已处于 Failed 或 Pending 阶段 5 分钟。
KubeNodeNotReady 警告 节点处于尚未就绪状态超过 15 分钟。
KubeNodeCPUUsageHigh 严重 节点的 CPU 使用率大于 80%。
KubeNodeMemoryUsageHigh 严重 节点的内存用量超过 80%。
NodeFilesystemSpaceFillingUp 警告 节点的文件系统用量大于 60%。
NodeFilesystemSpaceFillingUp 严重 节点的文件系统用量超过 85%。
CertManagerCertExpirySoon 警告 证书将于 21 天后过期。
CertManagerCertNotReady 严重 证书在 10 分钟后仍未准备好处理流量。
CertManagerHittingRateLimits 严重 您在创建或续订证书时达到了速率限制，请等待 5 分钟。
DeploymentNotReady 严重 组织基础架构集群上的 Deployment 处于尚未就绪状态超过 15 分钟。
StatefulSetNotReady 严重 组织基础架构集群上的 StatefulSet 对象处于非就绪状态的时间已超过 15 分钟。
AuditLogsForwarderDown 严重 anthos-audit-logs-forwarder DaemonSet 已停机超过 15 分钟。
AuditLogsLokiDown 严重 audit-logs-loki StatefulSet 处于尚未就绪状态超过 15 分钟。