Einführung

Wenn die Produktion ausfällt, sind drei Fragen wichtig: Was ist passiert? Wann ist es passiert? Warum ist es passiert?

In der Praxis sind die Antworten oft verstreut—Metriken an einem Ort, Traffic-Logs an einem anderen und Änderungshistorie wieder woanders.

Es gibt noch eine weitere Realität: Exporte an externe Systeme sind typischerweise selektiv. Wenn das bei einem Vorfall benötigte Signal nie für den Export ausgewählt wurde, werden Sie es nicht haben.

Der TR7-Ansatz ist klar: Export-Integrationen sind wichtig, aber die Untersuchung sollte nicht ausschließlich von ihnen abhängen. Deshalb hält TR7 kritische Signale auf dem Appliance, ausgerichtet auf einer einzigen Zeitachse.

Ein Signal, das nicht erfasst wird, ist ein Risiko, das unsichtbar bleibt.

Warum reicht nur Export nicht aus?

SIEM, Log-Server und Prometheus/Grafana-Plattformen sind wertvoll für Unternehmens-Sichtbarkeit. Der Untersuchungserfolg hängt jedoch davon ab, dass die richtigen Daten verfügbar sind, wenn Sie sie brauchen.

Selektive Erfassung ist unvermeidlich

Kosten und Rauschen bedeuten, dass nicht jede Metrik/jedes Log exportiert wird. Bei einem Vorfall kann das kritische Signal fehlen.

Korrelation wird schwieriger, wenn Daten verstreut sind

Wenn Metriken, Events, Audit und Traffic-Logs an verschiedenen Orten sind, dauert das Erstellen einer einzigen Zeitachse länger.

Die Pipeline ist ein weiterer Risikobereich

Agent-, Netzwerk-, Quota/Limit- oder Indexierungsprobleme können Datenverlust verursachen—besonders während Vorfällen.

Investigation-Ready

Verbringen Sie Zeit mit Problemlösung, nicht mit Datensammlung. TR7 hält kritische Signale auf dem Appliance bereit.

Dynamic Flow Panel: Runtime-Sichtbarkeit und schneller Einstiegspunkt

In der TR7-Oberfläche kann die Service-Topologie live (Runtime) über das Dynamic Flow Panel überwacht werden. Complete Control →

Das Panel zeigt den Servicestatus mit Farben an. Wenn beispielsweise der Interface-Link, der die IP eines vService bedient, ausfällt, erzeugt das System eine Warnung und der Servicename wechselt von Grün zu Gelb.

Dies ermöglicht es Operatoren, sofort zu sehen, was untersucht werden muss. Die Triage beginnt schneller und die Untersuchungszeit verkürzt sich.

Statusfarben

Farben im Flow Panel helfen Ihnen, den Servicestatus schnell zu lesen:

Grün: Normal

Service-Verbindungen und Health-Checks funktionieren wie erwartet.

  • Alle Backends gesund
  • Interface-Links aktiv
  • Health-Checks erfolgreich
Routineüberwachung
Gelb: Achtung

Es gibt einen Zustand, der Überwachung erfordert.

  • Interface-Link ausgefallen (Service funktioniert möglicherweise noch)
  • Ein Backend-Health-Check fehlgeschlagen
  • Annäherung an Ressourcenschwellenwert
Schnelle Prüfung über Metriken + Benachrichtigung + Audit
Rot: Kritisch

Es gibt ein Problem, das den Service beeinträchtigt.

  • Backends ausgefallen
  • vService nicht erreichbar
  • Kritischer Config-Fehler
Schnelle Triage: Metrik + Event + Audit

Beispiel-Untersuchungsszenarien

Die folgenden Beispiele zeigen, wie eine typische Untersuchung auf TR7 abläuft.

Szenario A: Latenzanstieg

  • Beschwerde: 'Anwendung ist langsam'
  • vService-Antwortzeit-Trend prüfen → irgendwelche Spitzen?
  • Backend-Antwortzeit-Verteilung prüfen → welches Backend ist langsam?
  • Mit Health-Check und Verbindungsverteilungen verifizieren
  • Ressourcen-Warnungen in Benachrichtigungslogs im gleichen Zeitraum?
  • Audit-Trail: kürzliche Änderungen?
  • Ergebnis: LB-Schicht oder spezifisches Backend — schnell geklärt

Szenario B: WAF-Blockierungen erhöht

  • Beschwerde: 'Formular-Einreichungen scheitern'
  • WAF-blockiert-Metrik prüfen → irgendwelche Spitzen?
  • Ausgelöste Regel in HTTP/WAF-Logs finden
  • Aus Request-Details bestimmen: False Positive oder echter Angriff?
  • Audit-Trail: Regel/Policy-Änderungen?
  • Gezieltes Debug bei Bedarf verwenden, um nur relevanten Traffic zu untersuchen
  • Ergebnis: Regel-Tuning oder Sicherheitsaktion — mit Daten entscheiden

Web-Konsole & TR7 CLI: Sofortige Diagnose und Beweissammlung von der UI

Die Untersuchung auf TR7 endet nicht bei Diagrammen. Die Web-Konsole ermöglicht das Ausführen der am meisten benötigten System- und Netzwerkbefehle von der Web-Oberfläche in der Produktion. Kein SSH erforderlich. TR7 CLI bringt die gleiche Fähigkeit zur Kommandozeile; Ausgabeformate (JSON/CSV/tab) und Pipe-Befehle machen Untersuchungsschritte wiederholbar.

Netzwerkprüfung: ping, traceroute, dig, iftop

Backend-Konnektivität, DNS-Auflösung, Pfadanalyse und Echtzeit-Bandbreitenverteilung vom Appliance aus verifizieren.

Gezieltes Traffic-Capture: tcpdump, ssldump

Pakete für spezifischen Host/Port erfassen. TLS-Handshakes untersuchen. Nur relevanten Traffic in Datei speichern.

Backend-Tests: curl, wrk

Backend-Response-Code und -Zeit aus ADC-Perspektive messen. Bei Bedarf kontrollierte Lasttests durchführen.

Systemstatus: netstat, ps, df, journalctl

TCP-Zustände, Prozesse, Festplattennutzung und Systemlogs von einem einzigen Bildschirm aus anzeigen.

Web-Konsole: Beispiel-Untersuchungsabläufe

Sie haben eine Warnung im Flow Panel entdeckt. Die folgenden Abläufe sind praktische Beispiele für schnelle Triage.

Backend-Timeout oder Netzwerkproblem?

  • Metriken zeigen Timeout
  • ping backend-ip → ist es erreichbar?
  • curl -I http://backend:8080/health → was ist der Response-Code?
  • traceroute backend-ip → irgendwelche Unterbrechungen auf dem Pfad?
  • Ergebnis: Netzwerk oder Anwendung — schnell getrennt

TLS-Fehler: Client oder Server?

  • SSL-Verbindungsfehler existiert
  • ssldump -i wan0 host client-ip → Handshake erfassen
  • Zertifikat-, Protokoll- oder Cipher-Mismatch identifizieren
  • Ergebnis: Client- oder Server-Konfiguration — mit Paketen bewiesen

Plötzliche Traffic-Spitze: Angriff oder echte Last?

  • Request-Anzahl plötzlich gestiegen
  • iftop -i wan0 → Echtzeit-Top-Talker sehen
  • netstat -an | grep ESTABLISHED | wc → Verbindungsanzahl
  • tcpdump -c 1000 port 443 | to-file spike.pcap → Probe-Capture
  • Ergebnis: DDoS, Bot oder legitimer Traffic — mit Daten entscheiden

Backend 'schnell' aber Benutzer sagt 'langsam'

  • App-Team sieht kein Problem
  • curl -w '%{time_total}' http://backend/api → Zeit aus ADC-Sicht
  • wrk -t2 -c10 -d10s http://backend/api → Test unter Last
  • Ergebnis: Client–ADC–Backend-Kette — Unterschied wird klar

Aktivieren Sie nicht Debug — zielen Sie es.

Metrik-Bibliothek: Retrospektive Überwachung und Analyse-Charts

Die folgenden Überschriften sind Metrik-Chart-Gruppentitel in der TR7-Oberfläche. Jede Gruppe enthält Charts, in denen verwandte Metriken retrospektiv überwacht und analysiert werden können. Diese Charts ermöglichen es Ihnen, bestimmte Zeitbereiche während oder nach einem Vorfall zu untersuchen, Trends zu erkennen und Anomalien zu entdecken.

