Налаштування Supervisord: керування процесами під ключ

Supervisord: чому процеси падають і не піднімаються

Картина, з якою стикаються найчастіше: обробник черги запущений у сесії термінала, уночі сесія обривається, процес отримує SIGHUP і помирає. Ніхто цього не помітив — до ранку в черзі накопичуються тисячі необроблених заявок, а черговий піднімає сервіс вручну й підчищає хвіст.

Причина в тому, що сервіс, який упав, не піднімається сам: ядро лише завершує процес і віддає код повернення батькові. Якщо батьком була оболонка або тимчасовий скрипт, забирати повернення нікому — процес залишається сиротою, і повторний старт ніхто не ініціює.

Той самий механізм породжує процеси-зомбі: батько не забирає статус, запис залишається в таблиці процесів і накопичується, доки нових нащадків уже не створити.

Supervisord закриває це на рівні операційної системи: демон стартує як системна служба, сам виступає батьком для кожної програми й тому забирає код повернення — зомбі не накопичуються.

Автозапуск процесів на сервері описується декларативно: у конфігурації для програми задаються команда, робочий каталог, користувач, ознака автозапуску, автоперезапуск, пауза між спробами та їхня гранична кількість.

Журнали роботи процесів не губляться: потік виводу та помилок пишеться в окремі файли з ротацією за розміром і кількістю копій, тому розбір нічного збою не потребує пошуку слідів по всій машині.

Стан видно однією командою, а ручний перезапуск застосунку виконується точково, не зачіпаючи сусідні сервіси. Нижче розбираємо, як це закривається на практиці.

Що змінюється після впровадження контролю процесів

До впровадження контролю процесів левова частка простоїв припадала на падіння процесу, яке ніхто не помітив: служба вмирала вночі, а дізнавалися про це зі звернень уранці.

Час відновлення сервісу складався з часу виявлення плюс ручний запуск — десятки хвилин і обов’язкова участь чергового.

Supervisord переводить це в керований режим.

Процеси описуються декларативно: автоматичний перезапуск спрацьовує за аварійним кодом повернення, startretries і startsecs відсікають «блимаючі» служби, exitcodes задає список штатних завершень — планова зупинка не маскується під збій і не викликає цикл рестартів.

Спостережуваність стану служб будується на виводі supervisorctl status і обробнику подій: перехід в аварійний стан іде алертом у моніторинг разом із хвостом логу процесу.

Чергова зміна бачить не «сервер недоступний», а конкретну службу, причину та кількість спроб — діагностика починається з факту, а не з пошуку.

Підсумок вимірний: відновлення вкладається в секунди й не потребує людини, частка простоїв через непомічені падіння падає до одиниць відсотків, кількість ручних втручань скорочується в рази. Навантаження на чергову зміну перестає зростати разом із кількістю сервісів.

Supervisord і альтернативи: що вибрати для сервісу

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

Різниця проявляється в деталях — хто стежить за процесом, як описуються залежності запуску, що відбувається після перезавантаження вузла та як змінювати конфігурацію без простою.

Нижче — варіанти, між якими реально вибирають на проєктах. Комбінувати їх можна: усередині контейнера часто залишається свій супервізор для кількох процесів застосунку.

Практичне правило: один процес у контейнері — мінімум зовнішнього керування; кілька процесів на вузлі — Supervisord із пріоритетами й групами; системні служби — профільному системному менеджеру.

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

Етапи впровадження: від аудиту до передачі в експлуатацію

Інвентаризація — половина роботи.

Перш ніж писати конфігурацію, наші інженери збирають усе, що фактично запускається на серверах: сервіси, підняті вручну в чужій сесії, завдання планувальника, скрипти, що залишилися від попередніх підрядників, «тимчасові» рішення, які живуть роками.

Supervisord бере їх під керування — але лише якщо точно відомо, що він має тримати і в якому порядку.

Порядок робіт

