一、背景

为保障业务稳定和安全，同时实现业务异地容灾、容器化、跨机房调度等，公司目前已生产落地多套 k8s 集群并落地众多项目。监控是我们生产稳定的一个重要保障手段，由于底层基础架构发生了变化，支撑的应用类型和部署上线模式发生了变化，所以在监控方面也面临着许多挑战。

prometheus 作为云原生时代最流行的监控组件，已然成为了社区监控的事实标准，拥有活跃的社区和丰富的周边项目。因此我们决定采用 prometheus 开源解决方案实现容器化的监控与告警。

在已有一套基于 prometheus 开发的成熟的监控平台，在容器化之后，我们也在思考如何完成容器生态监控的层级覆盖以及如何融合进现有监控体系。

二、主要问题与解决方案

问题 1：如何保证容器集群监控系统的稳定与告警的实时性

• 采用 Prometheus Operator 解决方案，通过自定义 pod nodeAffinity，实现 prometheus 与业务资源隔离，保障其性能与稳定；

• 对于非业务类型的指标，我们 95%的查询是针对 24 小时内的数据。因此我们将容器集群内 prometheus 数据保存时间设置为 24 小时，来保障我们集群组件、pod 监控告警的实时性；

• 对于超过 24 小时的数据，我们采用 Thanos Query 实现对联邦集群的数据聚合与查询。

问题 2：接入容器后如何实现业务监控

• 通过添加 additionalScrapeConfigs 来配置 prometheus operator 额外的采集点，业务侧通过注解进行传参[参见图 1]，实现业务监控的服务发现。

图 1 业务侧通过注解进行传参即可实现业务监控数据自动化采集

问题 3：如何实现容器集群事件监控

• 目前容器事件监控大多采用 ELK 方案实现日志的采集，但此方案也有弊端，ELK 采用全文检索对日志进行索引导致资源占用率较高。因此我们选择更轻量级的 Loki 解决方案（见下图）。

图 2 事件监控流程图

• 它使用了和 Prometheus 一样的标签来作为索引，可直接对接 Alertmanager 实现告警功能，并且可直接集成 Grafana  （见下图）  ，避免了在 Kibana 和 Grafana 之间切换，影响体验。

图 3 通过 Grafana 即可对容器事件实时查询与告警

问题 4：如何实现应用在多集群部署场景下监控数据的聚合与持久化

• 通过配置 operator 的 prometheus 额外属性标签 externalLabels 来区分不同集群，供查询语句使用

• prometheus 配置 remote write 的目标地址，它会从 WAL 读取数据，然后把采样数据写入各分片的内存队列，最后发起向远程目标地址的请求，实现 prometheus 集群的联邦机制；采用 Thanos 实现 prometheus 数据聚合查询与规则管理

• 
  

• 整体架构如图所示

图 4 整体监控平台架构图

三、未来规划

目前容器监控已经在生产集群落地，具有高可用、高性能、数据持久化、采集分片等特点。未来还会持续探索：引入 eBPF 技术提升主机端的可观测性、日志转 metric 通过时序库查看该指标的变化趋势等，以确保更好地为 k8s 提供稳定可靠智能的监控服务。

未来，将在告警故障自愈、扩容预测、辅助根因分析等场景进行深度挖掘以提供有价值的信息。