可观测性问题排查

本文档介绍了如何识别 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 提供了一个界面 (UI)，用于查看 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. 验证您是否在所有集群中获取了过去 5 分钟内来自 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 正常运行，没有错误。

检索可观测性日志

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

组件 日志检索命令
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 的日志记录和监控运算符来管理可观测性组件（例如 Prometheus 和 Fluent Bit）的部署。logmon-operator 组件的 API 是 logmon 自定义资源定义。logmon 自定义资源定义会指示 logmon-operator 如何为您的部署配置可观测性。此自定义资源定义包含用于存储指标的卷的属性、Alertmanager 的提醒规则、用于收集指标的 Prometheus 配置，以及用于信息中心的 Grafana 配置。

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

  • 查看可观测性部署的当前配置：

    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 未将提醒发送到配置的通知渠道

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

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

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

  2. 确保连接到外部软件的 Webhook 网址正确无误。 如果网址正确，请确保软件已配置为接受 Webhook。 您可能需要生成 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. 在 Web 浏览器中前往 Prometheus 界面，然后按照以下步骤操作：
      1. 依次点击状态 > 目标。
      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 字段用于定义条件必须为 true 的时长。interval 字段用于定义评估条件的频率。相互比较这些字段的值，并确保您的条件符合逻辑。
  4. 在 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 服务器客户端的错误率已超过 0.01，持续 15 分钟。
KubeClientErrors 严重 Kubernetes API 服务器客户端的错误比率已超过 0.1，持续 15 分钟。
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 分钟。