本期文章，咱们将给大家分享有道容器服务API监控计划，这个计划同时具备轻量级和灵活性的特点，很好地体现了k8s集群化治理的劣势，解决了动态配置的监控不满足容器服务监控的需要。并做了易用性和误报消减、可视化面板等一系列优化，目前曾经超过80%的容器服务曾经接入了该监控零碎。

起源/ 有道技术团队微信公众号
作者/ 郭超容 王伟静
编辑/ hjy

1.背景

Kubernetes 曾经成为事实上的编排平台的领导者、下一代分布式架构的代表，其在自动化部署、监控、扩展性、以及治理容器化的利用中曾经体现出独特的劣势。

在k8s容器相干的监控上， 咱们次要做了几块工作，别离是基于prometheus的node、pod、k8s资源对象监控，容器服务API监控以及基于grafana的业务流量等指标监控。

在物理机时代，咱们做了分级的接口性能监控——域名级别接口监控和机器级别监控，以便在某个机器呈现问题时，咱们就能疾速发现问题。

上图中，右边是物理机时代对应的性能监控，包含域名级别接口监控和3台物理机器监控。左边是对应的k8s环境，一个service的流量会由k8s负载平衡到pod1，pod2，pod3中，咱们别离须要增加的是service和各个pod的监控。

因为K8s中的所有资源都是动静的，随着服务版本升级，生成的都是全新的pod，并且pod的ip和原来是不一样的。

综上所述，传统的物理机API不能满足容器服务的监控需要，并且物理机性能监控须要手动运维治理，为此咱们冀望设计一套适配容器的接口性能监控零碎，并且可能高度自动化治理监控信息，实现pod API主动监控。

2.技术选型

为了满足以上需要，咱们初期思考了以下几个计划。

1. 手动保护各个service 和pod 监控到目前物理机应用的podmonitor开源监控零碎。

2. 重新制定一个蕴含k8s目录树结构的零碎，在这个零碎外面看到的所有信息都是最新的， 在这个零碎外面，能够做咱们的目录树中指定服务的公布、性能监控、测试演练等。

3. 沿用podmonitor框架，反对动静获取k8s集群中最新的服务和pod信息，并更新到监控零碎中。

+计划剖析+

针对计划一，思考咱们服务上线的频率比拟高，并且k8s设计思维便是可随时主动用新生成的pod（环境）顶替原来不好用的pod，手动保护pod监控效率太低，该计划不可行。

第二个计划应该是比拟零碎的解决办法，但须要的工作量会比拟大，这种思路根本全本人开发，不能很好的利用已有的性能监控零碎，迁徙老本大。

于是咱们抉择了计划三，既能兼容咱们物理机的接口性能监控计划，又能动静生成和保护pod监控。

3.整体设计思路

k8s监控包含以下几个局部：

其中API性能监控，是咱们保障业务性能正确性的重要监控伎俩。

通常业务监控零碎都会蕴含监控配置、数据存储、信息展现，告警这几个模块，咱们的API性能监控零碎也不例外。

咱们沿用apimonitor框架性能，并联合了容器服务性能监控特点，和已有的告警体系，造成了咱们容器API性能监控系统结构：

首先介绍下目前咱们物理机应用的apimonitor监控：一个开源的框架
https://gitee.com/ecar_team/a...

能够模仿探测http接口、http页面，通过申请耗时和响应后果来判断零碎接口的可用性和正确性。反对单个API和多个API调用链的探测。

如下图所示，第一行监控外面监控的是图片翻译服务域名的地址，后边的是各台物理机的ip：端口。

点开每条监控

咱们沿用apimonitor框架的大部分性能，其中次要的适配和优化包含：

1. 监控配置和存储局部：一是制订容器服务service级别监控命名规定：集群.我的项目.命名空间.服务；（和k8s集群目录树保持一致，不便依据service生成pod监控），二是依据service监控和k8s集群信息动静生成pod级别监控，

2. 监控执行调度器局部不必改变

3. 信息展现局部，减少了趋势图和谬误汇总图表

