Cluster
logkit 通过添加 runner 的形式，提供了丰富的功能来收集、解析和发送多种格式的日志和系统信息，但是当在集群中部署多个 logkit 时，runner 的管理也变得繁琐。不仅需要查看各个 logkit 的管理页面来监控 runner 的运行状态，当需要统一管理(增加、删除、更新、停止、启动) runner 时，更是会浪费大量的时间来执行重复性的操作。
为了解决这个问题，我们特意为 logkit 开发了 cluster 功能，它将 logkit 分成 master 和 slave 两类，master 可以管理 slave 上的 runner。当然，master本身也可以是一个slave，承担数据收集的责任。
- 通过 master 可以查看所有 logkit 上的 runner 的运行状态；
- 通过 master 可以批量对 logkit 上的 runner 添加/删除/更新/停止 等操作；
- logkit 的 cluster 功能采用了 master/slave 的架构，slave 会定期向 master 发心跳注册；
- 一个 slave 的 master 可以有多个，它们都可以对该 slave 进行管理，master本身是一个无状态服务，相当于一个中转站，负责将用户的请求分发给所有的slave，也可以收集所有slave的状态方便用户查看;
- 每一个 slave 都分配一个 tag，tag 可以用于将 slave 分类。 master 可以以 tag 为单位，对 slave 进行批量操作。当然也可以对某一个特定的 slave 进行操作。
logkit 的 cluster 功能配置非常简单，只需要在 logkit 的主配置文件中添加下面的配置即可
对于 master 来说, 应该添加:
{
"cluster": {
"master_url": [],
"is_master": true,
"enable": true
}
}
若master本身也想承担slave的功能，只需要在 "master_url" 的地方将自身的地址填写上即可。
对于 slave 来说，假设其 master 的 url 为192.168.0.2:3000, 应该添加:
{
"cluster": {
"master_url": ["http://192.168.0.2:3000"],
"is_master": false,
"enable": true
}
}
以 slave 为例，完整的 logkit 主配置文件示例如下：
{
"max_procs": 8, # 选填，默认为机器的CPU数量
"debug_level": 1, # 选填，默认为0，打印DEBUG日志
"bind_host":"127.0.0.1:3000", # 选填，默认自己找一个4000以上的可用端口开启
"profile_host":"localhost:6060", # 选填，默认为空，不开启
"clean_self_log":true, # 选填，默认false
"clean_self_dir":"./run", # 选填，clean_self_log 为true时候生效，默认 "./run"
"clean_self_pattern":"*.log-*", # 选填，clean_self_log 为true时候生效，默认 "*.log-*"
"clean_self_cnt":5, # 选填，clean_self_log 为true时候生效，默认 5
"rest_dir":"./.logkitconfs", # 选填，通过web页面存放的logkit配置文件夹，默认为logkit程序运行目录的子目录`.logkitconfs`下
"static_root_path":"./public", # 必填，logkit页面的静态资源路径，即项目中public目录下的内容，包括html、css以及js文件，请尽量填写绝对路径
"timeformat_layouts":["[02/Jan/2006:15:04:05 -0700]"], #选填，默认为空。
"confs_path": ["confs","confs2", "/home/me/*/confs"], #必填，监听的日志目录
"cluster": { # 启用 cluster 功能时填写.
"master_url": ["http://192.168.0.2:3000"],
"is_master": false,
"enable": true
}
}
此处仅介绍 cluster 配置的字段信息，完整的 logkit 主配置文件字段说明请参考 logkit主配置文件
cluster 配置参数说明如下:
| 参数名称 | 参数类型 | 是否必填 | 参数说明 |
|---|---|---|---|
| master_url | string 数组 | slave 必填 master 选填 |
master_url中的每一项都应该是一个url(包括端口号)，它们是当前 logkit 各个 master 的 url1. 对于 slave, 它会定期向每个链接发心跳注册，以便让其 master 获取自己的状态 2. 对于 master, 当填写该字段后，它本身也会作为 slave 受到它的 master 控制，当然这个 master 可以是它自己。 |
| is_master | bool | 必填 | 标明当前 logkit 是否是 master: 1. master 请置为 true 2. slave 请置为 false |
| enable | bool | 必填 | 是否启用 cluster 功能， master 和 slave 都应该置为 true |
注意：
- 在启用 cluster 功能时，建议将 logkit 主配置文件中的
bind_host字段显式绑定一个可以保证master、slave能够互相通信的ip地址和端口。 因为当此处的ip地址为空时，作为slave的logkit会自行获取本机的一个ip地址，并在向master发心跳时将该ip地址发送给master,master会利用该ip与slave进行通信。此时，若该ip与master不在同一网段，就会造成master无法访问slave的情况。 - 在配置结束后，建议先启动作为
master的logkit，再启动作为slave的logkit，这样可以避免slave产生向master发心跳失败的错误日志。
logkit 助手一直是 logkit 的一大特色，它通过可视化的界面可以让人轻松搞定 runner 的配置以及 runner 运行状态的监控。加入 cluster 功能后，我们对 logkit 配置助手进行了完善，使其能更加便利的管理和监控 master 及其所有 slave 的 runner。下面是对 logkit 助手在 cluster 模块开启后的介绍。
注意： 在开启 cluster 模式后，请在 master 的 master_url 选项中填入自己或者另一个 master 的 url 以便 master 自身的 runner 可以被监控起来。
- 升级后的 logkit 监控中心在开启
cluster功能后会分为三个部分，他们分别是标签页面、机器页面和runner管理页面。 - “标签”页面：标签页面展示的是上文提到的
tag的列表，在这个页面上，可以对同一个tag的slave添加一个runner，或者对一个特定的runner进行开启、关闭、重置和删除等操作。当然还可以更改这个tag的名字。当需要进行批量操作时，可以通过一个弹框选择要操作的
runner的名字。 - “机器”页面：机器页面展示的是
master管理的所有的slave, 包括他们的url、tag、与 master 的连接状态、上次心跳时间等。同时在该页面上也可以更改一台机器的tag, 为一台特定的机器添加runner以及将这台机器从master的slave列表中删掉(注意: 这个删掉是临时的, 如果这个slave还处于活跃状态，当它向master发心跳注册时，它还会回到列表中, 提供这个功能的目的是在需要时从列表中清除处于失联状态的slave) - “runner管理”页面：runner管理页面会展示
master下所有slave的runner, 在这里可以看到每个runner的运行状态，并可以对这些runnr进行修改、关闭、重启、重置和删除等操作。
当需要进行批量操作时，可以通过一个弹框选择要操作的 
