vivo 容器集群监控系统优化之道

随着vivo业务迁移到容器平台，vivo云原生监控体系面临着指标量快速上涨带来的一系列挑战，本文将分享vivo 容器化项目中容器监控遇到的问题以及我们的解决和优化方法。

首先对vivo容器监控架构进行一个简单的介绍。

原生Prometheus没有提供高可用的标准方案，我们通过自研 Adapter “分组选举”方式实现去重，即每个 Prometheus 副本对应一组 Adapter，两组 Adapter 之间会进行选主，只有Leader组的 Adapter才会转发数据。通过这种方式既实现了去重，也实现了Prometheus双副本高可用。

过去几年来，vivo容器化服务快速增长，监控流量上涨数倍，我们主要遇到如下三个问题：监控组件负载快速升高、容器监控数据断点和数据存储组件负载陡增。

3.1 监控组件负载快速升高

容器化每次部署IP都会变化的特性，导致容器监控指标量相比物理机和虚拟机要高出好几个数量级。同时由于集群规模的不断增加以及业务的快速增长，导致监控 Prometheus、VictoriaMetrics 负载快速增高，给我们容器监控带来极大的挑战。监控总时间序列可以精简为以下的表达式，即与 Pod数量、Pod指标量、指标Label维度数量呈线性关系：

而随着集群规模的不断增加以及容器数量的不断增多，监控序列就会快速增长，同时监控组件负载快速升高，会对容器监控系统的稳定性产生影响。

3.2 监控丢点现象

vivo容器层面（业务）的监控数据则通过自研Adapter转发给Kafka，进而存储到公司基础监控做业务监控展示和告警配置，同时也存储一份到Druid做更多维度的统计报表。我们在推送监控数据的时候发现，Pod维度的指标难以保证发送频率，即配置指标采集频率为 10s，但是在推送的数据中频率无法做到10s，且会有波动。下图为 采集频率设置 10s，查询1分钟的指标数据。

一分钟内某一容器的

container_cpu_user_seconds_total 指标的值：

可以看到只取到了4个值，与期望的 6个值不相符，即发生了“掉点”的情况，监控面板按指定频率展示数据会有频繁掉0现象。

3.3 数据存储组件负载陡增

vivo容器监控使用 VictoriaMetrics的v1.59.1-cluster版本做为后端时序数据库来持久化存储监控数据。在使用过程中发现 VictoriaMetrics的负载有不定期增高的情况，而后端数据库的延迟会导致监控查询告警功能的异常影响用户体验。

4.1 监控组件负载快速升高

我们使用 Prometheus-Operator 管理 Prometheus，因为优化方案中有 Prometheus-Operator 相关的名词，故为了下面的理解，先对 Prometheus-Operator 做一个介绍：

（图片来源：官方架构图）

上图是Prometheus-Operator官方提供的架构图，下面来介绍下图中各组件:

我们重点关注 ServiceMonitor，因为ServiceMonitor为我们提供了指定 target 采集的配置，例如采集频率，target内指标过滤，指标中label重命名等等操作。

对于监控组件负载快速升高问题的解决，我们主要从两个方面着手，分别是指标治理以及性能优化。

4.1.1 指标治理

 # 过滤  container_threads  开头的指标    - action: drop      regex: container_threads(.*)      sourceLabels:      - __name__

完成指标精简后，监控单次采集样本量从 1000万降低到 250万。Prometheus 的CPU 使用量降低 70% ，内存 使用量降低 55%。

# 名称为cadvisor的 daemonset 提供的 podcadvisor-xxxx1                                    1/1     Running            cadvisor-xxxx2                                    1/1     Running

且 cAdvisor 提供的指标中包含了 namespace 和 pod 的 label。

container_memory_cache{container="POD", namespace="monitoring", pod="kube-state-metrics-xxxx-xxxx", service="cadvisor"}

所以我们通过在 ServiceMonitor 上面组合指标的 pod 和 namespace，并与指定的规则进行匹配丢弃掉我们不需要的 daemonset pod 的序列。

# 过滤掉 monitoring namespace 下面 telegraf 这个daemosnet提供的 pod 的相关指标    - action: drop      regex: monitoring@telegraf(.*)      separator: '@'      sourceLabels:      - namespace      - pod

在对集群中部分ds Pod 的指标进行过滤后。

对 cAdvisor 的单次采集数据量下降 70%。效果十分明显。

将监控 target 进行分类交由不同的组 Prometheus 采集，且每类 Prometheus 为双副本模式。随着集群规模的增加，发现当前模式的不合理之处，即因为Pod维度监控数据量级十分高，导致container 类型 Prometheus 负载远远高于其他类型的 Prometheus。在高负载的情况下面会发生重启，remote_write 异常等情况。

