用户名：燃烧的大脑
文章数：14
访问量：1721
注册日期：
阅读量：1297
阅读量：3317
阅读量：589015
阅读量：475651
51CTO推荐博文
open-falcon 实现各自独立报警先来说说这篇文章要实现什么具体功能。这里只说配置思路，不去详细交大家怎么配置，只要理解各个配置的意义，就能很快配置出来。配置还是很简单的，我也就是1年多一点儿的工作经验，我连着装整个服务和配置分布式用了一个礼拜。所以说，各位大神应该更速度。前几天我接到新任务，要用阿里的 open-falcon 的 去管理配置银商、兆维等机房的报警规则，但是报警又不能让阿里这边承担，必须要让各个机房各自报各自的警。意思就是从阿里云这边登录open-falcon的管理端，可以在portal里配置兆维等其他机房的报警规则，触发报警后，报警邮件是由它们各自发出去的，并不是让 阿里云这边发送，阿里云这边只提供配置规则，存储数据，制作图表，各个机房只负责发送自己的报警邮件。这样配置的原因是为了防止阿里那边judge服务挂了后，影响到其他机房的正常监控报警。只要阿里的mysql数据库不死，其他机房的监控报警都可以正常运行，别的机房监控挂了也不会影响其他机房。好吧~实在不知道怎么用简单明了的话来表达，以上这些碌慕馐拖Ｍ吹娜四芸疵靼住Ｏ肓讼牖故巧细鐾急冉虾茫狭肆椒菀谎耐际欠奖阋槐叨烈槐呖赐祭斫狻＃ê谏指钕咦蟊呶slave，右master）。如果想在master方绘图，那么参照亮蓝色的线。下面开始介绍思路：首先。slave（方便描述，把主的服务端阿里云那边叫master，别的机房的叫slave）这边的报警所用到的组件分别是heartbeat server（hbs）、judge、alarm、邮件组件（我用的是+sender）。那么是怎么用这几个组件去关联master那边来实现slave自己独立判断故障并且发送邮件呢？&它们的数据是这样传输的： &salve端的 agent将采集到的数据发送给slave这边的transfer，transfer将收到的数据给slave方的judge一份（slave方的judge用来判断报警用的），同时也将数据发送给master方的graph一份（这样就可以将曲线图在master端绘制了）。&原版的官方文档是说的transfer收到数据会发送给judge和graph各一份& 这里我们只做报警功能，可以忽略发送给master方的graph的数据。& salve端的judge在收到数据后，会到salve端的hbs（heartbeat server）内拿报警规则去和收到的transfer发来的数据判断对比是否触发报警，如果报警成立，那么salve端的judge会将报警数据发到salve端的的redis内，salve端的alarm发现salve端的redis内有数据，便会将信息推送给salve端的sender发出报警邮件。那么问题来了，salve端的hbs（heartbeat server）内的报警规则哪里来？我们的办法是，将salve端的hbs（heartbeat server）的hosts表数据配置为从master端同步过来，具体配置方法，在官方文档内有说明。这样，我们就可以实现在master端的portal内添加报警规则，添加规则后portal的数据写在musql的portal表内。我们开启3306的防火墙规则，这样我们就可以从slave端来拉取master端的报警规则了。最后说一句，open-falcon毕竟是中国人研发的，配置很容易理解，明白数据传输过程和工作原理，配置很简单的。不常写博客，不喜欢的希望不要喷。希望需要这样配置的人可以很快配置成功。本文出自 “” 博客，谢绝转载！
了这篇文章
类别：┆阅读(0)┆评论(0)基于Falcon的滴滴内部监控系统
基于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）的主要组件结构如下。配置流由棕色曲线表示，数据流由黑色曲线表示。配置流从右向左，依次为:用户 –& 配置(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，主要有如下改进:监控数据按服务单元分类增加垃圾数据清洗分级索引精简 RRA巡检大盘支持同环比重组看图首页报警数据获取由推变拉干掉报警模板重新定义 nodata下面，针对每一项做下详细介绍1. 监控数据按服务单元分类每一个监控数据点，不管是机器指标、应用指标还是业务指标，都必须标明 所属的 服务单元 su。服务单元定义:su = ${cluster}.${uniq-service-name}如 gz01.falcon-query 代表 “falcon-query服务 的 gz01 部署集群”（gz01 为逻辑机房标识）监控数据点举例：强制 su 的约束，给后续的缓存分片、数据清洗、报警、看图展示等增加了一个常用的、可信的服务维度。如，看监控图时，服务树与 su 严格对应，查看某个服务的监控图会很方便:2. 增加数据清洗DD-Falcon 继承了 OF 允许用户上报自定义数据的功能，带来了很多便利，同时也给带来了垃圾数据的困扰。一些用户，将 traceid、errmsg 等非 tsd 属性的数据，直接上报到了监控系统。另外，一些通用的中间件采集，也可能会将 orderid 等信息上报到监控系统。有几次，我们不得不通过清空历史数据的方式来清理垃圾数据，监控系统表示受伤很深。垃圾数据经常要事后发现、人肉拦截，开发人员表示无法接受。为此，我们在 nsq 到存储集群间，增加了一个垃圾数据清洗环节，如下图所示位置每个监控数据点，都有几个固定的维度，包括 su、metric、tagk(如 host、trace)、tagv，垃圾数据一般能在某一个维度上有所体现。下面的例中，垃圾数据就体现在 tagk=trace 这个维度上。另外，垃圾数据通常较”明显”，通过简单的字符串匹配就能识别出来。因此，我们的数据清洗主要集中在如下两个方面:清洗维度: 服务单元 su, 指标 metric, tagk, tagv, metric/tagk清洗方式: 字符串 相等, 前缀, 后缀, 包含举例: 垃圾指标，及对应的清洗规则:从目前的经验来看, 95% 的清洗规则, 是通过 tagv 前缀匹配 实现的。垃圾数据，可以通过服务的指标总量、单位时间指标增量、指标最新上报时间等方式被定位，再结合简单的学习算法，就能自动生成过滤规则。最终，数据清洗会变得自动化。3. 分级索引DD-Falcon 根据滴滴的用户习惯，实现了一个多级索引结构，让用户看图、数据读取更灵活。如上图，左侧是一个典型的监控指标，右侧是分级索引。用户首先选择要查看的服务，然后选择一个监控指标，最后设置每个 tagk 的取值；经过这几步，用户就能拿到一系列备选曲线，并能够从中选择自己想要的曲线。整个过程，耗时不超过 1 秒，用户体验很好。我们采用全内存的方式，实现了上述结构，性能数据如下:1000 万指标: 构建耗时 30s, 消耗内存 2GB1 亿指标: 构建耗时 5min, 消耗内存 17GB之所以选择内存方式，是 快速重建索引的需要（早期垃圾数据预防未到位，业务上要求 10min 内恢复服务）。当前没有计划做分片，原因在于:廉价的高内存主机已经很普遍，内存消耗优化后预计还可以降低 50%灵活的索引，可能是监控数据查询语言的雏形，后续还会继续进化。4. 精简 RRADD-Falcon 只保留了均值降采样、干掉了最大值&最小值降采样，原因在于 最大值&最小值降采样使用率过低。DD-Falcon 的高精度数据会保存 8 天，这个是同环比报警的需要。精简后的 RRA，如下图所示:按需调整 rra 后，节省了更多的磁盘资源5. 巡检大盘支持同环比这是一个产品形态上的完善，最终将回馈到 Open-Falcon 社区。大部分公司，业务都是以 1 天或者 1 周为周期变化的（节假日除外），因此我们的同环比只支持 1 天和 1 周两个选项。一个典型的每日巡检大盘，如下图其中，绿线代表今天、蓝线代表昨天、红线代表 1 周前，同环比波动一目了然。目前，60% 的巡检大盘，都是同环比。6. 重组看图首页我们的监控数据已经带上了服务单元标识（之前已经有了机器标识），我们的索引已经支持分级查询，因此我们将 首页看图的步骤约定为：服务单元 –& 节点 –& 机器 –& 指标分组 –& 看图 –& 订阅大盘指标分组，是将用户常用的、类似的指标归为一个 tab，以方便查询。这是一个比较定制的功能，不一定适合社区环境。最终的首页看图，效果如下图:7. 报警数据获取由推变拉DD-Falcon 的报警数据获取，调整为 judge 主动从存储拉数据。整个报警过程，变为:拉数据更灵活，可以实现多种判断条件: 多条件组合判断, 同环比报警, 集群报警等。下图是 DD-Falcon 的报警配置页面，补充一句，在智能报警时代，拉数据的方式必将全面取代推数据的方式，我们也算是提前做了过渡。8. 干掉报警模板OF 为了简化报警策略的管理，继承了 zabbix 报警模板的衣钵。从最后的效果看，模板并没有明显降低管理成本，却带来了很高的学习成本，特别是模板间的继承、覆盖云云，最后连维护者都搞不清了。因此，DD-Falcon 干掉了模板的概念，每个报警配置就是一条策略，策略和策略之间没有关联关系，策略借助服务树的节点父子关系实现继承和动态生效，借助节点排除实现特例。虽然有可能增加管理成本，但大大降低了用户的学习成本，这个收益我们更关注。如下是对典型场景下使用报警模板与否的利弊分析，关注的童鞋可以了解下9. 重新定义 nodataDD-Falcon 重新定义了 nodata 报警的业务场景，也简化了产品形态。具体，如下图nodata 报警比较小众，只适用于 核心指标 + 数据驱动报警的场景，有兴趣可以私聊交流下。以上，是 DD-Falcon 相比 OF 的一些主要改进，再次概括下:已知问题DD-Falcon 目前主要面临如下问题：1、非周期的数据处理能力不足报警延时风险断点，环比看图不易发现问题历史数据严重有损(rrdtool 不能很好地支持非周期数据)2、打通非时间序列化的系统trace（目前通过 服务、机器、指标、时间段这四个固定维度，做关联跳转）将来规划DD-Falcon 的平台建设工作，已经趋于完善。后续，我们计划在如下几个方面重点投入:1、全快准稳的发现问题智能报警（低成本）集群报警2、辅助定位问题基于服务间关联关系的报警个性化的看图解决方案（Grafana）社区介绍欢迎大家，加入Open-Falcon的开源社区:官网: http://open-falcon.orgGithub: /open-falconQQ讨论组:
/ 微信公众号: OpenFalconQ&A提问1：DD-Falcon 源码也是 go 语言吗？聂安: 除了 fe 是 react 外，其他都是 golang提问2： 能大概说下 Falcon 相对于 prometheus 的区别优劣？聂安:Falcon 经过了数家公司 2+亿指标的海量数据验证，在稳定性、易用性方面都没有问题。Prometheus 是随着 Borgmon 概念而走红的新一代监控系统，在部分设计理念上更优一些。我们也在借鉴 Prometheus~提问3：能否介绍下 DD-falcon 如何结合 cmdb 使用？聂安: DD 内部有服务树，两者通过服务单元在数据采集、展示、报警灯方面紧密结合。特别的，我们的部署系统已经将服务树规范推广到各个服务和业务，监控系统基本可以拿来主义~提问4：falcon 是否支持进程监控？比如从 /proc 目录下面获取数据聂安: falcon支持进程监控，方式即为 从 /proc 获取信息。详情，可以参见 /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 人左右的公司，可以考虑下: /open-falcon提问10：问个问题，这套系统适合多大的系统使用，比如说十几台机器的小项目适合吗？本身需要多少台机器可以部署？聂安: DD-Falcon 和 Open-Falcon 都是可扩展的，单机部署也没问题。DD-Falcon 的监控比，大概是 1: 1000，后续做完高可用可能会降低一些提问11：能和携程开源的 cat 对比一下吗？聂安: cat 是基于日志的、Java 友好的监控系统，提供了通用监控、trace 等能力，对于 Java 系的公司可能会更好（抱歉 没有详细了解过）。Open-Falcon 是通用监控系统，未针对语言做优化，可以通过各个扩展来快速搭建服务能力
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: 分享一些最新的新技术
作者最新文章小米监控系统开源
Ops make no ops | Ops的目标是没有Ops，嗯！
小米监控系统开源
& 5,996 浏览
This article was posted in
and tagged , . Bookmark the . Follow comments with the .
or leave a trackback: .小米运维―互联网企业级监控系统实践_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
小米运维―互联网企业级监控系统实践
阅读已结束，下载文档到电脑
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩12页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢}