AlloyDB Omni-Diagnose-Dumpdateien generieren

Wählen Sie eine Dokumentationsversion aus:

Generieren Sie einen AlloyDB Omni-Fehlerbehebungs-Dump mit Systemstatus und Diagnoselogs, um unerwartete Probleme in Ihren Bereitstellungen zu beheben. Die Debugging-Logs enthalten wichtige Diagnoseinformationen zum Status von AlloyDB Omni, mit denen Sie oder das Cloud Customer Care-Team Probleme im Zusammenhang mit Fehlern oder Problemen bei der Ausführung verschiedener Dienste des AlloyDB Omni-Stacks analysieren können. Erfassen Sie diese Dateien entweder mit einer Ansible-Rolle oder einem eigenständigen Tool.

Steuern Sie die Diagnoseprotokolle auf Orchestrierungsebene für alloydbctl und Ansible, um die Ausführlichkeit für die Fehlerbehebung anzupassen oder die Ausgabe für automatisierte Skripts zu unterdrücken. Diese Logs sind für die Diagnose von Problemen während des Cluster-Bootstraps, der Verwaltung oder des allgemeinen Betriebs unerlässlich.

Debugging-Informationen erfassen und ausgeben

Sie können Debugging-Informationen entweder mit einer Ansible-Rolle oder dem Debugging-Dump-Tool erfassen und ausgeben.

Debugging-Informationen mit Ansible erfassen

Die Ansible-Rolle google.alloydbomni_orchestrator.dump_debug automatisiert den Erfassungsprozess für alle AlloyDB Omni-Knoten, die in Ihrer Bereitstellungsspezifikation definiert sind. Die folgenden Informationen werden erfasst und konsolidiert:

  • Systemd-Status: aktueller Status aller AlloyDB Omni-Dienste.
  • Journalprotokolle: Systemprotokolle, die zeitbasiertes Filtern ermöglichen.

Dump von Debug-Informationen generieren

  1. Erstellen Sie ein Ansible-Playbook (z. B. dump_debug.yml) auf Ihrem Steuerungsknoten. Fügen Sie dem Playbook Folgendes hinzu:

    - name: Collect AlloyDB Omni Debug Dump
  hosts: all
  become: true
  gather_facts: true
  vars:
    ansible_user: ANSIBLE_USER
    ansible_ssh_private_key_file: PATH_TO_PRIVATE_SSH_KEY
    # Optional: Customize dump behavior
    dump_debug_binary_path: "BINARY_PATH"
    dump_debug_collection_type: "COLLECTION_TYPE"
    dump_debug_local_dest: ""ANSIBLE_DESTINATION""
    dump_debug_tag: ""TAG_NAME""
    dump_debug_journal_spec: "JOURNAL_SPEC"
  roles:
    - role: google.alloydbomni_orchestrator.dump_debug

    Ersetzen Sie Folgendes:

    • ANSIBLE_USER: Der Nutzer, als der sich Ansible anmeldet.
    • PATH_TO_PRIVATE_SSH_KEY: Der Pfad zur privaten SSH-Schlüsseldatei.
    • BINARY_PATH: Optional. Pfad zu Binärdateien auf Remote-Knoten. Die Standardeinstellung ist /usr/local/bin.
    • COLLECTION_TYPE: Optional. Der Sammlungstyp (status, logs, config oder all). Standardmäßig all.
    • ANSIBLE_DESTINATION: Optional. Ziel auf dem Ansible-Steuerungsknoten. Die Standardeinstellung ist /tmp/debug_dump.
    • TAG_NAME: Optional. Benutzerdefinierte Kennung. Suffixe (z. B. _1) werden hinzugefügt, wenn das Tag vorhanden ist. Die Standardeinstellung ist der Systemzeitstempel.
    • JOURNAL_SPEC: Optional. Unterstützt journalctl-Flags (z. B. "--since '1 hour ago'"). Die Standardeinstellung ist -n 1000.

  2. Führen Sie das Playbook mit dem Befehl ansible-playbook aus und geben Sie Ihre deployment_spec.yaml als Inventar an.

    # standard execution
