open-falcon经过这周的安装的流程，基本上也就全部安装完毕了，今天就为大家再将最后的三个组件nodata、gateway、Aggregator来为大家一一道来。

一、nodata组件

nodata组件是用于检测监控数据的上报异常。nodata是和实时报警judge模块协同工作，过程则为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；用户配置相应的报警策略，收到mock数据就产生报警。采集项上报异常检测，作为judge模块的一个必要补充，能够使judge的实时报警功能更加可靠、完善。

1、生成并修改配置文件

• mv cfg.example.json cfg.json
• vim cfg.json，打开配置文件后，可参照如下配置介绍对该配置文件中的参数进行配置：

各配置项的含义，如下
{
    "debug": true,
    "http": {
        "enabled": true,
        "listen": "0.0.0.0:6090" #nodata的http服务监听地址
    },
    "query":{ #query组件相关的配置
        "connectTimeout": 5000, #查询数据时http连接超时时间,单位ms
        "requestTimeout": 30000, #查询数据时http请求处理超时时间,单位ms
        "queryAddr": "127.0.0.1:9966" #query组件的http监听地址,一般形如"domain.query.service:9966"
    },
    "config": { #配置信息
        "enabled": true,
        "dsn": "root:passwd@tcp(127.0.0.1:3306)/falcon_portal?loc=Local&parseTime=true&wait_timeout=604800", #portal的数据库连接信息,默认数据库为falcon_portal
        "maxIdle": 4 #mysql连接池空闲连接数
    },
    "collector":{ #nodata数据采集相关的配置
        "enabled": true,
        "batch": 200, #一次数据采集的条数,建议使用默认值
        "concurrent": 10 #采集并发度,建议使用默认值
    },
    "sender":{ #nodata发送mock数据相关的配置
        "enabled": true,
        "connectTimeout": 5000, #发送数据时http连接超时时间,单位ms
        "requestTimeout": 30000, #发送数据时http请求超时时间,单位ms
        "transferAddr": "127.0.0.1:6060", #transfer的http监听地址,一般形如"domain.transfer.service:6060"
        "batch": 500, #发送数据时,每包数据包含的监控数据条数
        "block": { #nodata阻塞设置
            "enabled": false, #是否开启阻塞功能.默认不开启此功能
            "threshold": 32 #触发nodata阻塞操作的阈值上限.当配置了nodata的数据项,数据上报中断的百分比,大于此阈值上限时,nodata阻塞mock数据的发送
        }
    }
}

2、组件服务相关操作

• 启动组件服务
  ./control start
• 检验组件服务
  curl -s “127.0.0.1:6090/health”
• 停止服务
  ./control stop
• 查看日志服务的运行状态
  服务启动后，可以通过日志查看服务的运行状态，日志文件地址为./var/app.log。可以通过调试脚本 ./scripts/debug 查看服务器的内部状态数据，如 运行 bash ./scripts/debug 可以得到服务器内部状态的统计信息

二、gateway组件

多IDC时，可能面对 “分区到中心的专线网络质量较差&公网ACL不通” 等问题。这时，可以在分区内部署一套数据路由服务，接收本分区内的所有流量(包括所有的agent流量)，然后通过公网(开通ACL)，将数据push给中心的Transfer。

1、生成配置文件

• mv cfg.example.json cfg.json

2、组件服务相关操作

• 启动组件服务
  ./control start
  服务启动后，可以通过日志查看服务的运行状态，日志文件地址为./var/app.log。可以通过调试脚本./test/debug查看服务器的内部状态数据，如 运行 bash ./test/debug 可以得到服务器内部状态的统计信息。
• 检验组件服务
  curl -s “127.0.0.1:6060/health”
• 停止服务
  ./control stop

3、特别说明

gateway组件，部署于分区中。单个gateway实例的转发能力，为 {1核, 500MB内存, Qps不小于1W/s}；但我们仍然建议，一个分区至少部署两个gateway实例，来实现高可用。

三、Aggregator组件

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

1、生成并修改配置文件

• mv cfg.example.json cfg.json
• vim cfg.json,打开配置文件后，按如下介绍做按需配置：

{
    "debug": true,
    "http": {
        "enabled": true,
        "listen": "0.0.0.0:6055"
    },
    "database": {
        "addr": "root:@tcp(127.0.0.1:3306)/falcon_portal?loc=Local&parseTime=true",
        "idle": 10,
        "ids": [1,-1], # aggregator模块可以部署多个实例，这个配置表示当前实例要处理的数据库中cluster表的id范围
        "interval": 55
    },
    "api": {
        "hostnames": "http://127.0.0.1:5050/api/group/%s/hosts.json", # 注意修改为你的portal的ip:port
        "push": "http://127.0.0.1:6060/api/push", # 注意修改为你的transfer的ip:port
        "graphLast": "http://127.0.0.1:9966/graph/last" # 注意修改为你的query的ip:port
    }
}

2、组件服务相关操作

• 启动组件服务
  ./control start
• 检验组件服务
  ss -tln
• 检查日志
  ./control tail
• 停止服务
  ./control stop

至此，open-falcon的监控常规组件就全部安装并启动完毕了。虽然是老古董，也没有zabbix一样一直锲而不舍的更新迭代，但也是值得大家一起学习和借鉴的一套技术。