Monitoring-Agent – Fehlerbehebung

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 Monitoring-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 Google 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 Monitoring-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 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 Monitoring-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 Google Cloud-Projekt verwenden, an das Sie die Messwerte senden. Informationen zu Anmeldedaten finden Sie unter Monitoring-Agent autorisieren. Informationen zum Verifizieren von Anmeldedaten finden Sie unter Anmeldedaten mit privatem Schlüssel verifizieren.

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

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.

Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

Zu Seite VM-Instanzen

Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Compute Engine lautet.

  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:
    • Wenn "Uneingeschränkten Zugriff auf alle Cloud-APIs zulassen" angezeigt wird, haben Sie gültige Anmeldedaten.
    • 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.
    • 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. Bisher gültige Anmeldedaten können Sie in der Google Cloud Console unter IAM & Verwaltung > Dienstkonten widerrufen. 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 das Feld 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 Google 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 Google Cloud-Projekt, an das Sie die Messwerte aus Ihrem AWS-Konto senden.
  • 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 die Messwerterfassung und roles/logging.logWriter (Log-Autor) für das Schreiben von Protokollen 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 – Projekte mit Compute Engine-Instanzen, die ohne den Zugriffs-Bereich https://www.googleapis.com/auth/monitoring.write erstellt wurden – ein Dienstkonto und generieren Sie einen privaten Schlüssel, falls noch nicht vorhanden. Führen Sie die
      Schritte unten aus:

    1. Öffnen Sie in der Google Cloud Console die Seite Einstellungen.

      Einstellungenaufrufen

      Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

    2. Wählen Sie den Tab Messwertumfang aus.
    3. Identifizieren Sie das Projekt, das die betreffenden Compute Engine-Ressourcen enthält, und öffnen Sie die Google Cloud Console.
    4. Rufen Sie in der Google Cloud Console die Seite IAM-Dienstkonten auf, wählen Sie Ihr Google Cloud-Projekt aus, erstellen Sie ein neues Dienstkonto und generieren Sie dann einen neuen privaten Schlüssel dafür.

      Um diese Schritte auszuführen, tun Sie eines der folgenden:

      • Rufen Sie die Seite IAM-Dienstkonten auf, wählen Sie Ihr Google Cloud-Projekt aus und folgen Sie der Anleitung unter Dienstkonto erstellen:

        IAM-Dienstkonten aufrufen

      • Klicken Sie auf die folgende Schaltfläche und wählen Sie Ihr Google Cloud-Projekt aus:

        Dienstkonto erstellen und Schlüssel herunterladen

        Mit der vorherigen Schaltfläche wird das Erstellen und Herunterladen eines Schlüssels für das agentenspezifische Dienstkonto auf Ihr lokales System automatisiert. Falls notwendig, wird dabei auch das erforderliche Dienstkonto erstellt und dafür gesorgt, dass es die richtigen Berechtigungen hat. Kundenservicemitarbeiterspezifische Dienstkonten haben einen Namen wie stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Sie werden über den Abschluss dieser Aktionen in einem Dialogfeld wie diesem informiert:

        Ein Banner, das den Nutzer darüber informiert, dass ein Dienstkonto und ein Schlüssel erstellt wurden.

  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 Linux den privaten Schlüssel in C:\ProgramData\Google\Auth\application_default_credentials.json. Weitere Informationen finden Sie unter Privaten Schlüssel 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-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]

    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 so aussehen:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[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.

Monitoring-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

In den folgenden Abschnitten werden Probleme beschrieben, die dem Monitoring-Agent bekannt sind.

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.

Problem mit Token-Pufferüberlauf (Linux)

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

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Diese Meldungen geben an, dass der Monitoring-Agent auf Version 6.1.2 oder höher aktualisiert werden muss.

Der "Ursprung"-Wert des Repositorys wurde geändert (Linux)

Möglicherweise erhalten Sie eine Fehlermeldung ähnlich der folgenden, wenn Sie den Agent aktualisieren, den Agent installieren oder apt-get update unter Debian/Ubuntu Linux ausführen:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Diese Meldung gibt an, dass der Cache des Paket-Repositorys möglicherweise von der Quelle abweicht. Führen Sie hierzu den folgenden Befehl aus: 

apt-get --allow-releaseinfo-change update

Führen Sie dann das Upgrade oder die Installation noch einmal aus.

Entfernter Agent 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.

Monitoring-Agent wird nicht in Windows angezeigt Programmliste deinstallieren

Führen Sie uninstall.exe in dem Verzeichnis aus, in dem Sie den Agent installiert haben, um den Monitoring-Agent zu deinstallieren, wenn er nicht in der Liste Programm deinstallieren der Windows-Systemsteuerung aufgeführt ist.