Frontend Gesamtanfragen
Total Requests
What?Zeigt die Gesamtzahl der HTTP/HTTPS-Anfragen an den Service im Zeitverlauf.
Why important?Grundlegende Referenz zum Verständnis von Traffic-Spitzen, plötzlichen Rückgängen und Kapazitätsauswirkungen. Ermöglicht Vorher/Nachher-Vergleich bei Vorfällen.
Frontend Statuscode-Verteilung
Status Code Distribution
What?Zeigt die Verteilung von HTTP-Response-Codes (2xx Erfolg, 3xx Weiterleitung, 4xx Client-Fehler, 5xx Server-Fehler) im Zeitverlauf.
Why important?Schnelle Erkennung von Fehlerraten-Anstiegen. 5xx-Spitze kann auf Backend-Probleme hinweisen; 4xx-Spitze kann auf Client-seitige oder Konfigurationsprobleme hinweisen.
Frontend Neue Verbindungen
New Connections
What?Zeigt neue TCP-Verbindungen, die pro Sekunde geöffnet werden.
Why important?Plötzliche Verbindungsanstiege können auf DDoS-Angriffe, Bot-Aktivität oder Client-seitige Wiederverbindungsprobleme hinweisen.
Frontend Gleichzeitige Sessions
Concurrent Sessions
What?Zeigt die gleichzeitig aktive Session-Anzahl.
Why important?Hilft zu verstehen, wie nah Sie an Kapazitätsgrenzen sind. Annäherung an Session-Limits kann Performance-Degradation verursachen.
Frontend Durchsatz
Throughput
What?Zeigt das gesamte Datenvolumen, das durch den Service fließt (bits/sec oder bytes/sec).
Why important?Wird verwendet, um Bandbreitennutzung und Traffic-Trends zu verstehen. Durchsatzrückgang kann auf Netzwerk- oder Backend-Probleme hinweisen.
SSL Gleichzeitige Verbindungen
SSL Concurrency
What?Zeigt die gleichzeitig aktive verschlüsselte TLS-Verbindungsanzahl.
Why important?SSL/TLS-Operationen sind CPU-intensiv; diese Metrik ist kritisch für Kapazitätsplanung und Performance-Analyse.
SSL Neue Verbindungen (TPS)
TLS Handshake TPS
What?Zeigt durchgeführte TLS-Handshakes pro Sekunde.
Why important?Plötzliche Handshake-Raten-Anstiege können darauf hinweisen, dass Session-Wiederverwendung nicht funktioniert oder Client-seitige Probleme vorliegen. Hohe Handshake-Raten erhöhen die CPU-Last.
SSL Session-Wiederverwendung
SSL Session Reuse
What?Zeigt TLS-Session-Wiederverwendungsrate und Statistiken.
Why important?Niedrige Session-Wiederverwendung verursacht unnötige CPU-Nutzung und höhere Latenz. Diese Metrik leitet die TLS-Performance-Optimierung.
Kompression
Compression
What?Zeigt HTTP-Response-Kompressionsrate und komprimiertes Datenvolumen.
Why important?Kompression spart Bandbreite, aber verbraucht CPU. Das Verständnis dieser Balance ist wichtig für Performance-Optimierung.
WAF Blockierte Anfragen
WAF Blocked Requests
What?Zeigt die Anzahl der von der Web Application Firewall blockierten Anfragen im Zeitverlauf.
Why important?Plötzlicher Anstieg der Blockierungen kann auf eine Angriffswelle oder eine neue Regel mit False Positives hinweisen. Beide Fälle erfordern Untersuchung.
WAF Erkannte Angriffsanfragen
WAF Detected Attacks
What?Zeigt Anzahl und Typen der von WAF erkannten Angriffsversuche.
Why important?Ermöglicht die Verfolgung von Bedrohungsstufe und Angriffstrends. Das Verständnis, welche Angriffstypen versucht werden und wie oft, ist wertvoll für die Sicherheitsstrategie.
WAF Inspektionsverteilung
WAF Inspection Distribution
What?Zeigt, welcher Anteil der WAF-Regeln und -Kategorien ausgelöst wird.
Why important?Zeigt, welche Regelsätze aktiv sind und welche am häufigsten auslösen. Grundlegende Daten für Regel-Tuning und Optimierungsentscheidungen.
Frontend Bandbreite
Bandwidth
What?Zeigt eingehende und ausgehende Bandbreite, die vom Service verwendet wird.
Why important?Wird verwendet, um Link-Sättigung und Durchsatzänderungen zu überwachen. Annäherung an Bandbreitengrenzen kann Performance-Probleme verursachen.
Integrationen: verfügbar, aber Untersuchung hängt nicht von ihnen ab

