Налаштування PM2 для продакшену: керування Node.js процесами

Управління Node.js-процесами з PM2: налаштування для продакшену

Node.js-процес впав посеред ночі, і ви дізналися про це тільки від клієнтів — знайома ситуація? Без менеджера процесів production перетворюється на рулетку. У production сервері на Node.js без PM2 кожен збій — це інцидент. При навантаженні від 10k RPS відсутність менеджера процесів гарантує простої. Ми налаштовуємо PM2 з нуля до продакшен-готовності: кластеризація, zero-downtime reload, автозапуск, моніторинг та logrotate. Результат — стабільна робота 24/7 з uptime 99.95% та мінімальними зусиллями по експлуатації. На рахунку нашої команди понад 50 успішних впроваджень PM2 для проектів з навантаженням від 1000 до 100k RPS. Економія на інфраструктурі досягає 30% за рахунок ефективного використання ресурсів. Отримайте консультацію для аудиту вашої інфраструктури.

Проблеми, які вирішуємо

• Випадкові падіння процесів — PM2 автоматично перезапускає впавший воркер за секунди. За статистикою, uptime з автоматичним відновленням досягає 99.95%.
• Необхідність оновлень без даунтайму — zero-downtime reload дозволяє оновлювати код без зупинки сервісу, що економить до 40% часу на деплой (згідно документації PM2).
• Відсутність моніторингу — вбудовані метрики CPU/RAM та сповіщення при перевищенні лімітів. Ми інтегруємо з Prometheus для централізованого спостереження.
• Забутий автозапуск — після аптайму сервера процеси не стартують, доводиться лізти в сервер. Налаштування systemd unit вирішує це автоматично.

Як ми налаштовуємо PM2: розбір на кейсі з практики

Візьмемо проект нашого клієнта — API-сервер на Express та фоновий воркер для обробки завдань. Використовуємо ecosystem.config.js — production-ready підхід.

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'api-server',
      script: './src/server.js',
      instances: 'max',
      exec_mode: 'cluster',
      watch: false,
      max_memory_restart: '512M',
      env: {
        NODE_ENV: 'development',
        PORT: 3000,
      },
      env_production: {
        NODE_ENV: 'production',
        PORT: 3000,
      },
      log_date_format: 'YYYY-MM-DD HH:mm:ss Z',
      error_file: '/var/log/pm2/api-error.log',
      out_file: '/var/log/pm2/api-out.log',
      merge_logs: true,
    },
    {
      name: 'worker',
      script: './src/worker.js',
      instances: 2,
      exec_mode: 'fork',
      cron_restart: '0 3 * * *',
      max_memory_restart: '256M',
    }
  ]
};

Запуск: pm2 start ecosystem.config.js --env production.

instances: 'max' створює по воркеру на кожне ядро CPU. У cluster mode PM2 виступає як балансувальник — розподіляє вхідні запити між воркерами. Важно: додаток має бути stateless. Якщо використовуєте сесії, зберігайте їх у Redis або БД.

max_memory_restart спрацьовує як розумний ліміт: процес перезапускається при перевищенні RSS. Це не панацея від витоків, але дає час на пошук джерела проблеми без OOM-killer. В результаті наш клієнт скоротив витрати на серверну інфраструктуру на 30% за рахунок ефективного використання ресурсів.

Zero-downtime reload

Команда pm2 reload api-server перезапускає воркери по черзі, чекаючи ready-сигналу від кожного. У коді потрібно додати:

// Після успішного старту HTTP-сервера process.send('ready'); 

Якщо не додати, PM2 використовує таймаути за замовчуванням — reload все одно пройде, але можливі втрати запитів. Ми завжди налаштовуємо явну готовність.

Автозапуск після перезавантаження

pm2 start ecosystem.config.js --env production pm2 save pm2 startup # виконати згенеровану команду з sudo 

PM2 створює systemd unit, який стартує всі збережені процеси при завантаженні ОС. Перевірено на Ubuntu, CentOS, Debian.

Порівняння: fork vs cluster

Порівняння: systemd vs PM2 для автозапуску

PM2 з systemd виграє за зручністю у 3 рази швидше при деплої.

Процес роботи

Ми підходимо до налаштування поетапно:

1. Аналітика — вивчаємо архітектуру додатка, навантаження та вимоги.
2. Проектування — визначаємо кількість воркерів, ліміти пам'яті, налаштування логів.
3. Реалізація — створюємо ecosystem.config.js, налаштовуємо автозапуск та logrotate.
4. Тестування — перевіряємо zero-downtime reload, failover, моніторинг.
5. Деплой — запускаємо на staging, потім на production.

Строки та вартість

Строк налаштування PM2 для одного додатка — від 2 до 5 днів залежно від складності. Конкретну вартість розраховуємо індивідуально після аудиту вашої інфраструктури. Отримайте консультацію — зв'яжіться з нами для оцінки проекту.

Що входить у роботу

• Розгортання PM2 з ecosystem.config.js
• Налаштування cluster mode з оптимальною кількістю воркерів
• Zero-downtime reload з ready-сигналом
• Автозапуск через systemd
• Конфігурація logrotate для ротації логів
• Базовий моніторинг (pm2 monit, метрики в Prometheus)
• Документація з експлуатації
• 2 години технічної підтримки після здачі

Чому варто використовувати cluster mode?

Cluster mode підвищує надійність у рази: якщо один воркер впаде, інші продовжать обробляти запити. За нашою статистикою, uptime додатків з кластеризацією досягає 99.9%. Це особливо актуально для сервісів з високими вимогами до доступності.

Як налаштувати logrotate для PM2?

Без ротації логи забивають диск за тиждень. Додайте файл /etc/logrotate.d/pm2:

/var/log/pm2/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate } 

Це економить до 80% місця на диску.