问题1：服务器遭遇被迫重启
无须太过担心，蓝鲸智云的所有服务都会随着系统开机自启动，只不过需要注意三台机子的性能问题。
如果性能不太够，可能会出现几种情况：
1.平台组件对接出错，进入Active黄色状态，且针对性重启不能成功。
原因：由于性能不够，导致后续的服务比前置服务启动得快，导致前置服务启动失败
2.出现一些网页502 Bad Gateway
问题2：重启之后如何进行例行检查
首先，我们要登陆中控机，在智云中所有系统命令均只能在中控机下发
第一步：检查组件状态
./bkcli status all
第二步：检查consul服务
该服务我觉得应该是智云之间的注册服务，在服务启动之后会自动向中控机发起注册信息表示服务启动成功，用于联通各个分布式主机，因此该服务十分重要
使用该命令检查每个主机上的consul服务，它会告诉你要确认哪些组件
./bkcli check consul
比如说出现上面这种状态，表示nodeman-api节点挂了，我们只需要针对性重启即可
./bkcli restart nodeman
或者出现check_resolv_conf_127.0.0.1[FAIL]，表明机器的resolv.conf文件配置不对,我们这时候需要检查/etc/resy ov.conf文件首行是否存在以下配置，如果不存在则添加：
nameserver 127.0.0.1
search node.consul问题3根空间存储不足
在运行久了之后，可能在job平台机或者其他机子上会出现根目录空间存储不足的情况，导致服务无法启动，这时候就会报错：出现/tmp/xxxx.env或者是什么空间不足什么的
这时候我们需要
df -hT|grep / #查看根目录的空间大小是否已经被占用满
解决方法1：
找出缓存文件或者是其他什么文件占用了空间，进行转移或者是删除（我找不到）
解决方法2：
对根目录进行拓展，调整根目录卷，使用vgs lvs等命令查看根目录卷的名称以及调整大小，一般来说根目录卷的位置是在/dev/centos/root下，具体系统具体看，反正就是调整这个玩意的大小即可
问题4 502 Bad Gateway
如果说在问题2的例行检查中所有组件的状态处于绿色的active状态，且所有组件重启没有问题，但是还是出现了502 Bad Gateway，且确定了你安装了此组件没有任何问题，那么就不要犹豫，重启对应该组件即可
原因：我个人使用的时候可能是由于性能不足的原因或者是蓝鲸自带的检测脚本的原因，服务和组件可能会处于绿色的active状态，但是无法在Web上面进行访问该组件。猜测是因为组件大部分的功能都起来了，但是少部分没有导致的，说白了可能还是性能不足的原因
使用
./bkcli restart xxx #重启对应的组件即可
以下是官方的一些帮助文档
机器重启
如果服务器发生了重启，正常情况下组件会由 systemd 自动拉起（因为安装配置了 systemctl enable）。由于组件分布在单台机器上的实际情况较为复杂，并发启动时存在重连次数的限制导致部分进程自启动会有失败的情况。
如果服务器重启后，systemctl list-units --failed 依然有 failed 状态的进程 <输出结果除了蓝鲸组件还包括系统的 systemd 服务，请注意分辨>，可根据它们的依赖关系，重新启动底层服务，确认成功后，再启动蓝鲸组件来解决。以下是几种常见场景：
● kafka 启动依赖 zookeeper 可用
● cmdb 启动依赖 zookeeper 可用
● 监控链路的 bk-influxdb-proxy 和 bk-transfer 依赖 kafka 可用
注意事项
以往的脚本提供了 stop all 和 start all 的操作，容易引发误操作，日常维护中，并不需要经常做全部服务的停止和启动。对于第三方组件尽量保证它们稳定运行，但是混搭进程的情况下，有时会因为内存不足导致不断 OOM 触发一系列异常。此刻应该按实际情况重启相关进程，避免全部进程重启的粗暴操作。
检查思路
检查 DNS 配置文件
● 在部署的 3 台机器上检查 /etc/resolv.conf 文件首行是否存在 nameserver 127.0.0.1 记录。如不存在，请自行加入该文件的首行。
检查相关服务
中控机执行命令
echo bkssm bkiam usermgr paas cmdb gse job consul bklog | xargs -n 1 ./bkcli check
如果 check 输出的状态为非 true，那么可以使用 ./bkcli start|restart 拉起。 module 为 check 状态非 true 的模块。
假设 paas，job，gse，bkmonitorv3 自启动失败，可以参考下述命令：
中控机执行
echo paas job gse bkmonitorv3 | xargs -n 1 ./bkcli restart
如果是模块的某个服务自启动失败，以 gse data 为例
./bkcli restart gse data
job 启动稍微有点慢，可等待 10s~30s 再执行 check 命令。
此外，还可以登录至模块所在的服务器，通过 systemctl start|restart 拉起服务。以 PaaS 为例：
登录 paas 模块所在的机器
source /data/install/utils.fc
ssh $BK_PAAS_IP
重启 paas 服务
systemctl restart bk-paas.target
启动蓝鲸所有 SaaS
./bkcli start saas-o