Fehlerbehebung beim Agent

Auf dieser Seite finden Sie Anleitungen zur Behebung häufiger Probleme bei der Installation des Logging-Agents und bei der Interaktion mit diesem.

Checkliste

Wenn Sie Probleme bei der Installation oder Verwendung des Logging-Agents haben, sollten Sie Folgendes prüfen:

  • Wenn Sie unter Linux bei Installationsbefehlen Fehlermeldungen erhalten, prüfen Sie, ob den Installationsbefehlen sudo vorangestellt wurde.

  • Prüfen Sie, ob der Agent auf Ihrer VM-Instanz ausgeführt wird:

    • Verwenden Sie für eine Windows-VM den folgenden PowerShell-Befehl:

      Get-Service -Name StackdriverLogging
      

      Suchen Sie nach einem Dienst namens Stackdriver Monitoring. Wenn der Agent nicht ausgeführt wird, müssen Sie ihn möglicherweise neu starten.

    • Verwenden Sie für eine Linux-VM den folgenden Befehl:

      sudo service google-fluentd status
      

      Wenn der Agent nicht ausgeführt wird, müssen Sie ihn unter Umständen neu starten. Führen Sie dazu den folgenden Befehl aus:

      sudo service google-fluentd restart
      

      Wenn der Neustart fehlschlägt und in der Logausgabe die Meldung "Über Metadaten deaktiviert" angezeigt wird, führen Sie möglicherweise ein Image über Google Cloud Marketplace aus. In Google Cloud Marketplace ist der Logging-Agent standardmäßig deaktiviert. Das wird durch den Metadatenschlüssel der Instanz google-logging-enable (mit dem Wert 0) gesteuert. Sie müssen diesen Schlüssel entweder entfernen oder den Wert auf 1 setzen (siehe Metadaten der Instanz festlegen), um den Agent wieder zu aktivieren.

      Wenn der Agent nicht über Metadaten deaktiviert ist, installieren Sie ihn neu. Weitere Informationen finden Sie im folgenden Abschnitt Agent neu installieren.

  • Prüfen Sie, ob der Agent Fehlermeldungen in Logs geschrieben hat.

    • Unter Windows, ab Version v1-9, speichert der Logging-Agent seine Logs im Verzeichnis C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      Es gibt keine Möglichkeit, die Logs für frühere Versionen des Agents abzurufen.

    • Unter Linux ist der Logging-Agent ein fluentd-Paket und protokolliert Nachrichten in /var/log/google-fluentd/google-fluentd.log:

      • Wenn Sie den HTTP-Fehler 429 erhalten, haben Sie möglicherweise Ihr Logging API-Kontingent überschritten. Sie können Ihr verfügbares Kontingent ansehen, wenn Sie in der Cloud Console APIs & Dienste > Dashboard auswählen. Wählen Sie die Logging API aus.

      • Wenn beim API-Zugriff oder der Autorisierung Probleme auftreten, wechseln Sie zu Compute Engine Anmeldedaten überprüfen.

  • Wenn der Agent scheinbar normal ausgeführt wird, Sie aber keine Daten erhalten, prüfen Sie, ob der Agent Daten an das richtige Projekt sendet. Weitere Informationen finden Sie im folgenden Abschnitt Compute Engine Anmeldedaten überprüfen.

Agent-Installation überprüfen

Um zu überprüfen, ob die Installation erfolgreich war, suchen Sie in der Loganzeige den Testeintrag des Agents.

Zur Loganzeige

  1. Wählen Sie oben auf der Seite das Projekt mit der VM-Instanz aus:

    • Wählen Sie für Compute Engine-VM-Instanzen das Projekt mit der VM-Instanz aus.
    • Wählen Sie für Amazon EC2-VM-Instanzen das Projekt AWS LINK aus. Dieses wird von Cloud Monitoring erstellt, wenn Sie Ihr AWS-Konto mit einem Arbeitsbereich verknüpfen.
    • Wählen Sie kein Arbeitsbereich-Projekt aus, es sei denn, das Projekt enthält Ihre Compute Engine-VM-Instanz.
  2. Wählen Sie in den Windows-Tabs die Ressource für Ihre VM-Instanz aus:

    • Wählen Sie für Compute Engine die GCE-VM-Instanz aus.
    • Wählen Sie für Amazon EC2 die AWS EC2-Instanz aus.
    • Wählen Sie für Linux syslog, für Windows fluent.info oder allgemein Alle Logs aus.

