open-falcon原理以及使用(不断更新)

目录

文章目录

概述

Open-falcon的特性

监控控范围

      1）基础监控。

      2）业务应用监控。

      3）第三方开源软件监控。

一、设计原理

1.模块架构

2.模块拆解(模块配置项查看第三章)

　　part01：数据采集&上报

　　part02: 告警

　　part03：归档&绘图

　　part04：报警策略配置

4.执行过程

5.模块描述表

二、Web使用​​​​

1.图表监控项目

Dashboard 使用

监控项解释（第三章第二节）

3.配置

创建主机组

创建策略模板

将HostGroup与模板绑定

如何配置策略表达式

 报警函数说明

nodata 上报异常监控

策略配置

注意事项

三、配置及监控项

1.模块配置项说明

2.采集项说明

运维基础采集项

CPU相关采集项

磁盘相关采集项

分区读写监控

IO相关采集项

机器负载相关采集项

内存相关采集项

网络相关采集项

端口采集项

机器内核配置

ntp采集项

进程监控

进程资源监控

ss命令输出

3.api

---

概述

    Open-Falcon 是小米研发的一款开源的互联网企业级监控系统解决方案。

Open-falcon的特性

• 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
• 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
• 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
• 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
• 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
• 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
• dashboard：多维度的数据展示，用户自定义Screen
• 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
• 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。

监控控范围

      1）基础监控。

       比如CPU、Load、内存、磁盘、IO、网络相关、内核参数、ss 统计输出、端口存活状态、进程存活状态、核心服务的进程存活信息采集、关键业务进程资源消耗、NTP offset采集、DNS解析采集，这些指标，都是open-falcon的agent组件直接支持的。

      2）业务应用监控。

       比如我的应用服务部署上线后，需要统计某个接口的平均耗时、调用次数、成功率等信息，这些属于业务应用的监控。这里需要研发人员编写脚本等方式来收集数据，然后发送到open-falcon的transfer组件。

      3）第三方开源软件监控。

      比如mysql、lvs、nginx、redis、mq等，需单独编写采集脚本或插件，这些常见的软件，一般开源社区都有提供相应的脚本。

---

一、设计原理

1.模块架构

2.模块拆解(模块配置项查看第三章)

整体来看，一般的监控系统分为四部分：

采集：对应open-falcon的agent以及App library

存储：对应open-falcon的transfer、Query和graph

告警：对应open-falcon的Judge、Alarm

绘图：对应open-falcon的Dashboard

　　part01：数据采集&上报

　　1、agent（数据采集组件）：golang项目

　　　　　　1. 需要监控的服务器都要安装falcon-agent，falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标

　　　　　　2. agent提供了一个http接口/v1/push用于接收用户手工push的一些数据，然后通过长连接迅速转发给Transfer。

　　　　　　3. 部署好agent后，能自动获取到系统的基础监控指标，并上报给transfer，agent与transfer建立了TCP长连接，每隔60秒发送一次数据到transfer。

　　2、 transfer（数据上报）

　　　　　　1. transfer进程负责分发从agent上送的监控指标数据，并根据哈希分片。

　　　　　　2. 将数据分发给judge进程和graph进程，供告警判定和绘图。

　　　　　　部署说明：

　　　　　　　　部署完成transfer组件后，请修改agent的配置，使其指向正确的transfer地址。

　　　　　　　　在安装完graph和judge后，请修改transfer的相应配置、使其能够正确寻址到这两个组件。

　　part02: 告警

　　3、judge（告警判断）

　　　　　　1.Judge从Heartbeat server获取所有的报警策略，并判断transfer推送的指标数据是否触发告警。

　　　　　　2. 若触发了告警，judge将会产生告警事件，这些告警事件会写入Redis（使用Redis消息队列）。

　　　　　　3. redis中告警事件，供处理告警事件的Alarm进程转发告警消息，或是Email，或是手机短信等。

　　　　　　部署说明：

　　　　　　　　Judge监听了一个http端口，提供了一个http接口：/count，访问之，可以得悉当前Judge实例处理了多少数据量。

　　　　　　　　推荐一个Judge实例处理50万~100万数据，用个5G~10G内存的服务器。

　　4、Alarm（告警）

　　　　　　https://book.open-falcon.org/zh_0_2/distributed_install/alarm.html

　　　　　　1. Alarm进程监听Redis中的消息队列，并将judge产生的告警事件转发给微信、短信和邮件三种REST接口，REST接口才是具体的发送动作。

　　　　　　2. 另外，关于告警，每条告警策略都会定义不同的优先级，Redis中的消息队列也按优先级划分。

　　　　　　3. Alarm不仅消费告警事件，优先级比较低的报警，其合并逻辑都是在alarm中做，所以目前Alarm进程只能部署一个实例。

　　　　　　4. 已经发送出去的告警事件，Alarm将会负责写入MySQL。

　　　　　　说明：

　　　　　　　　1）我们在配置报警策略的时候配置了报警级别，比如P0/P1/P2等等，每个及别的报警都会对应不同的redis队列 

　　　　　　　　2）alarm去读取这个数据的时候我们希望先读取P0的数据，再读取P1的数据，最后读取P5的数据，因为我们希望先处理优先级高的。

　　　　　　　　3）已经发送的告警信息，alarm会写入MySQL中保存，这样用户就可以在dashboard中查阅历史报警。

　　　　　　　　4）针对同一个策略发出的多条报警，在MySQL存储的时候，会聚类；历史报警保存的周期，是可配置的，默认为7天。

　　　　　　注：alarm是个单点。对于未恢复的告警是放到alarm的内存中的，alarm还需要做报警合并，故而alarm只能部署一个实例。后期需要想办法改进。

　　part03：归档&绘图

　　5、graph（数据存储&归档）

　　　　　　1. graph进程接收从transfer推送来的指标数据，操作rrd文件存储监控数据。

　　　　　　2. graph也为API进程提供查询接口，处理query组件的查询请求、返回绘图数据。

　　6、API（提供统一的restAPI操作接口） ：go的后端模块

　　　　　　1. API组件，提供统一的绘图数据查询入口 （提供http接口））。

　　　　　　2. API组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不同metric的数据，然后汇总拿到的数据，最后统一返回给用户。

　　　　　　补充说明：

　　　　　　　　部署完成api组件后，请修改dashboard组件的配置、使其能够正确寻址到api组件。

　　　　　　　　请确保api组件的graph列表 与 transfer的配置 一致。

　　8、dashboard（趋势图web界面）：python的web项目

　　　　　　1. dashboard是面向用户的查询界面，在这里，用户可以看到push到graph中的所有数据，并查看其趋势图。

　　　　　　2. dashboard模块配置 报警策略，并把策略同步给：aggregator、nodata、grafana。

　　9、Aggregator

　　　　　　1. 集群聚合模块，聚合某集群下的所有机器的某个指标的值，提供一种集群视角的监控体验。

　　10、Nodata

　　　　　　1. nodata用于检测监控数据的上报异常。

　　　　　　2. nodata和实时报警judge模块协同工作，过程为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；

　　　　　　3. 用户配置相应的报警策略，收到mock数据就产生报警。

　　　　　　4. 采集项上报异常检测，作为judge模块的一个必要补充，能够使judge的实时报警功能更加可靠、完善。

　　11、grafana（生成更详细图形）

　　part04：报警策略配置

　　12、web portal（报警策略配置）：最新open-falcon中此模块功能合并到Dashboard模块中

　　　　　　1. web portal是python写的django项目，用户可以在这里配置报警策略，存入mysql

　　　　　　2. Portal的数据库中有一个host表，维护了公司所有机器的信息，比如hostname、ip等等。

　　　　　　3. HBS会将agent发送心跳信息给HBS的时候的hostname、ip等信息告诉HBS，HBS负责更新host表。

　　13、hbs：Heartbeat server（心跳服务）

　　　　　　1. 功能1： agent发送心跳信息给HBS的时，会把hostname、ip、agent version、plugin version等信息告诉HBS，HBS负责更新web portal 的host表。

　　　　　　2. 功能2： hbs会从从dashboard模块中获取 报警策略配置 并缓存到本地，所有Judge从hbs中获取报警策略

4.执行过程

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等配置。
 

5.模块描述表

组件名称	用途	服务端口	备注
Agent	部署在需要监控的服务器上	http: 1988	http://192.168.153.134:1988/
Transfer	数据接收端，转发数据到后端的Graph和Judge	http: 6060 rpc: 8433 socket: 4444
Graph	操作rrd文件存储监控数据	http: 6071 rpc：6070
Query	查询各个Graph数据，提供统一http查询接口	http: 9966
Dashboard	查询监控历史趋势图的web	http: 8081	需要python环境，需要连接数据库dashborad实例、graph组件
Task	负载一些定时任务，索引全量更新、垃圾索引清理、自身组件监控等	http: 8082	需要连接数据库graph实例
Aggregator	集群聚合模块	http: 6055
Alarm	告警	http: 9912
Api	API	http: 8080
Gateway	Gateway	http: 16060
Hbs	心跳服务器	6030
Judge	告警判断	http: 6081 rpc: 6080
Nodata	告警异常处理	http: 6090
Mysql	数据库	3306
Redis	缓存服务器	6379

---

二、Web使用​​​​

1.图表监控项目

• Dashboard 使用

1. 数据分析 我们都知道监控是为了收集各种信息数据，收集了肯定要使用，最简单就达到阀值报警。 但是有事我们避免不可少的会遇到各种各样的问题，就需要我们快速根据已知的数据进行一定的数据分析或者查询。 Dashboard，可以从几个纬度进行数据查询：
2. tags：可以理解为组或者分类
3. hosts：机器名称
4. metric：监控项

我们说agent只要部署到机器上，并且配置好了heartbeat和transfer就自动采集数据了，我们就可以去dashboard上面搜索监控数据查看了。dashboard是个web项目，浏览器访问之。左侧输入endpoint搜索，endpoint是什么？应该用什么搜索？对于agent采集的数据，endpoint都是机器名，去目标机器上执行hostname，看到的输出就是endpoint，拿着hostname去搜索。

搜索到了吧？嗯，选中前面的复选框，点击“查看counter列表”，可以列出隶属于这个endpoint的counter，counter是什么？counter=${metric}/sorted(${tags})

假如我们要查看cpu.busy，在counter搜索框中输入cpu并回车。看到cpu.busy了吧，点击，会看到一个新页面，图表中就是这个机器的cpu.busy的近一小时数据了，想看更长时间的？右上角有个小三角，展开菜单，可以选择更长的时间跨度

• 监控项解释（第三章第二节）

3.配置

Open-Falcon的数据模型，采用和OpenTSDB相似的数据格式：metric、endpoint加多组key value tags，举个例子：

{
    metric: load.1min,                        // 监控项名称
    endpoint: open-falcon-host,               // 目标服务器的主机名
    tags: srv=falcon,idc=aws-sgp,group=az1,   // tag标签，作用是聚合和归类，在配报警策略时会比较方便。
    value: 1.5,                               // 监控项数值
    timestamp: `date +%s`,                    // 采集时间
    counterType: GAUGE,                       // 监控项类型。 
    step: 60                                  // 采集间隔 秒。
}

其中，metric是监控指标名称，endpoint是监控实体，tags是监控数据的属性标签，counterType是Open-Falcon定义的数据类型(取值为GAUGE、COUNTER)，step为监控数据的上报周期，value和timestamp是有效的监控数据。

open-falcon使用的监控项类型主要有两种：

(1) GAUGE：实测值，直接使用采集的原始数值，比如气温；

(2) COUNTER：记录连续增长的数据，只增不减。比如汽车行驶里程，网卡流出流量，cpu_idle等；

  这种模型的主要好处：一是方便从多个维度来配置告警，二是可以灵活的进行自主数据采集。

