在多代码库模式下监控 Config Sync

本页介绍了在使用 Config Sync 从多个代码库同步时可用于监控资源的其他方法。

启用多代码库模式时,Config Sync 使用 OpenCensus 来创建和记录指标,并使用 OpenTelemetry 将其指标导出到 PrometheusCloud Monitoring。您还可以使用 OpenTelemety 将指标导出到自定义监控系统。此过程为您提供了三种监控资源的方法:

  1. Prometheus:要使用 Prometheus,请参阅使用 Prometheus 监控 Config Sync
  2. Cloud Monitoring:如需使用 Cloud Monitoring,请参阅使用 Cloud Monitoring 监控资源部分。
  3. 自定义监控系统:如需使用自定义监控系统,请参阅配置自定义 OpenTelemetry 导出器部分。

可用指标

Config Sync 会收集以下指标并将其提供给 OpenTelemetry。标记列列出了适用于每个指标的所有标记。带有标记的指标代表多个测量结果,每个标记值组合对应一个。

名称 类型 标记 说明
api_duration_seconds 分布 reconciler、operation、type、status API 服务器调用的延迟时间分布
apply_duration_seconds 分布 reconciler、status Applier 资源同步事件的延迟时间分布
apply_operations_total 计数 reconciler、operation、type、status 已执行以便将资源同步至可靠来源的操作总数
declared_resources 最后一个值 reconciler 从 Git 解析的已声明资源数量
internal_errors_total 计数 reconciler、source Config Sync 触发的内部错误总数
last_apply_timestamp 最后一个值 reconciler、status 最新 Applier 资源同步事件的时间戳
last_sync_timestamp 最后一个值 reconciler 从 Git 最近一次同步的时间戳
parse_duration_seconds 分布 reconciler、status 解析事件的延迟分布
parse_errors_total 计数 reconciler、errorcode 解析期间发生的错误总数
parser_duration_seconds 分布 reconciler、status、trigger、source “解析-应用-监视”循环的延迟时间分布
reconcile_duration_seconds 分布 status 由协调器管理器处理的协调事件的延迟时间分布。
reconciler_errors 最后一个值 reconciler、component RootSync 和 RepoSync 协调器中的错误数
remediate_duration_seconds 分布 reconciler、type、status 补救器协调事件的延迟时间分布
resource_conflicts_total 计数 reconciler、type 因缓存资源和集群资源之间存在不匹配而导致的资源冲突总数
resource_fights_total 计数 reconciler、operation、type 过于频繁同步的资源总数。任何高于零的结果都表示有问题。如需了解详情,请参阅 KNV2005:ResourceFightWarning
watch_manager_updates_duration_seconds 分布 reconciler、status 监视管理器更新的延迟时间分布
watches 计数 reconciler、type 针对已声明资源的监视次数

使用 Cloud Monitoring 监控资源

如果 Config Sync 在具有默认服务帐号的 Google Cloud 环境中运行,则 Config Sync 会自动将指标导出到 Cloud Monitoring。

如果启用了 Worklod Identity,则您需要使用以下命令将命名空间 config-management-monitoring 中的 Kubernetes ServiceAccount default 绑定到具有指标写入者角色的 Google 服务帐号:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

替换以下内容:

  • GSA_NAME:具有指标写入者角色的 Google 服务帐号
  • PROJECT_ID:您的项目 ID

此操作需要项目的 iam.serviceAccounts.setIamPolicy 权限。

然后,使用 Google 服务帐号的电子邮件地址为 Kubernetes ServiceAccount 添加注释。

kubectl annotate serviceaccount \
  --namespace config-management-monitoring \
  default \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

如需查看关于如何查看这些指标的示例,请参阅下面的调试程序示例部分和 Cloud Monitoring 中的 OpenCensus 指标一文。

调试程序示例

以下 Cloud Monitoring 示例展示了一些模式,当您使用多代码库模式时,它们使用 OpenCensus 指标来检测和诊断与 Config Sync 相关的问题。

指标格式

在 Cloud Monitoring 中,指标采用以下格式:custom.googleapis.com/opencensus/config_sync/METRIC

