Fehlerbehebung bei der Agent-Installation

Diese Seite erleichtert Ihnen die Diagnose von Fehlern, die während der Installation oder Ausführung des Monitoring-Agents auftreten können.

Checkliste

Wenn bei der Installation oder Verwendung des Monitoring-Agents Probleme auftreten, prüfen Sie Folgendes:

  • 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 StackdriverMonitoring
      

      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 stackdriver-agent status
      

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

      sudo service stackdriver-agent restart
      

      Wenn der Neustart fehlschlägt und in der Logausgabe die Meldung "Über Metadaten deaktiviert" angezeigt wird, führen Sie wahrscheinlich ein Image über Google Cloud Marketplace aus. Dort ist der Monitoring-Agent standardmäßig deaktiviert. Das wird durch den Metadatenschlüssel der Instanz google-monitoring-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. Informationen zu diesem Vorgang finden Sie unter Agent neu installieren.

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

    • Unter Windows schreibt der Monitoring-Agent Meldungen in das Windows-Ereignislog.

    • Unter Linux ist der Monitoring-Agent ein collectd-Paket und protokolliert Nachrichten in /var/log/syslog oder /var/log/messages. Die Logeinträge haben das Präfix collectd oder stackdriver-agent:

      • Wenn Sie den HTTP-Fehler 429 erhalten, haben Sie möglicherweise Ihr Monitoring 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 Monitoring API aus.

      • Wenn Probleme mit dem Proxy auftreten, prüfen Sie, ob der HTTP-Proxy richtig konfiguriert ist. Eine Anleitung hierzu finden Sie in Unter Linux installieren bzw. Unter Windows installieren.

      • Wenn Probleme beim API-Zugriff bzw. bei der API-Autorisierung auftreten oder Fehlermeldungen wie "Unable to determine collectd endpoint" (collectd-Endpunkt kann nicht bestimmt werden) angezeigt werden, lesen Sie den folgenden Abschnitt Projekt und Anmeldedaten verifizieren.

      • Wenn in den Logs Fehler wie "Unsupported collectd plugin/type combination" (Nicht unterstützte collectd-Plug-in/Typ-Kombination) oder "Unsupported collectd id" (Nicht unterstützte collectd-ID) angezeigt werden, senden Sie unter Umständen nicht unterstützte Agent-Messwerte. Dies kann in den folgenden Fällen passieren:

        • Sie haben eine der Konfigurationen der Agent-Drittanbieteranwendung geändert. Wenn Sie die Änderungen rückgängig machen möchten, installieren Sie die Konfiguration für das jeweilige Plug-in anhand der Anleitung auf der entsprechenden Dokumentationsseite neu. Wenn Sie den Messwert mithilfe des Agents an Monitoring senden möchten, sollten Sie sie in benutzerdefinierte Messwerte umwandeln.

        • Eines der Plug-ins der Drittanbieteranwendung sendet neue Messwerte, die Monitoring unbekannt sind. Auf der Supportseite finden Sie weitere Informationen dazu, wie Sie eine Anfrage stellen können, damit diese Messwerte überprüft und kategorisiert werden.

  • Wenn der Agent scheinbar normal ausgeführt wird, Sie aber keine Daten erhalten oder die Benachrichtigungsrichtlinien nicht ordnungsgemäß funktionieren, prüfen Sie, ob der Agent Daten an das richtige Projekt sendet. Weitere Informationen finden Sie im folgenden Abschnitt Projekt und Anmeldedaten verifizieren.

Projekt und Anmeldedaten verifizieren

