本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」，未经作者(laiwei)书面许可，不允许用于商业用途的转载、分发、和演绎。

在上一章中，我们介绍和对比了业界一些杰出的开源监控解决方案。早期，我们一直在用Zabbix，不过随着业务的快速发展，以及互联网公司特有的一些需求，现有的开源监控系统在性能、扩展性和用户的使用效率方面，已经无法支撑了。

因此，从公司的一些需求出发，从各位运维人员、研发人员的使用经验和反馈出发，结合业界一些大型互联网公司监控系统的设计理念，研发了Open-Falcon，目标是做最开放、最好用的互联网企业级监控产品（Open-Falcon的详细内容，可以参考http://open-falcon.org）。

监控系统主要有4个功能：数据采集、告警、图表展示和历史数据挖掘。Open-Falcon也是着重从这4个方面来设计和开发的。Open-Falcon具有以下一些特点。

• 强大灵活的数据采集：通过配套的Falcon-agent，可以自动采集400多个单机指标，也可以通过用户自定义的插件来增加更多的采集项。用户可以自己实现采集程序获取相关的指标，然后主动推送给监控系统，由监控系统负责后续的存储、展示和告警功能。比如编写脚本通过SNMP方式获取网络设备的相关运行指标，并把采集结果推送给监控系统。
• 良好的水平扩展能力：监控系统能通过水平扩展来支撑业务的快速发展。
• 高效率的告警策略管理：高效的用户配置界面，支持策略模板，支持模板继承和覆盖，支持多种告警方式和回调动作。
• 人性化的告警设置：支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈值，支持维护周期设置，支持告警合并。
• 高效的历史数据查询：采用RRDtool的数据归档策略，秒级返回上百个指标一年的历史数据。
• 人性化的Dashboard：多维度的数据展示，用户自定义Dashboard等功能。
• 高可用：整个系统无核心单点，易运维，易部署。

Open-Falcon架构

Open-Falcon架构示意图如图1所示。

图1 Open-Falcon架构示意图

整个监控系统，由Agent、Web-portal、Heartbeat-server、Dashboard、Transfer、Judge、Graph 等几个核心组件构成。

Agent

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

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

Agent是一个Daemon程序，只要安装了Falcon-agent的Linux服务器，便会自发现地采集单机的各种数据指标，共计400多个，基本覆盖了上面提到的各个类别。
这些采集好的指标，Agent会以一个固定的周期主动上报到服务端，并不需要用户在服务端做任何配置（这和Zabbix有很大的不同）。这样做的好处就是用户维护起来方便，指标覆盖率高，在服务器上架初始化的时候，就会自动安装Agent。有了这些详细的指标，对于运维人员和研发人员来讲，事后追查问题不再是难题。当然，这样做也会给服务端带来一些压力。

另外，Agent提供了一个Proxy-gateway功能，用户可以方便地通过HTTP的方式，POST自定义的数据到本机的Proxy-gateway，Proxy-gateway会将这些数据转发到服务端，便于用户推送数据，并提高整个监控系统的稳定性。

Agent支持的这些采集项，都是大量运维人员在长期的工作中总结出来的，基本能覆盖常见的一些监控需求。但仍然会存在一些特殊的业务需求，或者不适合在Agent里面内置的采集项，对于这些需求，如何更好地进行支持呢？我们设计开发了插件机制。

插件是符合一定规范的，由用户开发的数据采集脚本或者可执行程序，Agent会负责周期性地调度这些插件，并将插件运行的输出推送到监控系统。
插件的工作流程如图2所示。

图2 插件的工作流程图

插件是作为一个Git项目（Falcon-plugin），通过Git来管理的。用户编写插件，完成测试之后，提交到Falcon-plugin的dev分支，并发起一个pull-request，管理员审核确认通过后，会合并到master分支。所有的Agent都会定期通过git pull来检查获取更新，这样用户提交的插件就更新到所有的服务器了。通过Git管理插件，好处就是版本管理和协作，所有的用户都可以自由贡献插件，通过pull-request合并到master分支。

插件更新到服务器之后，Agent并不会对其进行调度，因为某些插件只是解决特定的问题，并不适合在所有的服务器上运行，或者无法正常运行在所有的服务器上。从安全的角度和产品设计的角度考虑，用户需要在Web-portal上进行配置，哪些机器允许执行哪些插件。完成这步操作后，相关的插件才会被相关服务器的Agent自动调度。

