Комментарии 12
У pm2 есть одна ублюдочная особенность — он преобразует логи при помощи .toString() даже если в настройках стоит тип "json", что делает невозможным нормальный анализ логов теми же ELK или хотя бы Cloudwatch insights
Наверно вам уже не актуально, но возможно кто-то столкнется с такой же проблемой:
нашел решение:
1) pm2 ecosystem
2) в файлеecosystem.config.js
module.exports = {
// ...
apps: [
{
// ...
error_file: 'path/to/error.log',
out_file: 'path/to/out.log',
log_date_format: 'YYYY-MM-DD HH:mm:ss',
log_type: 'json', // Указываем формат JSON
// ...
},
],
// ...
};3) перезапусте апку
pm2 restart ecosystem.config.js
логи будут в json формате
у меня с pm2 вечная проблема с потерей всего состояния при обновлении ноды. unstartup/startup недостаточно, нода установлена через nvm и у неё меняются пути при установке новой версии. это надёжно убивает все записи сохранённые в дампе (pm2 save), потому что там абсолютные пути. получается так что я обновляю ноду, переустанавливаю pm2 (npm i -g pm2) так как путь к глобальному node_modules тоже изменился, делаю pm2 update – и после перезапуска у меня девственно чистый список процессов (pm2 ls)… :(
приходится заниматься жостким колхозингом – руками править startup-скрипты, руками править pm2.dump и то – как повезёт всё равно…
с логами тоже не всё идеально, pm2 logs неудобен, monit даёт кучу информации, но как раз по логам отмотать на произвольное время в прошлом не получается… в итоге приходится руками лезть в ~/.pm2/logs и там искать нужное…
по итогу несмотря на то что вроде инструмент хороший, в проде оказывается проще поднять докер, задеплоить с docker-compose up -d с параметром --scale, чтобы поднять нужное количество копий и позволить докеру самому разруливать между ними подключения… обновление версии ноды выполняется вместе с обновлением самого сервиса, а там и до интеграции с ci/cd недалеко, для автоматического прогона тестов перед деплоем, например…
на долю pm2 остаётся случай когда надо по-быстренькому что-то сунуть на сервер, всякие времянки, стейджинг – такого рода вещи…
Я решил эту проблему модулем Cluster. Там и общение между процессами можно организовать. А перезаупскать падающий процесс есть supervisor/ мониторинг это пкфафтф. Всеже pm это как то не unix-way. шаг в сторону и дикие костыли.
почему производительность меньше? там же под капотом обычный нодовский cluster, он принимает соединения и сокеты прокидывает в воркеры, которые их обслуживают. откуда там задержки или низкая производительность вдруг?
А потому, видимо, меньше, что создаётся лишний слой, который прокидывает запросы в воркеры. К тому же, он работает на одном потоке. Вот, если бы было несколько независимых процессов, связанных напрямую с nginx, то было бы быстрее, чем через прослойку, которая нужна только для того, чтобы использовать один порт на всех.
PM2: подходим к вопросу процесс-менеджмента с умом