4. 告警局部，和其它告警应用对立告警组。

4.具体实际操作

4.1 增加service 级别API监控告警

须要为待监控服务，配置一个固定的容service级别监控。

service级别监控命名规定：集群.我的项目.命名空间.服务

以词典查词服务为例，咱们配置一条service级别的多API监控（也能够是单API监控）

· 单API：一个服务只须要加一条case用

· 多API：如果一个服务须要加多条性能case

其中“所属零碎” 是服务所属的告警组，反对电话、短信、popo群、邮件等告警形式（和其它监控告警通用）

工作名称：取名规定，rancher中k8s集群名字.我的项目名字.命名空间名字.service名字（一共四段）

告警音讯的字段含意：

docker-dict:告警组，订阅后会收到告警音讯k8s-prod-th：集群dict: 我的项目dict:命名空间data-server：workload名字data-server-5b7d996f94-sfjwn：pod名字{} ：接口返回内容, 即：response.contenthttp://dockermonitor.xxx.youdao.com/monitorLog?guid=61bbe71eadf849558344ad57d843409c&name=k8s-prod-th.dict.dict.data-server.data-server-5b7d996f94-sfjwn : 告警具体链接

4.2 主动生成pod API监控

主动生成上面三行监控工作：（第一行监控是按下面办法配置的容器service ip监控，后边三行是主动生成pod监控工作 ）

监控service级别是单API，则主动生成的是单API，service级别是多API，则主动生成的是多API监控。

主动生成的pod级别监控，除了最初两行标红处（ip: port）和service级别不一样，其余都一样。

实现pod主动生成的办法

1.给podmonitor（改框架是java语言编写的），减少一个java模块，用来同步k8s信息到podmonitor中。思考到批改podmonitor中数据这个行为，自身是能够独立于框架的，能够不批改框架任何一行代码就能实现数据动静更新。

2.比照podmonitor数据库和k8s集群中的信息，不统一的数据，通过增删改查db，减少pod的监控。因为数据之间存在关联性，有些工作增加完没有例行运行，故采纳了办法三。

3.比照podmonitor数据库和k8s集群中的信息，不统一的数据，通过调用podmonitor外部接口增加/删除一项监控，而后调接口enable /disable job等。依照可操作性难易， 咱们抉择了办法三

针对于k8s集群中查到的一条pod信息：总共有三种状况：

1.对于表中存在要插入pod的监控信息记录，并且enable状态为1。则认为该pod的监控不须要扭转

2.对于表中存在要插入pod的监控信息记录（删除操作并不会删除源数据信息），并且enable状态为0。则认为该pod的监控已被删除或者被进行。调用删除操作， 清空QRTZ （例行工作插件）表中的响应内容， 调用delete db操作清出监控信息相干表中的内容（使得监控记录不至于始终在增长）

3.对于表中不存在pod相干信息记录， 则须要新减少的一个pod。调用post 创立监控工作接口（依据service 监控配置）， 并调用get申请设置接口为监控enabled状态。

另外对于曾经在物理机podmonitor中增加了监控的服务，提供了一个小脚本，用于导出物理机podmonitor域名级别监控到docker monitor监控中。

5.难点和重点问题解决

5.1 误报消减

5.1.1上线告警克制

因为服务重启期间，会有removing状态和未ready状态的pod，在dockermonitor零碎中存在记录，会引起误报。
咱们的解决办法是提供一个通用脚本，依据k8s服务的存活查看工夫，计算容器服务的公布更新工夫，确定再主动开启服务监控的机会。实现在服务重启时间段，进行该服务的接口性能告警；存活查看工夫过了之后，主动开启监控。
如下如所示，即Health Check中的Liveness Check查看工夫。

在咱们上线公布平台上连接了该告警克制性能。

5.1.2弹性扩缩容告警克制

