killed by systemd.kill

#Blog

故障

昨天有一个线上故障，今天反思总结一下，我们线上有一个刚刚上线的发布系统，用于升级替换掉老系统，我们自己的监控大部分组件和服务树都已经完全用发布系统来编译上线。直到昨天，我们全量升级了一版发布client端……

Time line

  • 2017.11.07 15:39 提交puppet变更，用puppet升级接管发布client包。
  • 2017-11-06 17:18 提交测试环境，测试没有问题
  • 2017-11-06 17:21 puppet变更上线，全量生效将在17:30生效
  • 2017-11-06 17:21 收到一台服务的报警，某个监控服务的组件被干掉了，和同事开始排查，但是毫无头绪
  • 2017-11-06 17:30 puppet变更生效，发布client开始升级，由 v0.0.1-5 升级到 v0.0.1-6
  • 2017-11-06 17:32 接到大量监控服务报警，发布系统和监控系统相关组件系数挂掉
  • 2017-11-06 17:35 紧急手动优先拉起重要服务，通过发布系统批量拉起其他服务，并开始着手回滚puppet配置
  • 2017-11-06 17:39 回滚puppet配置
  • 2017-11-06 17:41 一级报警，监控室电话通报
  • 2017-11-06 17:43 根据报警大盘恢复所有服务，并排查问题，同事review puppet变更
  • 2017-11-06 17:56 从监控室要来了所有报警的主机名，发现只有el7有问题
  • 2017-11-06 18:01 定位到问题
  • 2017-11-06 18:16 对发布client重新打包 v0.0.1-7 着手测试
  • 2017-11-06 18:19 测试环境，故障复现，确定问题
  • 2017-11-06 18:47 puppet重新上线， 由 v0.0.1-5 升级到 v0.0.1-7，部分yum缓存仍然有可能升级到 v0.0.1-6
  • 2017-11-06 19:00 puppet变更生效，出现两台有问题的服务

问题

此次故障涉及通过发布系统上线，并拉起服务的el7系统，问什么会这样呢？和 systemd有关系

# If you modify this, please also make sure to edit init.sh

[Unit]
Description=deploy agent for deploy services
Documentation=https://monitor.xxx.com/
After=network-online.target

[Service]
User=root
Group=root
LimitNOFILE=655360
ExecStart=/usr/local/deploy-agent/bin/deploy-agent start -c /usr/local/deploy-agent/conf/deploy-agent.conf
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=deploy-agent.service

问题就出现在 KillMode=control-group 这一配置上，文档是这样介绍的：If set to control-group, all remaining processes in the control group of this unit will be killed on unit stop。Defaults to control-group.

于是改成了

KillMode=process

这样就只会有主进程被kill掉了。

反思

虽然运维成本很高，但是得益于坚持多操作系统（ubuntu/centos）,多版本（el6/el7)部署服务, 以至于大部分组件虽然挂掉，但是监控系统仍得以存活，能正常报警，正常提供部分重要服务，当某一平台爆发严重漏洞或者某一配置出现人为失误不至于全军覆灭。但是对于测试还是暴露出了非常大的问题，其实在测试阶段问题已经暴露，但是由于没有排查到问题，也没有想到其中的关联关系，沉迷于排查问题，没有及时终止上线操作，以至于后来很多服务出现异常（量大必能找到规律和其中的关联关系，故障也一样）。对systemd的配置不够清晰，对于这些重要服务，没有具体深入了解这些配置项的作用。所幸的是目前发布系统的最大用户就是监控系统和发布系统本身，能及时的暴露出这些问题还为时不晚。