Trace und Audit

<< Server Eigenschaften/Protokolle | IBExpert | Datenbankvalidierung (Datenbankzustand) >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation


Trace und Audit

Dieser Menüpunkt unterstützt die Firebird 2.5 Trace and audit services. Er wurde ursprünglich vom TraceAPI, die von Nickolay Samofatov für die auf Firebirdcode basierte, kommerzielle Red Soft Database entwickelt. Dieses Feature bietet einen Einblick im Firebirdengine und protokolliert verschiedene Events für Echtzeitanalyse. (Dieses Feature ist leider nicht in der kostenlosen IBExpert Personal Edition enthalten.)

Zwei verschiedene Arten eines Traces können ausgeführt werden: User Traces (Benutzerprotollierung) und ein System Audit (Systemaudit).

Es gibt für die Verwendung drei allgemeine Fälle:

  1. Durchgehender Audit von Engineaktivität
  2. Interaktive Protokollierung spezifizierter Aktivität in angegebenen Datenbanken.
  3. Engineaktivitätsprotokollierung für einen bestimmten Zeitraum (sei es Stunden oder einen ganzen Tag) für spätere Analyse.

Die unterstützten Anweisungen beinhalten:

Erweiterte Unterstützung für Firebird 3.0:

  • Seit Version 2014.01.01 unterstützt IBExpert auch Firebird 3.0 Konfiguration Syntax
  • Unterstützung der log_function_start/log_function_finish-Optionen wurden in IBExpert Version 2014.03.16 hinzugefügt.
  • Unterstützung der explain_plan-Option wurde in IBExpert version 2014.06.17 hinzugefügt.

Allerdings ersetzt einen Audit/Trace nicht die Monitoring-Tabellen, da mit diesen Tabellen kann der Benutzer einen Snapshot der aktuellen Datebankbestand abfragen, im Gegensatz zu einen Audit/Trace, die einen sequenziellen Strom protokollierter Anweisungen ähnelt. Zum Beispiel, wenn Sie wissen möchten, derzeit wieviele aktive Transaktionen sich in einer Datenbank befinden, brauchen Sie nur die MON$TRANSACTIONS-Tabelle abzufragen. Mit Audit/Trace wäre dies wahrscheinlich - wenn überhaupt- nur durch fortgeschrittene Datenanalyse auf dem Logdatastream möglich.

Folgende Szenarien zeigen einfache Beispiele für einen Audit/Trace:

  • Anzahl ausgeführte Anweisungen in einem bestimmten Zeitraum
  • Ausführungs-Trace für eine bestehende (Dritthersteller) Applikation (Blackbox-Debugging)
  • Untersuchung eventueller Leistungsprobleme, wenn COMMIT RETAINING (weiches Commit) oder COMMIT (hartes Commit) von Ihrer Anwendung aus verwendet wird
  • Gebrauchsstatistik für Ressourcen- und Auslastungsplanung
  • Geloggte Statements als Input für einen Sicherheitsaudit.

Sessionvergleich der Anwender- und Audit Trace Sessions

  • User Trace Session: Jede Trace Session hat seine eigene Konfiguration, Status und Output und wird von den Benutzern verwaltet. Trace Sessions können mit diesem IBExpert Menüpunkt konfiguriert und überwacht werden. Geloggte Anweisungen werden in einer temporären Datei auf dem Server so lange gespeichert, bis die auslösende Applikation die Trace-Daten über die Services API holt. Ein User Trace bleibt bei einem Serverneustart nicht bestehen, sondern muss manuell neu gestartet werden.
  • Audit Services: Die System Audit Session wird vom Firebirdengine gestartet. Ein Parameter in firebird.conf, namens AuditTraceConfigFile, zeigt auf dem Namen und Speicherort der Trace Konfigurationsdatei, die bei jedem System Audit Sessionstart, konsultiert wird. Der Defaultwert dieses Parameters ist leer; dies bedeutet, dass kein System Audit Tracing konfiguriert ist. Eine Konfigurationsdatei beinhaltet eine Liste Traced Events und zeigt auf den Ablageort der Trace Logdatei für jedes Event. Es ist ausreichend flexibel, um verschiedene Eventsets für verschiedene Datebanken in getrennten Logdateien loggen zu können. Die Vorlagedatei, fbtrace.conf, ist im Firebird Rootverzeichnis zu finden und enthält eine vollständige List aller verfügbaren Events, mit Formaten, Regeln und Syntax für die Zusammenstellung einer Audit Trace-Datei. Der System Audit ist in den Firebird 2.5 Release Notes ausführlich beschrieben.

