На платформе, несущей трафик, если дочерний процесс невидим, маленькая ошибка процесса превращается в крупный простой.
Корпоративные платформы ADC и WAAP не состоят из единственного монолитного процесса. Воркеры, собирающие статистику трафика, сетевые операции, управление межсетевым экраном, CLI-сервисы, процессы routing console, сборщики логов и RRD работают вместе. Если один из этих процессов тихо останавливается или работает с неправильным профилем ресурсов, проблема начинается не на плоскости трафика, а раньше — на плоскости управления и видимости.
В классическом подходе мониторинг процессов отдаётся внешним агентам или универсальным инструментам process manager. Эти инструменты могут видеть, работает процесс или нет; но не знают роль процесса внутри TR7, с каким профилем ресурсов он должен работать или при какой ошибке делать reload, а при какой restart. В итоге мониторинг остаётся общим, а действие становится ручным.
В многопроцессных системах на основе Node.js настройки ресурсов также критичны. Давать каждому процессу одинаковый лимит heap и одинаковое значение thread pool неправильно. Если лёгкий CLI-процесс и интенсивный RRD collector запускаются с одним профилем, либо возникает трата ресурсов, либо интенсивный процесс подавляется недостаточными лимитами.
Поведение restart тоже должно проектироваться внимательно. Слишком частый restart скрывает корневую причину; слишком поздний restart приводит к тому, что неисправный процесс долго остаётся активным. В контейнерах ADC, несущих трафик, сначала должен пробоваться soft reload, при неудаче делаться fallback hard restart.
TR7 Мониторинг процессов держит внутренние процессы платформы под операционным контролем с помощью профилей производительности по типу процесса, управления дочерними процессами на основе ForkManager, сбора статистики на основе RRD и потока soft-to-hard restart.
Наш подход
TR7 рассматривает мониторинг процессов не только как проверку «жив ли процесс?», но вместе с типом процесса, профилем ресурсов и поведением restart.
Профили типа процесса настраивают лимиты ресурсов по задаче
Каждый тип процесса запускается с одним из профилей default, light, heavy, worker или ioIntensive в зависимости от собственной рабочей нагрузки. Настройки heap, semi-space и UV thread pool порождаются по этому профилю.
Collector на основе RRD регулярно обрабатывает системные метрики
Процессы RRD collector собирают события CPU, памяти, диска и сети в логике временных рядов. Эти данные обеспечивают основу для экранов мониторинга, логики тревог и операционного анализа.
ForkManager управляет дочерними процессами как независимыми node process
Внутренние процессы TR7 запускаются как child process и отслеживаются в реестре ForkManager. Если процесс падает, manager может управлять потоком перезапуска, а дерево процессов операционно разделяется.
При превышении порога ошибок применяются soft reload и fallback
Когда ошибки статистики ADC достигают определённого порога, сначала пробуется soft reload. Если soft reload не удаётся, с fallback hard restart контейнер контролируемо перезапускается.
Возможности
Мониторинг процессов эксплуатирует внутренние компоненты TR7 с помощью управления ресурсами на основе профилей, автоматического restart и централизованного отслеживания процессов.
Пять профилей производительности обеспечивают лимиты ресурсов под разные типы процессов
TR7 использует пять профилей производительности: default, light, heavy, worker и ioIntensive. Каждый профиль имеет разные настройки max-old-space-size, max-semi-space-size и UV thread pool. Лёгкие процессы работают с меньшим heap, а интенсивные collector-процессы запускаются с более широкими ресурсами. Эта модель снижает ошибку выдачи всем процессам единого лимита.
Значение UV thread pool автоматически масштабируется по числу CPU
Значение UV_THREADPOOL_SIZE вычисляется по числу CPU системы. Значение определяется по логике двойного числа ядер CPU, с минимумом 4 и максимумом 32. Это не даёт thread pool оставаться слишком маленьким в процессах с интенсивным I/O. Одновременно ограничивает возникновение избыточного потребления ресурсов при неконтролируемо высоких значениях.
max-old-space-size определяет верхний предел heap для каждого процесса
При запуске процессов Node.js значение max-old-space-size задаётся через профиль. Профиль default может работать с heap 1024 МБ, профили light и worker — 512 МБ, профиль heavy — 2048 МБ, профиль ioIntensive — 1024 МБ. Эта настройка ограничивает использование памяти процессами по их задаче. Крупные collector-процессы и небольшие процессы управления не принуждаются к одному профилю памяти.
max-semi-space-size настраивает поведение короткоживущих объектов по профилю
Значение semi-space — важный рабочий параметр, влияющий на поведение garbage collection. Могут использоваться значения вроде 8 МБ в профиле light, 16 МБ в профиле default, 32 МБ в профиле heavy. Это разделение обеспечивает более комфортную работу процессов интенсивной обработки данных и сохранение малого footprint у лёгких процессов. Настройки ресурсов становятся более предсказуемыми по типу процесса.
Типы процессов привязываются к профилям производительности фиксированным mapping
Процессы с интенсивными данными, такие как rrd-collector и rrd-websocket, могут привязываться к профилю heavy. pool-stats-worker может работать с профилем worker, network-fork — с профилем ioIntensive, frr-console и cli-server — с профилем light. Этот mapping обеспечивает операционный стандарт и снижает риск неправильного выбора профиля. При добавлении нового процесса явно определяется, к какому профилю он привязывается.
Аргументы runtime exec автоматически порождаются по информации профиля
Поток buildExecArgv при запуске процесса порождает необходимые рабочие аргументы Node.js из значений профиля. Параметры вроде max-old-space-size и max-semi-space-size не оставляются на ручную правку командной строки. Это повышает согласованность deployment. Разные среды порождают схожее поведение, используя одни и те же определения профилей.
Переменные окружения готовятся по потребности процесса
Поток buildEnvVars порождает окружающие настройки, такие как UV_THREADPOOL_SIZE, по профилю процесса. Особенно в процессах с интенсивным I/O правильное значение thread pool важно для производительности и стабильности. Этот подход снижает потребность системного администратора управлять отдельным файлом окружения для каждого процесса. Поведение ресурсов привязывается к централизованной модели профилей.
Реестр ForkManager делает дерево процессов управляемым
Семейства процессов, такие как network_fork, firewall_fork и stat_fork, отслеживаются под инфраструктурой ForkManager. Каждый дочерний процесс работает как независимый child process. При падении или неожиданном выходе manager может выполнить поток перезапуска и обновления состояния. Эта структура не даёт внутренним сервисам оставаться невидимыми внутри одного главного процесса.
Интеграция логгера делает события процессов видимыми в отдельном канале
События управления процессами могут отслеживаться через отдельный канал логов. События запуска, остановки, ошибки, restart и internal exception записываются так, чтобы операционная команда могла их изучить. Эти записи облегчают анализ корневой причины при повторяющихся проблемах процессов. Мониторинг не ограничивается мгновенным состоянием, можно изучить и историческое поведение.
Счётчики ошибок ADC могут запускать автоматический поток reload
Когда счётчики ошибок stat ADC достигают определённого порога, система может запустить поток автоматического восстановления. Первый шаг — soft reload; при неудаче применяется fallback hard restart. Это поведение помогает восстановлению временных runtime-сбоев без ожидания ручного вмешательства. Постоянно повторяющиеся ситуации требуют дополнительного операционного изучения.
Операционная глубина
Мониторинг процессов эксплуатируется вместе со значениями профилей, mapping типов процессов, лимитами UV thread pool, управлением fork и поведением restart.
Профиль default
Профиль default может использоваться для процессов общего назначения со значениями heap 1024 МБ и semi-space 16 МБ. Значение UV thread pool следует значению по умолчанию, вычисленному по числу CPU. Обеспечивает сбалансированную отправную точку для процессов без особых потребностей.
Профиль light
Профиль light работает с более низкими значениями ресурсов, такими как heap 512 МБ и semi-space 8 МБ. Подходит для лёгких процессов, таких как FRR console и CLI server. Этот профиль снижает избыточное потребление памяти.
Профиль heavy
Профиль heavy со значениями heap 2048 МБ и semi-space 32 МБ выделяется для интенсивных collector-процессов. Может использоваться в процессах, обрабатывающих больше данных, таких как rrd-collector и rrd-websocket. Верхний предел UV thread pool может доходить до 32.
Профиль worker
Профиль worker с heap 512 МБ используется для более узких, задачеориентированных процессов. Значение UV thread pool может настраиваться минимум на 8 и в зависимости от числа CPU, верхний предел держится более контролируемо. Может предпочитаться в процессах, таких как pool-stats-worker.
Профиль ioIntensive
Профиль ioIntensive с heap 1024 МБ используется для процессов с интенсивным I/O. UV thread pool увеличивается по числу ядер CPU и может доходить до верхнего предела 32. Подходит для сетевых и I/O-интенсивных задач, таких как network-fork.
Mapping типа процесса
Структура PROCESS_TYPE_PROFILES привязывает типы процессов к соответствующему профилю производительности. rrd-collector может сопоставляться с heavy, pool-stats-worker — с worker, network-fork — с ioIntensive, frr-console — с light и cli-server — с light. Этот mapping обеспечивает операционный стандарт.
В каких сценариях используется
Настройка лимита ресурсов worker после нового деплоя
Если после новой функции pool-stats-worker испытывает давление ресурсов, профиль процесса может быть переведён с worker на более подходящий профиль. Значения heap и UV thread pool обновляются через централизованную модель профилей. Операционной команде не приходится править аргументы runtime по одному.
Поток автоматического восстановления после CPU spike
Если ошибки статистики ADC превышают определённый порог, TR7 может попробовать автоматический soft reload. Если soft reload удаётся, процесс восстанавливается со сниженным влиянием на трафик. В случае неудачи применяется fallback hard restart.
Совместный просмотр состояния процесса и системы в ходе инцидента NetOps
Команда сетевых операций может оценить состояние нужного процесса в едином операционном потоке через состояние процессов, системные команды и вывод мониторинга. Состояние network fork, firewall fork или collector-процессов ускоряет изучение инцидента.
Изучение истории restart после cluster failover
После failover или обслуживания то, какие процессы и когда перезапустились, можно изучить по операционным записям. Эти записи используются для анализа простоев и процессов change management. Отдельные restart процессов можно соотнести с общим поведением системы.
Частые вопросы
К каким типам процессов применяются пять профилей производительности?
Как вычисляется значение UV thread pool?
В чём разница между soft reload и hard restart?
Какими процессами управляет ForkManager?
Как записываются события процессов?
Можно ли изменить профиль процесса позже?
Управляйте внутренними процессами интегрированно с платформой
Лимиты ресурсов на основе профилей, поток автоматического restart и централизованная видимость процессов. Проведём по живой установке в вашей собственной среде.