数据模型

在讲述其他组件之前，有必要先描述一下Open-Falcon的数据模型（Data Model）。

数据模型是否强大、是否灵活，对于监控系统用户的“使用效率”至关重要。比如以Zabbix为例，上报的数据格式为hostname（或者IP地址）、metric、timestamp、value这4个维度，那么用户添加告警策略、管理告警策略的时候，就只能以这几个维度来进行。

举一个最常见的场景：hostA的磁盘空间，小于5%，就告警。在一般的服务器上，都会有两个主要的分区，即root分区和home分区，在Zabbix中，就得加两条规则；如果是Hadoop服务所在的机器，一般还会有十几块数据盘，还得再加十多条规则，这样就会很烦琐，不利于自动化（当然，Zabbix可以通过配置一些自动发现策略来搞定，不过仍然比较麻烦且不直观）。

Open-Falcon采用类似于OpenTSDB的数据模型，由以下7个字段构成。

• metric：最核心的字段，代表这个数据采集项具体度量的是什么东西，比如是内存的使用量（memory_used），还是某个接口调用的次数（QPS）。
• endpoint：代表metric的主体，比如metric是内存使用量（memory_uesd），那么endpoint就表示该metric属于哪台机器。
• tags：这是一组用逗号分隔的键值对，用来对metric进行进一步的描述，比如service=falcon,location=beijing。
• timestamp：UNIX时间戳，表示产生该数据的时间点。
• value：整型或者浮点型，代表该metric在指定时间点的值。
• step：整型，表示该数据采集项的汇报周期，这对于后续的配置监控策略很重要，必须明确指定。
• counterType：只能是COUNTER或者GAUGE二选一，前者表示该采集项为计数器类型，后者表示其为原值。对于计数器类型，在告警判定以及图表展示前，会被先计算为速率。

举两个例子：

{ 
metric: df.bytes.free.percent, 
endpoint: hostA,
tags: mount=/home,
value: 5, 
timestamp: UNIX时间戳,
counterType: GAUGE, 
step: 60
}
{
metric: df.bytes.free.percent, 
endpoint: hostA, 
tags: mount=/root, 
value: 15, 
timestamp: UNIX时间戳,
counterType: GAUGE, 
step: 60 
}```

metric为df.bytes.free.percent，表示这个指标的具体含义为服务器的磁盘可用百分比；endpoint描述这个metric所在的主体是hostA；tags是对这个metric的一组补充描述，比如mount=/home这一组tag，表示这个metric描述的是home分区的磁盘可用百分比；同样mount=/root，表示这个metric描述的是root分区的磁盘可用百分比。

使用tags的好处是可以简化告警策略的配置。比如上面提到的这个最简单的场景，hostA的磁盘可用百分比小于5%就触发告警。对于root和home两个分区，在Open-Falcon中，可以用一条规则来描述，即 ：
>endpoint=hostA && metric=df.bytes.free.percent < 5%

而不再需要针对两个分区，写两条规则：

>endpoint=hostA && metric=df.bytes.free.percent && mount=/home < 5%
endpoint=hostA && metric=df.bytes.free.percent && mount=/root < 5%

另外，在Dashboard中，可以借助于tags，把tags作为筛选过滤条件，更方便用户查看自己关心的指标。

#  数据采集
数据采集，是监控系统一个最基本的功能。在Open-Falcon中，Agent采集到的数据，会先发送给Transfer组件。Transfer接收到客户端发送的数据，做一些数据规整、检查之后转发到多个后端系统去处理。在转发到每个后端业务系统的时候，Transfer会根据一致性哈希算法进行数据分片，来达到后端业务系统的水平扩展。Transfer自身是无状态的，挂掉一台或者多台不会有任何影响。

Transfer目前支持的业务后端有三种：Judge、Graph和OpenTSDB。Judge是我们开发的高性能告警判定组件，Graph是我们开发的高性能数据存储、归档、查询组件，OpenTSDB是开源的时间序列数据存储服务。每个业务后端都可以通过Transfer的配置文件来开启。

Transfer的数据来源一般有4种。
1. Falcon-agent主动采集的基础监控数据。
2. Falcon-agent执行用户自定义的插件返回的数据。
3. client-library：线上的业务系统，都嵌入使用了统一的基础库，对于业务系统中的每个业务接口，都会主动计算其CPS、Lantency等指标并上报。
4. 用户产生的一些自定义的指标，由用户自行上报。

这4种数据都会先发送给本机的Proxy-gateway，再由Proxy-gateway转发给Transfer。

一个推送数据给Proxy-gateway的例子如下：
```python
#!-*- coding:utf8 -*-
 