Der Audit wird auf dem Trace errichtet. Der Engine enthält lediglich Trace Sessions. Allerdings unterscheidet sich die Funktionalität der zwei Sessiontypen:

User TraceSystem Audit
Wird immer vom Benutzer über eine besondere Service (Applikation oder ähnliches) gestartet.Wird immer von Firebird selbst gestartet.
Viele Schreiber.Viele Schreiber.
Ein Leser.Kein Leser.
Die Logdatei wird nach einem Firebirdshutdown nicht aufbewahrt.Die Logdateien werden nicht vom Firebird gelöscht.
Output wird von der startenden Serviceverbindung gelesen (die Logdatei beginnt und hört auf mit dem Start und Ende der Session).Output wird in Logdatei(en) gespeichert.
Der Logdateiname wird von Firebird vergeben.Ein Logdateiname kann für jede Datenbank (per Service) in fbtrace.conf festgelegt werden. Der Name kann anders oder derselbe für alle Datenbanken sein.
Der Umfang hängt von den Benutzerprivilegien ab.Der Umfang ist nicht eingeschränkt.
Sie könnte von Firebird temporär unterbrochen werden, wenn die temporäre Dateien voll sind. Wird automatisch von Firebird wieder aufgenommen, so bald Platz zur Verfügung steht.Wird nie von Firebird unterbrochen.
Viele User Trace Sessions können simultan laufen. Jeder Benutzer darf so viele Trace Sessions starten, die er benötigt.Nur eine Audit Trace Session darf existieren - Firebird ist für das Starten und Anhalten verantwortlich.
Kann vom Datenbankbesitzer oder dem SYSDBA verwaltet (d.h. gestartet und gestoppt) werden.Kann nur vom SYSDBA verwaltet werden.

zurück zum Seitenanfang

Mit der IBExpert Trace und Audit Service arbeiten

IBExperts Trace and Audit wird vom IBExpert Systemdienste Menü gestartet:

Um Trace-Daten in einer Datei zu laden und analysieren, klicken Sie einfach auf dem Datei öffnen-Symbol (in der Symbolleiste zweite von links). Um eine neue Trace Session zu starten, klicken Sie auf dem Neue Trace Session-Symbol oben links, um das New trace session options (Neue Trace Session Optionen) Fenster zu öffnen:

Wenn Sie die Trace Session konfigurieren, wird sie von oben nach unten konfiguriert. Es gibt zwei Teile: Database und Services. Die Parameter können als Standard gespeichert werden und für alle Datenbanken oder Services verwendet werden. Lediglich ist ein Defaultteil für jedes Teil erlaubt. Nach der Verarbeitung des Default Datenbankteils, fährt die Suche fort: wenn der Datenbankname mit dem Muster übereinstimmt, werden die Optionen sofort angewendet und die Suche wird nicht fortgesetzt. Das Muster ist entweder der Datenbankname ohne Verzeichnisangabe oder ein SIMILAR TO-basierten Ausdruck, der dem vollen Datenbank-/Pfadnamen entspricht.

Zuerst nennen Sie die Session (IBExpert bietet bereits einen Defaultnamenvorschlag mit automatisch generiertem Timestamp-Teil). Geben Sie Benutzername, Passwort, Serverpfad und Clientbibliothek an. Schließlich spezifizieren Sie, ob das Protokoll auf dem Bildschirm angezeigt oder in eine Datei (oder beides) gespeichert werden soll, bevor Sie angeben, welche Aktionen protokolliert werden sollen.

