自用型监控系统方案设计

一、监控系统整体概述

系统背景：
在当前项目中，当我们对特定流程注入故障后，如何评估故障的效果以及系统应对故障的表现？传统方式是用户需要登录线上机器或者各种监控系统去查看具体的指标信息，然后通过人工判断，来判断故障的影响范围，产品使用上不够自动化，且没有闭环。我们期望引入监控系统，把之前需要人来做的事情交给系统来做，为故障注入后的影响进行量化分析。

整个监控系统对数据处理的四个步骤：

系统架构图：

组件说明：

API Gateway：agent 与 Server 所有交互都会通过API Gateway，统一由API Gateway进行管控，为整个MK提供一致的数据门面接口，实现之前约定的数据总线的方案。

Data Collector：为数据采集器，接受来自客户端推送上来的监控数据 或 拉去外部监控数据；

Data Transfer： 数据转换器，把采集到的非一致性架构的数据转换为统一的数据模型；

Config： 此模块主要提供一些Agent、Collector、Analyzer需要的一些元数据；

Schedule： 依赖Schedule，主要是期望能把周期性数据拉取采集任务转换为 schedule任务，降低重复编写分布式任务调度的复杂度，其次，借助schedule实现周期任务分发的负载均衡；

Diamond：采用Diamond作为数据采集规则的动态配置中心。

MQ： 把数据采集器采集到的数据转换为统一的消息格式，解耦数据采集与数据分析对数据使用差异性；其次，当数据分析器Data Analyzer集群宕机或处理性能下降时，MQ能起到数据缓存池的作用，一定程度上防止采集上来的数据未能处理而导致的数据丢失。

Data Analyzer： 数据分析器，对收集到的监控数据进行一定程度上的计算转换，并根据关注点规则，进行事件监控处理；

自研监控系统，需要面临一系列的抉择：

二、行业监控系统架构：

ONEAPM

CAT

参考：https://tech.meituan.com/CAT_in_Depth_Java_Application_Monitoring.html

三、数据采集方案

数据采集面的的挑战：

• 数据源多种多样
• 数据量大
• 变化快
• 如何保证数据采集的可靠性的性能
• 如何避免重复数据
• 如何保证数据的质量

3.1 采集方案

目前常用的数据采集方式有两种：

1. 主动监控（客户端推模式-Push）；
   • 优势：
     • 实时性好；
     • 对服务端的压力相对较小；
     • 插件化支持用户自定义采集脚本；
     • 监控自动发现；
   • 劣势：
     • 数据聚合与异常处理复杂；
2. 被动监控（服务端拉模式-Pull）；
   • 优势：
     • 数据处理方便；
     • 数据准确性、完备性更好；
     • Edas已经存在根据staragent进行数据拉去的实践方案；
   • 劣势：
     • 集群规模大时，服务器压力大，任务分发易积压，分发线程忙，带来一定数据延迟；
     • 数据拉取时服务隔离难(twitter)；
     • 无法区分服务失效和代理失效(twitter)；

现有监控系统采集方案：

系统	采集方式	备注
AliMonitor	Push
Ali-Sunfire	Pull
TLog	Pull
aliyun-sls-ilogtail	Push
Zabbix	push+pull
Open-falcon	Push
OneAPM	Push
Cacti	Pull

主动监控示意图（Push）：

服务端提供一个接受数据请求的域名地址，客户端把数据推送到服务端，服务端负责数据解析与存储；

被动监控示意图（Pull）：

Agent一般具备的功能:

1. LogFinder: 能够根据请求的时间区间返回区间内的监控数据；
2. LogQuery: 能够根据偏移量定位到日志位置；
3. LogCompression： 支持日志数据压缩；

此部分可以参考LogAgent的实现逻辑。

我们的需求：

• 轻量级；
• 可扩展；
• 支持系统监控（OS）、业务监控（Agent）
• 支持Agent自动注册以及静态数据主动上报；
• 监控项受控开启与关闭，具备开关功能（非常态化挂载）；
• 需要具备数据堆积能力；
• 需要具备多数据源扩展能力；