Примечание: статья 2016 года, размещенная на Nuggets, не знаю, устарела ли она.

Для управления фоновыми процессами обычно используется инструмент crontab, который можно использовать в двух сценариях: запланированные задачи и резидентные сценарии. Что касается резидентных скриптов, сегодня я представлю лучший инструмент: pm2, диспетчер процессов, разработанный на основе nodejs, подходящий для фонового управления резидентными скриптами и имеющий встроенную функцию балансировки нагрузки для сетевых приложений узла. Официально pm2 — это менеджер процессов для Node-приложений с функцией балансировки нагрузки, но лично это не совсем так, потому что pm2 поддерживает несколько языков, но не имеет возможности балансировки нагрузки для других процессов, кроме node.

Особенности PM2

Давайте сначала поговорим о достоинствах и преимуществах pm2.

Поддержка конфигурации поведения процесса, то есть вы можете обновлять и изменять некоторые основные свойства приложений управления pm2 через конфигурацию, такие как имя приложения, режим запуска и т. д.;
Он поддерживает кластерный режим и балансировку нагрузки, но применим только к процессу nodejs, поскольку реализуется кластерным модулем nodejs;
Поддержка исходной карты, этот элемент предназначен для js, файл исходной карты представляет собой информационный файл исходного файла js, в котором хранится информация о местоположении исходного файла;
Поддержка горячего перезапуска;
Поддержка рабочего процесса развертывания, pm2 может автоматически развертываться на разных серверах в соответствии с тестовой средой и онлайн-средой и одновременно работать в разных конфигурациях;
Поддержка перезапуска мониторинга, автоматический перезапуск процесса может быть реализован в случае обновления файла и т. д.;
Поддержка процесса запуска Linux, запуск относится к загрузке системы, и процесс запускается автоматически, например, chkconfig Centos;
Управление журналами, два вида журналов, системный журнал pm2 и журнал управляемого процесса, будут по умолчанию записывать консольный вывод процесса в журнал;
Функция автозавершения команд, я лично считаю, что эта функция не имеет большого значения, и я попробовал ее, и нет родного ответа автодополнения команд Linux-быстро;
Функция мониторинга, pm2 monit отслеживает использование процессора и памяти, более подробный мониторинг ключевых показателей;
Поддержка режима разработки и отладки, работа без фона, запуск pm2-dev;
Поддержка разработки модуля pm2 и реализация расширения функций pm2;
мониторинг ключевых показателей, более подробный и удобный, чем мониторинг pm2 monit, отображаемый на веб-страницах;
Перезапустите с максимальной памятью, установите максимальный предел памяти и автоматически перезапустите при превышении предела;
Programming API, предоставляющий разработчикам API для гибкого управления процессом посредством программирования;

Выше кратко описаны функции инструмента управления процессами pm2.

общие команды pm2

Общие команды обычно относительно просты. Ниже перечислены некоторые часто используемые команды управления для pm2.

pm2 start [параметры] Запустить указанное приложение, например pm2 start index.js --name httpServer;

pm2 stop [опции] Остановить указанное приложение, например pm2 stop httpServer;

pm2 reload|restart [параметры] Перезапустить указанное приложение, например, pm2 restart httpServer;

pm2 show [параметры] Показать сведения об указанном приложении, например, pm2 show httpServer;

pm2 delete [параметры] Удалить указанное приложение, например, pm2 удалить httpServer.Если вы изменяете поведение конфигурации приложения, лучше сначала удалить приложение, а затем перезапустить его, чтобы оно вступило в силу, например, изменить файл записи сценария;

pm2 kill убивает все процессы, управляемые pm2;

журналы pm2 Просмотр журналов указанного приложения, а именно стандартного вывода и стандартных ошибок;

pm2 monit отслеживает использование процессора и памяти каждым процессом приложения;

общая конфигурация pm2

Есть два способа настроить pm2: через командную строку и через файл конфигурации.

Командная строка

pm2 start index.js --name HttpServer --interpreter node

Здесь настройте имя приложения как httpServer с помощью параметров команды, а интерпретатор файла сценария index.js — как узел Дополнительные параметры см. в разделе pm2 --help;

