Die meisten Reporting-Infrastrukturen sehen so aus: Das ADC- oder WAAP-Produkt generiert periodische PDFs, legt sie in einen Dateifreigabeordner ab, und ein wöchentlicher Cron oder ein manueller Schritt sendet sie per E-Mail an die richtigen Stakeholder. Es gibt mehrere manuelle Glieder in der Kette; wenn eines bricht, kann der fehlende Stakeholder wochenlang ohne Informationen sein.
Darüber hinaus benötigen verschiedene Stakeholder innerhalb derselben Organisation den Bericht desselben vService in unterschiedlichen Detailtiefen. Das Führungsgremium möchte eine zweiseitige monatliche Zusammenfassung; der Betrieb möchte eine wöchentliche vollständige Ansicht; die interne Revision möchte ein tägliches vollständiges XLSX. Ein einzelnes Berichtsprofil kann nicht alle drei bedienen — aber die meisten Produkte erlauben nur ein Profil pro vService.
Hochverfügbarkeitscluster stellen eine weitere Falle dar: Wenn derselbe geplante Bericht von mehreren Knoten generiert wird, erhält der Stakeholder entweder zwei Kopien derselben PDF, oder der Operator schreibt Koordinationsskripte. Cluster-bewusste Einzelversand-Semantik liegt in der Regel außerhalb der Software und auf den Schultern des Operators.
Format- und Sprachpräferenz sind ebenfalls operative Anforderungen. Ein lokaler Kunde benötigt möglicherweise einen Bericht in seiner Sprache, ein internationaler Prüfer benötigt möglicherweise Englisch, ein Inspektor benötigt möglicherweise ein formaleres Format und das Operations-Team benötigt möglicherweise technischere Ausgabe. Diese Vielfalt durch manuelles Kopieren von Vorlagen zu verwalten, ist nicht nachhaltig.
TR7 Geplante Berichtslieferung löst alle vier in einem Produkt: Mehrfachfrequenz + Mehrfach-Empfänger + Mehrfachformat pro Profil, unbegrenzte Profile pro vService, cluster-bewusster Einzelversand, pro-Profil-Sprachpräferenz.
TR7 entwirft Berichtsterminierung als natürlichen Teil der vService-Konfiguration — kein separater Terminierungsdienst, keine separate Benutzeroberfläche, das Profil lebt unter dem vService.
Stündliche, tägliche, wöchentliche, monatliche und jährliche Voreinstellungen sind an feste Cron-Ausdrücke gebunden. Das Ad-hoc-Formular und das geplante Profil teilen denselben Parametersatz — der Operator füllt das Formular einmal aus, speichert es als Profil, wählt eine Frequenz, und die Lieferung beginnt.
Jedes Berichtsprofil kann mehreren E-Mail-Empfängern, mehreren Dateitypen (PDF, XLSX) und mehreren Frequenzen zugewiesen werden. Ein Profil kann parallel eine wöchentliche PDF-Zusammenfassung und ein monatliches vollständiges XLSX an verschiedene Stakeholder-Gruppen liefern.
Ein vService kann ein primäres Profil und eine beliebige Anzahl zusätzlicher Profile tragen. Monatliche Executive-Zusammenfassung, wöchentliche Operations-Details, tägliche Vollabdeckungs-Audit-PDF — alles unter demselben vService, aus derselben Datenquelle.
In einem Hochverfügbarkeitscluster wird derselbe geplante Bericht nur vom aktiven Knoten generiert und gesendet. Operatoren müssen keine Koordinationsskripte schreiben, um doppelte Lieferung zu verhindern; der Engine kennt die Cluster-Topologie.
Die Terminierungsoberfläche — Profildefinition, Frequenzauswahl, Empfängerverwaltung, Dateityp und Sprachpräferenz — läuft auf einem gemeinsamen Ad-hoc- und Cron-Engine.
Stündlich: jede Stunde + 5 Minuten. Täglich: 01:30. Wöchentlich: Montag 03:30. Monatlich: 1. des Monats 05:30. Jährlich: Jahreswechsel. Ein einzelnes Profil kann mehreren Frequenzen zugewiesen werden; derselbe Dimensionssatz kann nach verschiedenen Zeitplänen an verschiedene Empfängergruppen gesendet werden.
Profile werden namentlich unter jedem vService definiert ("Executive Monthly", "SRE Weekly", "Internal Audit Daily"). Profilnamen erscheinen in der Operator-Konsole, in E-Mail-Betreffzeilen und in Audit-Logs — so ist nachvollziehbar, wer welchen Bericht unter welchem Profil erhalten hat.
Jedes Profil kann an mehrere E-Mail-Adressen versendet werden. Adressen werden beim Speichern gegen das E-Mail-Muster validiert; ungültige Adressen werden abgelehnt. Das Ad-hoc-Berichtsformular akzeptiert ebenfalls einen einmaligen Empfänger.
Derselbe geplante Bericht kann sowohl als PDF als auch als XLSX gerendert und an dieselbe E-Mail angehängt werden. Stakeholder erhalten zwei Ansichten derselben Daten — PDF zum Lesen, XLSX für Detailabfragen.
Jedes Berichtsprofil legt seine eigene Sprache fest. In Service-Provider-Szenarien erhält jeder Kunde den Bericht in seiner eigenen Sprache; derselbe Engine produziert parallel Berichte in verschiedenen Sprachen für Dutzende von Kunden. Deckblatt-Titel und Abschnittsbeschriftungen werden an die Sprache des Profils angepasst.
In einem Hochverfügbarkeitscluster wird ein gegebener geplanter Bericht nur einmal generiert und gesendet, vom aktiven Knoten. Operatoren schreiben keine Koordinationsskripte, Stakeholder erhalten keine duplizierten PDFs, und Inter-Knoten-Wettlaufbedingungen entstehen nicht. Der Engine kennt die Cluster-Topologie und verhält sich entsprechend.
Jeder vService kann ein primäres Berichtsprofil und eine beliebige Anzahl von Extra-Profilen tragen. Das primäre Profil lebt in der vService-Konfiguration; Extras werden in einer separaten Liste verwaltet. Verschiedene Stakeholder erhalten verschiedene Berichtstiefen unter demselben vService.
Das Ad-hoc-Berichtsformular der Operator-Konsole (Format, Bereich, Dimensionen, Diagrammauswahl, Zeilenlimit, Sprache, Ziel-E-Mail) teilt den Parametersatz 1:1 mit dem geplanten Profil. Eine zufriedenstellende Ad-hoc-Ausgabe wird zu einem Profil und beginnt als Cron zu laufen.
Der Terminierungs-Engine ist neben Cron-Ausdrücken, Datei-Lebenszyklus, E-Mail-Lieferung, Clusterverhalten und Audit-Logs konzipiert.
Stündlich 5 * * * *, täglich 30 1 * * *, wöchentlich 30 3 * * 1, monatlich 30 5 1 * *. Dieselben geplanten Berichts-Slots sind positioniert, um Überschneidungen mit anderen periodischen Jobs zu vermeiden; stündliches Reporting fällt nicht zu einem einzelnen Traffic-Peak.
PDF/XLSX-Anhänge werden als Standard-SMTP-E-Mail geliefert; die Betreffzeile ist konfigurierbar. Der Engine arbeitet über Unternehmens-E-Mail-Server (Exchange, Postfix, überwachte Cloud-Provider). Webhook-, S3-Upload- und SFTP-Lieferung sind im aktuellen Release nicht enthalten.
Generierte Berichtsdateien werden unter /tmp mit zeitgestempelten Namen geschrieben, als E-Mail-Anhänge verwendet und durch den OS-Lebenszyklus entfernt. Langzeitarchivierung erfordert manuelle Weiterleitung der Profilausgabe an einen gemeinsamen Speicher oder die Konfiguration von SIEM-Weiterleitung.
Nur der aktive Knoten des Clusters führt die periodische Lieferung durch; Standby-Knoten führen nicht denselben Cron aus. Bei einem Failover übernimmt der neue aktive Knoten die Lieferung ab dem nächsten Zeitraum.
Sowohl L7-Traffic-Berichte als auch WAAP-Angriffsberichte laufen auf demselben Terminierungs-Engine. Operatoren verwalten keine zwei Terminierungsdienste; Profildefinitionen, Frequenzvoreinstellungen und Empfängerverwaltung sind für beide Oberflächen identisch.
Wenn ein Profil aktualisiert wird, gelten die Änderungen beim nächsten Cron-Auslöser; laufende Generierungen sind nicht betroffen. Wenn ein Profil gelöscht wird, werden zukünftige Auslöser abgebrochen, während historische Lieferaufzeichnungen erhalten bleiben.
Banken und Konzerne senden monatlich eine Executive-PDF pro vService an das Führungsgremium — Deckblatt mit Unternehmenslogo, 2-3 Seiten Gesamttraffic, geografische Intensität, Fehlerrate und Backend-Gesundheit. Das Profil wird der monatlichen Frequenz mit mehreren Empfängern parallel zugewiesen.
SRE-Teams erhalten ein wöchentliches vollständiges Aufschlüsselungs-XLSX für denselben vService — ein Reiter pro Abschnitt, bereit für Detailanalysen. "Executive Monthly"- und "SRE Weekly"-Profile laufen parallel unter demselben vService.
Die interne Revision erhält täglich vollständige Abdeckungsberichte — PDF und XLSX zusammen. Tägliche PCI-DSS-Dossier-Einträge akkumulieren automatisch; das Archiv des Prüfers ist am Monatsende einquellig.
MSPs definieren ein pro-Tenant-Berichtsprofil unter jedem vService; jeder Kunde erhält einen monatlichen Bericht in seiner eigenen Sprache, mit seinem eigenen Logo, an seine eigene E-Mail-Liste. Kein manueller Schritt; das Onboarding eines neuen Tenants erfordert nur einen neuen vService und ein Profil.
5 Frequenzvoreinstellungen, Mehrfach-Empfänger, Mehrfachformat, cluster-bewusster Einzelversand, pro-Profil-Sprachpräferenz. Lassen Sie uns eine Live-Demo auf Ihrem eigenen vService durchgehen.