微服务监控探索

微服务监控简介

 

做为一种灵活性极强的构架风格，微服务在各类开发项目中日益普及。当开发者从微服务架构得到敏捷时，观测整个系统的运行状况成为最大的痛点。
从网络流量分析的角度出发，经过生成各个微服务之间访问关系的拓扑结构来直观地观察整个系统的运做情况。

 

监控总体架构

 

部署

 

目前各组件部署在测试集群的容器环境中

 

• elasticsearch

• kibana

• topology

 

packetbeat

 

packetbeat是一个实时网络包分析工具，能够用于应用的监控和性能分析。它对7层协议进行解析，根据requests和responses划分transactions，对每个transaction产生一个json文档写入elasticsearch（一般状况下）。

 

目前packetbeat兼容的协议包括：

• HTTP

• MySQL

• PostgreSQL

• Redis

• Thrift-RPC

• MongoDB

• DNS

• Memcache

  安装

  官方提供的安装方式

  sudo apt-get install libpcap0.8curl -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支持三种抓包方式：

 

• pcap 依赖于libpcap，兼容各类平台，但性能并不是最高（默认方式）

• af_packet 内存映射方式，该方式性能优于pcap而且不依赖内核模块，可是仅限于linux

• pf_ring 依赖ntop.org的项目，该方式性能最佳，可是依赖于内核模块且限于linux

运行

 

/etc/init.d/packetbeat start

 

 

packetbeat配置动态修改(ctl_pb)

 

packetbeat的部署以node为单位，所以须要为其配置该node上全部service的服务端口，然而单个node上运行着多个service的示例，而且因为k8s的调度会动态的建立和销毁，所以须要动态的修改packetbeat的配置。

 

ctl_pb.py负责在每一个node上动态修改packetbeat的配置，其工做流程大体以下：

 

 

 

1. 初始化k8s_api地址以及docker daemon的api地址

2. 以stream的方式请求docker daemon的watch api，当有容器建立或销毁时返回该event，并触发更新配置的操做

3. 根据宿主机的ip用k8s_api得到该node上全部podip

4. 根据podip得到该node上全部endpoint的端口

5. 更新packetbeat的配置文件并重启packetbeat

 

 

topology

 

总体预览效果以下：

 

 

 

图中边的粗细对应请求数的大小，边的颜色对应延迟的大小

 

生成topology的流程大体以下：

1. 初始化完成读取配置文件等信息，包括es地址、k8s_api地址等等

2. 根据宿主机的ip从k8s_api的/pods查询该node上全部podIP，返回ip-->podname的字典

3. 接受请求or定时刷新触发，使用es的search api拉取符合过滤条件（时间周期、协议类型等）的数据，生成拓扑图必须的节点---nodes[]和边---links[]的数组，并计算对应的请求数、平均responsetime等统计信息

4. 对节点和边信息中的ip，若存在ip-->podname的对应关系则转换为podname

5. 若某ip没有对应podname，则转换为查询DNS返回的hostname

6. 利用获得的nodes[]和links[]渲染模板，生成html

7. 拓扑图的渲染使用开源JS做图库Echarts中的力导向图

 

Kibana Plugin

 

为了和更好的结合elk，将topology做为plugin集成到kibana的visualization里是一个不错的选择。然而kibana官方文档只介绍了plugin的安装，并无相关的develop文档...从收集到的民间文档来看，开发plugin存在如下坑：

 

1. 因为不是官方api，用到的api极可能在下个版本被和谐，意味着对每个版本的kibana都要调整

2. plugin安装的来源限于官方或者github，须要发布后才能安装

3. 最关键的是，在kibana的官方repo中赫然写着：             

 

 

鉴于以上，仍是部署了一个kibana的dev模式进行尝试开发一个Visualization用于展现拓扑结构。 一个Visualization plugin的核心主要由template和controller控制，在模板中的div中指定controller用以操做内部变量和逻辑。拓扑图的实现基于开源js做图库Echarts，其原理是为每个图指定一个固定大小的空白div，而后在js中取得该div对象并进行初始化和渲染。所以想法是讲初始化和渲染的逻辑放在controller中，以下图：

然而实际状况存在如下问题：

 

1. controller须要继承kibana中的ui/modules，从代码上看该module属于angularJS风格，然而在该module中大部分angularJS的内置方法都没法使用，例如service $document；

2. 该module中没法使用除了kibana/src之外的模块，包括echarts和nodejs内置模块;

3. 该module彷佛不是很兼容异步数据加载和渲染（未验证）。

 

因为以上问题，渲染的逻辑只能以/标签写在template中，然而template中的标签是没法动态修改的（须要经过controller），所以须要另外的部分去修改template从而在每次Visualization读取template时加载数据的变化，目前的实现是经过一个web server按期将模板渲染出的拓扑图导出成html，用该html做为Visualization的template：

 

目前的效果能够在kibana dashboard中添加拓扑结构图，然而该图的统计时间范围控制、前端参数等等都在web server中控制，而且因为异步渲染的问题，在dashboard中须要先切换到别的标签再切换回来才能看到该图...

 

 

 

参考资料

• https://www.elastic.co/guide/en/beats/packetbeat/current/index.html packetbeat官方文档

• https://www.timroes.de/2015/12/02/writing-kibana-4-plugins-basics/ kibana plugin民间文档

 

 

 

网易云新用户大礼包：https://www.163yun.com/gift

 

本文来自网易实践者社区，经做者何丹受权发布。