作为一种灵活性极强的构架风格,微服务在各种开发项目中日益普及。当开发者从微服务架构获得敏捷时,观测整个系统的运行情况成为最大的痛点。
从网络流量分析的角度出发,通过生成各个微服务之间访问关系的拓扑结构来直观地观察整个系统的运作状况。
目前各组件部署在测试集群的容器环境中
packetbeat是一个实时网络包分析工具,可以用于应用的监控和性能分析。它对7层协议进行解析,根据requests和responses划分transactions,对每一个transaction产生一个json文档写入elasticsearch(通常情况下)。
目前packetbeat兼容的协议包括:
Memcache
官方提供的安装方式
sudo apt-get install libpcap0.8
curl -L -O https://download.elastic.co/beats/packetbeat/packetbeat_1.1.1_amd64.deb
sudo dpkg -i packetbeat_1.1.1_amd64.deb
基本的配置包括网络设备,输出(本例是es),各协议端口。 配置文件默认为/etc/packetbeat/packetbeat.yml,最基本的配置示例如下:
interfaces: {device: docker0}
output:
elasticsearch:
hosts: ['223.252.222.168:42400']
protocols:
dns:
ports: [53]
http:
ports: [8000, 8080]
memcache:
ports: [11211]
mongodb:
ports: [27017]
mysql:
ports: [3306]
pgsql:
ports: [5432]
redis:
ports: [6379]
thrift:
ports: [9090]
packetbeat支持三种抓包方式:
/etc/init.d/packetbeat start
packetbeat的部署以node为单位,因此需要为其配置该node上所有service的服务端口,然而单个node上运行着多个service的示例,并且由于k8s的调度会动态的创建和销毁,因此需要动态的修改packetbeat的配置。
ctl_pb.py负责在每个node上动态修改packetbeat的配置,其工作流程大致如下:
整体预览效果如下:
图中边的粗细对应请求数的大小,边的颜色对应延迟的大小
生成topology的流程大致如下:
为了和更好的结合elk,将topology作为plugin集成到kibana的visualization里是一个不错的选择。然而kibana官方文档只介绍了plugin的安装,并没有相关的develop文档...从收集到的民间文档来看,开发plugin存在以下坑:
鉴于以上,还是部署了一个kibana的dev模式进行尝试开发一个Visualization用于展示拓扑结构。 一个Visualization plugin的核心主要由template和controller控制,在模板中的div中指定controller用以操作内部变量和逻辑。拓扑图的实现基于开源js作图库Echarts,其原理是为每一个图指定一个固定大小的空白div,然后在js中取得该div对象并进行初始化和渲染。因此想法是讲初始化和渲染的逻辑放在controller中,如下图:
然而实际情况存在以下问题:
由于以上问题,渲染的逻辑只能以/标签写在template中,然而template中的标签是无法动态修改的(需要通过controller),因此需要另外的部分去修改template从而在每次Visualization读取template时加载数据的变化,目前的实现是通过一个web server定期将模板渲染出的拓扑图导出成html,用该html作为Visualization的template:
目前的效果可以在kibana dashboard中添加拓扑结构图,然而该图的统计时间范围控制、前端参数等等都在web server中控制,并且由于异步渲染的问题,在dashboard中需要先切换到别的标签再切换回来才能看到该图...
网易云新用户大礼包:https://www.163yun.com/gift
本文来自网易实践者社区,经作者何丹授权发布。