360容器平台基于容器平台基于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 容器平台监控系统架构图如下: