本篇文章介绍下openfalcon的基本原理和使用，粒度相对较粗，主要目的是使大家迅速掌握open-falcon的数据模型、功能模块、运作流程和使用方法。具体分解如下，
- 基本介绍
- 技术架构
- 数据模型
- 主要模块
- 如何使用
- 其他
一、基本介绍
Open-Falcon 是小米研发的一款开源的互联网企业级监控系统解决方案，目前小米、金山云、美团、京东金融、滴滴等公司有在使用。
下面我们遵循着问题来展开整篇文章。首先，open-falcon能做什么？
a.主要特点有
①数据采集免配置：agent自发现、支持Plugin、主动推送模式
②容量水平扩展：生产环境每秒50万次数据收集、告警、存储、绘图，可持续水平扩展。
③告警策略自发现：Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动作。
④告警设置人性化：支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈
值、支持维护周期，支持告警合并。
⑤历史数据高效查询：秒级返回上百个指标一年的历史数据。
⑥Dashboard人性化：多维度的数据展示，用户自定义Dashboard等功能。
⑦架构设计高可用：整个系统无核心单点，易运维，易部署。
其次，openfalcon能对哪些项目做监控 ？
1）基础监控。
比如CPU、Load、内存、磁盘、IO、网络相关、内核参数、ss 统计输出、端口存活状态、进程存活状态、核心服务的进程存活信息采集、关键业务进程资源消耗、NTP offset采集、DNS解析采集，这些指标，都是open-falcon的agent组件直接支持的。
2）业务应用监控。
比如我的应用服务部署上线后，需要统计某个接口的平均耗时、调用次数、成功率等信息，这些属于业务应用的监控。这里需要研发人员编写脚本等方式来收集数据，然后发送到open-falcon的transfer组件。
3）第三方开源软件监控。
比如mysql、lvs、nginx、redis、mq等，需单独编写采集脚本或插件，这些常见的软件，一般开源社区都有提供相应的脚本。
这里有个openfalcon与其他一些监控软件的对比，
个人觉得，falcon比较大的优势在于扩展性和灵活性方面。
二、技术架构
涉及架构或结构时，图是比较好的展示方式，下图摘自官网，可以看出组件及组件间协作。
绿色的粗线表示数据传输流程，橙黄色虚线表示控制流（策略，告警），浅蓝色虚线标识查询流程；
下图是一个相对规整的数据流图，更有助于理解：
具体而言，整体的运作流程如下：
1、目标服务器运行agent
2、agent采集各类监控项数值，传给transfer
3、transfer校验和整理监控项数值，做一致性hash分片，传给对应的judge模块以验证是否触发告警
4、transfer整理监控项数值，做一致性hash分片，传输给graph以进行数据的存储
5、judge根据具体报警策略或阈值进行告警判断，如触发告警则组装告警event事件，写入缓存队列。
6、alarm和sender根据event事件中的判定结果，执行event，像用户组发送短信或邮件。
7、graph收到监控项数据后，将数据存储成RRD文件格式，进行归档，并提供查询接口。
8、query将调用graph的查询接口，将监控数据传送到dashboard以进行页面展示。
9、dashboard则渲染页面，展示曲线报表图等。
10、portal提供页面供用户配置机器分组、报警策略、表达式、nodata等配置。
三、数据模型
灵活强大的数据模型能提高监控系统的使用效率和灵活性（这小节提到的数据模型应该叫监控项数据模型），open-falcon的数据模型长什么样？设计初衷又是什么？
open-falcon的"监控项"模型如下，
{
metric: cpu.busy, // 监控项名称
endpoint: open-falcon-host, // 目标服务器的主机名
tags: srv=falcon,group=az1, // tag标签，作用是聚合和归类，在配报警策略时会比较方便。
value: 10, // 监控项数值
timestamp: `date +%s`, // 采集时间
counterType: GAUGE, // 监控项类型。
step: 60 // 采集间隔。 秒。
}
这种模型的主要好处：一是方便从多个维度来配置告警，二是可以灵活的进行自主数据采集。
第一点，比如tag的使用起到了给机器进行归类的作用，比如有3台机器：host1、host2和host3，如果tags依次配置为"group=java", "group=java"和"group=erlang"，那么配置报警策略"metric=cpu/group=java“时就只会对java标签的机器（即host1，host2)生效。
第二点，由于agent会自发现的采集很多基本的系统指标，但是对业务应用等需要研发人员自己写脚本收集和上报。这里openfalcon定义了监控项模型，相当于定义了一个规范，当研发人员需要监控某个对象（比如mysql、redis等），只需采集数据，并遵守规范包装成监控项模型，再上报即可。
open-falcon使用的监控项有哪些类型 ？
主要有三种：
(1) GAUGE：实测值，直接使用采集的原始数值，比如气温；
(2) COUNTER：记录连续增长的数据，只增不减。比如汽车行驶里程，网卡流出流量，cpu_idle等；
(3) DERIVE：变化率，类似COUNTER ，但是可增可减。
四、主要模块
4-1. agent
- 首先，什么是Agent？
agent是go开发的daemon程序，用于自发现的采集机器的各种数据和指标。部署在目标机器上，无需在server端进行任何配置，安装后启动即工作，是open-falcon的”数据采集者”。
- 主要功能？
1）自发现的采集各类数据和指标，上报transfer；
2）与hbs进行心跳连接通信，上报主机状态，同步插件和监控进程、监控端口；
- 可采集的数据有哪些？
基础监控项(硬件,负载)、业务应用监控数据、各种开源软件监控数据等。
- falcon是如何采集的？
1）基础监控
一般是读系统文件或执行基本命令，然后对原始值进行处理。比如cpu和内存信息是通过读取/proc/stat和/proc/meminfo获得；端口监控，是通过ss –ln 来判断指定端口是否处于listen状态；
2）业务应用监控
一般由”插件”或”采集脚本”实现，需自己编写。比如接口的调用次数、耗时、失败次数、成功次数都属于这类。(日志、基础统计工具)
3）开源软件监控
一般开源社区都有提供采集脚本。
- 如何扩展agent -- 插件？
除了基础监控项，有时用户想扩展agent的功能以采集更多指标，openfalcon提供了插件机制。插件的使用可以参考官方git文档，下面摘抄了作者们的一段话，其实就是一些采集脚本及同步执行的方式。
“插件设计思路：
a) 写一个采集数据的脚本
b) 把脚本分发到需要采集数据的机器上
c) 写一个cron每隔一段时间去跑这个脚本
d) 收集脚本的输出，调用server的接口去push数据
e) 根据需求相应的对脚本做上线、下线、升级”
- agent的工作流程：
4-2. Transfer组件
- 什么是transfer？
open-falcon的后端门户，监控数据的中转接点。
- transfer的职责角色？
提供数据接收接口和自定义脚本push数据；
根据一致性hash算法将内存队列中的数据发送给graph和judge模块；(重点)
为每个后端实例创建一个 定长Queue；
为每个后端实例维护一个rpc连接池；
这里每个后端的graph或judge实例都建立了一个rpc连接池和一个定长Queue队列。有两个小点这里提下：1，定长Queue队列目的是应对高峰流量，丢失一部分高峰时段的数据保证了后端的graph和judge组件不受影响； 2. v1.0版本的openfalcon中，每个graph实例可以有多个ip而且transfer会给每个ip发送相同的一份数据，但是judge中每个实例只能有1个ip。
- transfer的工作流程？
4-3. graph组件
- 什么是graph？graph的职责？
存储监控数据、提供监控数据的高效查询接口。
- graph的架构图(摘自项目git)：
4-4. judge&alarm&sender组件
这三个组件是报警的链路，负责判断是否触发报警，理论上可以进化成一个模块。感兴趣的可以看代码，很多匹配逻辑。
judge: 记载策略到缓存，判断监控项是否触发告警策略，发告警事件；
alarm&sender: 读取告警事件；发邮件、短信等；
4-5. hbs组件
- 什么是hbs，hbs的职责？
heart beat server，心跳服务器，更多承担”配置中心”的角色。
1）Agent可以从hbs同步”报警策略”、”进程存活监控”、”端口存活监控”等信息。
2）agent定期发送心跳信息，hbs负责维护host表；
- hbs的工作流程：
五、如何使用？
5.1 目标
(1)、如何监控基本监控项？
(2)、如何使用插件，监控“第三方应用”？如何监控“端口/进程”？
(3)、如何配置“告警规则”?
(4)、如何使用hostGroup、template、expression、nodata、uic？
(5)、如何更好管理机器？如hostName、hostGroup的命名约定；
5.2 先要理解的一些概念
(1)、机器分组
(2)、用户组
(3)、模板
(4)、表达式
(5)、报警策略
(6)、回调动作
5.3 如何采集基本监控项 ？
在目标机器上部署agent，正确配置，启动即可；
5.4 如何监控“第三方应用”，如mysql/lvs/nginx？
自己写脚本，上报到open-falcon；或者使用开源的插件或脚本；
https://book.open-falcon.org/zh/philosophy/data-collect.html
5.5 如何监控“端口存活”、“进程存活” ？
在port页面，新增expression或template，给指定进程或端口配置报警策略；
5.6 使用机器分组和报警策略模板？
这里刚开始接触时觉得特别麻烦，后来拉出代码，分析其关联关系，梳理出了模型及关系图，一切变得清晰。下图依次是：hostgroup机器组管理、Tempalte报警策略模板、模型关系UML图。重点理解UML图，然后去页面上操作和比较下。
b.
c.
5.7 如何使用表达式 ？“策略表达式”与”策略模板”的区别？
表达式比较简洁，在结合tag时可以使用策略表达式。
当无法区分类别时，比如所有监控项都没有加tag，只有进行人工分类，即使用”机器分组”，然后将”策略模板”绑定到”机器分组”。
六、其他
其他需要自己翻文档或代码了，比如nodata，aggravation等等。通过这篇文章，希望能掌握open-falcon的运作机制，数据模型，如何使用它。