此指标名称由以下各部分组成:

  • custom.googleapis.com:所有自定义指标都具有此前缀
  • opencensus:已添加此前缀,因为 Config Sync 使用 OpenCensus 库
  • config_sync/:由 Config Sync 导出到 Cloud Monitoring 的指标具有此前缀
  • METRIC:您要查询的指标的名称

按协调器查询指标

RootSync 和 RepoSync 对象可通过概要指标进行检测,有助于您全面了解 Config Sync 在集群上的运行情况。几乎所有指标都按照协调器名称进行标记,因此您可以查看是否发生了任何错误,并且可以在 Cloud Monitoring 中为其设置提醒。

协调器是部署为 Deployment 的 Pod。它会将清单从 Git 代码库同步到集群。当您创建 RootSync 对象时,Config Sync 会创建名为 root-reconciler 的协调器。 当您创建 RepoSync 对象时,Config Sync 会创建一个名为 ns-reconciler-NAMESPACE 的协调器,其中 NAMESPACE 是您在其中创建了 RepoSync 对象的命名空间。

下图展示了协调器 Pod 的工作原理:

协调器流程

例如,若要在使用 Cloud Monitoring 时按协调器名称进行过滤,请完成以下任务:

  1. 在 Google Cloud Console 中,转到 Monitoring

    转至 Resources

  2. Monitoring 导航窗格中,点击 Metrics Explorer

  3. Find resource type and metric(查找资源类型和指标)框中,添加 custom.googleapis.com/opencensus/config_sync/reconciler_errors

  4. 过滤条件下拉列表中,选择 root_reconciler。此时会显示一个过滤条件字段框。

  5. 在过滤条件字段框中,在第一个字段中选择 =,在第二个字段中选择 root-reconciler

  6. 点击应用

您现在可以查看 RootSync 对象的指标。

如需详细了解如何按特定数据类型进行过滤,请参阅过滤数据

按组件和状态查询 Config Sync 操作

在多代码库模式下,从 Git 代码库导入和搜寻以及同步至集群由协调器处理。reconciler_errors 指标按组件进行标记,因此您可以查看发生错误的位置。

例如,若要在使用 Cloud Monitoring 时按组件过滤,请完成以下任务:

  1. 在 Google Cloud Console 中,转到 Monitoring

    转至 Resources

  2. Monitoring 导航窗格中,点击 Metrics Explorer

  3. Find resource type and metric(查找资源类型和指标)框中,添加 custom.googleapis.com/opencensus/config_sync/reconciler_errors

  4. 过滤条件下拉列表中,选择组件。此时会显示一个过滤条件字段框。

  5. 在过滤条件字段中,在第一个框中选择 =,在第二个框中选择 source

  6. 点击应用

现在,您就可以查看从协调器的 Git 代码库搜寻时发生的错误了。

您还可以通过查询以下指标并按 status 标记进行过滤,自行检查来源的指标并自行同步进程:

custom.googleapis.com/opencensus/config_sync/parse_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

配置自定义 OpenTelemetry 导出器

如果要将指标发送到其他监控系统,您可以修改 OpenTelemetry 配置。如需受支持的监控系统列表,请参阅 OpenTelemetry Collector ExportersOpenTelemetry Collector-Contrib Exporters

OpenTelemetry 监控资源在单独的 config-management-monitoring 命名空间中管理。如需配置自定义 OpenTelemetry 导出器以与 Config Sync 搭配使用,您需要在该 config-management-monitoring 命名空间中创建名为 otel-collector-custom 的 ConfigMap。ConfigMap 应包含 otel-collector-config.yaml 键,并且值应该是自定义 OpenTelemetry 收集器配置的文件内容。如需详细了解配置选项,请参阅 OpenTelemetry 收集器配置文档

以下 ConfigMap 是一个具有自定义日志记录导出器的 ConfigMap 示例:

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

所有自定义配置都必须定义 opencensus 接收器和 metrics 流水线。其余字段均为可选且可配置,但我们建议您添加 batch 处理器和运行状况检查扩展程序,如示例中所示。

创建 ConfigMap 后,您可以使用 kubectl 创建资源:

kubectl apply -f otel-collector-custom-cm.yaml

OpenTelemetry Collector Deployment 选取此 ConfigMap 并自动重启以应用自定义配置。