Folgende Optionen werden angeboten:

Datenbank

  • Database name: (Datenbankname) Wählen Sie eine registrierte Datenbank von der Aufklappliste aus.
  • Trace database events: (Datenbankevents aufzeichnen) Diese Option sollte aktiviert werden, ansonsten wird nichts aufgezeichnet. Der Standardwert ist true.
  • SQL queries include filter: (SQL Abfragen enthalten den Filter) Nur die SQL-Anweisungen, die dem angegebenen Ausdruck entsprechen, werden geloggt.
  • SQL queries exclude filter: (SQL Abfragen Auschlussfilter) Die SQL-Anweisung, die dem angegebenen Ausdruck entsprechen, werden NICHT geloggt.
  • Put attach/detach log events: (Log Events anhängen/trennen) Setzt den log_connections-Parameter in der fbtrace.conf-Datei auf true oder false. Standardwert ist true.
  • Put transaction start/end events: (Erfasse Transaktion Start/Ende Events) Setzt den log_transactions-Parameter auf true oder false. Standardwert ist true.
  • Put SQL statement prepare records: (Erfasse SQL-Anweisung Datensätzevorbereitung) Setzt den log_statement_prepare-Parameter auf true oder false. Standardwert ist true.
  • Put SQL statement free records: (Erfasse SQL-Anweisung freigegebene Datesätze) setzt den log_statement_free-Parameter auf true oder false. Standardwert ist true.
  • Put SQL statement start records: (Erfasse SQL-Anweisung Datensätzestart) setzt den log_statement_start-Parameter auf true oder false. Standardwert ist true.
  • Put SQL statement finish/fetch to EOF records: (Erfasse SQL-Anweisung beenden/holen zu EOF Datensätze) setzt den log_statement_finish-Parameter auf true oder false. Standardwert ist true.
  • Put stored procedure execution start records: (Erfasse Prozedurausführung Anfangsdatensätze) setzt den log_procedure_start-Parameter auf true oder false. Standardwert ist true.
  • Put stored procedure execution finish records: (Erfasse Prozedurausführung Schlussdatensätze) setzt den log_procedure_finish-Parameter auf true oder false. Standardwert ist true.
  • Put trigger execution start records: (Erfasse Triggerausführung Anfangsdatensätze) setzt den log_trigger_start-Parameter auf true oder false. Standardwert ist true.
  • Put trigger execution finish records: (Erfasse Triggerausführung Schlussdatensätze) setzt den log_trigger_finish-Parameter auf true oder false. Standardwert ist true.
  • Put context variable change records (RDB$SET_CONTEXT): (Erfasse Kontextvariable Datensatzänderung (RDB$SET_CONTEXT)) setzt den log_context-Parameter auf true oder false. Standardwert ist true.
  • Put access path (plan) with SQL statement: (Erfasse Zugangspfad (Plan) mit SQL-Anweisung) setzt den print_plan-Parameter auf true oder false. Standardwert ist true.
  • Put detailed performance info when applicable: (Wenn relevant, erfasse detaillierte Leistungsinformation) setzt den print_perf-Parameter auf true oder false. Standardwert ist true.
  • Log BLR requests compile/execute records: (Protokolliere BLR-Abfragen Datensätze kompilieren/ausführen) setzt den log_blr_requests-Parameter auf true oder false. Standardwert ist false.
  • Print BLR requests: (BLR-Abfragen drucken) setzt den print_blr-Parameter auf true oder false. Standardwert ist false.
  • Put DYN requests execute records: (Erfasse DYN-Abfragen Datensätze ausführen) setzt den log_dyn_requests-Parameter auf true oder false. Standardwert ist false.
  • Print DYN requests: (Drucke DYN-Abfragen) setzt den print_dyn-Parameter auf true oder false. Standardwert ist false.
  • Put xxx_finish record only if its timing exceeds this number of milliseconds: (Erfasse xxx_finish Datensatz nur, wenn die Zeit diese Anzahl Millisekunden überschreitet) setzt den time_threshold-Parameter in Millisekunden. Standardwert ist 100.
  • Maximum length of SQL strings logged: (Maximale Länge der geloggten SQL-Strings) setzt den max_sql_length-Parameter zur maximalen Stringlänge, die geloggt werden soll. Standardwert ist 300.
  • Maximum length of BLR request logged: (Maximale Länge der geloggten BLR-Abfrage) setzt den max_blr_length-Parameter zur maximalen BLR-Länge, die geloggt werden soll. Standardwert ist 500.
  • Maximum length of DYN request logged: (Maximale Länge der geloggten DYN-Abfrage) setzt den max_dyn_length-Parameter zur maximalen DYN-Länge, die geloggt werden soll. Standardwert ist 80.
  • Maximum length of individual arguments logged: (Maximale Länge der einzelnen geloggten Argumente) setzt den max_arg_length-Parameter zur maximalen Stringlänge, die geloggt werden soll. Standardwert ist 80.
  • Maximum number of query arguments to put in log: (Maximale Anzahl der geloggten Abfrageargumente) setzt den max_arg_count-Parameter zur maximalen Anzahl der Argumente, die geloggt werden sollen. Standardwert ist 30.
  • Put errors happened: Fehlermeldungen.
  • Put sweep activity events: unterstützt die log_sweep-Option (Firebird 2.5.2).