Wenn Sie den Logeintrag "Successfully sent gRPC to Logging API" (gRPC erfolgreich an Logging API gesendet) sehen, ist die Agent-Installation abgeschlossen. Diese Nachricht wird bei der Installation des Agents und bei jedem Neustart des Agents einmal generiert.

Weitere Informationen zur Loganzeige finden Sie unter Logs ansehen.

Agent testen

Wenn Sie vermuten, dass der Agent nicht funktioniert, senden Sie eine Testnachricht an Logging:

Linux-Instanz

Das folgende Verfahren funktioniert sowohl auf Compute Engine- als auch Amazon EC2-VM-Instanzen, die unter Linux ausgeführt werden:

  1. Überprüfen Sie mit den folgenden Befehlen für Ihre VM-Instanz, ob der Stackdriver Logging-Agent ausgeführt wird:

    ps ax | grep fluentd
    

    Die Ausgabe sollte in etwa so aussehen:

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
     2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
    
  2. Senden Sie mit dem folgenden Befehl für die VM-Instanz eine Test-Lognachricht:

    logger "Some test message"
    

Windows-Instanz

Der Stackdriver Logging-Agent hat zwei Windows-Dienstnamen:

  • StackdriverLogging für Versionen ab v1-5
  • fluentdwinsvc für frühere Versionen

Sie sollten einen Agent-Dienst ausführen. Führen Sie die folgenden Befehle über PowerShell für die VM-Instanz aus:

  1. Fragen Sie den Status beider Dienste ab. Wenn Sie wissen, welcher Dienst ausgeführt werden soll, reicht es, wenn Sie nur dessen Dienstnamen verwenden:

    Get-Service StackdriverLogging,fluentdwinsvc
    
  2. Wenn ein Dienst nicht ausgeführt wird, erhalten Sie eine Fehlermeldung. Wird er ausgeführt, sehen Sie in etwa folgende Ausgabe:

    Status    Name                DisplayName
    ------    ----                -----------
    Running  StackdriverLogging   Cloud Logging
    
  3. Wenn Sie beide Dienste abfragen, sollten Sie eine Fehlermeldung und einen Status Running sehen:

    • Wenn Sie den Status Running nicht sehen, wird der Logging-Agent nicht ausgeführt.
    • Wenn Sie sehen, dass StackdriverLogging ausgeführt wird, haben Sie eine aktuelle Agent-Version. Wie Sie die spezielle Version ermitteln, erfahren Sie unter Version abrufen.
    • Wenn fluentdwinsvc ausgeführt wird, sollten Sie den Agent auf die neueste Version upgraden.
  4. Erfordert Administratorrechte: Wenn eine Agent-Version ausgeführt wird, senden Sie mit den folgenden PowerShell-Befehlen eine Test-Lognachricht:

    New-EventLog   -LogName Application -Source "Test Source"
    Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."
    

Testnachricht suchen

Suchen Sie die gesendete Testnachricht in der Loganzeige:

