个人认为分几个层面。
第一个是系统层面,包括主机系统监控,这个已有监控系统可以搞定;
第二个是容器层面,容器启停都是秒级,有些动态变化也比较快,现有监控不一定能搞定,需要使用新的开源框架或者对现有监控系统改造;
第三个是应用层面,应用的状态,传统是通过打探针agent方式,但在容器环境下,这种方式不一定可行,我认为可以根据具体的应用使用场景,采用不同的监控方式,比如健康检查、agent、主动上报等多种方式。
这个问题说以银行内部已有监控系统为前提,那么我认为问题的场景是需要容器平台和已有监控系统进行对接。在这个前提下,我个人的想法是:
首先监控是分层的,可以分为系统层面、应用层面、服务层面。
对于系统层面,主要是针对资源使用情况、网络连通性、节点健康情况的监控,传统的监控系统在这方面已经非常完备,我们直接可以利用传统的监控系统对容器平台的宿主机进行系统层面的监控,对接大屏幕等。至于单个容器本身使用的资源等,我个人觉得这些数据对进行弹性伸缩、迁移等容器平台内部动作是比较关心的,而对于外部资源监控意义不大,所以我个人认为多数场景下单个容器的资源使用情况、健康状况这样的信息没有多大必要送到外部的传统监控。系统层面的监控还有一层意思是容器平台本身的监控,即控制节点和相关服务的监控,这些在容器管理系统是必备的功能,用户可以根据需要决定是否需要把这部分信息上报到传统监控进行统一展示。
对于应用层面,容器平台本身通常都带有类似K8S的replication control这样的机制保持某个服务运行实例数量的能力,所以通常情况下容器平台都能保证应用和应用下每个微服务的运行正常。但我个人认为关于应用层面的健康监控,还是需要来对接传统的监控系统,进行适当的告警输出,例如当遇到应用逻辑错误而导致启动反复失败、或资源不足导致启动总是不成功等问题时,容器平台本身的replication control机制就不能解决问题了。这种情况就需要我们把应用的故障信息传递到传统监控,并根据问题的严重情况进行不同等级的告警通知等,由相关的应用人员介入来解决问题,比如升级补丁或回退等。那么怎样和传统监控的对接?方法就因用户的喜好而异了,例如可以写一个独立运行的程序,定时调用容器平台的接口,获得应用中每个微服务的当前实例数、预期实例数、应用的资源使用总量等,调用相应接口把数据传递到传统监控,在传统监控中设立告警策略,例如当运行实例数低于预期实例数持续2分钟后,抛出告警等。
对于服务层面,是监控应用提供的服务是否运行正常。例如某个提供WEB服务的应用,在一些时候虽然应用和应用中微服务的运行实例数量正常,但它的WEB服务已经失去响应,或者返回的是错误的状态,这种情况在多数容器平台中是无法监测到的,这个需要我们丰富容器故障的监测手段,或者自己编写服务访问+检测逻辑来判断,并把检测出现的问题上报到传统监控,在传统监控中设立相应的告警策略、告警等级。
收起个人意见:
IAAS层:
1.容器云首先是搭载在IAAS层上的,传统监控仍然可以用于IAAS层监控(CPU、内存、网络等),只是针对容器特性这块,IAAS层监控需要增加额外的监控KPI,如专供docker image使用的文件系统的使用率,docker service状态,开源网络组件服务状态,K8S node service状态等等
PAAS层:
1.首先是PAAS框架自身的状态,如K8S自身就有大量的命令可以列举集群状态,集群事件等等,这部分监控可以通过额外定制监控agent完成。
2.PAAS内部应用的状态,比如镜像是否宕机重启过,服务是否可用等,如果使用的k8s,需要结合k8s命令以及框架提供的应用健康侦测功能实现监控。
3.对于单个容器所使用的资源监控,其实很多框架都提供了非常完善的开源解决方案,选择合适的实施就可以。
4.针对应用监控,个人感觉其实应用上云后,单个容器应用监控其实意义不大,系统要做的是能够正确发现异常并恢复异常,比如框架尽早发现应用hang或者应用压力比较大,然后由框架决定是重启容器还是自动扩容。这部分如果使用K8S,框架层面本身就有这个功能,上线的时候做好规范规划就行。
如果一定要深入容器监控应用,监控总体思路是一样的,不是主动推数据,就是工具拉数据,由于容器数量及IP会经常变更,所以一般情况下采用主动推送的方式,容器启动后就自主收集数据并推送至监控平台。至于如何监控应用其实和传统方式没有差别,大体就是监控中间件提供的性能数据,再通过APM监控应用的性能数据。如果是采用的K8S,可以考虑将监控单独做成一个docker镜像,发布是同应用发布在同一个pod中,而不是将监控写入应用镜像。