Wenn der Agent Zugriffs- oder Autorisierungsfehler meldet oder wenn er scheinbar normal ausgeführt wird, Sie aber keine Daten erhalten oder die Benachrichtigungsrichtlinien nicht ordnungsgemäß funktionieren, prüfen Sie, ob die Anmeldedaten für Ihre VM-Instanz korrekt sind und auf das richtige Projekt verweisen.

  • Wenn Sie feststellen möchten, ob Daten in Monitoring eingehen, prüfen Sie die Zeitachsendaten. Eine Anleitung finden Sie unter Verbindung zwischen Agent und Projekt verifizieren. Wenn Sie Daten sehen, liegt das Problem nicht beim Agent.

  • Wenn Sie eine Compute Engine-VM-Instanz mit Standardanmeldedaten ohne privaten Schlüssel verwenden, ist es unwahrscheinlich, dass Daten an das falsche Projekt gesendet werden. Es kann aber sein, dass Ihre Anmeldedaten ungültig sind. Informationen zu Anmeldedaten finden Sie unter Agent autorisieren. Informationen zum Verifizieren von Anmeldedaten finden Sie unter Compute Engine-Anmeldedaten verifizieren.

  • Wenn Sie eine Amazon EC2-VM-Instanz oder Anmeldedaten mit privatem Schlüssel für Ihre Compute Engine-Instanz verwenden, sind die Anmeldedaten möglicherweise ungültig oder vom falschen Projekt. Bei AWS-Konten muss der Agent das AWS-Connector-Projekt verwenden. Informationen zu Anmeldedaten finden Sie unter Agent autorisieren. Informationen zum Verifizieren von Anmeldedaten finden Sie unter Anmeldedaten mit privatem Schlüssel verifizieren.

Wenn das Problem weiterhin besteht, lesen Sie unter Agent neu installieren weiter.

Agent-Daten verifizieren

Wenn Sie prüfen möchten, ob der Agent Messwerte ordnungsgemäß sendet, suchen Sie mit der Methode timeSeries.list der Monitoring API nach den letzten Zeitachsendaten von der VM-Instanz. Sie können die Methode mit dem APIs Explorer auf der Dokumentationsseite der Methode aufrufen. Wenn Sie keine Daten sehen, sendet der Agent sie möglicherweise an das falsche Projekt. Wie Sie das prüfen, erfahren Sie unter Projekt und Anmeldedaten verifizieren.

Im Folgenden finden Sie eine detaillierte Anleitung zur Verwendung der Methode timeSeries.list:

  1. Ermitteln Sie die Instanz-ID der VM-Instanz, auf der Sie den Agent installiert haben:

    • Compute Engine-Instanzen: Rufen Sie die Compute Engine-Detailseite für Ihre Instanz auf. Klicken Sie unten auf der Seite auf Equivalent REST (Entsprechende REST). Die ID ist eine 19-stellige Zahl.

    • Amazon EC2-Instanzen: Die ID für jede Instanz wird in der Instanzliste angezeigt. Die ID sieht wie i-1a2b3c4d aus.

  2. Rufen Sie die Dokumentationsseite für die Methode timeSeries.list auf.

  3. Füllen Sie das APIs Explorer-Formular aus:

    1. Geben Sie unter name das Projekt mit Ihrer VM-Instanz ein. Stellen Sie dem Namen projects/ voran. Beispiel: projects/[YOUR_PROJECT_ID] Verwenden Sie bei Amazon EC2-Instanzen das AWS-Connector-Projekt für Ihr Amazon-Konto.

    2. Geben Sie unter filter die folgende Zeile an, um einen Agent-Messwert aus Ihrer VM-Instanz auszuwählen. Kopieren Sie ihn und fügen Sie ihn in APIs Explorer ein. Ändern Sie anschließend die ID der VM-Instanz:

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
      
    3. Legen Sie den Suchzeitraum fest. Verwenden Sie ein Intervall von etwa fünf Minuten.

      • Geben Sie unter interval.endTime die aktuelle GMT-Zeit an. Sie finden sie unter time.is/GMT. Die Uhrzeit muss wie im folgenden Beispiel formatiert sein. Setzen Sie die Zeit nicht in Anführungszeichen.

        2016-10-31T14:10:00Z
        
      • Stellen Sie interval.startTime auf etwa fünf Minuten vor der Endzeit ein. Verwenden Sie dabei dasselbe Format.

    4. Lassen Sie alle anderen Felder leer.

  4. Klicken Sie auf Ausführen.