Zur Loganzeige

  1. Wählen Sie oben auf der Seite das Projekt mit der VM-Instanz aus:

    • Wählen Sie für Compute Engine-VM-Instanzen das Projekt mit der VM-Instanz aus.
    • Wählen Sie für Amazon EC2-VM-Instanzen das Projekt AWS LINK aus. Dieses wird von Cloud Monitoring erstellt, wenn Sie Ihr AWS-Konto mit einem Arbeitsbereich verknüpfen.
    • Wählen Sie kein Arbeitsbereich-Projekt aus, es sei denn, das Projekt enthält Ihre Compute Engine-VM-Instanz.
  2. Wählen Sie in den Windows-Tabs die Ressource für Ihre VM-Instanz aus:

    • Wählen Sie für Compute Engine die GCE-VM-Instanz aus.
    • Wählen Sie für Amazon EC2 die AWS EC2-Instanz aus.
    • Wählen Sie für Linux syslog, für Windows fluent.info oder allgemein Alle Logs aus.
  3. Sie sollten einen Logeintrag mit Ihrer Testnachricht sehen. Wenn dies der Fall ist, arbeitet der Logging-Agent ordnungsgemäß.

Compute Engine-Anmeldedaten überprüfen

Damit eine Compute Engine-VM-Instanz den Agent ohne Anmeldedaten mit privatem Schlüssel ausführen kann, muss die Instanz geeignete Zugriffsbereiche haben, und die von der Instanz verwendete Dienstkontoidentität benötigt die geeigneten Cloud IAM-Berechtigungen.

Wenn Sie eine VM-Instanz erstellen, reichen die Standardeinstellungen für Bereich und Dienstkonto aus, um die Agents auszuführen. Sehr alte Instanzen oder Instanzen, für die Sie die Standardeinstellungen geändert haben, haben möglicherweise nicht die geeigneten Anmeldedaten.

Zugriffsbereiche überprüfen

Führen Sie die folgenden Schritte aus, um die Zugriffsbereiche zu überprüfen:

  1. Öffnen Sie die Seite Compute Engine > VM-Instanzen:

    Zur Seite "VM-Instanzen"

  2. Klicken Sie auf den Namen Ihrer VM-Instanz. Daraufhin wird die Detailseite für Ihre Instanz eingeblendet.

  3. Klicken Sie im Abschnitt Zugriffsbereiche für Cloud API auf Details, um die Liste der APIs aufzurufen. Suchen Sie nach den folgenden Einträgen:

    1. Wenn Sie die Meldung "Diese Instanz hat uneingeschränkten API-Zugriff auf alle Google Cloud-Dienste" sehen, reichen Ihre Zugriffsbereiche aus.
    2. Wenn neben Cloud Logging API die Berechtigung Nur Schreibzugriff oder Vollständiger Zugriff angegeben ist, sind die Zugriffsbereiche Ihrer Instanz für den Cloud Logging-Agent geeignet.
    3. Wenn neben Cloud Monitoring API die Berechtigung Schreibzugriff oder Vollständiger Zugriff angezeigt wird, sind die Zugriffsbereiche Ihrer Instanz für den Cloud Monitoring-Agent geeignet.

Problem beheben

Wenn in Ihrer Compute Engine-Instanz keine geeigneten Zugriffsbereiche vorhanden sind, fügen Sie der Instanz die erforderlichen Zugriffsbereiche hinzu.

Die folgende Tabelle zeigt die für die Logging- und Monitoring-Agents relevanten Bereiche:

Zugriffsbereich Agent-Berechtigungen
https://www.googleapis.com/auth/logging.write Für den Logging-Agent ausreichend
https://www.googleapis.com/auth/monitoring.write Für den Monitoring-Agent ausreichend

Standardmäßige Dienstkontoberechtigung prüfen

Auch wenn die Zugriffsbereiche Ihrer Compute Engine-VM-Instanz ausreichend sind, hat das Standarddienstkonto Ihrer Instanz möglicherweise nicht die richtigen Cloud IAM-Berechtigungen für den Agent.

