这个最佳实践只是个噱头，标题党，呵呵，下面所述只是个人看法~
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服务宕”，这样在报警的时候就可以把这个备注信息塞到报警短信里。
那作为一个开发人员，他应该做些什么呢？
- 创建一个HostGroup，放置要部署服务的一批机器
- 服务部署完成之后创建一个策略模板，添加端口监控策略
- 把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
对于端口文件的修改，可以在服务的启停脚本中操作，这样一来，就自动化起来了~