Die Ausgabe sollte in etwa wie folgt aussehen:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[GCP-OR-AWS-INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Wenn der API-Aufruf wie oben gezeigt Zeitachsendaten von Ihrer VM-Instanz zurückgibt, funktioniert der Agent ordnungsgemäß und der Vorgang ist abgeschlossen.

Falls Sie keine Zeitachsendaten sehen, prüfen Sie Folgendes:

  • Wenn vom API-Aufruf eine Fehlermeldung zurückgegeben wird, weist dies nicht auf ein Agent-Problem hin. Prüfen Sie, ob die APIs Explorer-Felder ordnungsgemäß ausgefüllt sind:

    • Die Fehlermeldung "Ungültiges Argument" zeigt wahrscheinlich ein Problem mit der Rechtschreibung und dem Format der Projekt-ID, des Filters oder der beiden Zeitstempel an.

      Die Anforderungen für die Zeitstempelargumente hängen vom angegebenen Messwerttyp ab. Je nach Messwert werden GAUGE-, DELTA- oder CUMULATIVE-Daten ermittelt. Weitere Informationen finden Sie unter MetricKind.

      Bei den Messwerten vom Typ DELTA und CUMULATIVE sind sowohl Start- als auch Endzeit erforderlich. Die Endzeit muss nach der Startzeit liegen. Diese Messwerttypen erfassen Änderungen, die über einen bestimmten Zeitraum gemessen werden. Daher müssen die Start- und Endzeiten ein Intervall ungleich null definieren.

    • Die Fehlermeldung "Nicht autorisiert" kann darauf hindeuten, dass die Projekt-ID nicht richtig eingegeben wurde.

    • Die Fehlermeldung "Nicht gefunden" kann ein Hinweis darauf sein, dass im Feld "name" das erforderliche Präfix projects/ fehlt.

    Korrigieren Sie dies und wiederholen Sie den API-Aufruf.

  • Wenn der API-Aufruf erfolgreich ist, aber eine leere Antwort ({ }) zurückgegeben wird, prüfen Sie, ob der Filter und das Zeitintervall richtig sind. Falsch formatierte Zeitstempel können dazu führen, dass keine Daten zurückgegeben werden. Wenn alle Angaben scheinbar richtig sind, Sie aber keine Daten erhalten, sendet der Agent keine Messwertdaten oder zumindest nicht an das erwartete Projekt. Das kann auf fehlerhafte Anmeldedaten hindeuten. Weitere Informationen hierzu finden Sie unter Anmeldedaten mit privatem Schlüssel verifizieren.

Anmeldedaten für Compute Engine prüfen

Prüfen Sie in der Cloud Console auf der Compute Engine-Seite VM-Instanzen, ob Ihre Compute Engine-VM-Instanz die erforderlichen Anmeldedaten für den Monitoring-Agent hat. Die Anmeldedaten werden in der Regel dem Standarddienstkonto aller neuen Compute Engine-VM-Instanzen hinzugefügt, können aber beim Erstellen einer Instanz überschrieben werden.

Zur Seite "Compute Engine-Instanzen"

  1. Verwenden Sie als Google Cloud-Projekt das Projekt, das mit Ihrer Compute Engine-VM-Instanz verknüpft ist. Wenn Sie beispielsweise die Eingabeaufforderung Abrechnung aktivieren erhalten, enthält das aktuelle Projekt keine Compute Engine-VM-Instanzen.
  2. Klicken Sie auf der Seite VM-Instanzen auf den Namen Ihrer VM-Instanz. Daraufhin wird die Seite mit den Details Ihrer Instanz eingeblendet.
  3. Sehen Sie sich auf der Seite VM-Instanzdetails den Abschnitt Zugriffsbereiche für Cloud API an:
    1. Wenn "Uneingeschränkten Zugriff auf alle Cloud-APIs zulassen" angezeigt wird, haben Sie gültige Anmeldedaten.
    2. Wenn neben Stackdriver Monitoring API, einem älteren Namen für die Cloud Monitoring API, angezeigt wird, dass Sie die Berechtigung Nur Schreibzugriff oder Uneingeschränkt haben, haben Sie die erforderlichen Anmeldedaten.
    3. Andernfalls hat das Standarddienstkonto Ihrer Instanz nicht die nötigen Anmeldedaten für den Agent. Damit Sie den Agent auf Ihrer Instanz verwenden können, müssen Sie dem Dienstkonto Anmeldedaten mit privatem Schlüssel hinzufügen. Eine Anleitung finden Sie unter Anmeldedaten hinzufügen.

Wenn Sie die erforderlichen Standardanmeldedaten haben, fahren Sie mit Unter Linux installieren oder Unter Windows installieren fort.

Anmeldedaten mit privatem Schlüssel prüfen

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 gültigen 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 Google Cloud-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 ungültig, wenn eine der folgenden Bedingungen zutrifft:

  • Sie prüfen eine Compute Engine-VM-Instanz, aber das Google Cloud-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 Google Cloud-Projekt in der Datei mit den Anmeldedaten ist nicht das AWS-Connector-Projekt für Ihr AWS-Konto.
  • Das aufgeführte Dienstkonto existiert nicht. Es wurde möglicherweise gelöscht.
  • Für das aufgeführte Dienstkonto sind nicht die richtigen Rollen aktiviert. Es sollte mindestens die Rollen roles/monitoring.metricWriter (Monitoring-Messwert-Autor) für den Monitoring-Agent und roles/logging.logWriter (Log-Autor) für den Logging-Agent haben.
  • Der private Schlüssel existiert nicht. Er wurde möglicherweise widerrufen.

Wenn das Dienstkonto in Ordnung ist, aber der private Schlüssel widerrufen wurde, können Sie einen neuen privaten Schlüssel erstellen und in Ihre Instanz kopieren. Erstellen Sie andernfalls ein neues Dienstkonto, wie im folgenden Abschnitt Neue Anmeldedaten generieren beschrieben.

Neue Anmeldedaten generieren

Wenn die Anmeldedaten nicht gültig sind, führen Sie folgende Schritte aus:

  1. Erstellen Sie für jedes verbundene Projekt mit Instanzen, die mit einem privaten Schlüssel autorisiert werden müssen (AWS-Connector-Projekte und Projekte mit Compute Engine-Instanzen, die ohne den Bereich monitoring.write erstellt wurden), ein Dienstkonto und generieren Sie einen privaten Schlüssel, falls noch nicht vorhanden. Führen Sie folgende Schritte aus:

    1. Die Liste der Projekte, die mit Ihrem Messwertbereich verbunden sind, finden Sie unter Monitoring:

      Zu Monitoring

    2. Wählen Sie im Navigationsbereich "Monitoring" Einstellungen und dann den Tab Zusammenfassung aus.

      • Verwenden Sie für AWS den Link, um das betreffende Projekt direkt in der Google Cloud Console aufzurufen.
      • Identifizieren Sie für Google Cloud das Projekt, das die betreffenden Compute Engine-Ressourcen enthält, und öffnen Sie die Google Cloud Console.
    3. Gehen Sie in der Cloud Console zur Seite IAM-Dienstkonten.

    4. Erstellen Sie ein neues Dienstkonto und generieren Sie einen neuen privaten Schlüssel dafür.

      Die einfachste Methode besteht darin, einen privaten Schlüssel mit der richtigen Konfiguration herunterzuladen. Sie können diesen Schlüssel abrufen, indem Sie die URL aus der aktuellen Seite ändern: Fügen Sie &createStackdriverServiceAccount an das Ende der URL an. Weitere Informationen finden Sie unter Dienstkonto erstellen.

  2. Ersetzen Sie den privaten Schlüssel für die Instanzen, die zum betreffenden Dienstkonto gehören.

    • Ersetzen Sie unter Linux den privaten Schlüssel in /etc/google/auth/application_default_credentials.json.
    • Ersetzen Sie unter Windows den privaten Schlüssel in C:\ProgramData\Google\Auth\application_default_credentials.json. Weitere Informationen finden Sie unter Privaten Schlüssels in die Instanz kopieren.
  3. Agent neu starten

    • Führen Sie unter Linux sudo service stackdriver-agent restart aus.
    • Öffnen Sie unter Windows die Dienstverwaltungskonsole und starten Sie den Dienst Cloud Monitoring neu.

Wenn Sie mehrere Projekte haben, die neue private Schlüssel benötigen, wiederholen Sie diesen Vorgang für jedes einzelne.

Wie Sie prüfen, ob der private Schlüssel korrekt ist, erfahren Sie unter Sind die Anmeldedaten vorhanden? Beispiele:

  • Lesen Sie die JSON-Datei mit dem privaten Schlüssel auf der Instanz. Beispiel (unter Linux): sudo cat /etc/google/auth/application_default_credentials.json
  • Achten Sie darauf, dass der Wert von project-id mit dem Wert des überwachten Projekts übereinstimmt, für das Sie gerade Anmeldedaten generiert haben.

Agent neu installieren

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

Ermitteln, auf welchen Linux-VMs der Agent installiert ist

  • Führen Sie eine der folgenden Abfragen aus, um zu sehen, auf welchen Linux-VMs der Agent ausgeführt wird:

    Beachten Sie, dass Sie für jede Abfrage Ihren Projektnamen eingeben und die Zeitgrenzen anpassen müssen.

Agent automatisch neu starten

Sie können ein Skript einrichten, um zu prüfen, ob der Agent ausgeführt wird, und den Agent dann neu zu starten, falls er abgestürzt ist.

Unter Linux können Sie beispielsweise den folgenden crontab-Eintrag erstellen, um den Status des Agents alle fünf Minuten zu prüfen:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Bekannte Probleme

  • Problem mit Datenzugriff verarbeiten (Windows):

    Im Windows-Ereignisprotokoll sehen Sie möglicherweise eine Agent-Fehlermeldung wie diese:

    Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)
    

    Diese Nachricht gibt an, dass der Agent keinen Zugriff auf diese Daten in Ihrem System hat. Wenn Sie diese Meldung nicht mehr sehen möchten, können Sie dem Nutzer SYSTEM ausreichende Berechtigungen zum Lesen von Prozessdaten für die in den Fehlermeldungen aufgeführten Prozesse und Dienste erteilen. Wenn Sie diese Daten nicht benötigen, können Sie diese Informationsnachrichten ignorieren.

  • Probleme mit Metadaten-Cache (Linux):

    In der Linux-Systemlogdatei (/var/log/syslog für Debian/Ubuntu oder /var/log/messages für Red Hat/CentOS/SLES) kann eine Fehlermeldung wie die folgende angezeigt werden:

    collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
    value time = 1511345468.180; last cache update = 1511345468.180;
    write_gcm: wg_update_stats failed.
    write_gcm: uc_update returned an error.
    

    Diese Meldungen enthalten unbedenkliche Warnungen und sind kein Hinweis auf einen Datenverlust. Diese Meldungen werden von der aktuellen Prozess-Plug-in-Implementierung generiert, wenn ein Zeitstempel nicht übereinstimmt.

  • Problem mit unbegrenztem Wert, verworfenem Datenpunkt (Linux):

    In der Linux-Systemlogdatei (/var/log/syslog für Debian/Ubuntu oder /var/log/messages für Red Hat/CentOS/SLES) kann eine Fehlermeldung wie die folgende angezeigt werden:

    write_gcm: can not take infinite value
    

    Diese Meldung gibt an, dass ein einzelner fehlerhafter Datenpunkt verworfen wurde. Das ist in der Regel unbedenklich und kann ignoriert werden.

  • Problem mit der Drosselung des Metadatenschlüssels (Linux):

    In der Linux-Systemlogdatei (/var/log/syslog für Debian/Ubuntu oder /var/log/messages für Red Hat/CentOS/SLES) kann eine Fehlermeldung wie die folgende angezeigt werden:

    collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
    collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed
    

    Diese Meldung gibt an, dass die Statusaktualisierung der Speicherdrosselung einmal fehlgeschlagen ist. Sie ist in der Regel unbedenklich, könnte jedoch ein Zeichen dafür sein, dass dem Agent nicht genügend Arbeitsspeicher zur Verfügung steht, insbesondere wenn sie häufig auftritt.

  • Problem mit Kontingentüberschreitung für die Cloud Monitoring API (Linux):

    In der Linux-Systemlogdatei (/var/log/syslog für Debian/Ubuntu oder /var/log/messages für Red Hat/CentOS/SLES) kann eine Fehlermeldung wie die folgende angezeigt werden:

    collectd[25198]: write_gcm: Unsuccessful HTTP request 429
    

    Diese Meldung zeigt an, dass das Kontingentlimit der Cloud Monitoring API erreicht wurde. In der Anleitung für Kontingente finden Sie Informationen zum Verwalten Ihres Kontingentlimits.

  • Hohe Speichernutzung aufgrund eines niedrigen COLLECTD_INTERVAL (Linux):

    Wenn COLLECTD_INTERVAL so konfiguriert ist, dass es kürzer als die Standardeinstellung 60 seconds ist, z. B. 10 seconds, ist die Arbeitsspeichernutzung des Agents möglicherweise erhöht. Dies ist eine bekannte Einschränkung des Agents, da er Anfragen nacheinander aus einem einzelnen Thread sendet. Sie können dieses Problem verringern, indem Sie COLLECTD_INTERVAL nur für eine Teilmenge der erforderlichen Messwerte reduzieren und für die restlichen Messwerte das Standardintervall belassen.

Entfernter Agent wird von der Google Cloud Console als installiert gemeldet

Nachdem Sie den Agent deinstalliert haben, kann es bis zu eine Stunde dauern, bis diese Änderung in der Google Cloud Console gemeldet wird.