updater只有一个功能，就是升级其他业务系统的agent。
每隔指定周期（配置文件中的interval，单位是秒）调用一下ops-meta的http接口，上报当前管理的各个agent的状态和版本号，比如：
[
{
"name": "falcon-agent",
"version": "1.0.0",
"status": "started"
},
{
"name": "dinp-agent",
"version": "2.0.0",
"status": "stoped"
}
]
response中顺便带回服务端配置的meta信息，也就是各个agent的版本号、tarball地址、要求的操作等等，比如
[
{
"name": "falcon-agent",
"version": "1.0.0",
"tarball": "http://11.11.11.11:8888/falcon",
"md5": "http://11.11.11.11:8888/falcon",
"cmd": "start"
},
{
"name": "dinp-agent",
"version": "2.0.0",
"tarball": "http://11.11.11.11:8888/dinp",
"md5": "",
"cmd": "stop"
}
]
updater将这个信息与自我内存中的信息做对比，该升级的升级，该启动的启动，该停止的停止。sorry，不能与内存中的信息做对比，应该直接去各个agent目录调用control脚本查看，因为agent有可能crash，或者做了一些手工操作，这将导致updater内存中的信息并不能实时反应线上情况
此处tarball和md5的配置并不是一个全路径（类似这样： http://11.11.11.11:8888/falcon/falcon-agent-1.0.0.tar.gz ），只是一部分路径，因为我们已经知道name和version了，就可以拼接出全路径了，算是一种规范化吧，拼接规范是：{$tarball}/{$name}-{$version}.tar.gz
举个例子：
/home/work/ops
|- ops-updater
|- ops-updater.pid
|- ops-updater.log
|- falcon-agent
|- 1.0.0
|- falcon-agent
|- control
|- 1.0.1
|- falcon-agent
|- control
|- .version
|- dinp-agent
|- 2.0.0
|- 2.0.1
|- .version
.version文件是当前这个agent应该使用的版本
./control start|stop|restart|tail
配置文件是cfg.json，我们提供了cfg.example.json作为配置模板，mv cfg.example.json cfg.json，然后修改成合适的配置
- updater访问ops-mata不能太集中，故而要加一个随机数，启动之后先随机sleep一下，然后再发送心跳请求
- updater只升级agent就可以了，事情做得少才不容易出错
- updater可能依赖一些Linux工具才能正常工作，比如tar、md5sum等，在启动之前要做验证，如果没有，退出
- 必须提供control脚本
./control start可以启动agent./control stop可以停止agent./control status打印出状态信息，只能是started或者stoped- control文件已经有可执行权限，并且在tarball根目录下