原来咱们通过查问rancher的 API接口失去集群中全量信息，在咱们服务越来越多之后， 查问一次全量信息须要的工夫越来越长，根本须要5min左右。在这个过程中，存在docker-monitor和k8s集群中的信息不统一的状况。一开始试图通过依照业务分组，并行调用rancher接口失去业务k8s集群信息。工夫从5min缩短到1min多钟。误报有肯定的缩小， 但从高峰期到低谷期时间段， 依然会有若干pod在k8s集群中缩掉了， 但docker-monitor中仍有相应的告警。

在调研了一些计划之后，咱们通过k8s增量事件（如pod减少、删除）的机制，拿到集群中最新的信息，pod的任何变更,3s钟之内就能拿到。

通过es的查问接口，应用 filebeat-system索引的日志， 把pod带有关键字Releasing address using workloadID （更及时），或kube-system索引的日志: Deleted pod: xx delete 。

通过这个计划，曾经根本没有误报。

5.2策略优化

为了适配一些API容许肯定的容错率，咱们在apimonitor框架中减少了重试策略（单API和多API形式均减少该性能）

为了适配各类不同业务，容许设置自定义超时工夫

5.3易用性

减少复制等性能，关上一个已有的告警配置，批改后点击复制， 则可创立一个新的告警项
应用场景: 在多套环境（预发、灰度和全量）监控，以及从一个类似API接口微调失去新API监控

5.4业务适配

精品课对服务的容器化部署中应用了接口映射机制，应用自定义的监听端口来映射源端口，将service的监听端口作为服务的入口port供内部拜访，如下图所示。当service的监听端口收到申请时，会将申请报文散发到pod的源端口，因而对pod级别的监控，须要找到pod的源端口。

咱们剖析了rancher提供的服务API文件后发现，在端口的配置信息中，port.containerPort为服务的监听端口，port.sourcePort为pod的监听端口，port.name蕴含port.containerPo
-rt和port.sourcePort的信息，由此找到了pod的源端口与service监听端口的要害分割，从而实现了对精品课服务接入本平台的反对。

6.上线成果

1.容器服务API监控对立，造成肯定的标准，帮忙疾速发现和定位问题。
通过该容器API监控零碎，拦挡的典型线上问题有：

· xx上线误操作
· 依赖服务xxxlib版本库问题
· dns server解析问题
· xxx服务OOM问题
· xxx服务堆内存调配有余问题
· xx线上压测问题
· 多个业务服务日志写满磁盘问题
· 各类性能不可用问题
·…

2.同时减少了API延时趋势图标不便评估服务性能：

谬误统计表不便排查问题：

联合咱们k8s资源对象监控，和grafana的业务流量等指标监控，线上故障率显著缩小，几个业务的容器服务0故障。

7.总结与瞻望

7.1总结

本期文章中咱们介绍了基于动态API监控和K8s集群化治理计划，设计了实时的主动容器API监控零碎。

通过上述计划，咱们可能在业务迁徙容器后，很快地从物理机监控迁徙到容器监控。对立的监控零碎，使得咱们线上服务问题裸露更及时、故障率也显著缩小

7.2瞻望

1.主动同步k8s服务健康检查到docker-monitor零碎，保障每一个服务都有监控。

2.集成到容器监控大盘中，能够利用大盘中k8s资源目录树，更快查找指定服务，以及关联服务的grafana指标等监控。

3.主动复原服务，比方在上线指定工夫内，产生API监控告警，则主动回滚到上一版本，咱们心愿监控不仅能发现问题，还能解决问题。

监只是伎俩，控才是指标。

8.结语

Docker技术将部署过程代码化和继续集成，能放弃跨环境的一致性，在利用开发运维的世界中具备极大的吸引力。

而k8s做了docker的集群化治理技术，它从诞生时就自带的平台属性，以及良好的架构设计，使得基于K8s容器能够构建起一整套能够解决上述问题的“云原生”技术体系，也升高了咱们做继续集成测试、公布、监控、故障演练等统一规划和平台的难度。目前有道业务服务根本都上线到容器，后续咱们将陆续迁徙根底服务，实现整体的容器化。

咱们也会一直踊跃拥抱开源，借鉴业界胜利案例，寻找适宜咱们以后业务倒退须要的现实选型。

-END-