Vermerk: die BLR und API Traces werden für System Audits empfohlen. Die Beschränkung der Anweisunglänge reduziert die gesamte Logdateigroße, die schnell sehr groß werden kann.

Services

  • Trace services events: (Servíces Events loggen) sollte aktiviert werden, wenn Sie das Loggen nicht auf nur eine einzelne Datenbank einschränken wollen. Standardwert ist true.
  • Service include filter
  • Service exclude filter
  • Put service attach, detach and start records: (Erfasse Serviceverbindung, -trennung und Anfangsdatensätze) setzt den log_service-Parameter auf true oder false. Standardwert ist false.
  • Put service query records: (Erfasse Service Abfragedatensätze) setzt den log_service_query-Parameter auf true oder false. Standardwert ist false.

Wenn Sie alle Optionen aktiviert oder deaktiviert haben, können Sie die Einstellungen in eine conf-Datei speichern oder klicken Sie auf dem Save this config as default-Button rechts, um die Firebird fbtrace.conf-Datei zu überschreiben.

Sie können dann beliebig viele Datenbanken für das Loggen hinzufügen. Wenn Sie damit fertig sind, klicken Sie einfach auf OK unten rechts. Wenn Sie die Output on screen-Option gewählt haben, schaltet IBExpert sofort auf die Log-Seite im TraceServiceForm. Mit einer einfachen Verbindung lösen und Datenbank verbinden können Sie Datenbankengine Aktivität gleich sehen.

Der erste geloggte Event ist TRACE_INIT mit Anzeige der Sessionnummer und des Sessionnamens. Dieser Befehl wird bei jeder neuen Servicesverbindung ausgeführt.

Die Trace Sessions können in Textform oder in einem Datengitter. Klicken Sie einfach auf Grid view oben, um die Daten in tabellarischer Form:

oder in einer Formularansicht anzusehen, oder sogar als einen Bericht zu drucken. Weitere Information zur Gitteransicht finden Sie im Tabelleneditor-Kapitel.

Im Grid-Modus das Source/Details-Fenster zeigt die Quelle und Details jedes Trace-Rekords an. Das Fenster kann mit dem Show source/details-Symbol (rechts neben dem Grid Ansicht-Button) ein- und ausgeblendet werden. Trace-Daten können auch aus dem Grid Ansicht-Modus exportiert werden.

Um zu der Textansicht zurück zu kehren, klicken Sie nochmal auf dem Gitteransicht-Symbol.

Egal mit welcher Ansicht Sie arbeiten, bietet IBExpert durch Rechtsanklicken auf einem der Register ein kleines kontextabhängiges Menü mit folgenden Optionen an:

  • Stop session (Session anhalten)
  • Stop session and close this page (Session anhalten und diese Seite schliessen)
  • New trace session (Neue Trace Session).