我们 Prometheus组件架构为按类型采集监控指标。其中 Container类型的 Prometheus采集的指标数量远远大于 Component、Host、Resource类型。故需要手动平衡 集群中 Prometheus的负载 将集群的 container类型 Prometheus上面kubelet 和 kube-state-metrics 转移到 resource-Prometheus 上面 降低 container-Prometheus负载。（与此同时resource-Prometheus也会发送到 kafka-adapter）。且在负载低的Prometheus上 监控跳转面板用到的监控指标（核心指标）进行重复采集，尽可能防止数据丢失。降低了container-Prometheus 40%的负，极大的减少了Prometheus异常情况的发生。

4.2 监控丢点现象

4.2.1 问题定位

最初我们认为是 Prometheus 在remote_write 的过程中发生了丢点的情况，但是通过在社区查询和配置问题Prometheus 远程写相关的监控指标发现Prometheus并没有在远程写的时候丢弃数据，且发现在推送数据的过程中只有kubelet 内置的 cAdvisor提供的数据有"丢点"的情况。 故我们开始研究指标提供端组件 cAdvisor，发现cAdvisor”丢点”问题的原因在于 cAdvisor 组件有自己的刷新频率 和 时间戳。cAdvisor 会去 cgroup 中读取数据并存储到内存中供外部使用。Kubelet的cAdvisor 的刷新数据频率达不到 10s，并且会根据刷新时间放到指标中。 而 Prometheus 按 10s 采集频率去采集数据时，底层的 cAdvisor 如果还没有去刷新数据，内存中则还是上次的数据。而cAdvisor 在0.31版本及之后的版本中添加了时间戳支持，即 cadvisor 提供的数据会带上自己的时间戳。当 Prometheus 去采集 cadviosr数据时会以 cAdvisor提供的时间戳为准。故当 Prometheus 按照ServiceMonitor 设置的采集频率10s去采集cAdvisor 提供的数据时，如果在此期间 cAdvisor 没有进行数据更新，则Prometheus会采集到与上次采集时间戳和值相同的情况，Prometheus 就只会记录一条数据。这就是cAdvisor “丢点”的本质。cAdvisor的刷新频率由 housekeeping相关参数 和 抖动 机制确定。

kubelet 内置 cAdvisor设置的参数：

// Kubelet 内置 cadvisor 默认参数  // cadvisor housekeeping 的间隔，刷新数据的间隔const defaultHousekeepingInterval = 10 * time.Second       // cadvisor 是否开启动态 housekeepingconst allowDynamicHousekeeping = true                         /*cadvisor housekeeping 的最大间隔，allow_dynamic_housekeeping=true的时候, 会判断容器活跃程度动态的调整 HousekeepingInterval， 当发现一段时间为容器状态为发生改变会将 housekeeping 的间隔 设置为maxHousekeepingInterval 。*/const maxHousekeepingInterval = 15 * time.Second

4.2.2 解决方案

1、部署 cAdvisor：主要是确定cAdvisor启动参数， 主要操作为禁用dynamic_housekeeping 和 设置 housekeeping_interval 为 1s，来保证 cAdvisor 获取数据的频率。

containers:// 参数设置  - -allow_dynamic_housekeeping=false  - -housekeeping_interval=1s

// return jitter(cd.housekeepingInterval, 1.0)func jitter(duration time.Duration, maxFactor float64) time.Duration {if maxFactor <= 0.0 {maxFactor = 1.0}wait := duration + time.Duration(rand.Float64()*maxFactor*float64(duration))return wait}

cAdvisor的 ServiceMonitor上配置忽略指标自带时间戳

spec:  endpoints:  - honorLabels: true    // 忽略时间戳    honorTimestamps: false    interval: 10s

监控面板展示数据连续，无中断现象发生。

4.3 后端数据库负载突增

4.3.1 问题定位

4.3.2 解决方案

正是由于VictoriaMetrics 这些的资源突增，导致自己负载过高，无法正常响应 Prometheus的 remote_write的数据。我们所期望的是在 indexdb merge 的时候，资源使用量的增长不会影响到正常的数据插入和查询。经过查询相关资源得到VictoriaMetrics在1.73.0版本中对indexdb的 merge进行优化,提升了整体性能。故我们对VictoriaMetrics 进行了版本升级以优化这个问题。在版本升级后，未发现 VictoriaMetrics 在indexdb merge时有资源突增的情况发生。