Um die Berechtigung des Standarddienstkontos zu prüfen, suchen Sie zuerst nach dem Standarddienstkonto:

  1. Öffnen Sie das Compute Engine-Dashboard für Ihr Projekt:

    Seite mit Compute Engine-Instanzen öffnen

  2. Klicken Sie auf den Namen Ihrer VM-Instanz. Daraufhin wird die Detailseite für Ihre Instanz eingeblendet.

  3. Suchen Sie auf der Seite nach der Überschrift Dienstkonto. Das Standarddienstkonto für die Instanz ist aufgeführt. Es könnte so aussehen:

    [ID]-compute@developer.gserviceaccount.com
    
  4. Öffnen Sie die Seite IAM & Verwaltung > IAM für Ihr Projekt. Die Seitenüberschrift lautet Berechtigungen für das Projekt [PROJECT_NAME]:

    Zur Seite IAM

  5. Wählen Sie Ansehen nach: Mitglieder aus. Sie sollten eine Liste mit Personen, Gruppen und Dienstkonten sehen. In der Spalte Rolle finden Sie die Rollen, die jedes Mitglied in Ihrem Projekt hat.

  6. In der Zeile für das Standarddienstkonto Ihrer Instanz sollten eine oder mehrere Rollen angezeigt werden:

    • Wenn Bearbeiter angezeigt wird, ist diese Rolle für alle Agents geeignet. Bearbeiter ist die Standardrolle, die Dienstkonten für Compute Engine zugewiesen ist.
    • Wenn Sie Logautor sehen, reicht diese Rolle für den Logging-Agent aus. Informationen zu weiteren Logging-Rollen mit Schreibberechtigung finden Sie unter Zugriffssteuerung für Cloud Logging.
    • Wenn Sie Monitoring-Messwert-Autor sehen, reicht diese Rolle für den Monitoring-Agent aus. Weitere Monitoring-Rollen mit Schreibberechtigung finden Sie unter Zugriffssteuerung für Cloud Monitoring.

Problem beheben

Wenn Ihr Standarddienstkonto nicht über ausreichende Rollen verfügt, versuchen Sie, die Rollen für Ihr Dienstkonto auf der Seite IAM & Verwaltung > IAM zu bearbeiten. Fügen Sie die entsprechenden Logging- oder Monitoring-Rollen hinzu, um die Agents zu autorisieren: Logging > Log-Autor oder Monitoring > Monitoring-Messwert-Autor.

Anmeldedaten mit privatem Schlüssel prüfen

Auf Compute Engine-VM-Instanzen können Sie den Agent so konfigurieren, dass er ein nicht standardmäßiges Dienstkonto verwendet, das über die erforderliche Berechtigung verfügt. Bei AWS EC2-VM-Instanzen müssen Sie den Agent für die Verwendung eines solchen Dienstkontos konfigurieren.

Um den Agent auf diese Weise zu konfigurieren, müssen Sie für das angegebene Dienstkonto Anmeldedaten für den privaten Schlüssel erstellen und diese Anmeldedaten dem Agent zuweisen. Der Agent sucht auf zweierlei Weise nach den Anmeldedaten:

  1. Der Agent sucht nach einer Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS mit dem Namen einer Datei, die die Anmeldedaten für den privaten Schlüssel enthält.
  2. Wenn die Umgebungsvariable nicht vorhanden ist, sucht der Agent nach Anmeldedaten in einer Standarddatei:

Linux

 /etc/google/auth/application_default_credentials.json

Windows

C:\ProgramData\Google\Auth\application_default_credentials.json

Die folgenden Informationen helfen Ihnen, Probleme mit den Anmeldedaten für private Schlüssel zu erkennen:

  1. Ist der private Schlüssel vorhanden?
  2. Ist der private Schlüssel für das Dienstkonto noch gültig?
  3. Hat das Dienstkonto die Rollen, die für den Agent benötigt werden?

Zur Bestätigung, dass auf Ihrer VM-Instanz gültige Anmeldedaten mit privatem Schlüssel vorhanden sind, prüfen Sie zuerst, ob sich die Datei mit den Anmeldedaten am erwarteten Speicherort befindet. Bestätigen Sie anschließend, dass die Informationen in der Datei mit den Anmeldedaten gültig sind. Zuvor gültige Anmeldedaten können in der Cloud Console im Abschnitt IAM & Verwaltung > Dienstkonten widerrufen werden. Wenn keine Anmeldedaten vorhanden sind, ersetzen Sie wie unter Anmeldedaten hinzufügen beschrieben die bestehenden Anmeldedaten oder fügen Sie neue hinzu.