第一点，比如tag的使用起到了给机器进行归类的作用，比如有3台机器：host1、host2和host3，如果tags依次配置为"group=java", "group=java"和"group=erlang"，那么配置报警策略"metric=cpu/group=java“时就只会对java标签的机器（即host1，host2)生效。

       第二点，由于agent会自发现的采集很多基本的系统指标，但是对业务应用等需要研发人员自己写脚本收集和上报。这里openfalcon定义了监控项模型，相当于定义了一个规范，当研发人员需要监控某个对象（比如mysql、redis等），只需采集数据，并遵守规范包装成监控项模型，再上报即可。
 

主机组(HostGroups)：用于对主机机器进行分组，一组的机器可以统一绑定模板。

模板(Template)：用于定义报警策略，对主机组进行统一管理。

表达式(Expression)：对上报数据模型进行全匹配（监控项名称以及tag），匹配到的监控项将执行表达式策略。

• 创建主机组

        比如我们要对falcon-judge这个组件做端口监控，那首先创建一个HostGroup，把所有部署了falcon-judge这个模块的机器都塞进去，以后要扩容或下线机器的时候直接从这个HostGroup增删机器即可，报警策略会自动生效、失效。咱们为这个HostGroup取名为：sa.dev.falcon.judge，这个名称有讲究，sa是我们部门，dev是我们组，falcon是项目名，judge是组件名，传达出了很多信息，这样命名比较容易管理，推荐大家这么做。

         在往组里加机器的时候如果报错，需要检查portal的数据库中host表，看里边是否有相关机器。那host表中的机器从哪里来呢？agent有个heartbeat(hbs)的配置，agent每分钟会发心跳给hbs，把自己的ip、hostname、agent version等信息告诉hbs，hbs负责写入host表。如果host表中没数据，需要检查这条链路是否通畅。

• 创建策略模板

       portal最上面有个Templates链接，这就是策略模板管理的入口。我们进去之后创建一个模板，名称姑且也叫：sa.dev.falcon.judge.tpl，与HostGroup名称相同，在里边配置一个端口监控，通常进程监控有两种手段，一个是进程本身是否存活，一个是端口是否在监听，此处我们使用端口监控。

        

 右上角那个加号按钮是用于增加策略的，一个模板中可以有多个策略，此处我们只添加了一个。下面可以配置报警接收人，此处填写的是falcon，这是之前在UIC中创建的Team。

• 将HostGroup与模板绑定

        一个模板是可以绑定到多个HostGroup的，现在我们重新回到HostGroups页面，找到sa.dev.falcon.judge这个HostGroup，右侧有几个超链接，点击【templates】进入一个新页面，输入模板名称，绑定一下就行了。

 

• 如何配置策略表达式

•  报警函数说明

