UAV心跳机制与容器、进程数据采集

背景

在微服务架构中，服务心跳是一个简单但很是重要的机制，用于确认微服务的存活状态。UAVStack中的心跳是一个Http请求，MonitorAgent（如下简称MA）经过定时向HealthManager（如下简称HM）发送一个带有特定报文格式的Http请求完成一次心跳的发送过程。心跳报文含有发送时的时间戳，用于更新HM端的数据状态。

与普通的心跳不一样，UAVStack中的心跳还负责上送MA端的应用容器和进程监控数据。每次发送心跳的时候，在MA端会有定时任务去收集MA所在的应用容器心跳的基本信息，及应用容器上的进程数据，随着心跳数据包一块儿上送。

本文将首先介绍UAVStack的基础心跳机制，以后对应用容器、进程的数据采集作详细说明。

基本架构

心跳的实现有不少种方式，心跳的发起能够由客户端发起也能够由服务端发起，只需完成确认存活这一基本功能便可。可是在通常的实现中，咱们更倾向于客户端主动向服务端进行报告，由于当客户端逐渐增长，单纯经过服务端的轮询会致使服务端的压力，影响性能。

在UAVStack的实现中，咱们也采用了这样的方式，经过客户端（MA）主动向服务端（HM）发送心跳信息，告知HM自身的存活状况。

一次心跳由UAV的MA和HM共同完成：

MA定时生成心跳数据，携带MA节点的应用容器信息、进程信息以及服务信息，经过Http请求上报给HM；

HM负责将接收到的心跳数据存入Redis缓存，并定时扫描心跳数据，确认节点的存活状态。对于随同的应用容器等监控信息，会在Redis进行暂存，后续随着HM的定时任务最终存入OpenTSDB进行落盘。总体的架构以下所示：

基础心跳机制

心跳服务主要流程如上图所示，其逻辑有如下几步：

1. MA的定时心跳任务生成一个空心跳数据，将心跳数据交给MA端的容器、进程数据采集任务。

2. MA端的容器、进程数据采集任务负责产生心跳数据的时间戳、采集节点的应用容器、进程监控数据、节点的基本信息、节点的可用服务信息等。通过以上过程以后，心跳数据将包含如下内容：

   心跳时间戳：节点发送心跳时的时间戳，方便HM后续比对断定节点的存活状态。

   应用容器的基本信息：包括节点ID、名称、主机名、IP等。

   应用容器的简单监控数据：包括CPU负载、内存使用、硬盘使用等。

   应用容器上的进程信息：包括每一个进程的pid、资源占用等。

   节点的能力信息：包括该节点上启用的Feature功能。

   节点的服务信息：包括该节点上可提供的服务及其访问接口，用以实现服务发现。

   子节点的节点信息（可选）：若是MA和HM部署在不一样的网段，则MA没法经过直接Http的方式推送数据给HM，此时须要MA将数据上送给本身网段内的HM，再由该HM的心跳客户端发送给总的HM。这种状况下，上报的数据中会携带子节点的节点信息。每一个节点信息均会包含上述几种数据。

   最后将心跳数据发送给HM。

3. HM端在接收到心跳数据以后，将其存入自身的Redis缓存。使用上报数据中的服务信息更新Redis中的服务状态，用于服务发现请求。

4. HM端在启动心跳接收服务时，会同时启动心跳检查任务。这个任务会定时扫描Redis中的心跳数据，根据当前系统时间与心跳时间戳的差，判断心跳节点的存活状态，更新节点的状态，并对于过时的节点作删除处理。

应用容器、进程数据采集

UAV的心跳数据除了完成心跳功能以外，还要上报节点的应用容器及进程的监控数据。

将应用容器与进程数据经过Http方式上报是为了保证应用容器监控数据与应用监控数据的隔离，经过不一样方式的上送能够保证在MQ服务不能使用时不影响容器与进程数据的采集。

本节将集中说明这些数据的采集细节。

1.应用容器数据采集

应用容器的数据分为两部分：

其一是容器的基本信息，即节点的ID，主机名，系统信息和JVM信息等；

另外一部分是一些简单的实时监控采集数据，包括CPU的负载、内存占用状况和磁盘占用状况等。这些数据在每次上报心跳数据的时候会分别从如下数据源实时采集：

应用启动后的System.getProperty：这部分数据主要包括操做系统的基本信息，JVM信息等。

Java提供的工具类：这部分主要包括网卡信息。

经过JMX获取的信息：包括CPU占用、内存占用等。

系统自己记录的信息：这部分包括可提供的服务信息、启动的Feature信息、节点ID等。

经过执行系统命令获得的信息：包括磁盘占用状况。

经过直接读取/proc目录下的文件获取的信息：包括CPU占用、内存占用等。

2.进程数据采集

不一样于应用容器数据采集，进程的数据并非在心跳进程中进行采集的，而是由专门的Feature负责。在Feature中将进程数据采集进一步分解成进程端口流量数据采集以及其余数据采集。这二者均由定时任务完成，互相协做，最终由进程探测的定时任务更新心跳客户端的进程数据。

这种使用多个采集任务分别采集的方式能够针对不一样的数据进行不一样频度的采集。如对于网络端口流量的采集，就能够以更长的周期进行，以减低数据采集带来的性能损耗。同时，不一样的任务也可使用不一样的线程执行，提高执行的效率。

进程数据采集流程大体以下图所示：

进程端口流量探测定时任务每隔必定时间读取本地变量端口列表，获取要采集的端口号。

以后对于Windows环境，采用JPcap获取网卡对象，并在网卡上设置tcp过滤器来统计一段时间内的端口流量。对于Linux环境则是直接经过调用Python脚本打开socket，分析流过的数据包得到。

得到所有端口上的流量数据后，任务会将采集数据交给进程数据采集任务，更新其本地变量，同时设置本次采集的时间戳。

进程探测定时任务由一系列子任务构成，在任务开始的时候，会先准备好一个Map结构的数据容器，用于存放采集到的进程信息，每一个进程由pid区分，做为Map的key。

任务会先扫描全部的进程，获取pid和进程的端口。扫描到的进程会通过一个过滤器排除不须要采集数据的进程，以后正式采集每一个进程上的数据。

对于每个进程，会经过运行系统命令采集链接数、CPU、内存占用，磁盘读写数据以及网络端口流量数据。其中网络端口流量数据是由端口流量探测任务采集并更新的本地变量，而进程探测任务也会将扫描到的最新的端口列表更新到端口流量探测任务的本地变量。

若是应用是部署在容器上的，则还会有对应的容器信息采集。最后进程探测任务会将采集到的进程数据更新到心跳客户端的本地变量，随着每次心跳数据的生成被一块儿采集并上报。

进程数据的采集分别来自如下数据源：

系统命令：包括CPU、内存、链接数等（top等命令）

/proc目录下各进程子目录：包括CPU、内存等信息、磁盘读写等信息

执行脚本：包括Linux环境下的端口流量数据采集

第三方工具包：包括win环境下的端口流量数据采集（JPcap）

HM处理

心跳数据和容器数据在经过Http上送到HM端以后，会由HM端对应的服务进行处理。

HM在启动时会启动本身的心跳客户端，负责发送本机的心跳数据和采集HM所在容器的监控数据。同时还会启动一个心跳服务，负责接收处理全部上送的心跳和容器数据信息。

心跳服务在收到心跳数据请求后，会根据HM的配置，断定当前的HM是否是Master节点。若是HM是Master节点，心跳服务会从Http携带的报文中拿出上报的数据，取得上报节点中的可用服务用于更新服务发现信息，以后将数据存入后端的Redis缓存中；若是不是Master节点，则会将数据移交至本机的心跳客户端，由其下次发送心跳时一块儿上送。

这样的设计是考虑到大规模监控时会有跨机房的状况存在，此时各监控节点每每不在同一个网段内，经过将同一个网段内的机器上交到边界的“网关”统一上交可解决这一问题。此时的HM即充当着“网关”这一角色。

HM在启动的时候同时还会启动一个定时任务，这个任务负责处理各节点的存活情况。任务定时从Redis中读取所有心跳数据，依次检查上送心跳数据中的客户端时间戳与当前系统时间戳的差值。

当时间超过必定的上送时间间隔以后，更改对应的节点存活状态。当超过一倍上送时间间隔，意味节点可能死亡，处于dying状态。当超过两倍时间间隔时，意味着节点已经死亡。当超过三倍时间间隔时，心跳服务会删除该节点的缓存记录。

随心跳一块儿上报的容器和进程数据会随着心跳数据一同被存入Redis中，后续由HM的其余定时任务读取并发送给预警中心进行处理，最终监控指标被格式化成特定的结构存入OpenTSDB。

同时采集的容器数据和进程数据会提供前端AppHub查看界面，如图所示：

点击页面上的每个节点，能够查看详细的节点信息，包括节点的操做系统信息、JVM信息、提供的服务和安装的Feture等等。这些也就是前文所说的随心跳数据上报的那部分信息。如图所示：

总结

心跳是微服务架构基础但重要的机制，经过定时发送心跳数据，MA节点报告了自身的存活状态，使得HM可以知晓当前系统的运行状态。

同时，UAVStack的心跳数据还同时负责上报节点的容器及进程监控数据，随着这些数据的上报，HM能够对监控的容器和进程作出预警，也可以在前端实时看到应用容器和进程的运行状态。

官方网站

开源地址

UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~

扫一扫下方二维码，关注一个不会让你失望的公众号