ansible-playbook dump_debug.yml -i PATH_TO_DEPLOYMENT_SPEC

    Alternativ können Sie das Playbook mit einem benutzerdefinierten Tag und einer Journal-Spezifikation Ihrer Wahl ausführen.

    ansible-playbook dump_debug.yml -i PATH_TO_DEPLOYMENT_SPEC \
-e 'dump_debug_tag=TAG_NAME' \
-e 'dump_debug_journal_spec: "JOURNAL_SPEC"'

    Ersetzen Sie Folgendes:

    • PATH_TO_DEPLOYMENT_SPEC: Der Pfad zur YAML-Datei mit der Bereitstellungsspezifikation.
    • TAG_NAME: Optional. Benutzerdefinierte Kennung. Suffixe (z. B. _1) werden hinzugefügt, wenn das Tag vorhanden ist. Die Standardeinstellung ist der Systemzeitstempel.
    • JOURNAL_SPEC: Optional. Unterstützt journalctl-Flags (z. B. "--since '1 hour ago'"). Standardmäßig auf -n 1000 festgelegt.

Debugging-Informationen mit dem Debug-Dump-Tool erfassen

Mit dem Tool alloydbomni_dump können Sie eine Dump-Datei generieren. Dieses Tool ist im AlloyDB Omni-Orchestrator-Paket enthalten.

Dumpdatei generieren

Führen Sie das folgende Skript auf den AlloyDB Omni-Clusterknoten aus, die Sie debuggen möchten.

sudo /usr/local/bin/alloydbomni_dump \
   -k SSH_KEY \
   -u USER \
   -d PATH_TO_DEPLOYMENT_SPEC \
   -o OUTPUT_DIRECTORY \
   [options]

Ersetzen Sie Folgendes:

  • SSH_KEY: Der Pfad zum privaten SSH-Schlüssel des Nutzers.
  • USER: Der Nutzername für den SSH-Zugriff auf die Clusterknoten.
  • PATH_TO_DEPLOYMENT_SPEC: Der Pfad zur YAML-Datei mit der Bereitstellungsspezifikation.
  • OUTPUT_DIRECTORY: Das lokale Verzeichnis, in dem die generierte Dumpdatei gespeichert werden soll.

Unterstützte Befehle

  • -k: Erforderlicher Pfad zum privaten SSH-Schlüssel.
  • -u: Erforderlicher Nutzername des Dienstkontos.
  • -d: Erforderlicher Pfad zur YAML-Datei mit der Bereitstellungsspezifikation.
  • -o: Erforderliches Ausgabeverzeichnis für die endgültige TAR-Datei.
  • -t: Optionale benutzerdefinierte Tag-ID.
  • -c: Optionaler Sammlungstyp (status, logs, config, all).
  • -s: Optionale Angabe der Journalgröße und -zeit (z. B. -s "--since \"30 minutes ago\"").

Beispiel für die Ausführung

alloydbomni_dump -k /home/user/ssh-key \
  -u sa_12345 -d /tmp/deployment_spec.yaml \
  -o /tmp/debug_dump -s "--since \"2 hours ago\""

Diagnoseprotokolle des Orchestrators abrufen

Sie können die Diagnoseprotokolle abrufen, die sowohl von alloydbctl- als auch von Ansible-Orchestratoren generiert werden. So können Sie die Ausführlichkeit für die Fehlerbehebung erhöhen oder die Ausgabe für automatisierte Skripts deaktivieren. Logging ist für die Diagnose von Problemen während des Bootstrappings, der Verwaltung oder des allgemeinen Betriebs Ihrer Cluster unerlässlich.

alloydbctl-Debugging-Logs abrufen

Das alloydbctl-Tool unterstützt Befehlszeilenargumente, um die Logebene und das Ausgabeziel zu steuern. Die Logebene bestimmt den Schweregrad der zu protokollierenden Nachrichten, während das Logziel angibt, wohin diese Logs geschrieben werden.

alloydbctl [command] ... [{-l|--log_level} <LEVEL>] [{-f|--log_file} <FILE>]

Protokollebenen (-l / --log_level)