zurück zum Seitenanfang

Firebird Trace Manager

Es stellt sich die Frage, wie diese Information produziert wird. Jede Datenbank und Serviceverbindung enthält ihr eigenes persönliches Objekt, den Firebird Trace Manager. Der Trace Manager hat für jede Trace Session seine eigene Sessionobjekte. Es gibt einen Set Trace Services, eine davon ist die StartTrace-Session. Wenn eine Tracesession gestartet wird, wird sie in die Trace Konfigurationsspeicher platziert, wo alle Tracesessions aufbewahrt werden. Wenn eine Verbindung bestimmte Events protokollieren will, konsultiert sie den Tracekonfigurationsspeicher und startet die Tracesession in dieser bestimmten Verbindung. Sie kann auch Tracesessions anhalten und unterbrechen/wieder fortfahren. Der SYSDBA darf alle Tracesessions verwalten; ein nicht-SYSDBA Benutzer darf nur seine eigenen Sessions verwalten.

Der Trace Konfigurationsspeicher besteht aus zwei Dateien: erstens die fb_trace, die in verteiltem Speicher gemappte Kontrolldatei, und zweitens, die fb_trace_nnnn, die die Tracesession Datensätze speichert (wo nnnn der temporäre Zufallsname ist). Diese Dateien speichern alle Tracesession Datensätze. Beide Dateien befinden sich im Firebird Lockverzeichnis (Default: COMMON_APPDATA\Firebird).

Benutzer Trace Ausgabe

Der Benutzer Trace Ausgabe wird in temporären Logdateien gespeichert, jede Datei mit einer festen 1MB Große und im Firebird Lockverzeichnis gespeichert. Diese Logdateien werden direkt vom Firebird erzeugt, verwaltet und gelöscht. Die maximale Große der Zusammenfassungs-Logdatei kann im firebird.conf: MaxUserTraceLogSize = 10 (Standardwert) festgelegt werden. Da diese die Zusammenfassungsdateigroße ist, sollte die Benutzeranwendung langsamer lesen als Firebird Ausgabe produziert, wird die Session, nachdem zehn Dateien (10MB) im temporären Speicher geladen wurden, angehalten. Wenn die Benutzeranwendung noch eine Datei gelesen hat, kann sie gelöscht werden, so dass Speicherplatz freigestellt wird, und Firebird die Tracesession automatisch wieder aufnehmen kann.

Wenn ein Superserver- oder Superclassic-Prozess heruntergefahren wird, werden alle offenen Tracessessions, auch wenn sie zur Zeit des Herunterfahrens angehalten worden waren, angehalten. Diese gilt nicht dem Classic Server, da hier jede Verbindung ihre eigene dedizierte Serverinstanz hat.

Keine Serviceinstanz kann ihre startende Verbindung überleben.

System Audit Trace Ausgabe

Die Logausgabe einer System Trace Ausgabe wird einfach in Datei(en) auf der Festplatte gespeichert. Der Logdateiname wird je Datenbank oder je Service in der fbtrace.conf-Datei festgelegt. Jede Logdatei kann beim Erreichen der max_log_size in MB gewechselt werden.

fbtracemgr

Ein neues Kommandozeilentool, fbtracemgr, wurde für die interaktive Arbeit mit den Trace Services in Firebird 2.5 eingeführt. Sehen Sie bitte InterBase® and Firebird command-line utilities

Quelle: Firebird Konferenz 2009, München, Deutschland: Trace and Audit Services in Firebird 2.5, Vlad Khorsun
Dieses Dokument enthält Auszüge des deutschen Entwickler Magazin Artikels, Audit und Trace Services in Firebird 2.5. Copyright 2010 Thomas Steinmaurer.

Siehe auch:
englischsprachig:
Firebird 2.5 Trace and Audit services

zurück zum Seitenanfang
<< Server Eigenschaften/Protokolle | IBExpert | Datenbankvalidierung (Datenbankzustand) >>