配置报警策略的时候open-falcon支持多种报警触发函数，比如all(#3) diff(#10)等等。 这些#后面的数字表示的是最新的历史点，比如#3代表的是最新的三个点。该数字默认不能大于10，大于10将当作10处理，即只计算最新10个点的值。

说明：#后面的数字的最大值，即在 judge 内存中保留最近几个点，是支持自定义的，具体参考 book 中描述 ； 源码位置 => cfg.example.json

all(#3): 最新的3个点都满足阈值条件则报警
max(#3): 对于最新的3个点，其最大值满足阈值条件则报警
min(#3): 对于最新的3个点，其最小值满足阈值条件则报警
sum(#3): 对于最新的3个点，其和满足阈值条件则报警
avg(#3): 对于最新的3个点，其平均值满足阈值条件则报警
diff(#3): 拿最新push上来的点（被减数），与历史最新的3个点（3个减数）相减，得到3个差，只要有一个差满足阈值条件则报警
pdiff(#3): 拿最新push上来的点，与历史最新的3个点相减，得到3个差，再将3个差值分别除以减数，得到3个商值，只要有一个商值满足阈值则报警
lookup(#2,3): 最新的3个点中有2个满足条件则报警；
stddev(#7) = 3：离群点检测函数，取最新 **7** 个点的数据分别计算得到他们的标准差和均值，分别计为 σ 和 μ，其中当前值计为 X，那么当 X 落在区间 [μ-3σ, μ+3σ] 之外时，则认为当前值波动过大，触发报警；更多请参考3-sigma算法：https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule。

最常用的就是all函数了，比如cpu.idle all(#3) < 5，表示cpu.idle的值连续3次小于5%则报警。

lookup为非连续性报警函数，适用于在一定范围内容忍监控指标抖动的场景，比如某个主机的cpu.busy忽高忽低，使用all(#1)>80明显过于严格，会产生大量报警干扰视线，使用all(#3)>80则连续三次偏高的概率很小，可能永远不会触发报警，不能帮助我们发现系统的不稳定，那么如果使用lookup(#3,5)，我们就可以知道cpu.busy最近抖动频繁，超过了我们容忍的界线。

新增 stddev 函数，基于高斯分布的离群点检测方式，比如cpu.idle stddev(#5) = 3 ，表示获取cpu.idle的历史5个点数据，计算得到他们的标准差和均值，分别计为 σ 和 μ，看其是否分布在(μ-3σ,μ+3σ)范围之内，如果不在范围之内则报警。具体参考wiki中描述

diff和pdiff理解起来没那么容易，设计diff和pdiff是为了解决流量突增突降报警。实在看不懂，那只能去读代码了：https://github.com/open-falcon/judge/blob/master/store/func.go

• nodata 上报异常监控

进入Nodata配置主页，可以看到Nodata配置列表 

点击右上角的添加按钮，添加nodata配置。 

进行完上述配置后，分组cop.xiaomi_owt.inf_pdl.falcon下的所有机器，其采集项 agent.alive上报中断后，nodata服务就会补发一个取值为 -1.0、agent.alive的监控数据给监控系统。

策略配置

配置了Nodata后，如果有数据上报中断的情况，Nodata配置中的默认值就会被上报。我们可以针对这个默认值，设置报警；只要收到了默认值，就认为发生了数据上报的中断（如果你设置的默认值，可能与正常上报的数据相等，那么请修改你的Nodata配置、使默认值有别于正常值）。将此策略，绑定到分组cop.xiaomi_owt.inf_pdl.falcon即可。

注意事项

1. 配置名称name，要全局唯一。这是为了方便Nodata配置的管理。
2. 监控实例endpoint, 可以是机器分组、机器名或者其他 这三种类型，只能选择其中的一种。同一类型，支持多个记录，但建议不超过5个，多条记录换行分割、每行一条记录。选择机器分组时，系统会帮忙展开成具体机器名，支持动态生效。监控实体不是机器名时，只能选择“其他”类型。
3. 监控指标metric。
4. 数据标签tags，多个tag要用逗号隔开。必须填写完整的tags串，因为nodata会按照此tags串，去完全匹配、筛选监控数指标项。
5. 数据类型type，只支持原始值类型GAUGE。因为，nodata只应该监控 "特征指标"(如agent.alive)，"特征指标"都是GAUGE类型的。
6. 采集周期step，单位是秒。必须填写 完整&真实step。该字段不完整 或者 不真实，将会导致nodata监控的误报、漏报。
7. 补发值default，必须有别于上报的真实数据。比如，cpu.idle的取值范围是[0,100]，那么它的nodata默认取值 只能取小于0或者大于100的值。否则，会发生误报、漏报。

---

三、配置及监控项

1.模块配置项说明

• Agent
• Transfer
• Graph
• API
• DashBoard
• 邮件/短信/微信发送接口
• Heartbeat Server
• Judge
• Alarm
• Task
• Gateway
• Nodata
• Aggregator

2.采集项说明

运维基础采集项

做运维，不怕出问题，怕的是出了问题，抓不到现场，两眼摸黑。所以，依靠强大的监控系统，收集尽可能多的指标，意义重大。 但哪些指标才是有意义的呢，本着从实践中来的思想，各位工程师在长期摸爬滚打中总结出来的经验最有价值。 在各位运维工程师长期的工作实践中，我们总结了在系统运维过程中，经常会参考的一些指标，主要包括以下几个类别：

• CPU
• Load
• 内存
• 磁盘
• IO
• 网络相关
• 内核参数
• ss 统计输出
• 端口采集
• 核心服务的进程存活信息采集
• 关键业务进程资源消耗
• NTP offset采集
• DNS解析采集

falcon-agent每隔一定时间间隔（目前是60秒）会采集一次相关的指标，并汇报给server端。

CPU相关采集项

计算方法：通过采集/proc/stat来得到，大家可以参考sar命令的统计输出来理解。

• cpu.idle：CPU或CPU处于空闲状态且系统没有未完成的磁盘I/O请求的时间百分比。
• cpu.busy：与cpu.idle相对，他的值等于100减去cpu.idle。
• cpu.guest：CPU或CPU运行虚拟处理器所花费的时间百分比。
• cpu.iowait：系统IOwait 等待
• cpu.irq：CPU或CPU为硬件中断服务所花费的时间百分比。
• cpu.softirq：CPU或CPU为软件中断服务所花费的时间百分比。
• cpu.nice：在具有nice优先级的用户级执行时发生的CPU利用率百分比。
• cpu.steal：虚拟机监控程序为另一个虚拟处理器提供服务时，虚拟CPU或CPU非自愿等待所花费的时间百分比。
• cpu.system：在系统级(内核)执行时发生的CPU利用率百分比。
• cpu.user：在用户级(应用程序)执行时发生的CPU利用率百分比。
• cpu.cnt：cpu核数。
• cpu.switches：cpu上下文切换次数，计数器类型。

磁盘相关采集项

计算方法：先读取/proc/mounts拿到所有挂载点，然后通过syscall.Statfs_t拿到blocks和inode的使用情况。 每个metric都会附加一组tag描述，类似mount=$mount,fstype=$fstype，其中$mount是挂载点，比如/home，$fstype是文件系统，比如ext4。

• df.bytes.free：磁盘可用量，int64
• df.bytes.free.percent：磁盘可用量占总量的百分比，float64，比如32.1
• df.bytes.total：磁盘总大小，int64
• df.bytes.used：磁盘已用大小，int64
• df.bytes.used.percent：磁盘已用大小占总量的百分比，float64
• df.inodes.total：inode总数，int64
• df.inodes.free：可用inode数目，int64
• df.inodes.free.percent：可用inode占比，float64
• df.inodes.used：已用的inode数据，int64
• df.inodes.used.percent：已用inode占比，float64

分区读写监控

测试所有已挂载分区是否可读写，每个metric都会有一组tag描述，表示挂载点，比如mount=/home

• sys.disk.rw： 如果值不为0，表明此分区读写出现问题

IO相关采集项

计算方法：每秒采集一次/proc/diskstats，计算差值，都是计数器类型的。 每个metric都会有一组tag描述，形如device=$device，用来表示具体的设备，比如sda1、sdb。 用户可以参考iostat的帮助文档来理解具体的metric含义。

• disk.io.ios_in_progress：当前正在运行的实际I/O请求的数量。
• disk.io.msec_read：所有读取花费的总毫秒数。
• disk.io.msec_total：os_in_progress> = 1的时间长度。
• disk.io.msec_weighted_total：最近的I / O完成时间和积压的度量。
• disk.io.msec_write：所有写入花费的总毫秒数。
• disk.io.read_merged：相邻的读取请求合并在单个请求中。
• disk.io.read_requests：成功完成的读取总数。
• disk.io.read_sectors：成功读取的扇区总数。
• disk.io.write_merged：相邻的写请求合并在单个请求中。
• disk.io.write_requests：成功完成的写入总数。
• disk.io.write_sectors：成功写入的扇区总数。
• disk.io.read_bytes：单位是byte的数字
• disk.io.write_bytes：单位是byte的数字
• disk.io.avgrq_sz：下面几个值就是iostat -x 1看到的值
• disk.io.avgqu-sz
• disk.io.await
• disk.io.svctm
• disk.io.util：是个百分数，比如56.43，表示56.43%

机器负载相关采集项

计算方法：读取/proc/loadavg，都是原始值类型的：

• load.1min
• load.5min
• load.15min

内存相关采集项

计算方法：读取/proc/meminfo 中的内容，其中的mem.memfree是free+buffers+cached，mem.memused=mem.memtotal-mem.memfree。 可以参考free命令的输出和帮助文档来理解每个metric的含义。

• mem.memtotal：内存总大小
• mem.memused：使用了多少内存
• mem.memused.percent：使用的内存占比
• mem.memfree
• mem.memfree.percent
• mem.swaptotal：swap总大小
• mem.swapused：使用了多少swap
• mem.swapused.percent：使用的swap的占比
• mem.swapfree
• mem.swapfree.percent

网络相关采集项

计算方法：读取/proc/net/dev的内容，每个metric都附加有一组tag，形如iface=$iface，标明具体那个interface，比如eth0。 metric中带有in的表示流入情况，out表示流出情况，total是总量in+out，支持的metric如下：

• net.if.in.bytes : 流量入口
• net.if.in.compressed
• net.if.in.dropped
• net.if.in.errors
• net.if.in.fifo.errs
• net.if.in.frame.errs
• net.if.in.multicast
• net.if.in.packets
• net.if.out.bytes： 流量出口
• net.if.out.carrier.errs
• net.if.out.collisions
• net.if.out.compressed
• net.if.out.dropped
• net.if.out.errors
• net.if.out.fifo.errs
• net.if.out.packets
• net.if.total.bytes
• net.if.total.dropped
• net.if.total.errors
• net.if.total.packets

端口采集项

计算方法，通过ss -ln，来判断指定的端口是否处于listen状态。原始值类型，值要么是1：代表在监听，要么是0，代表没有在监听。

每个metric都附件一组tag，形如port=$port，$port就是具体的端口。

• net.port.listen

机器内核配置

• kernel.maxfiles： 读取的/proc/sys/fs/file-max
• kernel.files.allocated：读取的/proc/sys/fs/file-nr第一个Field
• kernel.files.left：值=kernel.maxfiles-kernel.files.allocated
• kernel.maxproc：读取的/proc/sys/kernel/pid_max

ntp采集项

使用 ntpq -pn 获取本机时间相对于 ntp 服务器的 offset。

• sys.ntp.offset： 本机偏移时间，单位为ms，值过大或者为0则表明有异常，需要报警

进程监控

• proc.num：判断某个进程的数目，这里需要分两个场景，一种是根据进程的名字来判定，比如name=sshd；
• 另外一种是根据cmdline来判定，比如Java的应用进程名可能都是java，根据第一种情况没法做区分，此时可以配置cmdline，如cmdline=./falcon_agent-c./cfg.ini

进程资源监控

• process.cpu.all：进程和它的子进程使用的sys+user的cpu，单位是jiffies
• process.cpu.sys：进程和它的子进程使用的sys cpu，单位是jiffies
• process.cpu.user：进程和它的子进程使用的user cpu，单位是jiffies
• process.swap：进程和它的子进程使用的swap，单位是page
• process.fd：进程使用的文件描述符个数
• process.mem：进程占用内存，单位byte

ss命令输出

• ss.orphaned: 没有用户态 fd 的 TCP Socket 数量，或者是处于 FIN_WAIT_1 、 FIN_WAIT_2、 CLOSING 状态的 TCP Socket 数量
• ss.closed: 处于 CLOSE_WAIT 、 LAST_ACK、 TIME_WAIT 状态的 TCP Socket 数量
• ss.timewait: 处于 TIMEWAIT 状态的 TCP Socket 数量
• ss.slabinfo.timewait
• ss.synrecv: 处于 SYN_RECV 状态的 TCP Socket 数量
• ss.estab：已经建立的 TCP Socket 数量

3.api

Falcon+ API