数据API 产品矩阵 案例 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

基于Falcon的滴滴内部监控系统

监控是架构可用性中最关键的环节之一,高可用架构邀请了滴滴的研发工程师聂安,分享了滴滴监控系统 DD-Falcon 近期的一些进展。

作者简介

聂安,滴滴运维研发工程师,长期从事监控、部署等运维工具平台的开发。现就职于滴滴,曾就职于阿里、小米。

很高兴和大家一起分享滴滴监控系统 DD-Falcon 近期的一些进展。今天分享主要包括如下几个部分 (技术架构、产品形态):

  • DD-Falcon 的系统架构

  • DD-Falcon 相比 Open-Falcon 的一些改进

  • 目前遇到的问题

  • 将来的几个规划

系统架构

DD-Falcon 脱胎于开源监控系统 Open-Falcon。Open-Falcon 是小米运维团队 2015 年开源的一款监控产品,目前已应用在 小米、美团、滴滴、快网、JD 等众多互联网公司,Open-Falcon 的详情可参见 [1]。

在介绍 DD-Falcon 之前,我们先介绍下 Oepn-Falcon 的系统架构。

上图是 Open-Falcon(后简称 OF)v0.1 的典型架构(v0.2 有些许调整)。橙色的线代表了配置流,绿色的线代表了数据流,紫色的线代表了报警链路。


OF 配置流

配置信息,由用户产生,并逐级应用到各个组件,主要流程是:

用户 –> UI(Portal) –> 配置中心(HBS) –> 采集(Agent), 报警(Judge), 计算(Aggr/Nodata)

其中,HBS 原意为心跳服务、后逐步发展成为配置中心。

OF 数据流

监控数据的整个生命周期,分为 采集、收集、分发、存储、消费等几个环节。

Falcon-Agent 是主要的采集器和收集器,它被部署在每个单机实例上(物理机或者容器),采集本机基础信息(如 CPU、内存、磁盘等,自动采集)、 本机部署的应用程序信息(如端口信息、进程信息等,由用户配置),同时也会作为代理、接收本机应用程序 主动上报的业务监控数据(如 App 埋点&内存统计产生的 Metrics 数据 等)。Falcon-Agent 将自己采集 或者 收集的监控数据,主动推送给 Transfer。

Transfer 是数据分发组件,将接收到的监控数据 一式两份、分别发送给 数据存储组件 Graph 和实时报警组件 Judge。Graph 和 Judge 都采用一致性哈希做数据分片,以提高横向扩展能力。Transfer 按照哈希规则,将监控数据主动推送到固定的分片上去,对数据生产者屏蔽分片细节。

Graph 提供数据存储能力。Graph 底层使用 rrdtool 做单个指标的存储,rrdtool 的特点决定了单个指标存储空间固定、数据自动降采样,这个特点很适合监控热数据的存储。Graph 在应用层对 rrdtool 做了写优化(缓存, 分批磁盘写等),使得一个 Graph 实例能够处理 8万+/秒的数据点写入频率。

Graph 一般由多个实例构成集群,不同实例存储不同的监控数据。为了屏蔽存储集群的分片细节,提供了 Query 模块,实现了和 Transfer 一样的一致性哈希分片逻辑,对数据消费者屏蔽存储分片细节。Transfer + Graph + Query 构成了功能完整、横向可扩展、技术门槛低的分布式时间序列化数据存储系统,这是 Open-Falcon 的核心竞争力所在。

存储之上,长出了用户最常用的监控看图功能,对应到上图中的 Dashboard 模块。另外,集群聚合模块Aggr、数据中断报警模块 Nodata 都会消费存储的数据。

OF 报警链路

Judge 和 Alarm 两个模块构成了 OF 的报警链路。Judge 由 Transfer 上报的监控数据驱动,结合用户配置的报警策略,实时计算、产生报警事件。Alarm 组件对报警事件做一些收敛处理后,将最终的报警消息推送到各报警通道。OF 的报警,是由监控数据驱动的,没有数据上报 就 不会报警。

以上大概介绍了下 OF 的系统架构。相比 OF,DD-Falcon(下面简称 DF)的主要组件结构如下。

408-640.jpg.jpg

配置流由棕色曲线表示,数据流由黑色曲线表示。

配置流从右向左,依次为:

用户 –> 配置(fe/api) –> 存储(config) –> 生效: 采集(agent/log/net/url), 清洗(transfer), 报警(judge)

数据流从左向右,依次为:

服务(apps) –> 采集 –> 收集 –> 清洗 –> 存储 –> 消费: 报警, 看图, 第三方

DF 的配置流,与 OF 的相似,不再赘述。DF 的数据流,核心存储部分继续使用 OF 原生组件(transfer + graph + query), 同时在数据采集、清洗、报警等方面做了调整。