1. Аудит запуску сервісів. Фіксуємо, що працює зараз, хто власник процесу, куди пишуться логи, що перезапускається при збої, а що вмирає мовчки.
2. Схема залежностей процесів. Визначаємо, хто кого чекає: застосунок не стартує раніше за базу, фонові завдання — раніше за чергу. На схемі видно порядок підйому та порядок зупинки.
3. Налаштування керування. Переносимо сервіси під Supervisord: автозапуск, правила перезапуску, ліміти, ротація логів, окремі системні користувачі.
4. Перевірка сценаріїв відмови. Вбиваємо процеси, валимо залежності, перезавантажуємо машину — дивимося, чи піднімається все в потрібному порядку і чи не залишається «напівживих» станів.
5. Приймальні перевірки. Проганяємо узгоджений список перевірок на тестовому та бойовому контурах разом із вашою командою; розбіжності усуваємо до передачі.
6. Передача в експлуатацію. Віддаємо конфігурації, схему, інструкції з типових операцій і регламент дій при збої.

Такий порядок знімає головний ризик — систему, яка працює «поки її ніхто не чіпав». Після передачі ваша команда керує сервісами штатними командами, а не пошуком того, хто пам’ятає, як це запускалося.

Конфігурації, політики перезапуску та регламенти

Комплект документації передаємо не «для галочки»: за ним черговий інженер, який не брав участі у впровадженні, зможе підняти сервіс, що впав, і зрозуміти, чому той зупинився. Нижче — що фізично залишається в замовника в репозиторії конфігурацій і у внутрішній базі знань.

• Файли конфігурації процесів — по одному опису на сервіс в окремому каталозі, зі шляхами, змінними середовища, лімітами спроб і порядком запуску; конфігурації версіонуються, зміни проходять перевірку.

• Політика перезапуску — які коди завершення вважаються нормою, скільки спроб дається на відновлення, що робити при повторному падінні: залишити зупиненим, підняти із затримкою або ескалувати.

• Права доступу до процесів — від якого користувача працює кожен сервіс, хто має право зупиняти й перезапускати його через керуючий інтерфейс, як обмежено доступ до логів і сокета.

• Схема груп і залежностей — що піднімається першим, який процес чекає сусідній, який не можна зупиняти окремо без ризику для інших.

• Регламент чергової зміни — таблиця «симптом → дія», поріг, за якого черговий викликає інженера, шаблон ескалації та порядок фіксації інциденту.

• Інструкція із супроводу — як додати новий процес, як плавно вивести сервіс з ротації, де дивитися логи та як відкотити конфігурацію до попередньої ревізії.

• Збір метрик і оповіщення — стан процесів, зростання споживання пам’яті та часті перезапуски видно до того, як сервіс упаде остаточно, а не за ранковим дзвінком.

Кожен пункт проходить приймання на тестовому контурі: ми навмисно валимо процеси й дивимося, чи відпрацьовує політика так, як записано в регламенті.

Кейс: сервіс перестав падати непомітно для команди

До впровадження

Сервіс тримався на п’яти процесах — воркери черги, планувальник завдань, обробник зовнішніх подій — і запускався вручну з консолі.

Коли воркер падав, черга продовжувала зростати, а команда дізнавалася про це зі скарги клієнта: від відмови до першого сигналу минало близько трьох годин, ще стільки ж — на розбір і ручний перезапуск. За місяць фіксували 11 таких зупинок, із них 8 виявляли користувачі, а не моніторинг.

Що змінили і що стало

Кожен процес описали декларативно: команда запуску, залежності, робоча директорія, поведінка при зупинці та ліміти перезапусків.

Supervisor узяв на себе контроль стану, автозапуск після перезавантаження вузла й автоматичне відновлення процесів, що впали, — із затримкою та стелею спроб, щоб цикл падінь не маскувався під стабільну роботу.

Потоки виводу звели в один лог із ротацією, а на події відновлення й перевищення ліміту повісили оповіщення черговому.

Частка зупинок, які закриваються без людини, зросла з нуля до 92% — відновлення займає секунди замість годин. Час реакції на реальну аварію скоротився з трьох годин до кількох хвилин: сигнал тепер надходить від системи, а не від клієнта.

Ручних втручань залишилося 1-2 на місяць замість 11, і пов’язані вони з дефектами в коді, а не з інфраструктурою. Звіт за результатами включив карту процесів, конфігурацію, схему оповіщень і регламент чергового — стан сервісу зрозумілий без читання вихідних кодів.

Чим Supervisord відрізняється від штатного менеджера служб

Штатний менеджер служб (у більшості дистрибутивів — systemd) розрахований на хостовий рівень: один юніт — одна служба, залежності між юнітами, автозапуск під час завантаження, ліміти через cgroups і загальний бінарний журнал.

