端口监控的最佳实践

这个最佳实践只是个噱头，标题党，呵呵，下面所述只是个人看法~

Open-Falcon的端口监控是在web端配置的，agent通过hbs的心跳机制拉取本机应该监听的端口，通过ss -tln指令判断端口是否在监听，在监听，汇报value=1到server端，没在监听，汇报value=0到server端，上报的数据长这样：

{
    "endpoint": "qd-sa-falcon-graph01.hd",
    "metric": "net.port.listen",
    "tags": "port=8080",
    "value": 1,
    "timestamp": 1451569142,
    "counterType": "GAUGE",
    "step": 60
}

tags中只是表明了这是哪个端口，没有其他维度的信息，于是我们要想对这个端口做监控需要做这种配置：

metric=net.port.listen port=8080 all(#2) != 1

报警的时候如果只是报8080端口宕了，不太容易知道这是哪个服务，所以通常需要为这个策略写一个备注信息，比如“a服务宕”，这样在报警的时候就可以把这个备注信息塞到报警短信里。

那作为一个开发人员，他应该做些什么呢？

1. 创建一个HostGroup，放置要部署服务的一批机器
2. 服务部署完成之后创建一个策略模板，添加端口监控策略
3. 把HostGroup与这个策略模板绑定

看起来也没有多少工作，也还好啦。但是，我可能会写多个服务，每个服务都有要监控的端口，那就要重复上面的工作，而在服务升级维护的时候可能需要修改屏蔽相关策略，服务下线的时候删除相关策略。

但是，上面都是手工操作。虽说系统做到这步，已经差不多了，但是刚才灵光乍现，把想法分享给大家。

针对服务的监控就要跟着服务走，比如某个监控脚本是为了采集某个服务的相关指标，那该监控脚本就要随着服务的上线而上线，随着服务的升级而升级，随着服务的下线而下线

而端口监控，就是针对某个服务的，于是，端口监控也应是跟着服务走的。

终极方案

我们可以编写一个脚本用来做端口监控，或者改造agent，让agent读取本机的某个端口命名的文件，读到哪个端口文件就去探测监控哪个端口。文件名是具体端口，文件内容是tags，比如：team=sa-dev,project=falcon,module=transfer，agent在push端口监控数据的时候，不同的端口要带上相关的这个tags。

服务端的端口监控配置可以大大减少，比如我们团队开发的falcon这个项目的所有组件的所有端口出了问题，都要给我发报警，我可以这么配置：

each(metric=net.port.listen team=sa-dev project=falcon) all(#2) != 1

对于端口文件的修改，可以在服务的启停脚本中操作，这样一来，就自动化起来了~