基于网络抓包如何实现kubernetes中微服务的应用级监控,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
微服务监控的挑战
监控的目的是为了让集群中所有的服务组件,不管是HTTP服务,数据库服务,还是中间件服务。都能够健康稳定得运行,能发现问题,遇到问题能找到原因。
在过去,监控工具侧重于基础设施或单一软件组件以及衡量运营健康。这些工具在实现这一目标方面只取得了一定的成功,但是对于单一的,传统的应用程序和基础设施来说效果不错。微服务的出现暴露了工具中的弱点。
现在,组件托管在位于私有云,公共云或两者的混合体之间的虚拟化机器或容器内。获悉我并不需要关心服务cpu用了多少,内存用了多少?确保这些服务相互通信以提供所需的结果需要从监控的角度重要看几件事情:
微服务集群中是否所有的服务的吞吐率,响应时间都正常?
<李>服务调用线中哪些线负载过大,哪些线负载过小?
<李>服务的错误率,例如HTTP 500错误。
我们想要监控分析应用,从它的服务状态出发是否更直接呢?
已有监控方案
目前有些厂商提出了微服务的监控解决方案。
从APM角度监控服务端到端状态。
<李>为每种类型服务开发代理收集应用状态信息。
通过产生统一的应用日志分析监控方案
<李>其他方案
每一种商业或开源方案都有它的优势所在。可以根据你的需求来进行选择,例如你的所有服务都是自己研发,日志标准一致或能够统一处理。所有访问信息都能打出日志,那么我认为日志分析可能是你最适合的方案。但是对于公有云平台,那就不同了。
好雨云帮采用的方案
好雨云帮提供了公有云和私有化的部署方式,平台内部署的服务各式各样。各种通信协议,各种日志标准。我们怎么实现对所有服务的应用状态监控?好雨云帮完善的租户网络,环境隔离,因此我们提供用户在自己环境下安装自己的监控组件,我们的基础数据收集是通过网络分析。下文详细讲解:
kubernetes POD共享机制
kubernetes中豆荚内容器共享网络空间,挂在卷等为我们监控豆荚内主服务容器提供方便。其实按照官方对吊舱的定义的使用面来说:
*, content 处理系统,file 以及data 装载机、,local cache 经理,等等。 *,log 以及checkpoint 备份,,压缩,旋转,快照,,等等。 *,data change 观察者,log 尾随者,,logging 以及monitoring 适配器,event 出版商,等等。 *,代理,桥梁,以及适配器 *,控制器,,经理,配置器,,以及更新
荚内除了主服务外我们可以部署一些附属服务。之前的文章我谈过使用豆荚的插件服务收集处理日志。今天我再谈使用豆荚的网络便利监控主服务应用级指标。
通过共享的网卡抓包分析网络流量反应应用状况
我们拿一个http服务为例,我们监控网络流量能拿到几乎所有访问和服务返回信息,例如1分钟内多少<代码>请求> 路径> 要获得以上的数据,我们需要获取到网络包,解码网络包然后获得http协议数据。
我们<代码> WatchData 服务容器与应用容器在同舱中,经过应用容器<代码> eth0> WatchData 容器中<代码> eth0> 反应形成一个消息发送到服务器端完成分析,存储然后形成连续的实时的监控数据。下图展现个简要的整体架构图:
当然,上文已经说了,我们采取此方案主要就是为了能够监控各种应用,只是<代码> http 怎么行。不通的通信应用使用不同的通信协议,比如<代码> mysql> mongodb> TCP/IP> 应用程序> 运输> 网络> 链接)四层. .我们抓取到的网络包信息也是四层模型。
