Genera file di dump di diagnostica di AlloyDB Omni

Seleziona una versione della documentazione:

Genera un dump di debug di AlloyDB Omni con lo stato del sistema e i log di diagnostica per risolvere i problemi imprevisti nei tuoi deployment. I log di debug forniscono informazioni diagnostiche critiche sullo stato di AlloyDB Omni, aiutando te o il team dell'assistenza clienti Google Cloud ad analizzare i problemi relativi a errori o problemi con l'esecuzione di vari servizi dello stack AlloyDB Omni. Raccogli questi file utilizzando un ruolo Ansible o uno strumento autonomo.

Controlla i log di diagnostica a livello di orchestratore per alloydbctl e Ansible per regolare la verbosità per la risoluzione dei problemi o per silenziare l'output per gli script automatici. Questi log sono essenziali per diagnosticare i problemi durante il bootstrap, la gestione o il funzionamento generale del cluster.

Raccogli ed esegui il dump delle informazioni di debug

Puoi raccogliere ed eseguire il dump delle informazioni di debug utilizzando un ruolo Ansible o lo strumento di dump di debug.

Raccogli informazioni di debug utilizzando Ansible

Il ruolo Ansible google.alloydbomni_orchestrator.dump_debug automatizza il processo di raccolta in tutti i nodi AlloyDB Omni definiti nella specifica del deployment. Raccoglie e consolida le seguenti informazioni:

  • Stato systemd: stato attuale di tutti i servizi AlloyDB Omni.
  • Log di Journal: log di sistema che consentono l'applicazione di filtri basati sul tempo.

Genera il dump delle informazioni di debug

  1. Crea un playbook Ansible (ad esempio dump_debug.yml) sul nodo di controllo. Aggiungi quanto segue al playbook:

    - 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

    Sostituisci quanto segue:

    • ANSIBLE_USER: l'utente con cui Ansible esegue l'accesso.
    • PATH_TO_PRIVATE_SSH_KEY: il percorso del file della chiave privata SSH.
    • BINARY_PATH: (Facoltativo) Percorso dei file binari sui nodi remoti. Il valore predefinito è /usr/local/bin.
    • COLLECTION_TYPE: (Facoltativo) Il tipo di raccolta (status, logs, config o all). Il valore predefinito è all.
    • ANSIBLE_DESTINATION: (Facoltativo) Destinazione sul nodo di controllo Ansible. Il valore predefinito è /tmp/debug_dump.
    • TAG_NAME: (Facoltativo) Identificatore personalizzato. Se il tag esiste, vengono aggiunti suffissi (ad esempio _1). Il valore predefinito è il timestamp di sistema.
    • JOURNAL_SPEC: (Facoltativo) Supporta i flag journalctl (ad esempio "--since '1 hour ago'"). Il valore predefinito è -n 1000.

  2. Esegui il playbook utilizzando il comando ansible-playbook, specificando deployment_spec.yaml come inventario.

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

    In alternativa, esegui il playbook con un tag personalizzato e una specifica del journal di tua scelta.

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

    Sostituisci quanto segue:

    • PATH_TO_DEPLOYMENT_SPEC: il percorso del file YAML della specifica del deployment.
    • TAG_NAME: (Facoltativo) Identificatore personalizzato. Se il tag esiste, vengono aggiunti suffissi (ad esempio _1). Il valore predefinito è il timestamp di sistema.
    • JOURNAL_SPEC: (Facoltativo) Supporta i flag journalctl (ad esempio "--since '1 hour ago'"). Il valore predefinito è -n 1000.

Raccogli informazioni di debug utilizzando lo strumento di dump di debug

Puoi utilizzare lo strumento alloydbomni_dump per generare un file di dump. Questo strumento è incluso nel pacchetto dell'orchestratore di AlloyDB Omni.

Genera un file di dump

Esegui lo script seguente sui nodi del cluster AlloyDB Omni di cui vuoi eseguire il debug.

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

Sostituisci quanto segue:

  • SSH_KEY: il percorso della chiave privata SSH dell'utente.
  • USER: il nome utente per l'accesso SSH ai nodi del cluster.
  • PATH_TO_DEPLOYMENT_SPEC: il percorso del file YAML della specifica del deployment.
  • OUTPUT_DIRECTORY: la directory locale in cui salvare il file di dump generato.

Comandi supportati

  • -k: percorso obbligatorio della chiave privata SSH.
  • -u: nome utente dell'account di servizio richiesto.
  • -d: percorso obbligatorio del file YAML della specifica del deployment.
  • -o: directory di output obbligatoria per il file tar finale.
  • -t: identificatore facoltativo del tag personalizzato.
  • -c: tipo di raccolta facoltativo (status, logs, config, all).
  • -s: (facoltativo) specifica delle dimensioni e del tempo del journal (ad esempio, -s "--since \"30 minutes ago\"").

Esempio di esecuzione

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

Ottieni i log di diagnostica dell'orchestratore

Puoi ottenere i log di diagnostica generati dagli orchestratori alloydbctl e Ansible. In questo modo puoi aumentare il livello di dettaglio per la risoluzione dei problemi o silenziare l'output per gli script automatici. Il logging è essenziale per diagnosticare i problemi durante il bootstrap, la gestione o il funzionamento generale dei cluster.

Ottieni i log di debug di alloydbctl

Lo strumento alloydbctl supporta gli argomenti della riga di comando per controllare il livello di log e la destinazione dell'output. Il livello di log determina la gravità dei messaggi da registrare, mentre la destinazione del log specifica dove vengono scritti i log.

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

Livelli di log (-l / --log_level)

Puoi utilizzare i seguenti livelli di log. I livelli di log non fanno distinzione tra maiuscole e minuscole (ad esempio, DEBUG e debug vengono trattati allo stesso modo).

  • NOTSET (valore predefinito): nessun logging.
  • DEBUG:registra informazioni dettagliate, in genere di interesse solo durante la diagnosi dei problemi. Registra le richieste e le risposte RPC.
  • INFO: conferma che tutto funziona come previsto.
  • WARNING: indica che si è verificato un evento imprevisto (ad esempio, "spazio su disco insufficiente"), ma il software continua a funzionare.
  • ERRORE: a causa di un problema più grave, il software non è in grado di eseguire alcune funzioni.
  • CRITICAL: un errore grave, che indica che il programma stesso potrebbe non essere in grado di continuare l'esecuzione.

Destinazione log (-f / --log_file)

Puoi selezionare le seguenti destinazioni dei log:

  • Percorso file: se fornito (ad esempio -f /tmp/alloydbctl.log), i log vengono scritti nel file specificato.
  • Output standard: se non viene fornito, i log vengono stampati nella console (stdout).

Esempio

L'esempio seguente utilizza alloydbctl per applicare le specifiche di deployment e delle risorse, attivando al contempo il logging a livello di DEBUG. I log, incluse le informazioni dettagliate e le richieste/risposte RPC, vengono scritti nel file /tmp/alloydbctl_debug.log anziché nell'output standard.

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

Ottieni i log di debug di Ansible

Ansible Orchestrator genera log dalle attività e dai moduli Ansible. Puoi passare argomenti della riga di comando Ansible standard per modificare il comportamento di logging sia per le attività che per i moduli. Per informazioni più dettagliate, consulta la documentazione di ansible-playbook.

Livello di log per i moduli Ansible

Per impostazione predefinita, i log vengono inviati alla console in cui è in esecuzione il playbook.

Per impostare l'impostazione di configurazione log_level, esegui questo comando:

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

Puoi anche utilizzare i seguenti flag di livello di dettaglio standard di Ansible per controllare il livello di dettaglio dell'output:

  • -v:livello di dettaglio di base (log di livello INFO).
  • -vv o superiore: Preferenze di lettura aumentate (log di livello DEBUG).

Ad esempio:

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

Percorso di log per i moduli Ansible

Per impostazione predefinita, i log non vengono acquisiti e il livello di log deve essere configurato per acquisire i log nel file di log.

Per salvare l'output di Ansible in un file di log, esegui questo comando per impostare la configurazione di log_path:

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

Reimposta le istanze systemd con errori

Se il dump di debug mostra istanze di servizio obsolete o non riuscite, cancellale eseguendo questo comando sul nodo del cluster interessato:

sudo systemctl reset-failed

Per reimpostare un servizio systemd specifico, specifica il nome dell'istanza del servizio:

sudo systemctl reset-failed INSTANCE_NAME

Sostituisci INSTANCE_NAME con il nome dell'istanza del servizio systemd, ad esempio alloydbomni18@abc.service.