DF 采集

DF 的采集覆盖了机器指标(如CPU、内存、磁盘)、应用指标(如端口信息、进程信息)、业务指标(如 rps、error_ratio、latency)等。

业务指标,主要是通过 log 本机日志实时分 和 metrics 业务统计 获取的。log 分析方式是历史沿袭,比较方便、但资源消耗不可控,正在被逐步弱化。

metrics 是类似开源 statsd [2] 的解决方案,通过业务代码埋点 将状态数据(rpc 调用质量、计数等)上报到本机 metrics-agent,再经由 metrics-agent 周期性的统计聚合,将最终的业务统计数据上报到 本机 agent 上(agent 充当了收集器)。

metrics 对于无状态的服务非常友好,正在逐步成为主流(有状态的服务可以在 应用内存中 做统计计数,正如 OF 一样)。

机器指标、应用指标的采集主要是由 本机上的 agent(DF-Agent)完成的,也会自动采集、主动上报数据,与 OF 相似,不再赘述。

DF 收集

为了应对上报峰值、网络抖动等问题,DF 增加了 nsq [3] 数据缓存队列,agent上报的监控数据先被q到nsq、再由分发组件消费。nsq按照服务单元(su) 划分topic。


DF 清洗

在nsq数据缓存和存储之间,增加了一个数据清洗环节,实现了容量控制、垃圾数据过滤等机制,用于监控系统的自我保护。后面会详细讲述。


DF 存储

DF 复用了 OF 的 transfer + graph + query 三个组件,在此基础上将数据索引模块index独立出来(OF 使用 mysql 做简单的查询索引)。索引信息,是在指标写入graph时同步生成的,可以满足分级查询的需求。索引模块是 DF 对 OF 的主要改进之一。


DF 消费: 看图

看图,是长在存储上的一个功能。DF 的支持动态看图、临时图、监控大盘等产品形态,支持同环比看图,支持灵活的聚合展示等。


DF 消费: 报警

与 OF 相比,报警变成了存储模块的一个下游,不再拥有独立的数据上报链路。judge 模块从 config 处获取报警配置,然后按需从存储组件拉取命中的指标数据,进行实时报警计算,产出报警事件。alarm 模块做报警收敛处理,并将最终的报警通知交给报警通道服务 notify 处理。notify 支持多种报警通道,包括钉钉、语音、短信、邮件等。

DF 将报警数据的获取方式由推变拉,给报警判断带来了巨大的灵活性。报警方式由推变拉是 DF 对 OF 的另一个主要改进。

DF 消费: 第三方

DF 的监控数据完全开放,供各个业务线使用。特别的,不同的业务场景看图功能的产品形态差异较大,开放数据、让用户自定义很可能是监控平台后期的大趋势。我们正计划结合 Grafana,给一种低成本的、较通用的个性化看图解决方案。

以上是对 DD-Falcon 的一个简单介绍。下面重点聊一下相比 Open-Falcon,我们的一些改进。

主要改进

DD-Falcon 相比 Open-Falcon,主要有如下改进:

  1. 监控数据按服务单元分类

  2. 增加垃圾数据清洗

  3. 分级索引

  4. 精简 RRA

  5. 巡检大盘支持同环比

  6. 重组看图首页

  7. 报警数据获取由推变拉

  8. 干掉报警模板

  9. 重新定义 nodata

下面,针对每一项做下详细介绍

1. 监控数据按服务单元分类

每一个监控数据点,不管是机器指标、应用指标还是业务指标,都必须标明 所属的 服务单元 su。

服务单元定义:

su = ${cluster}.${uniq-service-name}

如 gz01.falcon-query 代表 “falcon-query服务 的 gz01 部署集群”(gz01 为逻辑机房标识)

监控数据点举例:

409-640.jpg.jpg

强制 su 的约束,给后续的缓存分片、数据清洗、报警、看图展示等增加了一个常用的、可信的服务维度。如,看监控图时,服务树与 su 严格对应,查看某个服务的监控图会很方便:

410-640.jpg.jpg


2. 增加数据清洗

DD-Falcon 继承了 OF 允许用户上报自定义数据的功能,带来了很多便利,同时也给带来了垃圾数据的困扰。一些用户,将 traceid、errmsg 等非 tsd 属性的数据,直接上报到了监控系统。另外,一些通用的中间件采集,也可能会将 orderid 等信息上报到监控系统。

有几次,我们不得不通过清空历史数据的方式来清理垃圾数据,监控系统表示受伤很深。垃圾数据经常要事后发现、人肉拦截,开发人员表示无法接受。为此,我们在 nsq 到存储集群间,增加了一个垃圾数据清洗环节,如下图所示位置

411-640.jpg.jpg

每个监控数据点,都有几个固定的维度,包括 su、metric、tagk(如 host、trace)、tagv,垃圾数据一般能在某一个维度上有所体现。下面的例中,垃圾数据就体现在  tagk=trace 这个维度上。另外,垃圾数据通常较”明显”,通过简单的字符串匹配就能识别出来。

因此,我们的数据清洗主要集中在如下两个方面:

  1. 清洗维度: 服务单元 su, 指标 metric, tagk, tagv, metric/tagk

  2. 清洗方式: 字符串 相等, 前缀, 后缀, 包含

举例: 垃圾指标,及对应的清洗规则

412-640.jpg.jpg

从目前的经验来看, 95% 的清洗规则, 是通过 tagv 前缀匹配 实现的。

垃圾数据,可以通过服务的指标总量、单位时间指标增量、指标最新上报时间等方式被定位,再结合简单的学习算法,就能自动生成过滤规则。最终,数据清洗会变得自动化。

3. 分级索引

DD-Falcon 根据滴滴的用户习惯,实现了一个多级索引结构,让用户看图、数据读取更灵活

413-640.jpg.jpg

如上图,左侧是一个典型的监控指标,右侧是分级索引。用户首先选择要查看的服务,然后选择一个监控指标,最后设置每个 tagk 的取值;经过这几步,用户就能拿到一系列备选曲线,并能够从中选择自己想要的曲线。整个过程,耗时不超过 1 秒,用户体验很好。

我们采用全内存的方式,实现了上述结构,性能数据如下:

  • 1000 万指标: 构建耗时 30s, 消耗内存 2GB

  • 1 亿指标: 构建耗时 5min, 消耗内存 17GB

之所以选择内存方式,是 快速重建索引的需要(早期垃圾数据预防未到位,业务上要求 10min 内恢复服务)。当前没有计划做分片,原因在于:

  1. 廉价的高内存主机已经很普遍,

  2. 内存消耗优化后预计还可以降低 50%

灵活的索引,可能是监控数据查询语言的雏形,后续还会继续进化。

4. 精简 RRA

DD-Falcon 只保留了均值降采样、干掉了最大值&最小值降采样,原因在于 最大值&最小值降采样使用率过低。DD-Falcon 的高精度数据会保存 8 天,这个是同环比报警的需要。

精简后的 RRA,如下图所示:

414-640.jpg.jpg

按需调整 rra 后,节省了更多的磁盘资源


5. 巡检大盘支持同环比

这是一个产品形态上的完善,最终将回馈到 Open-Falcon 社区。大部分公司,业务都是以 1 天或者 1 周为周期变化的(节假日除外),因此我们的同环比只支持 1 天和 1 周两个选项。

一个典型的每日巡检大盘,如下图

415-640.jpg.jpg

其中,绿线代表今天、蓝线代表昨天、红线代表 1 周前,同环比波动一目了然。目前,60% 的巡检大盘,都是同环比。


6. 重组看图首页

我们的监控数据已经带上了服务单元标识(之前已经有了机器标识),我们的索引已经支持分级查询,因此我们将 首页看图的步骤约定为:

服务单元 –> 节点 –> 机器 –> 指标分组 –> 看图 –> 订阅大盘

指标分组,是将用户常用的、类似的指标归为一个 tab,以方便查询。

这是一个比较定制的功能,不一定适合社区环境。最终的首页看图,效果如下图:

416-640.jpg.jpg


7. 报警数据获取由推变拉

DD-Falcon 的报警数据获取,调整为 judge 主动从存储拉数据。整个报警过程,变为:

未命名1501041383.png

拉数据更灵活,可以实现多种判断条件: 多条件组合判断, 同环比报警, 集群报警等。

下图是 DD-Falcon 的报警配置页面,

417-640.jpg.jpg

补充一句,在智能报警时代,拉数据的方式必将全面取代推数据的方式,我们也算是提前做了过渡。


8. 干掉报警模板

OF 为了简化报警策略的管理,继承了 zabbix 报警模板的衣钵。从最后的效果看,模板并没有明显降低管理成本,却带来了很高的学习成本,特别是模板间的继承、覆盖云云,最后连维护者都搞不清了。

因此,DD-Falcon 干掉了模板的概念,每个报警配置就是一条策略,策略和策略之间没有关联关系,策略借助服务树的节点父子关系实现继承和动态生效,借助节点排除实现特例。虽然有可能增加管理成本,但大大降低了用户的学习成本,这个收益我们更关注。

如下是对典型场景下使用报警模板与否的利弊分析,关注的童鞋可以了解下

418-640.jpg.jpg

9. 重新定义 nodata

DD-Falcon 重新定义了 nodata 报警的业务场景,也简化了产品形态。具体,如下图

419-640.jpg.jpg

nodata 报警比较小众,只适用于 核心指标 + 数据驱动报警的场景,有兴趣可以私聊交流下。

以上,是 DD-Falcon 相比 OF 的一些主要改进,再次概括下:

  1. 监控数据按服务单元分类

  2. 增加垃圾数据清洗

  3. 分级索引

  4. 精简 RRA

  5. 巡检大盘支持同环比

  6. 重组看图首页

  7. 报警数据获取由推变拉

  8. 干掉报警模板

  9. 重新定义 nodata

已知问题

DD-Falcon 目前主要面临如下问题:

1、非周期的数据处理能力不足

  • 报警延时风险

  • 断点,环比看图不易发现问题

  • 历史数据严重有损(rrdtool 不能很好地支持非周期数据)

2、打通非时间序列化的系统

  • trace(目前通过 服务、机器、指标、时间段这四个固定维度,做关联跳转)

将来规划

DD-Falcon 的平台建设工作,已经趋于完善。后续,我们计划在如下几个方面重点投入:

1、全快准稳的发现问题

  • 智能报警(低成本)

  • 集群报警

2、辅助定位问题

  • 基于服务间关联关系的报警

  • 个性化的看图解决方案(Grafana)

社区介绍

欢迎大家,加入Open-Falcon的开源社区:

Q&A

提问1:DD-Falcon 源码也是 go 语言吗?

聂安: 除了 fe 是 react 外,其他都是 golang

提问2: 能大概说下 Falcon 相对于 prometheus 的区别优劣?

聂安: 

  1. Falcon 经过了数家公司 2+亿指标的海量数据验证,在稳定性、易用性方面都没有问题。

  2. Prometheus 是随着 Borgmon 概念而走红的新一代监控系统,在部分设计理念上更优一些。我们也在借鉴 Prometheus~

提问3:能否介绍下 DD-falcon 如何结合 cmdb 使用?

聂安: DD 内部有服务树,两者通过服务单元在数据采集、展示、报警灯方面紧密结合。特别的,我们的部署系统已经将服务树规范推广到各个服务和业务,监控系统基本可以拿来主义~

提问4:falcon 是否支持进程监控?比如从 /proc 目录下面获取数据

聂安: falcon支持进程监控,方式即为 从 /proc 获取信息。详情,可以参见  https://github.com/open-falcon/falcon-plus/tree/master/modules/agent

提问5:DD Falcon 目前有多少人在开发维护?

聂安: 3人(目前正在补强到5人)

提问6:falcon 支持按星期和月份做同比和环比吗?

聂安: 支持 1 周的同比,不支持 1 月的 环比。因为滴滴的业务大部分是以7天为周期的,没有以月为周期的。产品形态,服务于业务特点~

提问7:DD-Falcon 的新特性会提交到开源版的 Falcon 中吗?

聂安: 会,我们会主动推进这件事。另外,服务树也可能在开源考虑范围内

提问8:Falcon 支持短信、邮件和微信报警吗?

聂安: 支持。微信报警 可能要根据公司内部情况,做一下定制

提问9:小型公司,业务访问量小,人手少,应用还是单体,有必要使用DF吗,或者更轻量级监控推荐一下

聂安: Open-Falcon v0.2 非常轻量级,很适合 10-100 人左右的公司,可以考虑下: https://github.com/open-falcon

提问10:问个问题,这套系统适合多大的系统使用,比如说十几台机器的小项目适合吗?本身需要多少台机器可以部署?

聂安: DD-Falcon 和 Open-Falcon 都是可扩展的,单机部署也没问题。DD-Falcon 的监控比,大概是 1: 1000,后续做完高可用可能会降低一些

提问11:能和携程开源的 cat 对比一下吗?

聂安: cat 是基于日志的、Java 友好的监控系统,提供了通用监控、trace 等能力,对于 Java 系的公司可能会更好(抱歉 没有详细了解过)。Open-Falcon 是通用监控系统,未针对语言做优化,可以通过各个扩展来快速搭建服务能力

相关链接:

  1. http://open-falcon.org/

  2. https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

  3. https://github.com/nsqio/nsq

本文来自高可用架构群内部分享,讲师聂安,转载请注明出处,关注公众号可以更多了解高可用架构群。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构.png

原文来自:高可用架构

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
基于Falcon的滴滴内部监控系统
发布:2017-07-26 11:49:22

监控是架构可用性中最关键的环节之一,高可用架构邀请了滴滴的研发工程师聂安,分享了滴滴监控系统 DD-Falcon 近期的一些进展。

作者简介

聂安,滴滴运维研发工程师,长期从事监控、部署等运维工具平台的开发。现就职于滴滴,曾就职于阿里、小米。

很高兴和大家一起分享滴滴监控系统 DD-Falcon 近期的一些进展。今天分享主要包括如下几个部分 (技术架构、产品形态):

  • DD-Falcon 的系统架构

  • DD-Falcon 相比 Open-Falcon 的一些改进

  • 目前遇到的问题

  • 将来的几个规划

系统架构

DD-Falcon 脱胎于开源监控系统 Open-Falcon。Open-Falcon 是小米运维团队 2015 年开源的一款监控产品,目前已应用在 小米、美团、滴滴、快网、JD 等众多互联网公司,Open-Falcon 的详情可参见 [1]。

在介绍 DD-Falcon 之前,我们先介绍下 Oepn-Falcon 的系统架构。

上图是 Open-Falcon(后简称 OF)v0.1 的典型架构(v0.2 有些许调整)。橙色的线代表了配置流,绿色的线代表了数据流,紫色的线代表了报警链路。


OF 配置流

配置信息,由用户产生,并逐级应用到各个组件,主要流程是:

用户 –> UI(Portal) –> 配置中心(HBS) –> 采集(Agent), 报警(Judge), 计算(Aggr/Nodata)

其中,HBS 原意为心跳服务、后逐步发展成为配置中心。

OF 数据流

监控数据的整个生命周期,分为 采集、收集、分发、存储、消费等几个环节。

Falcon-Agent 是主要的采集器和收集器,它被部署在每个单机实例上(物理机或者容器),采集本机基础信息(如 CPU、内存、磁盘等,自动采集)、 本机部署的应用程序信息(如端口信息、进程信息等,由用户配置),同时也会作为代理、接收本机应用程序 主动上报的业务监控数据(如 App 埋点&内存统计产生的 Metrics 数据 等)。Falcon-Agent 将自己采集 或者 收集的监控数据,主动推送给 Transfer。

Transfer 是数据分发组件,将接收到的监控数据 一式两份、分别发送给 数据存储组件 Graph 和实时报警组件 Judge。Graph 和 Judge 都采用一致性哈希做数据分片,以提高横向扩展能力。Transfer 按照哈希规则,将监控数据主动推送到固定的分片上去,对数据生产者屏蔽分片细节。

Graph 提供数据存储能力。Graph 底层使用 rrdtool 做单个指标的存储,rrdtool 的特点决定了单个指标存储空间固定、数据自动降采样,这个特点很适合监控热数据的存储。Graph 在应用层对 rrdtool 做了写优化(缓存, 分批磁盘写等),使得一个 Graph 实例能够处理 8万+/秒的数据点写入频率。

Graph 一般由多个实例构成集群,不同实例存储不同的监控数据。为了屏蔽存储集群的分片细节,提供了 Query 模块,实现了和 Transfer 一样的一致性哈希分片逻辑,对数据消费者屏蔽存储分片细节。Transfer + Graph + Query 构成了功能完整、横向可扩展、技术门槛低的分布式时间序列化数据存储系统,这是 Open-Falcon 的核心竞争力所在。

存储之上,长出了用户最常用的监控看图功能,对应到上图中的 Dashboard 模块。另外,集群聚合模块Aggr、数据中断报警模块 Nodata 都会消费存储的数据。

OF 报警链路

Judge 和 Alarm 两个模块构成了 OF 的报警链路。Judge 由 Transfer 上报的监控数据驱动,结合用户配置的报警策略,实时计算、产生报警事件。Alarm 组件对报警事件做一些收敛处理后,将最终的报警消息推送到各报警通道。OF 的报警,是由监控数据驱动的,没有数据上报 就 不会报警。

以上大概介绍了下 OF 的系统架构。相比 OF,DD-Falcon(下面简称 DF)的主要组件结构如下。

408-640.jpg.jpg

配置流由棕色曲线表示,数据流由黑色曲线表示。

配置流从右向左,依次为:

用户 –> 配置(fe/api) –> 存储(config) –> 生效: 采集(agent/log/net/url), 清洗(transfer), 报警(judge)

数据流从左向右,依次为:

服务(apps) –> 采集 –> 收集 –> 清洗 –> 存储 –> 消费: 报警, 看图, 第三方

DF 的配置流,与 OF 的相似,不再赘述。DF 的数据流,核心存储部分继续使用 OF 原生组件(transfer + graph + query), 同时在数据采集、清洗、报警等方面做了调整。


DF 采集

DF 的采集覆盖了机器指标(如CPU、内存、磁盘)、应用指标(如端口信息、进程信息)、业务指标(如 rps、error_ratio、latency)等。

业务指标,主要是通过 log 本机日志实时分 和 metrics 业务统计 获取的。log 分析方式是历史沿袭,比较方便、但资源消耗不可控,正在被逐步弱化。

metrics 是类似开源 statsd [2] 的解决方案,通过业务代码埋点 将状态数据(rpc 调用质量、计数等)上报到本机 metrics-agent,再经由 metrics-agent 周期性的统计聚合,将最终的业务统计数据上报到 本机 agent 上(agent 充当了收集器)。

metrics 对于无状态的服务非常友好,正在逐步成为主流(有状态的服务可以在 应用内存中 做统计计数,正如 OF 一样)。

机器指标、应用指标的采集主要是由 本机上的 agent(DF-Agent)完成的,也会自动采集、主动上报数据,与 OF 相似,不再赘述。

DF 收集

为了应对上报峰值、网络抖动等问题,DF 增加了 nsq [3] 数据缓存队列,agent上报的监控数据先被q到nsq、再由分发组件消费。nsq按照服务单元(su) 划分topic。


DF 清洗

在nsq数据缓存和存储之间,增加了一个数据清洗环节,实现了容量控制、垃圾数据过滤等机制,用于监控系统的自我保护。后面会详细讲述。


DF 存储

DF 复用了 OF 的 transfer + graph + query 三个组件,在此基础上将数据索引模块index独立出来(OF 使用 mysql 做简单的查询索引)。索引信息,是在指标写入graph时同步生成的,可以满足分级查询的需求。索引模块是 DF 对 OF 的主要改进之一。


DF 消费: 看图

看图,是长在存储上的一个功能。DF 的支持动态看图、临时图、监控大盘等产品形态,支持同环比看图,支持灵活的聚合展示等。


DF 消费: 报警

与 OF 相比,报警变成了存储模块的一个下游,不再拥有独立的数据上报链路。judge 模块从 config 处获取报警配置,然后按需从存储组件拉取命中的指标数据,进行实时报警计算,产出报警事件。alarm 模块做报警收敛处理,并将最终的报警通知交给报警通道服务 notify 处理。notify 支持多种报警通道,包括钉钉、语音、短信、邮件等。

DF 将报警数据的获取方式由推变拉,给报警判断带来了巨大的灵活性。报警方式由推变拉是 DF 对 OF 的另一个主要改进。

DF 消费: 第三方

DF 的监控数据完全开放,供各个业务线使用。特别的,不同的业务场景看图功能的产品形态差异较大,开放数据、让用户自定义很可能是监控平台后期的大趋势。我们正计划结合 Grafana,给一种低成本的、较通用的个性化看图解决方案。

以上是对 DD-Falcon 的一个简单介绍。下面重点聊一下相比 Open-Falcon,我们的一些改进。

主要改进

DD-Falcon 相比 Open-Falcon,主要有如下改进:

  1. 监控数据按服务单元分类

  2. 增加垃圾数据清洗

  3. 分级索引

  4. 精简 RRA

  5. 巡检大盘支持同环比

  6. 重组看图首页

  7. 报警数据获取由推变拉

  8. 干掉报警模板

  9. 重新定义 nodata

下面,针对每一项做下详细介绍

1. 监控数据按服务单元分类

每一个监控数据点,不管是机器指标、应用指标还是业务指标,都必须标明 所属的 服务单元 su。

服务单元定义:

su = ${cluster}.${uniq-service-name}

如 gz01.falcon-query 代表 “falcon-query服务 的 gz01 部署集群”(gz01 为逻辑机房标识)

监控数据点举例:

409-640.jpg.jpg

强制 su 的约束,给后续的缓存分片、数据清洗、报警、看图展示等增加了一个常用的、可信的服务维度。如,看监控图时,服务树与 su 严格对应,查看某个服务的监控图会很方便:

410-640.jpg.jpg


2. 增加数据清洗

DD-Falcon 继承了 OF 允许用户上报自定义数据的功能,带来了很多便利,同时也给带来了垃圾数据的困扰。一些用户,将 traceid、errmsg 等非 tsd 属性的数据,直接上报到了监控系统。另外,一些通用的中间件采集,也可能会将 orderid 等信息上报到监控系统。

有几次,我们不得不通过清空历史数据的方式来清理垃圾数据,监控系统表示受伤很深。垃圾数据经常要事后发现、人肉拦截,开发人员表示无法接受。为此,我们在 nsq 到存储集群间,增加了一个垃圾数据清洗环节,如下图所示位置

411-640.jpg.jpg

每个监控数据点,都有几个固定的维度,包括 su、metric、tagk(如 host、trace)、tagv,垃圾数据一般能在某一个维度上有所体现。下面的例中,垃圾数据就体现在  tagk=trace 这个维度上。另外,垃圾数据通常较”明显”,通过简单的字符串匹配就能识别出来。

因此,我们的数据清洗主要集中在如下两个方面:

  1. 清洗维度: 服务单元 su, 指标 metric, tagk, tagv, metric/tagk

  2. 清洗方式: 字符串 相等, 前缀, 后缀, 包含

举例: 垃圾指标,及对应的清洗规则

412-640.jpg.jpg

从目前的经验来看, 95% 的清洗规则, 是通过 tagv 前缀匹配 实现的。

垃圾数据,可以通过服务的指标总量、单位时间指标增量、指标最新上报时间等方式被定位,再结合简单的学习算法,就能自动生成过滤规则。最终,数据清洗会变得自动化。

3. 分级索引

DD-Falcon 根据滴滴的用户习惯,实现了一个多级索引结构,让用户看图、数据读取更灵活

413-640.jpg.jpg

如上图,左侧是一个典型的监控指标,右侧是分级索引。用户首先选择要查看的服务,然后选择一个监控指标,最后设置每个 tagk 的取值;经过这几步,用户就能拿到一系列备选曲线,并能够从中选择自己想要的曲线。整个过程,耗时不超过 1 秒,用户体验很好。

我们采用全内存的方式,实现了上述结构,性能数据如下:

  • 1000 万指标: 构建耗时 30s, 消耗内存 2GB

  • 1 亿指标: 构建耗时 5min, 消耗内存 17GB

之所以选择内存方式,是 快速重建索引的需要(早期垃圾数据预防未到位,业务上要求 10min 内恢复服务)。当前没有计划做分片,原因在于:

  1. 廉价的高内存主机已经很普遍,

  2. 内存消耗优化后预计还可以降低 50%

灵活的索引,可能是监控数据查询语言的雏形,后续还会继续进化。

4. 精简 RRA

DD-Falcon 只保留了均值降采样、干掉了最大值&最小值降采样,原因在于 最大值&最小值降采样使用率过低。DD-Falcon 的高精度数据会保存 8 天,这个是同环比报警的需要。

精简后的 RRA,如下图所示:

414-640.jpg.jpg

按需调整 rra 后,节省了更多的磁盘资源


5. 巡检大盘支持同环比

这是一个产品形态上的完善,最终将回馈到 Open-Falcon 社区。大部分公司,业务都是以 1 天或者 1 周为周期变化的(节假日除外),因此我们的同环比只支持 1 天和 1 周两个选项。

一个典型的每日巡检大盘,如下图

415-640.jpg.jpg

其中,绿线代表今天、蓝线代表昨天、红线代表 1 周前,同环比波动一目了然。目前,60% 的巡检大盘,都是同环比。


6. 重组看图首页

我们的监控数据已经带上了服务单元标识(之前已经有了机器标识),我们的索引已经支持分级查询,因此我们将 首页看图的步骤约定为:

服务单元 –> 节点 –> 机器 –> 指标分组 –> 看图 –> 订阅大盘

指标分组,是将用户常用的、类似的指标归为一个 tab,以方便查询。

这是一个比较定制的功能,不一定适合社区环境。最终的首页看图,效果如下图:

416-640.jpg.jpg


7. 报警数据获取由推变拉

DD-Falcon 的报警数据获取,调整为 judge 主动从存储拉数据。整个报警过程,变为:

未命名1501041383.png

拉数据更灵活,可以实现多种判断条件: 多条件组合判断, 同环比报警, 集群报警等。

下图是 DD-Falcon 的报警配置页面,

417-640.jpg.jpg

补充一句,在智能报警时代,拉数据的方式必将全面取代推数据的方式,我们也算是提前做了过渡。


8. 干掉报警模板

OF 为了简化报警策略的管理,继承了 zabbix 报警模板的衣钵。从最后的效果看,模板并没有明显降低管理成本,却带来了很高的学习成本,特别是模板间的继承、覆盖云云,最后连维护者都搞不清了。

因此,DD-Falcon 干掉了模板的概念,每个报警配置就是一条策略,策略和策略之间没有关联关系,策略借助服务树的节点父子关系实现继承和动态生效,借助节点排除实现特例。虽然有可能增加管理成本,但大大降低了用户的学习成本,这个收益我们更关注。

如下是对典型场景下使用报警模板与否的利弊分析,关注的童鞋可以了解下

418-640.jpg.jpg

9. 重新定义 nodata

DD-Falcon 重新定义了 nodata 报警的业务场景,也简化了产品形态。具体,如下图

419-640.jpg.jpg

nodata 报警比较小众,只适用于 核心指标 + 数据驱动报警的场景,有兴趣可以私聊交流下。

