Почему mesos-slave попросил убить задачу?

Я запускаю кластер mesos с тремя ведущими и подчиненными в настоящее время на одних и тех же машинах.

Мой вопрос в том, что иногда я вижу, что процесс резко останавливается как в 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 [email protected]: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
Marathon: 0.8.0-1.1.97.debian77
Chronos: 2.3.2-0.1.20150207000917.debian77

Я знаю, что они устарели, но эта проблема возникает в течение длительного времени, по-видимому, в случайное время, затрагивая случайные контейнеры, и даже если она будет возникать реже в будущих выпусках, меня все еще беспокоит, почему ведомое устройство решает убить задачу без регистрации какой-либо причины...

Если вам нужны еще журналы, просто спросите, какой из них предоставить. Я включил так мало, потому что этот контейнер работал больше дня без каких-либо проблем или ошибок / предупреждений в журнале mesos или stderr, и вдруг в журнале появилась первая строка с просьбой убить его.


mesos
person Salaander    schedule 26.01.2016    source источник
comment
Задачи просто убиты или перекочевали на другие рабы? Если это так, это может быть связано с отсутствием ресурсов на ведомом устройстве, на котором изначально запускалось приложение...   -  person Tobi    schedule 26.01.2016
comment
После уничтожения задачи в Marathon она запускается снова, но Marathon не выполняет обычную процедуру масштабирования/обновления, поскольку игнорирует свойство MinimumHealthCapacity; он просто убивал задачу и запускал новую (иногда на том же хосте), не дожидаясь ее работоспособности. Если задача Chronos была уничтожена, которая была запланирована только для однократного запуска, она не будет перезапущена Chronos. Эти модели поведения действительно касаются ....   -  person Salaander    schedule 27.01.2016
comment
Могу я спросить, почему вы не обновляетесь до более поздних версий стека Mesos?   -  person Tobi    schedule 27.01.2016
comment
Он находится в производстве, и обновление уже запланировано, но здесь меня в основном беспокоит не тот факт, что эта ошибка происходит, а тот факт, что у меня нет возможности получить информацию об этом из журналов или где-либо еще, и всякий раз, когда я вижу другие вопросы, упоминающие это я не нашел ответа. После обновления я проверю, стал ли журнал лучше/подробнее; Я только не пробовал уровень журнала трассировки, но я думаю, что это должен быть как минимум уровень информации ... В любом случае, спасибо за советы.   -  person Salaander    schedule 27.01.2016
comment
Ясно... Извини, что не смог помочь.   -  person Tobi    schedule 27.01.2016

Ответы (2)


arrow_upward
0
arrow_downward

Добавьте команду проверки работоспособности в приложение для марафона. Новая версия приложения Marathon убивает неработоспособное приложение после льготного периода (300 секунд), и оно продолжает возрождаться на каком-то другом подчиненном устройстве.

Самый простой способ проверить работоспособность — использовать команду pwd.

Если проверка работоспособности не работает, попробуйте увеличить ЦП и ОЗУ.

введите здесь описание изображения

person HimalayanCoder    schedule 17.05.2016
comment
У всех приложений была проверка работоспособности, и это можно было найти в журнале, если они стали неработоспособными, но этого не произошло, mesos убил совершенно исправные работающие докер-контейнеры. - person Salaander; 19.05.2016
comment
попробуй увеличить оперативку и процессор - person HimalayanCoder; 20.05.2016

arrow_upward
0
arrow_downward

Мы тоже недавно столкнулись с этой проблемой. Что мы узнали, так это то, что задача была фактически убита убийцей OOM.

В справочном документе по докеру упоминается, что:

По умолчанию ядро ​​​​убивает процессы в контейнере, если возникает ошибка нехватки памяти (OOM). Чтобы изменить это поведение, используйте параметр --oom-kill-disable.

Мы понимаем, что ошибка OOM не обязательно должна быть на хосте mesos-slave (т.е. хосте докера), в случае, если контейнеру докера не хватает памяти, в то время как у хоста докера все еще есть свободная память, процесс также был убит .

После того, как мы добавили опцию --oom-kill-disable в нашу марафонскую задачу, проблема исчезла.

"parameters": [
  {
    "key": "oom-kill-disable",
    "value": "true"
  }
]
person fayndee    schedule 05.07.2016