import requests
import time
import json

ts = int(time.time())
payload = [
    {
        ＂endpoint＂: ＂test-endpoint＂,
        ＂metric＂: ＂test-metric＂,
        ＂timestamp＂: ts,
        ＂step＂: 60,
        ＂value＂: 1,
        ＂counterType＂: ＂GAUGE＂,
        ＂tags＂: ＂location=beijing,service=falcon＂,
    },
]
r=requests.post(＂http://127.0.0.1:1988/v1/push＂,data=json.dumps(payload))

业务性能数据采集基础库设计思路

除了一些基础采集项，线上业务各接口的各项性能数据也是研发人员和运维人员重点关注的内容。我们抽象总结出了两类最通用的指标，供大家参考。

• 每秒调用次数：CPS。
• 接口调用延时：Lantency-75th、Lantency-95th、Lantency-99th。

即针对线上业务的每个接口，都会由基础库自动计算这两类指标，并由基础库周期性地推送给本地的Proxy-gateway。这样不用业务研发人员投入过多的精力，就可以自动化、标准化地采集业务性能指标数据。

有了相关的性能数据后，一方面，我们可以针对某些核心接口调用配置监控策略，在接口调用耗时增大到一定程度的时候，或者接口调用次数发生突升突降的时候，发送告警及时通知相关人员；另一方面，借助于性能数据，相关的研发人员和运维人员能够更从容地规划整个系统的容量，提高系统的稳定性以及资源利用率。

注：线上业务性能数据采集，一个开源的实现可以参考 http://metrics.dropwizard.io。

HTTP服务数据采集思路

目前HTTP服务仍然在我们的所有业务中占据重要地位，所以如何自动化地监控、评估Web服务的可用性指标和性能数据是非常重要的。我们的线上业务大量使用Nginx作为Web Server。

在第一阶段，通过分析Nginx的访问日志得到访问次数，通过分析日志中的status code得到正常返回和服务器出错的数量。这个方案可以解决一部分问题，不过存在一些不足的地方，比如：

• 在线上服务器上分析日志，会对服务器造成一定的压力，拖慢正常业务的响应时间。
• 分析的时效性较差，一般都是5分钟的粒度和延迟。
• 日志的覆盖率有限，有些性能数据很难在日志中体现，比如upstream到某个后端花费的时间等。

在第二阶段，我们尝试在Nginx中内嵌Lua脚本来自动计算和获取每个Nginx Location对应的相关性能指标，包括：

• qps，该Location每秒被访问的次数。
• request_time，请求的平均响应时间。
• upstream_time_to_xxx，upstream到某个后端的平均响应时间，用来衡量Nginx到每个后端应用服务器花费的时间。
• bytes_sent，每秒返回的字节数，用来衡量网络带宽的利用率。
• status_code.200，每秒钟，HTTP的状态码等于200的次数。
• status_code.4xx，每秒钟，HTTP的状态码大于等于400、小于500的次数。
• status_code.5xx，HTTP的状态码大于等于500的次数。
• availability : 1-(status_code.4xx + status_code.5xx) / qps，用来衡量服务的可用性。

采用该方案后，HTTP服务的各项指标的覆盖率得到大大提高，数据分析的时效性也提高到1分钟粒度，同时相对于第一阶段日志分析的方案，该方案的运维成本得到大大降低，对服务器资源的消耗也降低到可以忽略不计的水平。

告警

告警判定，是由Judge组件来完成的。用户在Web-portal上配置相关的报警策略，存储在MySQL中。Heartbeat-server 会定期加载MySQL中的内容。Judge也会定期和Heartbeat-server保持沟通，来获取相关的报警策略。

Heartbeat-server不仅仅是单纯地加载MySQL中的内容。另一个重要功能是根据用户配置的模板继承关系、模板项覆盖关系、报警动作覆盖关系、模板和机器组的绑定关系，计算出最终关联到每个endpoint的告警策略，下发给Judge组件来进行告警判定。

Transfer转发到Judge的每条数据，都会触发相关策略的判定，来决定是否满足报警条件，如果条件满足，则会将告警信息写入告警队列。Alarm会从告警队列中获取数据，再以邮件、短信、米聊等形式通知相关用户，也可以执行用户预先配置好的回调动作。

用户可以很灵活地来配置告警判定策略，比如连续N次都满足条件，连续N次的最大值满足条件，不同的时间段设置不同的阈值，如果处于维护周期内则忽略告警等。同时也支持最大告警次数设置、告警级别设置，支持告警恢复通知、一段时间内突升突降判定等功能。

与告警组件相关的几个重要概念如下。

• 告警策略：某个metric触发告警需要满足的条件，称之为一个告警策略。比如cpu.idle，连续3次的值都小于10%，则触发告警。这就是一个典型的告警策略。
• 模板：一组告警策略的集合，称之为模板。模板和某个服务器分组绑定之后，该服务器分组下面的所有endpoint都会自动应用该模板中所有的策略。
• 服务器分组：一组endpoint的集合，称之为一个服务器分组。一个endpoint加入某个服务器分组中，那么就会自动应用该分组所绑定的策略模板；同理，一个endpoint从某个服务器分组中去掉，这个endpoint便不再拥有该分组所绑定的策略模板。通过这种管理方式，使得服务扩容和缩减时监控可以自动化地变更。服务器分组是绑定策略模板的唯一单位。
• 告警动作：满足告警策略需要后续执行的动作，称之为告警动作。目前支持的告警动作包括发送短信、发送邮件、发送米聊、执行指定的回调动作。回调动作这种机制，便于用户执行一些自动化的预案。

为了提高运维人员和研发人员配置、维护监控策略的效率，Open-Falcon有两个很重要的功能：一是根据tag来设置告警策略；二是引入模板来组织告警策略。

根据tag来设置告警策略，我们在前面讲述Open-Falcon数据模型的时候，有过简单介绍。这里再举几个场景来说明一下。

场景一：部署了Falcon这个服务的所有服务器，SDA盘的磁盘IO使用率，超过80%就告警。

service=falcon && metric=disk.io.util && device=sda > 80%

场景二：部署了Falcon这个服务的所有服务器，任何一块磁盘IO使用率，超过80%就告警。

service=falcon && metric=disk.io.util > 80%

在上面两个场景中，我们用到了service和device这两个tag来作为配置告警的条件，仅仅通过一条配置，就能满足用户的需求。

模板是用户管理一组策略的唯一单元，一个模板可以和多个机器分组进行绑定。模板的作用在于用户修改了模板中的某个策略之后，与该模板绑定的所有机器分组中的endpoint都会即时生效该策略变动。

模板之间可以存在继承关系，子模板会自动拥有父模板中的所有策略。另外，在子模板中，可以覆盖父模板中的某些策略。比如我们可以创建一些标准的模板，其他用户只需要继承该模板，做一些简单的增、删、改就可以使用了。模板的继承和覆盖特性，可以有效地帮助运维人员减少维护告警策略的工作量。

对于模板的继承和覆盖特性，我们可以通过以下两个场景来阐述。

在图3所描述的场景一中，我们需要监控FalconHostGroup这个服务器分组下的所有服务器，其cpu.idle都不能低于10%；否则发送告警给falcon-dev用户组。我们通过给FalconHostGroup分组绑定Template-A策略模板，即可达到目的。

图3 场景一——模板继承和覆盖

这时候，用户的需求场景发生了变化，即如图4所示的新场景中所描述的，用户希望在场景一的基础上，监控portal这个服务器分组下的所有服务器，其cpu_idle不能低于50%；否则发送告警给portal-dev用户组。为了解决用户的新需求，通常的做法是，去除FalconHostGroup和Template-A的绑定关系，然后给下面的5个子分组分别绑定不同的策略模板。这样的操作方式，对用户来讲是非常烦琐的，特别是在子分组很多的情况下。

在Open-Falcon中，我们可以利用模板的继承和覆盖特性，方便地满足这个新需求。我们保持FalconHostGroup分组和Template-A的绑定关系不变，只需要给portal这个有特殊需求的分组单独绑定一个策略模板Template-B即可，其中Template-B继承自Template-A，且对Template-A中的cpu.idle策略项进行了覆盖。这样就可以满足用户的新需求了。

图4 新场景——模板继承和覆盖

告警分级

同样是告警，有的告警需要立即处理；否则就会造成很大的影响，比如严重影响用户体验，无法正常使用该业务的核心功能等；有的告警则时效性要求较低，比如多台Nginx中的一台宕机了，暂时不影响服务，稍后处理即可。告警分级，让运维人员做到对重点故障重点关注。

考虑到这样的场景，监控系统在设计的时候，允许用户设置告警级别，对于高级别的告警，会优先在第一时间通过多种通道下发给相关用户；对于低级别的告警，则只会通过邮件进行发送。

告警级别，是按照对服务、对用户的影响范围来确定的。下面是相关定义，如表24-1所示。

表24-1 告警级别定义

告警合并

不知道各位读者在运维过程中，有没有遇到过一些告警短信轰炸的场景，比如机房之间专线故障导致连通性下降，或者内网DNS出现问题导致各种解析失败，短时间内产生大批量的告警。这些瞬时的大批量告警给运维和研发人员造成了很大的干扰，造成短信网关、邮件网关资源的浪费，同时也会淹没一些重要的告警。因此，我们尝试通过告警合并来解决这种告警轰炸问题。

在告警未合并之前，只要产生了告警，就会立即发送。如果要做合并，那么就必然需要有一个等待时间，比如产生告警后等1分钟，然后看看这1分钟里哪些告警可以合并为一条，最后再统一发送给目标用户。告警合并需要有一定的规则，按照metric合并是一个很自然的方案，即很多endpoint的同一个metric告警，可以很自然地合并为一条，在减少告警数量的同时，尽可能少地丢失信息量。用户收到合并后的消息后，如果想进一步查看详情，可以点击附加在告警消息中的详情链接进入。

目前我们仅按照相同metric这一个维度来进行合并。更进一步，可以结合更多的纬度信息，比如相同机柜、同一接入交换机、同一类服务等，做到更智能、更准确的信息合并和问题定位。

实施告警合并，会对告警时效性存在影响，这和高级别的告警要求立即发送的原则存在矛盾，因此最终的方案是只对低级别的告警实施合并。

数据存储方案

对于监控系统来讲，历史数据的存储、高效率查询和快速展示是很重要且困难的问题。这主要表现在如下三个方面。

1. 数据量大：目前我们的监控系统每个周期大概有2500万次数据采集项上报（上报周期为1分钟和5分钟两种，各占50%），一天24小时里，从来不会有低峰，不管是白天还是黑夜，每个周期总会有那么多的数据要更新。
2. 写操作多：一般的业务系统通常都是读多写少，可以方便地使用各种缓存技术。再者，各类数据库对于查询操作的处理效率远远高于写操作。而监控系统恰恰相反，写操作远远高于读。每个周期几千万次的更新操作，对于常用数据库（MySQL、PostgreSQL、MongoDB）都不是最合适和擅长的。
3. 高效率查询：我们说监控系统读操作少，是相对写入来讲的。监控系统本身对于读的要求很高，用户经常会查询上百个metric，在过去一天、一周、一月、一年的数据。如何在秒级返回给用户并在前端展现，这是一个不小的挑战。

Open-Falcon在这块投入了较大的精力。我们把数据按照用途分成两类，一类是用于图表展示的；一类是用户做数据挖掘的。

对于图表展示的数据来讲，查询要快是关键，同时尽可能不丢失信息量。对于用户要查询100个metric在过去一年里的数据，数据量是巨大的，很难能在1秒之内返回。另外，就算返回了，前端也无法渲染这么多的数据，还得再采样，这就造成很多无谓的消耗。

我们参考RRDtool的理念，在数据每次存入的时候会自动进行采样、归档。归档策略是，历史数据保存5年。同时为了不丢失信息量，数据归档的时候，会按照平均值采样、最大值采样、最小值采样存三份。用户在查询某个metric在过去一年的历史数据时，Graph会选择最合适的采样频率，返回采样后的数据，提高了数据查询速度。

以1分钟的上报周期为例，下面是我们采用的数据归档采样策略（RRA的概念请参考RRDtool的文档）。

// 1分钟一个点存12小时
RRA(＂AVERAGE＂, 0.5, 1, 720)

// 5分钟一个点存2天
RRA(＂AVERAGE＂, 0.5, 5, 576)
RRA(＂MAX＂, 0.5, 5, 576)
RRA(＂MIN＂, 0.5, 5, 576)

// 20分钟一个点存7天
RRA(＂AVERAGE＂, 0.5, 20, 504)
RRA(＂MAX＂, 0.5, 20, 504)
RRA(＂MIN＂, 0.5, 20, 504)

// 3小时一个点存3个月
RRA(＂AVERAGE＂, 0.5, 180, 766)
RRA(＂MAX＂, 0.5, 180, 766)
RRA(＂MIN＂, 0.5, 180, 766)

// 1天一个点存1年
RRA(＂AVERAGE＂, 0.5, 720, 730)
RRA(＂MAX＂, 0.5, 720, 730)
RRA(＂MIN＂, 0.5, 720, 730)

为了更进一步地提高写入性能，Graph充分使用内存，将待更新的数据缓存一定的时间（30分钟）后，再刷新到磁盘中，这样对磁盘IO的压力减少了一个数量级。同时为了避免刷新磁盘产生压力峰值，我们把刷新磁盘的操作打散到了每一秒钟。当然，使用缓存技术后，会产生两个副作用，一是当程序异常崩溃或者服务器断电的时候，会导致内存中尚未刷新到磁盘的数据丢失；二是用户查询数据的时候，就需要把内存中的数据和磁盘上的数据做合并，在一定程度上增加了代码的复杂度。

前面在讲述Transfer的时候，我们提到Transfer根据一致性哈希算法，将数据打散分发到后端不同的Graph实例上来达到水平扩展的能力。那么这里就存在一个问题，如果后端的Graph需要扩容实例数目的时候，一致性哈希算法得到的结果就会跟着发生变化，导致一部分历史数据丢失。为了解决这个问题，我们正在给Transfer增加一个migrating功能，当后端Graph需要扩容实例数目的时候，Transfer会根据扩容前后的实例信息，对每个数据采集项进行两次一致性哈希计算，根据计算结果来决定是否要进行数据迁移。

对于原始数据，Transfer会推送一份到HBase，也可以直接使用OpenTSDB，Transfer支持往OpenTSDB中写入数据。

数据查询

到这里，数据已经成功地存储在Graph里了。如何快速地读出来呢？读过去1小时的、过去1天的、过去一月的、过去一年的，都需要在秒级时间内返回。

这些都是靠Graph和Query组件来实现的，Transfer会将数据往Graph组件中转发一份，Graph收到数据以后，会以RRDtool的数据归档方式存储，同时提供查询RPC接口。

Query面向终端用户，收到查询请求后，根据一致性哈希算法，会去相应的Graph里面查询不同metric的数据，汇总后统一返回给用户。

Dashboard

在Dashboard首页，用户可以根据关键字来搜索endpoint，也可以根据上报的tags来搜索相关联的endpoint，如图5所示。

图5 搜索

用户可以自定义多个metric，添加到某个screen中，这样每天早上只需要打开screen看一眼，服务的运行情况便尽在掌握中了，如图6所示。

图6 掌握服务的运行情况

当然，也可以查看清晰大图，在横坐标上放大或缩小区间范围，快速筛选或反选监控项目，如图7所示。总之，用户的“使用效率”是第一要务。

图7 查看清晰大图

Web-portal

一个高效的用户配置交互界面，对于提升用户的“使用效率”有很大的作用。

如图8所示是服务器分组管理页面，某个endpoint加入到某个服务器分组中，就会自动拥有该分组所绑定的所有策略列表。此处可以和服务树结合，服务器进出服务树节点，相关的模板会自动关联或者解除。这样服务上、下线都不需要手动来变更监控，大大提高了效率，降低了遗漏和误报警。

图8 服务器分组管理页面

如图9所示是一个最简单的模板的例子。模板支持继承和策略覆盖，模板和服务器分组绑定后，该服务器分组下的endpoint会自动应用该模板的所有策略。
告警接收人这些配置信息，是作为模板的一个属性存在的。给定一个模板绑定了服务器分组之后，当该模板中的任何一个策略满足告警条件时，就会发送告警给模板的告警接收人。

图9 模板示例

总结

监控系统是运维基础设施中最重要的组成部分。本章，我们分享了从监控系统的选型、对比、优化到自研的整个过程。Open-Falcon项目可以在我们的github主页https://github.com/open-falcon上找到，期待各位读者一起交流和改进。

本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」，未经作者(laiwei)书面许可，不允许用于商业用途的转载、分发、和演绎。