以上,是 DD-Falcon 相比 OF 的一些主要改进,再次概括下:

  1. 监控数据按服务单元分类

  2. 增加垃圾数据清洗

  3. 分级索引

  4. 精简 RRA

  5. 巡检大盘支持同环比

  6. 重组看图首页

  7. 报警数据获取由推变拉

  8. 干掉报警模板

  9. 重新定义 nodata

已知问题

DD-Falcon 目前主要面临如下问题:

1、非周期的数据处理能力不足

  • 报警延时风险

  • 断点,环比看图不易发现问题

  • 历史数据严重有损(rrdtool 不能很好地支持非周期数据)

2、打通非时间序列化的系统

  • trace(目前通过 服务、机器、指标、时间段这四个固定维度,做关联跳转)

将来规划

DD-Falcon 的平台建设工作,已经趋于完善。后续,我们计划在如下几个方面重点投入:

1、全快准稳的发现问题

  • 智能报警(低成本)

  • 集群报警

2、辅助定位问题

  • 基于服务间关联关系的报警

  • 个性化的看图解决方案(Grafana)

社区介绍

欢迎大家,加入Open-Falcon的开源社区:

Q&A

提问1:DD-Falcon 源码也是 go 语言吗?

聂安: 除了 fe 是 react 外,其他都是 golang

提问2: 能大概说下 Falcon 相对于 prometheus 的区别优劣?

聂安: 

  1. Falcon 经过了数家公司 2+亿指标的海量数据验证,在稳定性、易用性方面都没有问题。

  2. Prometheus 是随着 Borgmon 概念而走红的新一代监控系统,在部分设计理念上更优一些。我们也在借鉴 Prometheus~

提问3:能否介绍下 DD-falcon 如何结合 cmdb 使用?

聂安: DD 内部有服务树,两者通过服务单元在数据采集、展示、报警灯方面紧密结合。特别的,我们的部署系统已经将服务树规范推广到各个服务和业务,监控系统基本可以拿来主义~

提问4:falcon 是否支持进程监控?比如从 /proc 目录下面获取数据

聂安: falcon支持进程监控,方式即为 从 /proc 获取信息。详情,可以参见  https://github.com/open-falcon/falcon-plus/tree/master/modules/agent

提问5:DD Falcon 目前有多少人在开发维护?

聂安: 3人(目前正在补强到5人)

提问6:falcon 支持按星期和月份做同比和环比吗?

聂安: 支持 1 周的同比,不支持 1 月的 环比。因为滴滴的业务大部分是以7天为周期的,没有以月为周期的。产品形态,服务于业务特点~

提问7:DD-Falcon 的新特性会提交到开源版的 Falcon 中吗?

聂安: 会,我们会主动推进这件事。另外,服务树也可能在开源考虑范围内

提问8:Falcon 支持短信、邮件和微信报警吗?

聂安: 支持。微信报警 可能要根据公司内部情况,做一下定制

提问9:小型公司,业务访问量小,人手少,应用还是单体,有必要使用DF吗,或者更轻量级监控推荐一下

聂安: Open-Falcon v0.2 非常轻量级,很适合 10-100 人左右的公司,可以考虑下: https://github.com/open-falcon

提问10:问个问题,这套系统适合多大的系统使用,比如说十几台机器的小项目适合吗?本身需要多少台机器可以部署?

聂安: DD-Falcon 和 Open-Falcon 都是可扩展的,单机部署也没问题。DD-Falcon 的监控比,大概是 1: 1000,后续做完高可用可能会降低一些

提问11:能和携程开源的 cat 对比一下吗?

聂安: cat 是基于日志的、Java 友好的监控系统,提供了通用监控、trace 等能力,对于 Java 系的公司可能会更好(抱歉 没有详细了解过)。Open-Falcon 是通用监控系统,未针对语言做优化,可以通过各个扩展来快速搭建服务能力

相关链接:

  1. http://open-falcon.org/

  2. https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

  3. https://github.com/nsqio/nsq

本文来自高可用架构群内部分享,讲师聂安,转载请注明出处,关注公众号可以更多了解高可用架构群。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构.png

原文来自:高可用架构

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

选择想要的接口, 看看能免费获取多少次调用 选择(单选)或填写想要的接口
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 证件识别
  • 企业工商信息
短信API服务
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 证件识别
  • 企业工商信息
  • 确定
选择您的身份
请选择寻找接口的目的
预计每月调用量
请选择预计每月调用量
产品研发的阶段
请选择产品研发的阶段
×

前往领取
电话 0512-88869195
×
企业用户认证,
可获得1000次免费调用
注册登录 > 企业账户认证 > 领取接口包
企业用户认证领取接口包 立即领取
× 企业用户认证,
可获得1000次免费调用,立即领取>
数 据 驱 动 未 来
Data Drives The Future