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 mit dem folgenden Befehl neu starten:

      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, in dem der Monitoring-Agent deaktiviert ist durch Standardeinstellung. 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 wurde, installieren Sie den Agent 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 Ihre Benachrichtigungsrichtlinien nicht ordnungsgemäß funktionieren, sollten Sie prüfen, ob der Agent Daten an das richtige Projekt sendet. aus. Weitere Informationen finden Sie im folgenden Abschnitt Projekt und Anmeldedaten verifizieren.

Projekt und Anmeldedaten verifizieren

Wenn der Agent Zugriffs- oder Autorisierungsfehler meldet oder der Agent anscheinend ordnungsgemäß ausgeführt wird, aber keine Daten vorhanden sind oder Ihre Benachrichtigungsrichtlinien nicht wie erwartet funktionieren, prüfen Sie, ob der Agent Die Anmeldedaten Ihrer VM-Instanz sind korrekt, auch wenn sie das richtige Projekt angeben:

  • 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 (nicht mit einem privaten Schlüssel) verwenden, ist es unwahrscheinlich, dass Daten an das falsche Projekt gesendet werden. Ihre Anmeldedaten sind jedoch eventuell noch immer fehlerhaft. 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 auf Ihrer Compute Engine-Instanz Anmeldedaten mit privatem Schlüssel verwenden, sind die Anmeldedaten möglicherweise ungültig oder stammen aus dem falschen Projekt. Bei AWS-Konten muss das vom Agent verwendete Projekt das AWS-Connector-Projekt sein. Informationen zu Anmeldedaten finden Sie unter Agent autorisieren. Informationen zum Verifizieren von Anmeldedaten finden Sie unter Anmeldedaten mit privatem Schlüssel prüfen.

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

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 möglicherweise Daten an das falsche Projekt. Informationen dazu finden 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 Liste der Instanzen angezeigt. Die ID sieht so aus: i-1a2b3c4d.

  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] Für Amazon EC2-Instanzen müssen Sie das AWS-Connector-Projekt für Ihr Amazon-Konto verwenden.

    2. Geben Sie unter filter die folgende Zeile an, um einen Agent-Messwert aus Ihrer VM-Instanz auszuwählen. Kopieren Sie die ID und fügen Sie sie in APIs Explorer ein. Ändern Sie dann 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.

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

  • Wenn Ihr API-Aufruf zu einer Fehlermeldung führt, weist dies nicht auf ein Problem mit dem Agent hin. Prüfen Sie, ob die APIs Explorer-Felder ordnungsgemäß ausgefüllt sind:

    • Fehler vom Typ "Ungültiges Argument" weisen wahrscheinlich auf ein Problem mit der Schreibweise und dem Format der Projekt-ID, des Filters oder der beiden Zeitstempel hin.

      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 alles korrekt zu sein scheint, 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 Seite VM-Instanzen, ob Ihre Compute Engine-VM-Instanz über die erforderlichen Anmeldedaten für den Monitoring-Agent verfügt. Die Anmeldedaten werden normalerweise dem Standarddienstkonto aller neuen Compute Engine-VM-Instanzen hinzugefügt. Es ist jedoch möglich, diese Standardeinstellungen beim Erstellen einer Instanz zu überschreiben.

Zur Seite "Compute Engine-Instanzen"

  1. Ändern Sie bei Bedarf das aktuelle Google Cloud-Projekt in das Compute Engine-VM-Projekt. Wenn Sie beispielsweise die Aufforderung 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 nebenStackdriver Monitoring API , einem älteren Namen für die Cloud Monitoring API,Nur Schreiben oderVoll geladen wenn Sie die erforderlichen Anmeldedaten haben.
    3. Andernfalls hat das Standarddienstkonto Ihrer Instanz nicht die vom Agent benötigten Anmeldedaten. 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 ist project_id Ihr Google Cloud-Projekt, client_email das Dienstkonto im Projekt und private_key_id. den privaten Schlüssel im Dienstkonto identifiziert. 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, das Ihre Instanz enthält.
  • 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 roles/monitoring.metricWriter (Monitoring-Messwert-Autor) für den Monitoring-Agent und roles/logging.logWriter (Logautor) 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

Falls die Anmeldedaten ungültig sind, gehen Sie so vor:

  1. Für jedes verbundene Projekt, das Instanzen enthält, die mit einem privaten Schlüssel autorisiert werden müssen (AWS-Connector-Projekte und =Projekte mit Compute Engine-Instanzen, die ohne Angabe des Bereichs erstellt wurden)monitoring.write ), erstellen Sie ein Dienstkonto und generieren Sie einen privaten Schlüssel, falls noch nicht vorhanden. Führen Sie folgende Schritte aus:

    1. Eine 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.

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

    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 sind harmlose Warnungen und sind kein Hinweis auf Datenverlust. Diese Nachrichten werden von der aktuellen Implementierung des Plug-ins für Prozesse generiert, wenn die Zeitstempel nicht übereinstimmen.

  • 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. Es ist in der Regel harmlos, kann aber ein Zeichen dafür sein, dass dem Agent nicht mehr genügend Arbeitsspeicher zur Verfügung steht. Dies gilt insbesondere dann, wenn dies häufig vorkommt.

  • Problem mit Kontingent 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 gibt an, dass das Kontingentlimit der Cloud Monitoring API erreicht wurde. Informationen zum Verwalten Ihres Kontingentlimits finden Sie im Leitfaden zu Kontingenten.

  • Hohe Speichernutzung aufgrund eines niedrigen COLLECTD_INTERVAL (Linux):

    Möglicherweise wird eine hohe Speicherauslastung des Agents angezeigt, wenn die COLLECTD_INTERVAL so konfiguriert ist, dass sie kürzer als die Standard-60 seconds ist, z. B. 10 seconds. Dies ist eine bekannte Einschränkung des Agents, da er Anfragen nacheinander aus einem einzelnen Thread sendet. Um dies zu vermeiden, können SieCOLLECTD_INTERVAL und nur für einen Teil der erforderlichen Messwerte. Für den Rest der Messwerte behalten Sie das Standardintervall bei.

Der Agent wurde 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 angezeigt wird.