Sind die Anmeldedaten vorhanden?

Führen Sie zur Prüfung, ob auf Ihrer Instanz Anmeldedaten mit privatem Schlüssel für das Dienstkonto vorhanden sind, die folgenden Linux-Befehle darauf aus:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Wenn mit einem der Befehle eine Datei mit folgendem Inhalt aufgerufen wird, verfügt Ihre Instanz unter Umständen über gültige Anmeldedaten mit privatem Schlüssel. Wenn beide Befehle eine Datei zurückgeben, wird die Datei mit der Bezeichnung GOOGLE_APPLICATION_CREDENTIALS verwendet.

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY@DEVELOPER].gserviceaccount.com",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Wenn keine Datei mit Anmeldedaten vorhanden ist, fahren Sie unter Anmeldedaten hinzufügen fort.

Sind die Anmeldedaten gültig?

In der Datei mit den Anmeldedaten bezieht sich project_id auf Ihr GCP-Projekt, client_email auf das Dienstkonto des Projekts und private_key_id auf den privaten Schlüssel im Dienstkonto. Passen Sie diese Informationen an die Angaben in der Cloud Console unter IAM & Verwaltung > Dienstkonten an.

Die Datei mit den Anmeldedaten ist nicht gültig, wenn eine der folgenden Bedingungen zutrifft:

  • Sie prüfen eine Compute Engine-Instanz, aber das GCP-Projekt in der Datei mit den Anmeldedaten ist nicht das Projekt, in dem Ihre Instanz enthalten ist.
  • Sie prüfen eine Amazon EC2-Instanz, aber das GCP-Projekt in der Datei mit den Anmeldedaten ist nicht das Verbindungsprojekt (mit der Bezeichnung AWS Link...) für Ihr AWS-Konto.
  • Das aufgeführte Dienstkonto existiert nicht. Es wurde möglicherweise gelöscht.
  • Im aufgeführten Dienstkonto sind nicht die richtigen Rollen aktiviert: Log-Autor für den Cloud Logging-Agent und Monitoring-Messwert-Autor für den Cloud Monitoring-Agent.
  • Der private Schlüssel existiert nicht. Er wurde möglicherweise widerrufen.

Wenn das Dienstkonto korrekt ist, aber der private Schlüssel widerrufen wurde, können Sie einen neuen privaten Schlüssel erstellen und ihn in Ihre Instanz kopieren. Siehe Dienstkontoschlüssel erstellen.

Andernfalls müssen Sie wie im Abschnitt Anmeldedaten hinzufügen beschrieben ein neues Dienstkonto erstellen.

Agent neu installieren

Die Installation der aktuellen Agent-Version kann zahlreiche Probleme lösen:

Weitere häufig auftretende Probleme

In der folgenden Tabelle sind einige häufig auftretende Probleme aufgeführt, die beim Umgang mit dem Cloud Logging-Agent auftreten können. Hier erfahren Sie, wie sich diese beheben lassen.

Unter Linux werden Fehlermeldungen des Logging-Agents in /var/log/google-fluentd/google-fluentd.log aufgezeichnet. Unter Windows werden Fehlermeldungen des Logging-Agents in C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log aufgezeichnet (ab Version v1-9). Die Fehlerklasse Google::APIClient::ClientError gibt an, dass ein Problem hinsichtlich der Berechtigungen oder des API-Zugriffs vorliegt.

Etwaige Fehlermeldungen werden angezeigt, sobald der Agent erfolgreich ausgeführt wird. Ein Fehler wird beispielsweise ausgegeben, wenn ein Nutzer die erforderlichen Berechtigungen für Ihr Projekt oder Ihre VM-Instanz aufgehoben hat.

