Wenn auf der den Verkehr tragenden Plattform der Subprozess unsichtbar ist, wird ein kleiner Prozessfehler zu einem großen Ausfall.
Enterprise-ADC- und WAAP-Plattformen bestehen nicht aus einem einzigen monolithischen Prozess. Worker, die Verkehrsstatistiken sammeln, Netzwerkoperationen, Firewall-Verwaltung, CLI-Dienste, Routing-Console-Prozesse, Log- und RRD-Collector arbeiten zusammen. Wenn einer dieser Prozesse still stoppt oder mit dem falschen Ressourcenprofil läuft, beginnt das Problem vor der Verkehrsebene auf der Verwaltungs- und Sichtbarkeitsebene.
Im klassischen Ansatz wird die Prozessüberwachung externen Agenten oder allgemeinen Process-Manager-Tools überlassen. Diese Tools können sehen, ob der Prozess läuft; aber sie kennen weder die Rolle des Prozesses innerhalb von TR7, noch mit welchem Ressourcenprofil er laufen sollte, noch ob bei welchem Fehlerfall ein Reload oder ein Restart durchgeführt werden soll. Im Ergebnis bleibt die Überwachung allgemein, die Aktion wird manuell.
In Node.js-basierten Systemen mit mehreren Prozessen sind auch die Ressourceneinstellungen kritisch. Jedem Prozess dasselbe Heap-Limit und denselben Thread-Pool-Wert zu geben ist nicht richtig. Werden ein leichter CLI-Prozess und ein intensiver RRD Collector mit demselben Profil ausgeführt, entsteht entweder Ressourcenverschwendung oder der intensive Prozess wird mit unzureichenden Limits gedrosselt.
Auch das Restart-Verhalten muss sorgfältig gestaltet werden. Ein zu häufiger Restart verbirgt die Grundursache; ein zu später Restart führt dazu, dass der fehlerhafte Prozess lange wirksam bleibt. Bei den verkehrstragenden ADC-Containern sollte zuerst ein Soft Reload versucht und bei Misserfolg ein Hard-Restart-Fallback durchgeführt werden.
TR7 Process Monitoring hält die internen Plattformprozesse mit prozesstypbasierten Performance-Profilen, ForkManager-basierter Subprozessverwaltung, RRD-basierter Statistiksammlung und Soft-to-Hard-Restart-Ablauf operativ unter Kontrolle.
Unser Ansatz
TR7 behandelt die Prozessüberwachung nicht nur als Prüfung "ist der Prozess aktiv?", sondern zusammen mit Prozesstyp, Ressourcenprofil und Restart-Verhalten.
Prozesstyp-Profile stellen die Ressourcengrenzen nach Aufgabe ein
Jeder Prozesstyp wird je nach seiner Arbeitslast mit einem der Profile default, light, heavy, worker oder ioIntensive ausgeführt. Heap-, Semi-Space- und UV-Thread-Pool-Einstellungen werden nach diesem Profil erzeugt.
Der RRD-basierte Collector verarbeitet Systemmetriken regelmäßig
Die RRD-Collector-Prozesse sammeln CPU-, Speicher-, Festplatten- und Netzwerkereignisse in Zeitserien-Logik. Diese Daten bilden die Grundlage für Überwachungsbildschirme, Alarmlogik und Betriebsanalyse.
ForkManager verwaltet Subprozesse als unabhängige Node-Prozesse
Die internen Prozesse von TR7 werden als Child Process gestartet und unter der ForkManager-Registry verfolgt. Stürzt ein Prozess ab, kann der Manager den Neustart-Ablauf verwalten und der Prozessbaum wird operativ ausgegliedert.
Wird der Fehlerschwellwert überschritten, werden Soft Reload und Fallback angewendet
Erreichen die ADC-Statistikfehler einen bestimmten Schwellwert, wird zuerst ein Soft Reload versucht. Schlägt der Soft Reload fehl, wird der Container mit einem Hard-Restart-Fallback kontrolliert neu gestartet.
Fähigkeiten
Process Monitoring betreibt die internen TR7-Komponenten mit profilbasiertem Ressourcenmanagement, automatischem Restart und zentraler Prozessverfolgung.
Fünf Performance-Profile bieten passende Ressourcengrenzen für verschiedene Prozesstypen
TR7 verwendet fünf Performance-Profile: default, light, heavy, worker und ioIntensive. Jedes Profil hat unterschiedliche max-old-space-size-, max-semi-space-size- und UV-Thread-Pool-Einstellungen. Während leichte Prozesse mit niedrigerem Heap laufen, werden intensive Collector-Prozesse mit größeren Ressourcen gestartet. Dieses Modell reduziert den Fehler, allen Prozessen ein einheitliches Limit zu geben.
Der UV-Thread-Pool-Wert wird automatisch nach der CPU-Zahl dimensioniert
Der UV_THREADPOOL_SIZE-Wert wird nach der System-CPU-Zahl berechnet. Der Wert wird mit der Logik des Doppelten der CPU-Kernzahl bestimmt, sodass er mindestens 4 und maximal 32 beträgt. Dies verhindert, dass der Thread Pool bei I/O-intensiven Prozessen zu klein bleibt. Zugleich begrenzt es unnötigen Ressourcenverbrauch durch unkontrolliert hohe Werte.
max-old-space-size bestimmt die Heap-Obergrenze für jeden Prozess
Beim Start von Node.js-Prozessen wird der max-old-space-size-Wert über das Profil vergeben. Das Default-Profil kann mit 1024 MB, light- und worker-Profile mit 512 MB, das heavy-Profil mit 2048 MB, das ioIntensive-Profil mit 1024 MB Heap-Wert laufen. Diese Einstellung begrenzt die Speichernutzung der Prozesse nach Aufgabe. Große Collector-Prozesse und kleine Verwaltungsprozesse werden nicht in dasselbe Speicherprofil gezwungen.
max-semi-space-size stellt das Verhalten kurzlebiger Objekte nach Profil ein
Der Semi-Space-Wert ist ein wichtiger Arbeitsparameter, der das Garbage-Collection-Verhalten beeinflusst. Werte wie 8 MB im light-Profil, 16 MB im default-Profil, 32 MB im heavy-Profil können verwendet werden. Diese Unterscheidung ermöglicht datenintensiven Prozessen ein bequemeres Arbeiten und lässt leichte Prozesse mit kleinem Footprint. Die Ressourceneinstellungen werden je nach Prozesstyp vorhersehbarer.
Prozesstypen werden mit fester Mapping an Performance-Profile gebunden
Datenintensive Prozesse wie rrd-collector und rrd-websocket können an das heavy-Profil gebunden werden. pool-stats-worker kann mit dem worker-Profil, network-fork mit dem ioIntensive-Profil, frr-console und cli-server mit dem light-Profil ausgeführt werden. Dieses Mapping schafft einen Betriebsstandard und reduziert das Risiko einer falschen Profilauswahl. Bei Hinzufügen eines neuen Prozesses wird klar definiert, an welches Profil er gebunden wird.
Runtime-Exec-Argumente werden automatisch nach den Profilinformationen erzeugt
Der buildExecArgv-Ablauf erzeugt die beim Prozessstart benötigten Node.js-Arbeitsargumente aus den Profilwerten. Parameter wie max-old-space-size und max-semi-space-size werden nicht der manuellen Kommandozeilenbearbeitung überlassen. Dies erhöht die Deployment-Konsistenz. Verschiedene Umgebungen erzeugen mit denselben Profildefinitionen ein ähnliches Verhalten.
Umgebungsvariablen werden nach Prozessbedarf vorbereitet
Der buildEnvVars-Ablauf erzeugt Umgebungseinstellungen wie UV_THREADPOOL_SIZE nach dem Prozessprofil. Besonders bei I/O-intensiven Prozessen ist der richtige Thread-Pool-Wert für Performance und Stabilität wichtig. Dieser Ansatz reduziert den Bedarf des Systemadministrators, für jeden Prozess eine separate Umgebungsdatei zu verwalten. Das Ressourcenverhalten wird an das zentrale Profilmodell gebunden.
Die ForkManager-Registry macht den Prozessbaum verwaltbar
Prozessfamilien wie network_fork, firewall_fork und stat_fork werden unter der ForkManager-Infrastruktur verfolgt. Jeder Subprozess läuft als unabhängiger Child Process. Bei Absturz oder unerwartetem Beenden kann der Manager den Neustart- und Statusaktualisierungsablauf durchführen. Diese Struktur verhindert, dass die internen Dienste innerhalb eines einzigen Hauptprozesses unsichtbar bleiben.
Die Logger-Integration macht Prozessereignisse in einem separaten Kanal sichtbar
Prozessverwaltungsereignisse können über einen separaten Log-Kanal überwacht werden. Start-, Stopp-, Fehler-, Restart- und Internal-Exception-Ereignisse werden so aufgezeichnet, dass das Betriebsteam sie untersuchen kann. Diese Aufzeichnungen erleichtern die Grundursachenanalyse bei wiederkehrenden Prozessproblemen. Die Überwachung bleibt nicht nur auf den momentanen Status beschränkt, auch das vergangene Verhalten kann untersucht werden.
ADC-Fehlerzähler können den automatischen Reload-Ablauf auslösen
Erreichen die ADC-Stat-Fehlerzähler einen bestimmten Schwellwert, kann das System einen automatischen Selbstheilungsablauf starten. Der erste Schritt ist ein Soft Reload; bei Misserfolg wird ein Hard-Restart-Fallback angewendet. Dieses Verhalten hilft, dass sich temporäre Runtime-Störungen ohne manuelles Eingreifen erholen. Kontinuierlich wiederkehrende Situationen erfordern jedoch zusätzlich eine operative Untersuchung.
Operative Tiefe
Process Monitoring wird zusammen mit Profilwerten, Prozesstyp-Mapping, UV-Thread-Pool-Grenzen, Fork-Verwaltung und Restart-Verhalten betrieben.
Default-Profil
Das Default-Profil kann für allgemeine Prozesse mit 1024 MB Heap und 16 MB Semi-Space-Wert verwendet werden. Der UV-Thread-Pool-Wert folgt dem nach der CPU-Zahl berechneten Standardwert. Es bietet einen ausgewogenen Ausgangspunkt für Prozesse, für die kein spezieller Bedarf definiert ist.
Light-Profil
Das Light-Profil läuft mit niedrigeren Ressourcenwerten wie 512 MB Heap und 8 MB Semi-Space. Es ist für leichte Prozesse wie FRR Console und CLI Server geeignet. Dieses Profil reduziert unnötigen Speicherverbrauch.
Heavy-Profil
Das Heavy-Profil ist mit 2048 MB Heap und 32 MB Semi-Space-Wert für intensive Collector-Prozesse reserviert. Es kann bei Prozessen wie rrd-collector und rrd-websocket verwendet werden, die mehr Daten verarbeiten. Die UV-Thread-Pool-Obergrenze kann bis 32 steigen.
Worker-Profil
Das Worker-Profil wird mit 512 MB Heap für engere, arbeitsfokussierte Prozesse verwendet. Der UV-Thread-Pool-Wert kann mit mindestens 8 und abhängig von der CPU-Zahl eingestellt werden, die Obergrenze wird kontrollierter gehalten. Es kann bei Prozessen wie pool-stats-worker bevorzugt werden.
ioIntensive-Profil
Das ioIntensive-Profil wird mit 1024 MB Heap für I/O-lastige Prozesse verwendet. Der UV Thread Pool wird nach der CPU-Kernzahl vergrößert und kann bis zur Obergrenze von 32 steigen. Es ist für netzwerk- und I/O-lastige Arbeiten wie network-fork geeignet.
Prozesstyp-Mapping
Die PROCESS_TYPE_PROFILES-Struktur bindet Prozesstypen an das entsprechende Performance-Profil. rrd-collector kann als heavy, pool-stats-worker als worker, network-fork als ioIntensive, frr-console und cli-server als light gemappt werden. Dieses Mapping schafft einen Betriebsstandard.
In welchen Szenarien wird es verwendet
Anpassung der Worker-Ressourcengrenze nach einem neuen Deploy
Erfährt der pool-stats-worker nach einer neuen Funktion Ressourcendruck, kann das Prozessprofil von worker auf ein geeigneteres Profil verschoben werden. Heap- und UV-Thread-Pool-Werte werden mit dem zentralen Profilmodell aktualisiert. Das Betriebsteam muss nicht einzeln Runtime-Argumente bearbeiten.
Automatischer Erholungsablauf nach einem CPU-Spike
Überschreiten die ADC-Statistikfehler einen bestimmten Schwellwert, kann TR7 automatisch einen Soft Reload versuchen. Gelingt der Soft Reload, erholt sich der Prozess mit reduziertem Verkehrseinfluss. Im Falle eines Misserfolgs wird ein Hard-Restart-Fallback angewendet.
Während eines NetOps-Incidents Prozess- und Systemstatus gemeinsam sehen
Das Netzwerkbetriebsteam kann die Gesundheit des betreffenden Prozesses mit Prozessstatus, Systembefehlen und Überwachungsausgaben in einem einzigen Betriebsablauf bewerten. Der Status von Network Fork, Firewall Fork oder Collector-Prozessen beschleunigt die Incident-Untersuchung.
Untersuchung des Restart-Verlaufs nach einem Cluster-Failover
Nach einem Failover oder einer Wartung kann aus den Betriebsaufzeichnungen untersucht werden, welche Prozesse wann neu gestartet wurden. Diese Aufzeichnungen werden für Ausfallanalyse und Change-Management-Prozesse verwendet. Einzelne Prozess-Restarts können mit dem allgemeinen Systemverhalten verknüpft werden.
Häufig gestellte Fragen
Auf welche Prozesstypen werden die fünf Performance-Profile angewendet?
Wie wird der UV-Thread-Pool-Wert berechnet?
Was ist der Unterschied zwischen Soft Reload und Hard Restart?
Welche Prozesse verwaltet der ForkManager?
Wie werden Prozessereignisse aufgezeichnet?
Kann das Prozessprofil nachträglich geändert werden?
Verwalten Sie Ihre internen Prozesse plattformintegriert
Profilbasierte Ressourcengrenzen, automatischer Restart-Ablauf und zentrale Prozesssichtbarkeit. Lassen wir Sie in einem Live-Setup in Ihrer eigenen Umgebung herumführen.