统一监控平台

李云龙 现任平台研发架构师，微服务与容器化推动者。

简介

从12年至今，7年时间里从零至2万亿交易额，经历了多次数据风暴，系统架构经历了数次更迭；随着微服务架构被广泛用于生产，迫切需要一种，可以发现、解决微服务架构下监控治理的解决方案，因此统一监控平台应运而生。

它的特点：

  1. 多，日处理TB级数据量，年PB以上的数据

  2. 快，real-time 显示视图图表，真的很real-time

  3. 好，支持Events、Metrics、JVM Graph、CPU MEM Graph、TPS&RPS Graph、Business Graph

  4. 省，经济寒冬成本为王，这条最重要

  5. 微服务架构下无缝兼容，接管微服务下的一体化监控

  6. 规则引擎、告警通知，支持微信、SMS、Email、OpenChat、村口大喇叭

  7. 无嵌入，不影响业务、NIAO么悄的就把数据归集起来

  8. 自动服务发现

  9. 发现性能瓶颈原因能力

  10. 发现内存溢出风险能力

发展历程

2.0 基于Zabbix架构

3.0 基于ELK架构

随着数据量的增长，需要一种

ELK 架构图

优势

好用

问题

巨额投入，10 * （32U 128G）+ PB 总价**W+ ，有钱也不能这么花，何况资本寒冬

4.0 现在的方案

Features

  1. 多，日处理TB级数据量，年PB以上的数据

  2. 快，real-time 显示视图图表，真的很real-time

  3. 好，支持 Events、Metrics、JVM Graph、CPU MEM Graph、TPS&RPS Graph、Business Graph

  4. 省，经济寒冬成本为王，这条最重要

  5. 向下兼容，兼容过去的架构采集的数据分析

  6. 规则引擎、告警通知，支持微信、SMS、Email、OpenChat、村口大喇叭

  7. 无嵌入，不影响业务、NIAO么悄的就把数据归集起来

  8. 自动服务发现

  9. 发现性能瓶颈原因能力

  10. 发现内存溢出风险能力

现在的架构

现在的方案

我们的需求

  • 小巧的采集端

    • 高可用 不可丢失数据

    • 低功耗 不可和业务系统抢资源

  • ETL 聚合层

    • 高可用 数据落盘防丢失

    • 具备线性业务处理能力

    • 低功耗 低成本

    • 数据无积压

  • 高效存储

    • 年PB存储能力

    • 实时分析能力（至少比ETL更强才可以）

  • 报表能力

    • 发现性能瓶颈原因能力

    • 发现内存溢出风险能力

  • 接管微服务监控治理能力

Behavior Collection 方案设计过程

  • 采集方案选型：

方案

优势

劣势

Logstash

Multiple inputs

Serveral outputs

Lots of filters

Lots of plugins

提取、解析、缓冲和传输

硬伤资源消耗

重启丢数据

Filebeat

大道至简，代码少犯错少😂

低功耗 CPU MEM

记录读取位置，不丢数据

功能少😂

Logagent

Sematext 提供的传输工具

本地缓冲，不丢数据

脱敏

功能少

<b></b>Fluentd<b></b>

初衷JSON作为日志输出

和 Logstash一样

Lots of plugins

缓冲只存在与输出端

单线程核心，大节点性能受限

硬伤资源消耗

Logtail

阿里云力作

占用资源少

结合阿里云日志服务使用

从上图表结合我们的需求，得出结论

我们选择了 Filebeat👏，他具备我们【小巧采集端】的要求。

Metrics Collection 方案设计方法

Metrics 采集域，使用简单，无需代码嵌入；通过注册中心自动发现微服务集群Application，然后采集各个App的metrics信息，我们采用一种取巧的形式，兼容prometheus exposer采集点，之所以这样考虑，因为它是Google BorgMon监控系统的开源版本，在google 开源软件生态体系被良好的支持，如：K8S。

我们提供两种方式采集：

  • Pull Metrics 主采，按频次发起请求，采集数据点

  • Push Metrics 被采，在App里主动向Push Gateway 发送测量数据

ETL 聚合层

聚合层做实时数据融合，将Behavior&Metrics收集到缓冲层后，在ETL聚合层内做数据的清洗、转换、最后存储到 Events Storage&Time Series Storage中。

Link Tracking Domain

敬请期待……

Time Series Storage

时序存储引擎，负责存储采集到的Metrics数据；我们主要用到三种数据结构：

  • Counter

    • 计数器用于累计值计算

    • 例如：TPS，RPS，Error in Logs

    • 数值一直增加，只有重启之后才会被重置

  • Gauge

    • 常规数值变化，例如：JVM Stack，CPU、Memory

  • Histogram

    • 直方图主要用于跟踪事件放生规模，例如：某请求的成功率 .95 .90 .50 发生规模

数据规模

    每秒一个点，每个点采集数种性能指标， 采集数百个微服务节点。每天处理量：11396\(每个点至少字节数\) \* 86400/5\(5秒一个采集一个点\) = 939MB \* 100\(app数量\) = 91GB。

时序存储能力：

  • 无缝接管Prometheus

  • 大数据存储能力

  • 大数据实时分析能力

Events Storage

事件存储引擎，存储采集来的 Events；

Output Domain

输出域，目前支持JVM Graph、Thread Graph、CPU Graph、Events等；可通过仪表盘轻松分析任何时刻，发现JVM性能瓶颈的原因，找出内存溢出风险的能力。

Alarm 告警

将触发告警的系统指标，推送给该接收的人

未来的路

我们下一步要做的事：

  • 智能监控，监控报告细化到解决方案级

  • 支持容器，Docker、K8S、Rancher等容器内的事件采集

  • 支持更多中间件监控

  • 支持自定义仪表配置

总结

想知道我们的存储引擎是怎么做的吗，JOIN US。

PreviousFQANextQ&A

Last updated

Was this helpful?