конфигурационный файл

Метод файла конфигурации pm2 поддерживает форматы yml и json.

файл процессов.yml

processes.json

Давайте рассмотрим элементы конфигурации, поддерживаемые PM2, а именно:

имя процесса приложения имени;
путь к скрипту запуска скрипта;
Путь для запуска приложения cwd.Пример отличия скрипта от cwd: запустить /data/release/node/index.js в каталоге /home/polo/, где скрипт /data/release/node/index .js, cwd — это /home/polo/;
аргументы args, переданные сценарию;
Интерпретатор сценария, указанный интерпретатором;
интерпретатор_args Аргументы, передаваемые интерпретатору;
instances Количество запускаемых экземпляров приложения, допустимо только в кластерном режиме, по умолчанию - fork;
режим запуска приложения exec_mode, поддерживает режим форка и кластера;
наблюдать за перезагрузкой мониторов.Если включено, приложения, которые изменяются в папке или подпапке, будут автоматически перезапускаться;
ignore_watch игнорирует отслеживаемую папку, поддерживает регулярные выражения;
max_memory_restart Максимальное количество лимитов памяти, превышающее автоматический перезапуск;
переменная окружения env, тип объекта, например {"NODE_ENV":"production", "ID": "42"};
log_date_format указывает формат даты журнала, например ГГГГ-ММ-ДД ЧЧ:мм:сс;
error_file записывает стандартный поток ошибок, $HOME/.pm2/logs/XXXerr.log), в этом файле можно найти ошибки кода;
out_file записывает стандартный поток вывода, $HOME/.pm2/logs/XXXout.log), если приложение печатает большой объем стандартного вывода, журнал pm2 будет слишком большим;
приложение min_uptime, работающее меньше времени, считается аварийным запуском;
max_restarts Максимальное количество аварийных перезапусков, то есть количество перезапусков меньше, чем время работы min_uptime;
autorestart по умолчанию имеет значение true и перезапускается автоматически в случае исключения;
cron_restart формат времени crontab для перезапуска приложения, в настоящее время поддерживает только режим кластера;
force по умолчанию имеет значение false, если это правда, сценарий можно запускать повторно. pm2 не рекомендует этого делать;
restart_delay Время задержки перезапуска в случае аварийного перезапуска;

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

форк и режим запуска кластера

Процесс запуска pm2 поддерживает два режима: вилка и кластер.Для тех, кто знаком с узлом, API многопроцессорного программирования узла: child_process.fork и кластер. Что касается существенной разницы между форком и кластером pm2, я лично думаю, что это разница между child_process.fork и API кластера узла.У Stackoverflow есть вопрос по этому поводу.обсуждать. Вот краткий обзор:

Кластер является производным от форка, и кластер поддерживает все функции, которые есть у кластера;

Форк не поддерживает мультиплексирование портов и адресов сокетов, кластер поддерживает мультиплексирование портов и адресов. Поскольку только модуль кластера узла поддерживает параметр сокета SO_REUSEADDR;

Форк не может запускать несколько процессов экземпляров, кластер может запускать несколько экземпляров. Но узел child_process.fork может запускать несколько процессов, но почему это не реализовано? Насколько я понимаю, node в основном предоставляет сетевые сервисы.Запуск нескольких экземпляров требует мультиплексирования адресов и портов.В этом случае можно использовать режим кластера.Однако режим fork не поддерживает мультиплексирование адресов и портов, а также мультиэкземплярный запуск процесса будет генерировать ненормальные ошибки. Однако для сценария резидентной задачи нет необходимости предоставлять сетевые сервисы, в это время может быть реализован многопроцессный запуск, а также повышается эффективность обработки задачи. Для выполнения вышеуказанных требований существует два способа: один — настроить app0, app1, app2 для запуска нескольких процессов, а другой — вызвать многопроцессорное программирование child_process.fork через сам экземпляр приложения;

режим fork можно применять к другим языкам, таким как php, python, perl, ruby, bash, coffee, тогда как кластер можно применять только к узлу;

Форк не поддерживает перезапуск по расписанию, но кластер поддерживает перезапуск по расписанию. Запланированный перезапуск также является элементом конфигурации cron_restart в конфигурации. На github обсуждается, нужно ли реализовывать cron-подобную синхронизацию в режиме fork:

GitHub.com/unite-super/screen2…

В документе на официальном сайте говорится, что функция временного перезапуска режима форка будет реализована в ближайшее время, и я с нетерпением жду этого...

мониторинг pm2

Есть два способа мониторинга pm2, а именно cli и keymetrics.

кли-метод

pm2 monit — это команда, специально используемая для мониторинга, элементы мониторинга включают процессор и память. Недостатки Мониторинг отображаемого содержимого слишком грубый и недостаточно детализированный.

В списке pm2 отображаются все текущие проекты управления pm2, и вы можете просмотреть текущее состояние каждого процесса. Если вам нужен более подробный контент для мониторинга, это обычно достижимо для cli.

Недостатки этого метода мониторинга:

Недостаточно интуитивно понятно, нужно выполнять команду и анализировать результаты самостоятельно;
Неудобно для мониторинга приложений и управления несколькими серверами;

Из-за этих недостатков необходим лучший способ мониторинга наших приложений.

keymetrics

мониторинг ключевых показателей — это инструмент мониторинга, разработанный и поддерживаемый разработчиками PM2. Вы можете попробовать его. Установка и настройка очень просты. Я просто попробовал его поверхностно. Вы можете обратиться к

Супер нет JS.org/topic/56554…

Я не особо занимаюсь мониторингом, предметом мониторинга здесь является процесс приложения, а не сервер, я расскажу только о нескольких функциях, которые мне нравятся:

Способствует многосерверному мониторингу и управлению;
Если код ненормальный, то можно увидеть стабильность программы в длительной эксплуатации;
Поддержка основных функций запуска, перезапуска и остановки приложений;

Тем не менее, keymetrics является коммерческой версией программного обеспечения для мониторинга, бесплатная версия имеет ограниченные функции и имеет только бесплатную квоту из двух серверов.Сервер этого программного обеспечения не создается сам по себе и использует данные мониторинга приложений, которые необходимо регулярно загружать. на третью платформу.Это дорого для компаний с большим количеством серверов, а информация о состоянии, такая как серверы и процессы службы приложений, является конфиденциальными данными, и доступ к сторонним платформам неприемлем. Конечно, если количество серверов ограничено, можно платить высокую плату за использование и нет конфиденциальных данных, рекомендуется использовать Keymetrics, ведь он разработан и поддерживается разработчиками PM2 и имеет богатые возможности.

Ввиду вышеуказанных проблем, домашние скотоводы разработали аналогичный бесплатный инструмент, который я не изучал, и название очень интересное: pm2.5.адрес ссылки.

Что касается мониторинга, у меня нет большого опыта, поэтому я не буду много говорить.

журнал проблемы

Система регистрации обычно является важной вспомогательной функцией для любого приложения. Связанные с pm2 файлы по умолчанию хранятся в каталоге $HOME/.pm2/ Существует два основных типа журналов:

Журнал самого pm2 хранится в $HOME/.pm2/pm2.log;
Журналы приложений, управляемых pm2, хранятся в каталоге $HOME/.pm2/logs/, стандартный журнал хранится в ${APP_NAME}_out.log, а стандартный журнал ошибок хранится в ${APP_NAME}_error.log. ;

Причина, по которой здесь объясняется журнал, заключается в том, что если разработка программы не является строгой, для отладки программы приложение будет генерировать большой объем стандартного вывода, так что сам сервер записывает большое количество журналов, что приводит к проблема полного обслуживания диска. Вообще говоря, приложения, управляемые pm2, имеют свои собственные системы журналов, поэтому для этого ненужного выходного содержимого журнал следует отключить и перенаправить в /dev/null.

По сравнению с crontab ситуация похожая, собственные журналы crontab и вывод приложений, которыми он управляет. Вывод сценария приложения должен быть перенаправлен на /dev/null, так как выводимый контент будет отправлен пользователю в виде электронного письма, а контент будет сохранен в файле электронной почты, что приведет к неожиданным результатам или вызовет скрипт вообще не должен выполняться;

Сводка по использованию инструмента управления процессами PM2