Klassische Load-Balancer-Logs bleiben oft nur auf der grundlegenden Access-Log-Ebene. Statuscode, Antwortzeit, URL, Backend, TLS, WAAP-Score, Geo-IP und Benutzerkontext können in verschiedenen Systemen oder gar nicht gesammelt verbleiben. In diesem Fall muss das Betriebsteam, um das Problem zu verstehen, Logs parsen, ein separates Dashboard schreiben oder Daten von verschiedenen Teams anfordern.
Wenn WAAP-Logs und ADC-Logs an verschiedenen Orten aufbewahrt werden, wird die Korrelation erschwert. Um sowohl den Performance- als auch den Sicherheitskontext derselben Anfrage zu sehen, müssen Request-ID, Zeitstempel, IP, Pfad und Sitzungsinformationen manuell abgeglichen werden. Im Moment eines Incidents kostet diese manuelle Korrelation Zeit.
In mandantenfähigen oder Multi-vService-Strukturen werden auch Retention und Reporting zu einem eigenen Problem. Während ein Tenant intensiv Logs erzeugt, dürfen die Daten eines anderen nicht verloren gehen; Anwendungen im Geltungsbereich kritischer Regulierungen sollen länger aufbewahrt werden können, während öffentlicher Webverkehr mit kürzerer Retention gehalten werden kann.
Der richtige Ansatz ist, die Logs auf L7-Anfrageebene zusammen mit Zeitreihenmetriken zu behandeln. Request Rate, SSL TPS, Statuscode-Verteilung, WAAP Attack Rate, Backend-Antwortzeit, Dropped Log und Health-Check-Metriken sollten in derselben Dashboard-Familie überwacht werden.
Das TR7 L7-Reporting-Add-on bietet dieses Modell: Es macht L7-Request-, WAAP-, Backend-, Health-Check- und QoS-Daten in einer integrierten Dashboard- und Reporting-Schicht sichtbar.
Das TR7 L7-Reporting arbeitet mit angereichertem Log-Strom, Zeitreihenmetriken, integrierten Dashboards und Drill-down-Variablen.
TR7 überführt die L7-Verkehrslogs und WAAP-Ereignisse in eine gemeinsame Reporting-Linie. So können Performance-, Fehler- und Angriffssignale im selben vService-Kontext untersucht werden.
Request Rate, Statuscode, SSL TPS, Throughput, Health Check und QoS-Metriken können im Laufe der Zeit gespeichert werden. Diese Struktur kann für Kapazitätsplanung, Post-Incident-Analyse und periodische Performance-Verfolgung genutzt werden.
TR7 bietet mit einer detaillierten vService-Dashboard- und einer globalen Dashboard-Struktur die grundlegenden Betriebspanels einsatzbereit an. Der Operator kann ab dem ersten Tag Verkehrs-, SSL-, Backend-, Speicher-, CPU- und WAAP-Metriken überwachen.
Mit den Variablen vService, Backend und Host können Dashboard-Filter angewendet werden. Vom Anstieg der 5xx zu einer bestimmten URL, von dort zum sich verlangsamenden Backend kann eine Untersuchung durchgeführt werden.
Das L7-Reporting-Add-on macht den Anwendungsverkehr von der Request-Ebene bis zum gesamten Plattformbereich mit 50+ Panels/Elementen überwachbar.
Das detaillierte Dashboard zeigt HTTP-/HTTPS-Request-Rate, neue Requests, Session-Requests, Total Connections, SSL TPS, Throughput, CPU, Memory, SSL Cache und Error-Metriken im vService-Kontext. Der Operator kann das Verhalten einer einzelnen Anwendung untersuchen, ohne sich mit dem plattformweiten Rauschen zu vermischen. Diese Ansicht trennt im Moment eines Incidents schnell, welcher vService betroffen ist. Performance- und Sicherheitssignale werden auf demselben Bildschirm interpretiert.
Das globale Dashboard zeigt durchschnittliche CPU-Auslastung, Gesamtzahl der vServices, Gesamtzahl der Backends, Uptime und allgemeine HTTP-/SSL-Metriken. Dieser Bildschirm fasst den Gesamtzustand der Plattform für Management- und Betriebsteams zusammen. In Multi-vService-Umgebungen wird schnell verständlich, welche Bereiche sich verdichten. Er kann als erster Übersichtsbildschirm für die Kapazitätsplanung genutzt werden.
Die Panels Health Check Status, Health Check Time und Health Check State zeigen den Erreichbarkeits- und Antwortzeitstatus der Backends. Zustände wie UP, DOWN oder NOCHECK können im Laufe der Zeit überwacht werden. Ein Anstieg der Antwortzeit kann auf eine Performance-Verschlechterung hindeuten, bevor ein vollständiger Ausfall eintritt. Diese Metriken erleichtern das Verständnis des Failover- und Pool-Verhaltens.
Die Response-Counter-Panels für 1xx, 2xx, 3xx, 4xx und 5xx klassifizieren das Antwortverhalten der Anwendung. Ein Anstieg der 5xx kann auf einen Backend- oder Anwendungsfehler, ein Anstieg der 4xx auf Client-, Bot- oder WAAP-Einfluss hindeuten. Der Operator kann zuerst die Fehlerklasse, dann das URL- und Backend-Detail untersuchen. Diese Struktur verkürzt die Incident-Triage-Zeit.
TR7 kann WAAP-Angriffsereignisse zusammenfassen und Angriffstypen auf Aggregationsebene anzeigen. Statt einzelner roher WAAP-Logs werden Angriffskategorie, Intensität und Zeitverteilung überwacht. Das Sicherheitsteam sieht schneller, welcher vService mit welcher Angriffsfamilie konfrontiert ist. Das erleichtert die tägliche SOC-Prüfung und das monatliche Sicherheits-Reporting.
Die Metrik `tr7_tm_vservice_waf_attack_rate` kann die WAAP-Angriffsrate auf vService-Ebene anzeigen. Plötzliche Anstiege können ein Signal für eine Bot-Welle, einen Exploit-Scan oder einen gezielten Angriff sein. Wenn diese Metrik zusammen mit dem Verkehrsvolumen interpretiert wird, wird die Angriffsintensität genauer verstanden. Sie hat in Alarm- und Dashboard-Szenarien hohen Wert.
Auf der Backend-Seite können Metriken wie Session, New Session, Response Code, In-/Outbound-Verkehr, Connection Error, Response Error, Queue Time, Connect Time, Response Time und Total Time überwacht werden. Diese Trennung hilft zu verstehen, ob das Problem auf der ADC-Seite, im Netzwerk oder im Backend liegt. Zum Beispiel kann ein Anstieg der Connect Time ein Netzwerk- oder Service-Annahmeproblem, ein Anstieg der Response Time eine Anwendungsverzögerung sein. Die Incident-Analyse wird präziser durchgeführt.
Wenn intensiver Verkehr oder ein Log-Pipeline-Problem auftritt, kann die Anzahl der Dropped Logs ansteigen. Das Logs-Dropped-Panel hilft, die Zuverlässigkeit der Observability-Daten zu überwachen. Falls ein Log-Verlust vorliegt, müssen die Dashboard-Interpretationen mit Vorsicht behandelt werden. Das Betriebsteam verfolgt nicht nur den Verkehr, sondern auch die Gesundheit der Messlinie.
Die Compress-In/Out-Metriken zeigen das Kompressionsverhalten. Der Operator kann überwachen, wie viel Verkehrswirkung die Kompression bei welchen vServices erzeugt. Diese Werte werden zusammen mit WAN-Kosten, Benutzererlebnis und CPU-Verbrauch bewertet. Kompressionsrichtlinien werden nicht mit Intuition, sondern mit Daten verwaltet.
Metriken wie `tr7_tm_vservice_memory_usage` und `tr7_tm_vservice_memory_alloc` können das Speicherverhalten des vService überwachen. Anstiegstrends im Laufe der Zeit sind für die Kapazitätsplanung und mögliche Leckanalysen wertvoll. Der Operator kann nicht nur den momentanen Ausfall, sondern auch den künftigen Kapazitätsdruck sehen. Das ermöglicht eine geplante Skalierung für wachsenden Anwendungsverkehr.
Metriken wie `tr7_tm_qos_cpu_count`, `tr7_tm_qos_cpu_percent_limit` und `tr7_tm_qos_memory_limit` machen die Plattform-Ressourcenlimits sichtbar. Diese Werte werden zusammen mit den Verkehrsmetriken überwacht, sodass Ressourcendruck verständlich wird. Wenn die Fehlerproduktion eines vService mit der Annäherung an das Ressourcenlimit zusammenhängt, wird sie schneller erkannt. Die QoS-Sichtbarkeit unterstützt Kapazitäts- und Isolationsentscheidungen.
TR7 kann die Interval-Konfigurationen für das detaillierte und das globale Dashboard mit separaten Dateien verwalten. Das macht das Dashboard-Aktualisierungs- und Zeitraumverhalten konsistenter. Langfristige Trend- und kurzfristige Incident-Analyse können mit unterschiedlichen Intervallen durchgeführt werden. Der Operator stellt das Panel-Timing je nach unterschiedlichen Anwendungsfällen ein.
Das L7-Reporting wird zusammen mit Metric Namespace, Frontend-/Backend-Metriken, Health-Check-State, QoS-Feldern und Dashboard-Variablen betrieben.
Die TR7-Metriken werden unter dem Namespace `tr7_tm_*` gruppiert. Diese Struktur erleichtert das Unterscheiden von Frontend-, Backend-, Health-Check-, QoS- und Geräte-Metriken. Dashboard- und Alarmregeln werden über diese Benennung standardisiert.
Request Rate, Total Connections, In-/Outbound-Bytes, Request Error, 1xx-5xx Response, SSL Connection, SSL Rate, SSL Cache, Compression, Dropped Log und Speichermetriken können auf der Frontend-Seite überwacht werden. Diese Metriken erklären das benutzerseitige vService-Verhalten. Es wird getrennt, ob das Problem durch externen Verkehr, TLS oder Antwortverhalten verursacht wird.
Auf der Backend-Seite können Session, Response Code, Verkehr, Connection Error, Response Error und Timing-Metriken gesammelt werden. Die Trennung von Queue, Connect, Response und Total Time ist in der Performance-Analyse kritisch. Anwendungs-, Netzwerk- und Service-Annahmeprobleme werden mit unterschiedlichen Metriken sichtbar.
`tr7_tm_bservice_hc_state` kann den Gesundheitsstatus des Backends als UP, DOWN oder NOCHECK ausdrücken. `tr7_tm_bservice_hc_time` kann die Antwortzeit der Gesundheitsprüfung auf Millisekundenebene anzeigen. Health-Check-Trends erleichtern das Verständnis des Failover-Verhaltens.
QoS-Felder wie CPU-Anzahl, CPU-Prozentlimit und Speicherlimit können ins Dashboard überführt werden. Diese Metriken ermöglichen es, die Wirkung der Ressourcenlimits in Momenten intensiven Verkehrs zu verstehen. Besonders bei mandantenfähigen oder hochlastigen Services unterstützen sie die Kapazitätsentscheidung.
Mit Variablen wie `$vservice`, `$bservice` und `$host` können Panels gefiltert werden. Der Operator kann vom globalen Diagramm zu einem bestimmten vService, von dort zu einem bestimmten Backend heruntergehen. Dieser Drill-down-Ablauf beschleunigt die Incident-Untersuchung.
Der Operator kann vom 5xx-Panel zur betreffenden URL, von dort zum sich verlangsamenden Backend heruntergehen. Die Metriken Connect Time und Response Time helfen zu trennen, ob das Problem durch das Netzwerk oder die Anwendung verursacht wird.
Das Sicherheitsteam kann die SSL-Metriken und die WAAP-Attack-Rate-Werte in einen periodischen Bericht aufnehmen. Diese Daten erhöhen die Sichtbarkeit der Anwendungssicherheits- und Verkehrsschutzkontrollen.
Für einen vService im Geltungsbereich von Gesundheits- oder Regulierungsvorgaben kann eine längere Retention, für öffentlichen Webverkehr eine kürzere Retention angewendet werden. So werden Speicherkosten und Compliance-Bedarf ausbalanciert.
Durch die Überwachung der Trends von Memory Alloc, Request Rate und Throughput kann der künftige Kapazitätsbedarf prognostiziert werden. Der Operator trifft die Skalierungsentscheidung nicht mit momentaner Intuition, sondern mit Zeitreihendaten.
Wenn die WAAP Attack Rate ansteigt, können die Angriffskategorien zusammengefasst und die betroffenen vServices gefiltert werden. Das SOC-Team kann den Angriffstyp und die Intensität sehen, ohne sich in rohen Logs zu verlieren.
Integriertes Dashboard, Drill-down-Metriken und WAAP-Reporting — lassen Sie uns alles in einer Live-Installation durchgehen.