Переконайтесь, що процес завжди працює


23

Нещодавно я почав розміщувати сайти, використовуючи Cherokee. Для зовнішніх джерел (FastCGI тощо) він має можливість запустити процес, якщо він не може знайти жодного, що працює на призначеному сокеті або порту. Це чудово, оскільки це означає, що якщо PHP або сайт Django потрапляє (як це трапляється іноді), він автоматично його перезапускає.

На новому сервері, що використовує PHP-FPM, я не міг використовувати Cherokee (він має помилку з PHP), тому я перейшов до NGINX. Мені дуже подобається NGINX (за його конфігураційний стиль), але у мене виникають серйозні проблеми з процесами, які перепадають і ніколи не розмножуються. PHP робить це іноді, але сайти Django є більшою проблемою. Я створив для них скрипти init, і вони з'являються під час завантаження, але це не допомагає мені, якщо вони переходять між перезавантаженнями.

Я думаю, я шукаю проксі-сервер FastCGI. Щось таке, що, як і Cherokee, знає, які процеси повинні працювати в яких сокетах / портах і відновлює їх на вимогу. Чи існує така річ? Чи є спосіб вбудувати це в NGINX (для зручності налаштування)?

Відповіді:


13

Як щодо daemontools та конкретно інструменту нагляду

контролювати моніторинг служби. Він запускає послугу і знову запускає службу, якщо вона загине. Налаштування нової служби легко: усі потреби в нагляді - це каталог із сценарієм запуску, який запускає службу.


+1 для демонтів. Однак ви часто не можете просто кинути такий сценарій, як /etc/init.d/apachectlу нього. Вам часто потрібно переписати власний простий сценарій запуску для використання exec. Хоча я хотів би побачити ще кілька прикладів із використанням daemontools
Стефан Ласєвський

daemontools має ще одне втілення як runit. Зараз не так важливо, що daemontools є загальнодоступним, але старіший дистрибутив може мати лише runit.
camh


5

Я друге daemontoolsпропозицію, але якщо вам не подобається, як працює програмне забезпечення DJB (з будь-якої причини), також є supervisord.

Я встановив зображення FreeBSD деякий час назад, яким supervisordкерував nginxі gunicornякий використовував для розміщення простих програм WSGI, і весь процес був досить простим.

Якщо ви робите це для Django, Gunicorn робить насправді простим розгортанням програм Django, btw. Дивіться цю публікацію в блозі для отримання більш детальної інформації.


4

Іншим варіантом може бути використання monit , який я зазвичай використовую.


3

Ви розглядали god?

Бог - це легко налаштувати, легко розширити рамку моніторингу, написану на Ruby.

Збереження серверних процесів і завдань, що працюють, повинно бути простою частиною процесу розгортання. Бог прагне бути найпростішим, найпотужнішим доступним моніторинговим додатком.

Я використовую це, щоб переконатися, що, якщо випадки Rails / nginx перепадуть, вони відроджуються, і хоча я не бачу вбудованої підтримки для перевірки, використовує він правильний порт чи ні, але якщо проблема полягає в тому, що процес не працює або більше не працює, ви не можете помилитися god.



0

Хакітським рішенням буде періодично запускати скрипт (через cron), який виявляє, якщо процес не працює, і в цьому випадку його повторно запускати .


0

Існують різні способи перезапустити невдалий демон, звичайна рекомендація - «заново вставити в inittab», але з деяким врахуванням обмеження, якщо машина справді накручена.

Демон-охоронець може також відслідковувати процес через свій PID-файл. Однак це слід розглядати лише як вторинну лінію захисту для перезавантаження машини, яка занадто больна для належного запуску (наприклад, з пам'яті, бомбардуванням вилами тощо), а не як основний спосіб або моніторинг та перезапуск демона.

Нарешті, ви можете розглянути моніторинг складних систем, використовуючи nagios, щоб надати адміністратору (ів) глобальний вигляд. Він може запускати плагіни, щоб перевірити роботу демона зовні, що є більш повним тестом його функціонування, що просто PID, який знаходиться в прямому ефірі.


-1

Проста відповідь - почніть, пишіть кудись кудись, і кожен раз (секунди, хвилини, ваша ставка) перевіряйте, чи завершився процес.

Довга відповідь - все вищезазначене - хороші методи. Але дещо складне.

Також пам’ятайте, що бути живими та відповідати на запити - це різні речі.


1
… І схрестіть пальці і сподіваєтесь, що нічого не прошиває файл PID, або стирає його, або повторно використовує його для іншого демона, або повторно вказує на якийсь інший невинний і не пов’язаний між собою процес, який не буде добре реагувати на перевірку за те, що вгору. ☺ Ось чому довга відповідь належного керівника демона, який керує демонами як дочірніми процесами і стежить за ними за допомогою звичайних системних механізмів Unix / Linux, - це давно прийнятий кращий спосіб.
JdeBP
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.