Sie können die folgenden Logebenen verwenden. Bei Logebenen wird die Groß-/Kleinschreibung nicht berücksichtigt. DEBUG und debug beispielsweise werden also gleich behandelt.

  • NOTSET (Standard): Kein Logging.
  • DEBUG: Protokolliert detaillierte Informationen, die in der Regel nur bei der Diagnose von Problemen von Interesse sind. Protokolliert RPC-Anfragen und -Antworten.
  • INFO: bestätigt, dass alles wie erwartet funktioniert.
  • WARNUNG: Ein Hinweis darauf, dass etwas Unerwartetes passiert ist (z. B. „Speicherplatz niedrig“), die Software aber weiterhin funktioniert.
  • FEHLER: Aufgrund eines schwerwiegenderen Problems kann die Software eine bestimmte Funktion nicht ausführen.
  • KRITISCH: Ein schwerwiegender Fehler, der darauf hinweist, dass das Programm möglicherweise nicht weiter ausgeführt werden kann.

Logziel (-f / --log_file)

Sie können die folgenden Logziele auswählen:

  • Dateipfad: Wenn angegeben (z. B. -f /tmp/alloydbctl.log), werden Logs in die angegebene Datei geschrieben.
  • Standardausgabe: Wenn nicht angegeben, werden Logs in der Console (stdout) ausgegeben.

Beispiel

Im folgenden Beispiel wird alloydbctl verwendet, um Bereitstellungs- und Ressourcenspezifikationen anzuwenden und gleichzeitig das Logging auf DEBUG-Ebene zu aktivieren. Die Logs, einschließlich detaillierter Informationen und RPC-Anfragen/-Antworten, werden in die Datei /tmp/alloydbctl_debug.log anstelle der Standardausgabe geschrieben.

alloydbctl apply -d deployment_spec.yaml -r resource_spec.yaml -l DEBUG -f /tmp/alloydbctl_debug.log

Ansible-Debugging-Logs abrufen

Der Ansible Orchestrator generiert Logs aus Ansible-Aufgaben und Ansible-Modulen. Sie können standardmäßige Ansible-Befehlszeilenargumente übergeben, um das Logging-Verhalten für Aufgaben und Module zu ändern. Weitere Informationen finden Sie in der Dokumentation zu ansible-playbook.

Logebene für Ansible-Module

Standardmäßig werden Logs an die Console gesendet, in der das Playbook ausgeführt wird.

Führen Sie den folgenden Befehl aus, um die Konfigurationseinstellung log_level festzulegen:

ansible-playbook -i inventory.yaml bootstrap.yaml \
  -e resource_spec=resource_spec.yaml \
  -e log_level=DEBUG

Sie können auch die folgenden standardmäßigen Ansible-Ausführlichkeits-Flags verwenden, um die Ausführlichkeit der Ausgabe zu steuern:

  • -v: Grundlegende Ausführlichkeit (Logs auf INFO-Ebene).
  • -vv oder höher: Erhöhte Ausführlichkeit (Logs auf DEBUG-Ebene).

Beispiel:

ansible-playbook -i inventory.yaml bootstrap.yaml \
  -e resource_spec=resource_spec.yaml \
  -vv

Logpfad für Ansible-Module

Standardmäßig werden keine Logs erfasst. Die Logebene muss konfiguriert werden, damit Logs in der Logdatei erfasst werden.

Führen Sie den folgenden Befehl aus, um die Ansible-Ausgabe in einer Logdatei zu speichern und die Konfiguration log_path festzulegen:

ansible-playbook -i inventory.yaml bootstrap.yaml \
  -e resource_spec=resource_spec.yaml \
  -e log_file=/tmp/ansible-module.log

Fehlgeschlagene systemd-Instanzen zurücksetzen

Wenn der Debug-Dump veraltete, fehlgeschlagene Dienstinstanzen enthält, löschen Sie sie, indem Sie den folgenden Befehl auf dem betroffenen Clusterknoten ausführen:

sudo systemctl reset-failed

Wenn Sie einen bestimmten systemd-Dienst zurücksetzen möchten, geben Sie den Namen der Dienstinstanz an:

sudo systemctl reset-failed INSTANCE_NAME

Ersetzen Sie INSTANCE_NAME durch den Namen der systemd-Dienstinstanz, z. B. alloydbomni18@abc.service.