TR7 kann in das Monitoring- und Log-Management-Ökosystem Ihrer Organisation integriert werden. Der kritische Unterschied: Die Vorfalluntersuchung hängt nicht ausschließlich von externen Pipelines ab. Externe Systeme fügen Wert hinzu; On-Appliance-Aufzeichnungen dienen als grundlegende Referenz.

Häufig gestellte Fragen

Das Ziel ist, dass untersuchungserforderliche Daten immer auf dem Appliance bereit sind. Externer Export und zentralisierte Archivierung werden unterstützt. Der Untersuchungserfolg hängt jedoch nicht ausschließlich von der Export-Konfiguration ab.

Das Ziel ist nicht, ständig alles anzusehen. Kategorien, Suche und Filterung ermöglichen es Ihnen, bei Bedarf schnell das richtige Signal zu erreichen.

Das Ziel der Web-Konsole ist nicht uneingeschränkter Zugang, sondern kontrollierte Diagnose. Bei Verwendung mit ordnungsgemäßer Autorisierung und Runbooks verkürzt sie die Untersuchungszeit.

Es ist in Echtzeit. Servicezustände werden zur Runtime überwacht und Änderungen werden sofort als Farbänderungen reflektiert. Zusätzlich werden retrospektive Metrik- und Eventaufzeichnungen beibehalten.

Normales Debug erfasst typischerweise allen Traffic und erfordert späteres Filtern. Gezieltes Debug erfasst von Anfang an Aufzeichnungen nur für spezifischen Host, Port, Pfad oder Header. Dies reduziert Rauschen, beschleunigt die Untersuchung und minimiert die Produktionsauswirkung.

TR7 unterstützt Prometheus-Export und SIEM-Log-Weiterleitung. Integrationen behalten ihren Wert. Der Unterschied: Untersuchungserforderliche Daten hängen nicht ausschließlich von externen Systemen ab—sie sind auch auf dem Appliance bereit.

Die Aufbewahrungsdauer ist konfigurierbar. Wichtig ist, dass Benutzeraktionen und Config-Änderungen auf der gleichen Zeitachse wie Metriken und Eventaufzeichnungen gehalten werden.

Detail ist Vorbereitung, nicht Komplexität. Selbst in kleinen Teams spart schnelles Erreichen der richtigen Daten während eines Vorfalls Zeit. Kategorisierte Struktur und Suchfunktionen erleichtern es, sich nur auf benötigte Daten zu konzentrieren.


Fazit

Der Anspruch von TR7 ist nicht 'mehr Charts'—es geht darum, die ADC/WAF-Schicht investigation-ready zu machen. vService/Backend/Interface-Metriken, Event/Benachrichtigungsaufzeichnungen, Audit-Trail und HTTP/WAF-Sichtbarkeit kombinieren sich auf einer einzigen Zeitachse; retroaktive Forensik und gezieltes Debug beschleunigen die Ursachenanalyse.

Export-Integrationen sind wertvoll; aber um das Risiko 'wurde nicht gesendet, existiert also nicht' in kritischen Momenten zu minimieren, muss die Beweiskette jederzeit innerhalb des Produkts zugänglich bleiben.

Diese und ähnliche Fähigkeiten—Details, die nicht auf Datenblättern erscheinen, in Demos schwer zu erfassen sind, aber die operative Qualität in der Praxis definieren—sind der Hauptgrund, warum fast alle Organisationen, die TR7 evaluieren, sich für den Wechsel entscheiden.

Der Unterschied zeigt sich bei der Nutzung.

Live-Demo anfordern