Для системних демонів це саме те, що потрібно — він піднімається раніше за прикладний код і переживає перезавантаження разом із хостом.

Supervisord закриває інший шар — групу прикладних процесів усередині одного середовища й без прав суперкористувача.

Конфігурація плоска: INI-секції [program:ім’я] з кількістю екземплярів, шаблоном імені процесу, змінними середовища, політикою повторів, кодом виходу для штатної зупинки та пріоритетом, який задає порядок старту; [group:...] збирає десяток процесів в одну керовану одиницю.

Гнучкість налаштування запуску — ключова відмінність.

Штатний менеджер чекає, що застосунок не форкається й коректно поводиться із сокетом; Supervisord працює і з тими, хто демонізується, чекає сусіда за портом або падає на прогріві — задаєш затримку перед повтором, межу спроб, сигнал зупинки.

Керування групою йде через supervisorctl: перезапуск усіх процесів однією командою, статус за кожним екземпляром і єдиний журнал подій — окремий файл на процес або загальний потік через обробник подій.

Де штатний надійніший: автозапуск після перезавантаження, ізоляція та ліміти, реакція на падіння за cgroup, а не за застарілим pid-файлом.

Тому підходи не сперечаються, а поєднуються: Supervisord живе під штатною службою і всередині тримає групу застосунків — хост отримує передбачуваний старт, застосунок — гнучкі правила повторів і порядок запуску.

Технічні сумніви та типові помилки налаштування

Після перезавантаження сервер повертає не «той самий стан», а те, що описано в конфігурації: автозапуск вмикається флагом autostart, порядок задає priority — база даних піднімається раніше за застосунок, який до неї підключається.

Якщо процес Supervisord запускали вручну із сесії, після перезавантаження його не буде: потрібен unit у systemd або init-скрипт, інакше конфіги на місці, а процесів немає.

Нову програму додають на ходу: reread перечитує файли, update піднімає лише нові та змінені групи, решта процесів не перезапускаються. Конфіг при цьому тримають в окремому файлі підключеної директорії — тоді правка одного сервісу не зачіпає сусідні.

Чи можна підключити сервіс без простою інших?

Так, reread і update зачіпають лише змінені групи. При синтаксичній помилці у файлі демон відмовить цілком і залишить попередню версію працювати.

Як поводиться система при нестачі пам’яті?

Жертву обирає OOM-killer за значенням oom_score_adj. Демон піднімає процес, що впав, знову, і без обмеження startretries виходить цикл перезапусків, який добиває сусідів.

Що робити, якщо застосунок породжує дочірні процеси?

Одного сигналу головному процесу мало: потрібні stopasgroup і killasgroup, інакше воркери залишаються висіти й тримають порт або блокування в базі.

Які помилки трапляються найчастіше?

Завищений startsecs приховує падіння на старті, відсутність environment дає сервіс без потрібних змінних, логи без ротації забивають диск. Окремий пункт — запуск від root: демон це дозволяє, доки не знадобиться ізоляція прав.

Обговоримо ваше завдання: що надіслати для оцінки

Щоб повернутися зі схемою рішення та планом робіт, а не із загальними формулюваннями, потрібен зріз поточної конфігурації. Чим точніші вхідні дані, тим менше уточнювальних ітерацій: оцінка спирається на реальні процеси, а не на припущення про них.

Надішліть те, що є — цього достатньо для першої версії плану:

• перелік сервісів: імена програм, команди запуску, робочі каталоги, змінні середовища;
• порядок запуску та залежності: що піднімається першим, що чекає готовності бази, які процеси мають жити в єдиному екземплярі;
• поточні конфігурації, включно з розбивкою за окремими файлами та каталогами;
• як зараз вирішується перезапуск після падіння та після перезавантаження вузла: юніт systemd, скрипт або ручний старт;
• куди пишуться логи та скільки зберігаються: вивід Supervisord або власні файли застосунків;
• цільове середовище: один вузол чи кілька, контейнери чи машини, права сервісного користувача;
• що болить зараз: процеси, які не піднімаються, петлі перезапусків, втрачені завдання, зростання логів.

Із цього ми збираємо карту процесів, пропонуємо схему керування ними та віддаємо план робіт з етапами й порядком викату. Опишіть завдання — повернемося з оцінкою та планом.