Fehler Ursache Lösung
Das Agent-Installationsprogramm kann nicht unter Windows ausgeführt werden. Möglicherweise haben Sie das Installationsprogramm in ein Systemverzeichnis heruntergeladen. Verschieben Sie das Installationsprogramm in ein Verzeichnis außerhalb des Systemverzeichnisses, z. B. C:\Users\[USERID]\.
Die API wurde nicht für das Projekt aktiviert. Sie haben die Cloud Logging API in Ihrem Projekt nicht aktiviert. Rufen Sie die API Console auf und ändern Sie den Status der Cloud Logging API in EIN.
Die Anfrage weist ungültige Anmeldedaten auf
oder
das Zugriffstoken kann nicht abgerufen werden (möglicherweise sind keine Bereiche konfiguriert).
Ihre VM-Instanz hat keine geeigneten Anmeldedaten. Wenn Sie Amazon EC2 verwenden, müssen Sie vor der Installation des Agents Anmeldedaten auf Ihren VM-Instanzen installieren. Wie Sie Anmeldedaten installieren, erfahren Sie unter Agent autorisieren.
Die Autorisierung ist fehlgeschlagen. Ihre Anmeldedaten mit privatem Schlüssel für den Stackdriver Logging-Agent sind nicht richtig konfiguriert. Weitere Informationen erhalten Sie unter Anmeldedaten mit privatem Schlüssel prüfen.
Das Dienstkonto hat keine Berechtigung. Die Berechtigungen des in Ihrem Projekt für die Autorisierung verwendeten Dienstkontos sind unzureichend. Dabei kann es sich um das in Compute Engine oder App Engine verwendete Standarddienstkonto oder ein benutzerdefiniertes Dienstkonto handeln, das Sie für die Autorisierung mit einem privaten Schlüssel verwenden. Das Konto muss Bearbeitungsberechtigungen haben. Ändern Sie die Berechtigung des Dienstkontos auf der Seite IAM für Ihr Projekt. Bei Bedarf können Sie den Zugriffsbereich für eine vorhandene VM ändern. Dazu ändern Sie die Dienstkonto- und Zugriffsbereiche für eine Instanz.
Die Projekt-ID kann nicht abgerufen werden. Der Cloud Logging-Agent konnte die Projekt-ID nicht aus der Datei mit den Anmeldedaten mit privatem Schlüssel eines Dienstkontos abrufen. Wenn Sie eine Projekt-ID für den Agent hinzufügen oder überschreiben möchten, bearbeiten Sie die Konfigurationsdatei des Agents, /etc/google-fluentd/google-fluentd.conf, in Ihrer VM-Instanz. Fügen Sie im Abschnitt <match **> die folgende Zeile ein:
project_id [YOUR_PROJECT_ID]
Wie Sie stattdessen die Anmeldedaten korrigieren oder ersetzen können, erfahren Sie unter Agent autorisieren.
Der Logging-Agent stoppt die Aufnahme von Logs bei Vorhandensein von Logrotate Wenn Logrotate mit der Einstellung copytruncateeingerichtet wurde, ist es möglich, dass der Logging-Agent den Überblick darüber verliert, an welcher Stelle er sich gerade bei den Eingabedateien befindet. Verwenden Sie am besten die Einstellung nocopytruncate, um sicherzustellen, dass Logrotate die Dateien verschiebt und nicht kürzt. Wenn Sie die Einstellung copytruncate beibehalten möchten, können Sie das Problem umgehen. Dazu starten Sie den Agent von Zeit zu Zeit neu. Alternativ können Sie den Agent mit der Einstellung postrotate neu starten.

Maximale Loggröße überschritten

Wenn ein oder mehrere Logeinträge die maximale Größe überschreiten, werden in den fluentd-Logs möglicherweise Einträge wie die folgenden angezeigt:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"


oder
Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

Um diesen Fehler zu beheben, sollten Sie Ihre Logeinträge so kürzen, dass sie die maximale Größe nicht überschreiten. Mit dem folgenden Beispielcode werden beispielsweise Logs mit dem Tag mytag mit den Daten im Feld message gekürzt:

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>