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.
TR7 behandelt die Prozessüberwachung nicht nur als Prüfung "ist der Prozess aktiv?", sondern zusammen mit Prozesstyp, Ressourcenprofil und Restart-Verhalten.
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.
Die RRD-Collector-Prozesse sammeln CPU-, Speicher-, Festplatten- und Netzwerkereignisse in Zeitserien-Logik. Diese Daten bilden die Grundlage für Überwachungsbildschirme, Alarmlogik und Betriebsanalyse.
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.
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.
Process Monitoring betreibt die internen TR7-Komponenten mit profilbasiertem Ressourcenmanagement, automatischem Restart und zentraler Prozessverfolgung.
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_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.
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.
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.
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.
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.
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.
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.
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.
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.
Process Monitoring wird zusammen mit Profilwerten, Prozesstyp-Mapping, UV-Thread-Pool-Grenzen, Fork-Verwaltung und Restart-Verhalten betrieben.
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.
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.
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.
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.
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.
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.
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.
Ü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.
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.
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.
Profilbasierte Ressourcengrenzen, automatischer Restart-Ablauf und zentrale Prozesssichtbarkeit. Lassen wir Sie in einem Live-Setup in Ihrer eigenen Umgebung herumführen.