为什么mesos-slave要求杀死任务？

Question

我正在运行一个带有三个主机和从机的介质集群，当前它们位于同一台机器上。

我的问题是，有时我发现在Marathon和Chronos中突然停止了一个进程。在检查了我看到的日志后，每次，mesos-slave都要求框架杀死这些任务。 我试图谷歌它，在这里找到它但我没有找到相关的答案。

我如何记录或了解为什么mesos-slave要求其中一个已注册的框架杀死任务？

使用以下相关行记录：

Jan 25 02:48:58 hostname mesos-slave[9817]: I0125 02:48:58.143537  9843 slave.cpp:1372] Asked to kill task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:48:59 hostname mesos-slave[9817]: I0125 02:48:59.108821  9834 slave.cpp:2215] Handling status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 from executor(1)@192.168.49.1:42710
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:04.976814  9823 status_update_manager.cpp:317] Received status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.108389  9823 status_update_manager.hpp:346] Checkpointing UPDATE for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.280825  9848 slave.cpp:2458] Forwarding the update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 to master@192.168.49.2:5050
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.346415  9848 slave.cpp:2391] Sending acknowledgement for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000 to executor(1)@192.168.49.1:42710
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.443266  9820 status_update_manager.cpp:389] Received status update acknowledgement (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:49:05 hostname mesos-slave[9817]: I0125 02:49:05.443447  9820 status_update_manager.hpp:346] Checkpointing ACK for status update TASK_KILLED (UUID: abad489c-73bb-4f45-abbe-85f033ddde51) for task TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2 of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.419437  9833 slave.cpp:2898] Executor 'TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' of framework 20150311-145345-20031680-5050-2698-0000 exited with status 0
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.445489  9833 slave.cpp:3007] Cleaning up executor 'TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' of framework 20150311-145345-20031680-5050-2698-0000
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471329  9837 gc.cpp:56] Scheduling '/tmp/mesos/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2/runs/473a2313-0147-44ae-ab9c-b39f5a23be22' for gc 6.99999454929185days in the future
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471817  9837 gc.cpp:56] Scheduling '/tmp/mesos/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' for gc 6.99999454685037days in the future
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471911  9837 gc.cpp:56] Scheduling '/tmp/mesos/meta/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2/runs/473a2313-0147-44ae-ab9c-b39f5a23be22' for gc 6.99999454636444days in the future
Jan 25 02:49:34 hostname mesos-slave[9817]: I0125 02:49:34.471997  9837 gc.cpp:56] Scheduling '/tmp/mesos/meta/slaves/20150512-155858-53586112-5050-11767-S0/frameworks/20150311-145345-20031680-5050-2698-0000/executors/TASKNAME.4b060055-b85a-11e5-8a34-52eb089dbeb2' for gc 6.99999454594963days in the future

我找到一个问题的同一错误的一个答案建议检查它是否被OOM杀手杀死，我检查并且没有内存不足问题，没有相关的内核日志。 mesos-slave本身记录了要求框架杀死它所以我不认为这是一个外部过程，如果我错了就纠正我。

我目前使用：
Mesos：0.21.1-1.2.debian77
马拉松：0.8.0-1.1.97.debian77
Chronos：2.3.2-0.1.20150207000917.debian77

我知道它们已经过时了，但是这个问题很长一段时间似乎在随机时间发生影响随机容器，即使它在未来的版本中发生的次数减少了我仍然困扰为什么奴隶决定在没有记录任何原因的情况下杀死任务...

如果您还需要更多日志，请询问提供哪一个。我只包括这么少，因为该容器运行超过一天没有任何问题或错误/警告登录mesos或stderr突然第一行出现在日志中，要求奴隶杀死它。

Answer 1

为您的马拉松应用添加运行状况检查命令。新版本的Marathon应用程序会在一段宽限期（300秒）后杀死一个不健康的应用程序，并且它会在其他一些奴隶身上不断重生

进行健康检查的最简单方法是使用pwd命令

如果健康检查不起作用，请尝试增加CPU＆amp; RAM

Answer 2

我们最近也遇到了这个问题。我们发现的是OOM杀手真正杀死的任务。

在docker's reference doc中提到：

  

默认情况下，如果发生内存不足（OOM）错误，内核会终止容器中的进程。要更改此行为，请使用--oom-kill-disable选项。

我们意识到OOM错误不需要在mesos-slave主机（即docker主机）上，以防docker容器内存不足而docker主机仍然有空闲内存，过程也被杀死了。

我们在马拉松任务中添加--oom-kill-disable选项后，问题就消失了。

"parameters": [
  {
    "key": "oom-kill-disable",
    "value": "true"
  }
]