基于 Prometheus 的监控实践

背景

360 在做容器化平台之前，有一个基于小米开源的 Open-Falcon 进行二次开发的老监控系 (Wonder)，这个系统承揽了公司所有的物理机和虚拟机的监控任务。随着容器技术的普及，以容器的方式在创建应用时，由于 Kubernetes 容器编排系统部署的服务具有弹性扩容的特性，而老的监控系统无法感知这些动态创建的服务，已经不适合容器化的场景，所以 360 团队就搭建了一套可以支持服务发现的新监控系统。

目前 360 一共有 5 个 k8s 线上集群，分布在北京上海和深圳，此外还有一些 GPU 集群。

容器平台构建以后带来了以下几个方面的好处：

节省资源。传统一台物理机只能部署一个实例，虚拟机能部署几个服务，而使用容器一台机器上能部署几十个服务。

提高效率。1. 缩短流程。老系统要增加机器需要提前申请，而使用 Kubernetes 容器平台只要整个资源池里有充足的资源，不用提交预算就可以直接使用。2. 弹性扩容。在流量高峰期，容器平台可以快速扩容；在流量不多的时段，空闲的资源可以处理其他离线任务，对资源的利用率高。

高可用。容器平台可以保证运行的服务数量总是能达到预期。

减轻运维负担。之前所有的部署上线活动都是运维来做。容器平台上线后，开发人员可以直接在程序完成之后将其制作成镜像，自己就可以进行部署。

当然任何事情不可能只有好的一面，容器平台也会带来相应的难度。容器平台对服务的调度具有动态性，这就需要监控系统能动态感知服务实例落在哪里，这是监控工作中的一个难点。

360 容器平台的监控维度

360 容器平台的监控系统对业务的技术指标进行监控，产品是从三个维度进行设计的：

容器: 这是最小的粒度。

Pod: 一个 Pod 里面可以有多个容器。

应用: 一个应用里可能会有多个 Pod。

除了这些技术指标监控，360 容器平台的监控系统还支持自定义监控。有些业务可能需要在自己的程序里打点，比如要调第三方接口，查看延时和调用的次数等。大平台上不同业务对数据的需求不同，为了达到业务需求，支持自定义监控还是很必要的。新开发的业务可以在自己的程序里引入 Prometheus 相关的 SDK 进行打点，360 的容器平台就会将这些 metrics 收集上来。

另外，没有使用 Prometheus 的老系统在开发时没有在程序里打点的功能，这时业务可以针对自己的需求以 sidecar 的方式在程序的边缘写 exporter 来采集该进程所有的监控数据，exporter 以 metrics 的形式报告给 Prometheus，Prometheus 进行抓取。

监控系统设计

360 容器平台监控系统架构图如下：

日志监控

360 容器平台监控系统的日志监控使用的是 ELK 技术栈，但是进行了二次开发。团队自己写了 Log controller 组件，该组件会实时地 watch Kubernetes API Server 的 Deployment 资源对象的状态变化。当业务在创建应用时，是以 Kubernetes deployment 的资源对象来创建的。Log controller 会感知到这个资源的创建，知道这个 deployment 下有多少 Pod 已经处于 Ready 状态。当 Log controller 感知到新创建的 Pod 已经处于 Ready 状态以后，会根据用户在创建 Pod 时指定的真实日志收集路径拼接成它在物理机上的绝对路径，然后将组装好的配置并推送到 360 自研的配置中心 QConf 中。

360 在 Kubernetes 集群的每个 Node 节点都会部署一个二次开发的 Logstash，该 Logstash 会定期（每隔十秒或者五秒，时间可配置）去配置中心 (Qconf) 拉取最新的配置。拉取完配置之后，Logstash 会根据最新的配置把相关的的日志收集到公司的 Qbus（对 Kafka 进行包装的产品）中，也就是数据已经进入到 Kafka 了。之后用户可以在 HULK 私有云平台 (内部的私有云平台) 开通 ES 服务，对日志进行检索分析或对其他日志指定数据进行监控。

数据面板

360 容器平台监控系统的数据面板使用的是 Grafana，并对其增加了 LDAP 用户认证。可以显示内存，访问量，SIO, GPU 等监控数据指标。

应用级别基础监控指标:

Pod 级别基础监控指标:

容器级别基础监控指标:

Prometheus 的基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口就可以接入监控。不需要任何 SDK 或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如 VM、 Docker 、Kubernetes 等。输出被监控组件信息的 HTTP 接口被叫做 exporter 。目前常用的组件大部分都有 exporter 可以直接使用，比如 HAproxy、Nginx、 MySQL 、 Linux 系统信息 (包括磁盘、内存、CPU、网络等等)。

报警

报警系统使用的是 Prometheus 自带的 Alertmanager 组件，但是对其进行二次开发，集成了 360 自己的报警系统 (Qalram)，并且可以通过 360 自己的即时通信工具（蓝信）实时接收报警信息，友好方便快捷。

360 容器平台监控系统选型对比

在构建容器平台的过程中，360 团队对监控系统的几种常用的开源方案进行过选型对比，主要调研了 K8s 社区的 Heapster（K8s 安装过程中默认安装的插件）和 Prometheus。

Heapster+InlfuxDB+Heapster 自带报警系统的方案有个缺点：它是针对 K8s 容器级别以及 Code 级别的技术指标监控，无法实现业务系统数据的监控，可扩展性不太友好，并且当未来数量级大时，不方便扩容。

最后团队选择了 Prometheus 云原生监控方案。虽然 Prometheus 在持久化方面做的还不够好，但是 Prometheus 更适合云原生生态。因为容器是动态变化的，微服务架构下一个实例的多个副本也是动态变化的，Prometheus 的 Pull 方式更适合动态变化的场景。

Prometheus 的应用实践

高可用

现在由于每个机房的机器数量不算太多，当前的设计方式是在每个机房部署一套 Prometheus 实例用于抓取目标的监控数据，同时在每个机房的上一层会部署两套 Prometheus 来做高可用 (HA). 这样上层的 Prometheus 只要去下层抓取关心的 metrics 就可以。这样做的好处:

过滤掉上层不关心的监控数据，减轻数据存储的压力。

对各个机房的数据进行聚合，并统一对外提供统一的报警，视图查询接口。

由于 promethues 实例运行在本地，本地的磁盘空间有限，默认只保留最近 15 天的监控数据，但是想查询最近一个月，或者半年的数据，这个需求是做不到的。所以将 prometheus 的数据又入到了远程存储 InfluxDB 一份，用于数据的查询使用。

报警

Prometheus 的报警基于配置文件形式的。这种情况下，基础性指标可以产品化。360 团队定制了配置模版，用户只需要填具体的监控值就可以了。

针对业务监控，用户需要学习 Prometheus 的 promQL，这是由于不同的业务监控的需求不同，没有办法给业务统一的产品化服务，只能按业务自己制定报警规则去下发报警。

对于自定义业务，让业务自己写告警，统一的配置文件会上报到 QConf。

运行在两台 Prometheus 机器上 Agent 会实时的 watch 配置中心 (Qconf) 是否有新的配置生成，如果存在则会 Pull 报警规则，并 reload Prometheus 实例。

为什么要使用开源系统

一般公司都有自研的监控系统，大多数监控系统都是基于开源项目开发的。为什么 360 要使用 Prometheus？

在 K8s 大规模使用的今天，整个容器云的生态推荐使用 Prometheus。

节省人力成本。公司开发一套监控系统需要投入人力，如果后期开发人员流失，后期的维护是个大问题。但是使用开源监控系统，在社区活跃的情况下项目也有保证，并且我们也会在使用过程中回馈社区。

360 容器平台监控系统演进方向

目前的监控系统整体架构对于容器平台来说可扩展性比较好。未来随着集群规模不断扩大，单个集群只有一个 Prometheus 实例要处理的 Job 数量爆发时，Prometheus 的性能就会变差。这个时候可以针对不同的任务类型，在一个集群里部署多个 Prometheus，每一个 Prometheus 只关心自己的任务，可控性会大大提升，同时整个架构的横向扩展比较方便。

另外 Prometheus 存在持久化的问题，未来还需要对 Prometheus 进行数据远程存储（在上面的架构图中使用的虚线标注部分）。

除了数据，360 也在探索 AIOps，可以对监控系统收集到的数据进行处理，探索故障定位和根因分析等。

普通团队如何构建监控系统？

360 监控团队认为，公司的监控系统要根据公司的规模和业务场景来定，不可能一套方案直接拿来就直接使用。

对于使用公有云并且规模较小的公司，公有云本身就有监控系统。如果公司自己有服务器，但是量不大，简单搭建一个小型 HA 的监控系统就完全可以满足监控的需求了。架构的演变是随着业务规模的增长而不断的演变改进的。这时就需要根据具体的情况，去选择适合自己平台的架构方案。