Die Backend-Gesundheit wird in der klassischen Load-Balancing-Welt stets von der Protokollschicht aus überwacht. Der ADC sendet eine HTTP-Anfrage an den Server, erhält 200 OK, fügt den Server dem Pool hinzu. Oder er führt eine TCP-Probe durch und gilt als gesund, wenn der Port offen ist. Vielleicht führt er sogar eine Inhaltsverifizierung durch: 'Enthält die Antwort dieses Wort?'
Dieser Ansatz schaut von der äußeren Hülle; er schaut nicht von innen. Er sieht nicht, dass die Festplattenauslastung des Servers 98 % erreicht hat, dass der RAM in den Swap gefallen und die Performance eingebrochen ist, dass der GC-Zyklus sich verlängert hat, dass das Verbindungslimit der Datenbank voll ist. Der Server gibt immer noch HTTP 200 zurück — aber der Benutzer erlebt für seine Anfrage eine sekundenlange Wartezeit.
Schlimmer noch: Die Protokoll-Probe gilt als lokal, sie berichtet nicht den eigenen Zustand des Servers. Der ADC sieht nur, was die Probe sieht. Der gereifte Ressourcendruck auf dem Server oder die Neustart-Schleife eines kritischen Prozesses wirken nicht auf die Routing-Entscheidung.
ETM Server Telemetry schließt diese Lücke. Der Agent auf dem Server übermittelt seinen eigenen internen Zustand kontinuierlich an den ADC. Die Routing-Entscheidung wird nicht aus der externen Protokoll-Probe, sondern aus den von innen kommenden Live-Daten getroffen.
TR7 ETM modelliert die Servergesundheit als Live-Eingabe der ADC-Routing-Schicht. Dieser Ansatz vereint Client-Sicherheit und Server-Observability auf derselben Plattform.
Der Agent auf dem Server misst CPU-Last, Speichernutzung, Swap-Druck, Disk-IO-Sättigung und Netzwerkschnittstellen-Durchsatz in Echtzeit. Die Daten werden in periodischen Intervallen — im Sekundenbereich — an den ADC übermittelt; die Routing-Entscheidung speist sich aus diesen aktuellen Daten.
Die Gesundheit kritischer Anwendungsprozesse, Neustart-Schleifen, Garbage-Collection-Dauer, Anzahl der offenen Datei-Handles, Thread-Pool-Status und anwendungsspezifische Metriken (z. B. Datenbank-Verbindungslimit) werden überwacht. Ist die Anwendung nicht gesund, geht kein Verkehr an diesen Server.
Der ADC-Load-Balancing-Algorithmus kann nach dem aus der ETM-Telemetrie kommenden Gesundheits-Score arbeiten. Ein Server mit hoher CPU erhält weniger Verkehr, ein Server mit IO-Sättigung wird aus neuen Verbindungen herausgenommen, ein in den Swap gefallener Server wird automatisch aus dem Pool entfernt.
Derselbe ETM-Agent, der für die Client-Sicherheit verwendet wird, läuft auch auf Servern. Das Betriebsteam verwendet einen einzigen Agenten, eine einzige Verwaltungsschicht und ein einziges Telemetriemodell. Für die Backend-Observability muss kein separates Tool ausgerollt werden.
Server Telemetry ist nicht nur Observability; sie ist die Live-Datenquelle der ADC-Routing-Entscheidung.
Einzelne CPU-Zahl, kontinuierlicher Load Average, momentaner Auslastungsprozentsatz und thermischer Status werden in Echtzeit gemessen. Eine Anomalie der Last pro Kern oder ein Performance-Abfall wegen thermischem Throttle spiegelt sich in der Routing-Entscheidung wider.
Gesamter und verfügbarer Speicher, Swap-Nutzung, Page-Fault-Rate und OOM-Killer-Aktivität werden überwacht. Ein in den Swap gefallener Server kann automatisch in einen Pool mit niedriger Priorität verschoben werden; ein Server mit deutlich werdendem OOM-Risiko kann aus dem Verkehr genommen werden.
Festplattenauslastung, IO-Wartezeit, IOPS-Zahl, Anzahl der Anfragen in der Warteschlange und SMART-Fehlerzahlen werden überwacht. Wird der Festplattenauslastungsschwellwert überschritten oder ist die IO-Sättigung hoch, wird der Server aus dem Verkehr zurückgezogen.
Ob definierte kritische Prozesse laufen, die letzte Neustart-Zeit und die Anzahl der Restart-Schleifen werden überwacht. Eine kontinuierlich neu gestartete Anwendung wird aus dem Verkehr gezogen; der Pool wird für ein Operator-Eingreifen markiert.
Anwendungsspezifische Metriken auf dem Server — Anwendungs-Runtime-Metriken (GC-Dauer, Event-Loop-Verzögerung), Sättigung des Datenbank-Verbindungslimits, Queue Depth — können über den Agenten abgerufen werden. Der ADC kann diese Metriken in die Routing-Entscheidung einbeziehen.
Durchsatz der Netzwerkschnittstellen des Servers, Paketverlustrate, Retransmit-Zahl und Anzahl aktiver TCP-Verbindungen werden überwacht. Ein Server mit Netzwerksättigung wird automatisch mit niedrigem Gewicht markiert.
Die Gültigkeitsdauer der TLS-Zertifikate auf dem Server, die Hash-Integrität kritischer Konfigurationsdateien und Änderungen in den Zertifikatspeichern werden überwacht. Ein Zertifikat mit nahendem Ablauf gibt sowohl eine Operator-Warnung aus als auch kann es in die Routing-Richtlinie einbezogen werden.
Eine Abweichung von der Server-Konfigurationsbaseline wird sofort erfasst. Eine unautorisierte Konfigurationsänderung, ein unerwartetes Benutzerkonto oder der Start eines neuen Dienstes erreicht ETM als Ereignis. Dieses Signal spiegelt sich sowohl in Sicherheits- als auch in Betriebsentscheidungen wider.
Die ETM-Telemetrie kann pro Server in einen Gesundheits-Score von 0–100 umgewandelt werden. Der ADC-Load-Balancing-Algorithmus (Round-Robin, Least-Conn, Weighted Least-Conn) kann diesen Score als Gewicht verwenden. Ein Server mit fallendem Score erhält weniger Verkehr; ein Server, der unter den Schwellwert fällt, verlässt den Pool.
Signale wie die Zunahmegeschwindigkeit der Festplattenauslastung, der Speicherverbrauchstrend und die Restart-Häufigkeit können prädiktiv interpretiert werden. Von einem Server, der noch nicht ausgefallen ist, dessen Ausfallwahrscheinlichkeit in kurzer Zeit aber steigt, wird der Verkehr sanft zurückgezogen.
Server Telemetry ist die Live-Datenquelle der ADC-Routing-Intelligenz — einschließlich Integration, Skalierbarkeit und Audit.
Die Telemetrie fließt periodisch zur ADC-Control-Plane. Der Load-Balancing-Algorithmus kann nach dem ETM-Score arbeiten; spezielle Routing-Entscheidungen können durch ETM-Ereignisse ausgelöst werden. Der Operator kann ETM-Metriken an die Policy-Sprache binden, ohne ein eigenes Skript zu schreiben.
Die protokollbasierte aktive Health-Probe (HTTP, TCP, Oracle) läuft weiter; die ETM-Telemetrie fügt neben dieser Probe eine 'innere Sicht'-Schicht hinzu. Die Routing-Entscheidung bewertet beide Quellen gemeinsam: 'antwortet er?' (Protokoll-Probe) + 'ist er gesund?' (ETM).
Welche Metriken in welcher Periode erfasst werden, ist je nach Serverrolle konfigurierbar. Für einen Webserver können CPU/RAM/IO, für einen Datenbankserver Verbindungslimit und Query-Latenz, für einen Anwendungsserver GC und Thread-Pool prioritär sein.
Der Agent auf dem Server ist auf minimale Ressourcennutzung ausgelegt. Er läuft auch auf Backends mit hohem Durchsatz, ohne Performance-Verluste zu verursachen. Die Intensität der Metric-Erfassung ist konfigurierbar.
Die Telemetrie kann an Unternehmens-Überwachungs- und -Observability-Plattformen übertragen werden. Wenn statt der eigenen Verwaltungsoberfläche von ETM der Observability-Stack des Unternehmensstandards verwendet werden soll, wird ein Datenstrom bereitgestellt.
Aus einem einzigen TR7-Cluster kann die Telemetrie Tausender Server erfasst werden. In Multi-Region-Strukturen werden die Server-Inventare verschiedener Regionen mit Central Management über eine einzige Konsole angezeigt.
Wenn sich die Sättigung des Datenbank-Verbindungslimits des Anwendungsservers nähert, übermittelt ETM dies dem ADC. Der ADC senkt das Gewicht dieses Servers schrittweise; neue Verbindungen werden auf andere Server geleitet. Der Benutzer sieht kein Timeout; das Backend atmet schrittweise auf.
Überschreitet die Festplattenauslastung eines Servers wegen Backup- oder Log-Ansammlung 95 %, erzeugt ETM ein Ereignis. Der Server wird automatisch aus dem Pool genommen; der Operator wird für ein Eingreifen markiert. Es wird verhindert, dass die Festplatte vollständig voll wird und der Dienst abstürzt.
Ein Server mit kontinuierlich steigender Speichernutzung und hohem OOM-Risiko kann von ETM, noch bevor er abstürzt, mit niedrigem Gewicht versehen werden. Der Verkehr wird sanft auf andere Server verlagert; das Problem wird gelöst, bevor es zu einem Incident wird.
Eine Restgültigkeit des TLS-Zertifikats auf dem Server von weniger als 30 Tagen wird ETM gemeldet. Eine Warnung geht an den Operator; bis das Zertifikat erneuert ist, erhält der Server möglicherweise keinen kritischen Verkehr oder der Alarm wird hochgestuft. Das Risiko eines überraschenden Zertifikatsfehlers entfällt.
Sehen wir uns ETM Server Telemetry in Ihrem eigenen Backend live an — planen wir eine Setup-Sitzung über einer Pilot-Servergruppe.