Resolva problemas do operador do Kubernetes do AlloyDB Omni

Selecione uma versão da documentação:

Esta página mostra como resolver problemas com o operador do Kubernetes do AlloyDB Omni.

Recolha informações de depuração

Estas secções descrevem como recolher registos e configurações para depuração.

Obtenha registos de pods de operador

Para obter registos dos pods do operador, execute os seguintes comandos:

kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system > alloydb-omni-system-fleet-controller-manager.out
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system > alloydb-omni-system-local-controller-manager.out

Obtenha registos de pods da base de dados

Para obter os registos do pod da base de dados, execute os seguintes comandos:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl logs -c database ${DB_POD} -n DB_CLUSTER_NAMESPACE > ${DB_POD}.log
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -c database -n DB_CLUSTER_NAMESPACE > dbcluster_DB_CLUSTER_NAME.out

Os seguintes registos são exemplos de verificações de funcionamento da base de dados bem-sucedidas:

I0813 11:01:49.210051      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196796      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196853      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.209824      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197013      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197093      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.210010      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197368      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197425      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.210416      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"

Obtenha o ficheiro postgresql.log

Para obter o postgresql.log, execute o seguinte comando:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE -it ${DB_POD} -- cat /obs/diagnostic/postgresql.log > dbcluster_DB_CLUSTER_NAME_postgresql.log

Obtenha o ficheiro YAML DBInstance

Para obter o ficheiro YAML DBInstance, execute o seguinte comando:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

Obtenha configurações e registos para cenários de HA

Para obter configurações e registos específicos de cenários de alta disponibilidade (HA), execute os seguintes comandos:

kubectl get replicationconfig.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > replicationconfig_DB_CLUSTER_NAME.yaml
kubectl get deletestandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > deletestandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > createstandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get failovers.alloydbomni.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > failovers_DB_CLUSTER_NAME.yaml

Obtenha os estados do pod e do STS

Para obter os estados do pod e do StatefulSet (STS), execute os seguintes comandos:

DB_POD=$(kubectl get pod -n DB_CLUSTER_NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod ${DB_POD} -n DB_CLUSTER_NAMESPACE > pod_${DB_POD}.out
kubectl describe statefulset -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE > statefulset_DB_CLUSTER_NAME.out

Identifique erros

Estas secções descrevem como identificar erros.

Procure o estado de erro e os códigos de erro

Para identificar o código de erro, verifique o ficheiro YAML DBCluster no estado. Consulte a documentação de códigos de erro para mais informações.

Para obter o ficheiro YAML DBCluster, execute o seguinte comando:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

Procure criticalIncidents. Esta secção contém o código de erro e um rastreio de pilha.

Seguem-se exemplos de criticalIncidents:

status:
    certificateReference:
      certificateKey: ca.crt
      secretRef:
        name: dbs-al-cert-dr-mce
        namespace: dr
    conditions:
    -   lastTransitionTime: "2024-10-07T22:46:03Z"
    ...
    criticalIncidents:
    -   code: DBSE0304
      createTime: "2024-10-03T11:50:54Z"
      message: 'Healthcheck: Health check invalid result.'
      resource:
        component: healthcheck
        location:
          group: alloydbomni.internal.dbadmin.goog
          kind: Instance
          name: bc0f-dr-mce
          namespace: dr
          version: v1
      stackTrace:
      -   component: healthcheck
        message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
          = Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
          dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
          Lag is 384837.296269 seconds, wanted 35 seconds'

Também pode obter o estado extraindo campos específicos no formato JSON:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.status.criticalIncidents}' | jq

O resultado é semelhante ao seguinte:

[
  {
    "code": "DBSE0085",
    "createTime": "2024-03-14T05:41:37Z",
    "message": "Platform: Pod is unschedulable.",
    "resource": {
      "component": "provisioning",
      "location": {
        "group": "alloydb.internal.dbadmin.goog",
        "kind": "Instance",
        "name": "b55f-testdbcluster",
        "namespace": "dbs-system",
        "version": "v1"
      }
    },
    "stackTrace": [
      {
        "component": "provisioning",
        "message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
      }
    ]
  }
]

Se a mensagem de erro se referir ao pod da base de dados, verifique as instâncias e os recursos do pod no mesmo espaço de nomes:

kubectl get instances.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > instance_DB_CLUSTER_NAME.yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE

Depure problemas de memória

Estas secções descrevem como depurar problemas de memória.

Executar e tirar um heapdump

Ative esta funcionalidade apenas para fins de resolução de problemas. Não se esqueça de a desativar depois.

Para fazer um heapdump, conclua os seguintes passos:

  1. Modifique a implementação do operador no espaço de nomes alloydb-omni-system com o nome fleet-controller-manager e local-controller-manager.
  2. Adicione o seguinte argumento ao pod --pprof-address=:8642 ou a qualquer outra porta disponível.
  3. Aguarde que o módulo do comando seja reiniciado.

  4. Encaminhar a porta anterior. Por exemplo:

    kubectl port-forward FLEET_CONTROLLER_MANAGER_POD_NAME -n alloydb-omni-system 8642:8642

  5. Noutro terminal, execute go tool pprof http://localhost:8642/debug/pprof/heap. Altere a porta para corresponder à porta anterior se não usar 8642.

  6. Estabeleça ligação ao endereço e execute comandos de resolução de problemas. Por exemplo: top.

  7. Após terminar a resolução de problemas, desfaça o passo 1 removendo o argumento e aguardando o reinício do pod.

Determinar o número de recursos que o operador está a monitorizar

Para compreender os recursos que estão em utilização, execute os seguintes comandos:

kubectl get backuprepositories -A  | wc -l
kubectl get failovers -A  | wc -l
kubectl get instancebackupplans -A  | wc -l
kubectl get instancebackups -A  | wc -l
kubectl get instancerestores -A  | wc -l
kubectl get instances -A  | wc -l
kubectl get instanceswitchovers -A  | wc -l
kubectl get lrojobs -A  | wc -l
kubectl get replicationconfigs -A  | wc -l
kubectl get sidecars -A  | wc -l
kubectl get deployments -A  | wc -l
kubectl get statefulsets -A  | wc -l
kubectl get certificates.cert-manager.io -A  | wc -l
kubectl get issuers.cert-manager.io -A  | wc -l
kubectl get configmaps -A  | wc -l
kubectl get persistentvolumeclaims -A  | wc -l
kubectl get persistentvolumes -A  | wc -l
kubectl get pods -A  | wc -l
kubectl get secrets -A  | wc -l
kubectl get services -A  | wc -l
kubectl get storageclasses.storage.k8s.io -A  | wc -l

Por exemplo, se o número de segredos for elevado, pode originar um erro Out Of Memory (OOM).

kubectl get secrets -A | wc -l

Depuração de HA avançada

Esta secção faz referência a recursos que são implementações internas. Estão sujeitas a alterações em qualquer altura e não têm compromissos de compatibilidade com versões anteriores. Aplique correções manuais apenas a problemas em bases de dados de não produção. Estes passos podem tornar a base de dados irrecuperável.

A configuração de HA do AlloyDB Omni tem três fases:

  1. Configure o servidor principal para receber uma ligação do servidor de reserva.
  2. Inicialize o standby e ligue-o ao principal.
  3. Defina as definições principais para tornar a associação síncrona.

Geralmente, o passo 2 é o mais lento. Consoante o tamanho da base de dados, pode demorar várias horas.

Cada instância que replica a instância deve ter um replicationconfig anexado. Por exemplo:

kubectl get replicationconfigs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

Exemplo de saída:

NAME                 PARENT     TYPE       ROLE         READY   HEALTHY   SYNC_U   SYNC_D   SLOT_LOG   SLOT_REPLAY
cd58-adb--58ea-adb   cd58-adb   Physical   Upstream     True    True      true
ds-58ea-adb          58ea-adb   Physical   Downstream   True    True               true

A especificação da configuração de replicação indica as definições pretendidas, enquanto o estado reflete o estado real lido a partir da base de dados. Se existir uma inconsistência entre a especificação e o estado, o controlador continua a tentar aplicar a alteração ou existe algum erro que está a impedir a aplicação da alteração. Isto reflete-se nos campos de estado.

Empregos em espera

Devem existir dois conjuntos de tarefas internas que monitorizam o fluxo de trabalho de um modo de espera:

  • createstandbyjobs.alloydbomni.internal.dbadmin.goog
  • deletestandbyjobs.alloydbomni.internal.dbadmin.goog

Se a configuração parecer estar bloqueada, veja as tarefas relacionadas com o cluster da base de dados (DBC). A tarefa pode ter mensagens de erro que explicam em que estado se encontra a configuração. As tarefas são limpas automaticamente algum tempo após a conclusão, pelo que pode não ver nenhuma tarefa se não houver nenhuma em curso.

kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

O resultado é semelhante ao seguinte:

apiVersion: alloydbomni.dbadmin.gdc.goog/v1
  kind: CreateStandbyJob
  metadata:
    creationTimestamp: "2024-11-05T03:34:26Z"
    finalizers:
    -   createstandbyjob.dbadmin.goog/finalizer
    generation: 1804
    labels:
      dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
    name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
    namespace: db
    resourceVersion: "11819071"
    uid: 1f24cedf-b326-422f-9405-c96c8720cd90
  spec:
    attempt: 3
    cleanup: false
    currentStep: SetupSynchronous
    currentStepTime: "2024-11-05T03:45:31Z"
    metadata:
      dbc: foo-ha-alloydb1-clone1
      primaryInstance: ac00-foo-ha-alloydb1-clone1
      retryError: 'etcdserver: leader changed'
      standbyInstance: 6036-foo-ha-alloydb1-clone1
    requeueTime: "2024-11-05T18:33:03Z"
    startTime: "2024-11-05T03:36:56Z"

Validação principal

A primeira coisa a verificar é se o feed principal está configurado corretamente. Deve existir um perfil de replicação para cada standby. Se isSynchronous for verdadeiro na especificação e no estado, a configuração deve estar concluída. Se isSynchronous for falso na especificação e no estado, significa que ainda não atingiu o passo 3. Veja as tarefas em espera para verificar se existem tarefas em execução e se têm mensagens de erro.

  replication:
    profiles:
    -   isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      password:
        name: ha-rep-pw-dbcluster-sample
        namespace: default
      passwordResourceVersion: "896080"
      role: Upstream
      type: Physical
      username: alloydbreplica

Verifique se a anotação disableHealthcheck é falsa. Destina-se a ser desativado apenas durante uma comutação por falha ou uma comutação.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Consultas

Para verificar se os recursos no pod da BD estão configurados corretamente, inicie sessão na base de dados como o utilizador administrador alloydbadmin. Em seguida, execute as seguintes consultas:

Ranhura de replicação

\x on
select * from pg_replication_slots;

-[ RECORD 1 ]-------+---------------------------------------------
slot_name           | d85d_dbcluster_sample
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | t
active_pid          | 250
xmin                | 16318
catalog_xmin        |
restart_lsn         | 0/CA657F0
confirmed_flush_lsn |
wal_status          | reserved
safe_wal_size       |
two_phase           | f

Um bom estado é a presença de um espaço de replicação com o mesmo nome que a instância de standby. A ausência de um slot de replicação indica que o primeiro passo de configuração não foi concluído com êxito.

Se active não for t (verdadeiro), significa que o modo de espera não está a estabelecer ligação por algum motivo (rede, modo de espera não a concluir a configuração, etc.) e é provável que a depuração tenha de continuar no lado do modo de espera.

Estatísticas de replicação

\x on
select * from pg_stat_replication;

-[ RECORD 1 ]----+----------------------------------------------------------------
pid              | 250
usesysid         | 16385
usename          | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr      | 10.54.79.196
client_hostname  | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port      | 24914
backend_start    | 2024-10-30 21:44:26.408261+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/CA64DA8
write_lsn        | 0/CA64DA8
flush_lsn        | 0/CA64DA8
replay_lsn       | 0/CA64DA8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 2
sync_state       | sync
reply_time       | 2024-11-04 22:08:04.370838+00

Se não existir, significa que não existe uma ligação ativa. O elemento sync_state deve ser sync. Se não for sync, significa que o passo final da configuração não foi concluído. A análise dos registos / tarefas deve fornecer mais detalhes.

Validação em espera

A base de dados em espera deve ter um perfil de replicação que corresponda ao mesmo perfil da base de dados principal:

  replication:
    profiles:
    -   host: 10.54.79.210
      isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      passwordResourceVersion: "896080"
      port: 5432
      role: Downstream
      type: Physical
      username: alloydbreplica

Se não existir ligação da base suplente à principal, existem duas possibilidades comuns:

  1. O modo de espera ainda está a ser configurado.
  2. O modo de espera está a receber um erro durante a configuração ou ao tentar estabelecer ligação.

Para verificar se a opção 1 está a ocorrer, obtenha os registos do pod da base de dados e procure declarações de registo com o nome dbdaemon/setupPhysicalReplicationDownstream. Seguem-se alguns exemplos de registos de configuração bem-sucedidos:

I1104 22:42:42.604871     103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590     103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403     103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440     103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749     103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783     103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565     103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621     103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689     103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838     103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732     103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"

Se existir um erro de ligação, verifique os registos do pod da base de dados, bem como o ficheiro de registo na base de dados em /obs/diagnostic/postgresql.log e veja qual é o erro ao tentar estabelecer ligação. Um erro comum é não existir conetividade de rede entre o sistema em espera e o sistema principal.

Correções manuais

A forma mais fácil de corrigir problemas de HA é desativar e, em seguida, reativar a HA definindo numberOfStandbys como 0 e, em seguida, repondo-o para o número pretendido. Se os standbys estiverem sempre desativados, siga estes passos para repor manualmente a configuração de HA para ficar vazia:

  1. Elimine manualmente as instâncias de espera.

  2. Faça a ligação à base de dados principal. Consulte os slots de replicação atuais e elimine os slots de replicação de standbys que quer eliminar:

    select pg_drop_replication_slot('REPLICATION_SLOT_NAME');

  3. Elimine todos os perfis de replicação da instância principal que quer eliminar.

Se uma instância não tiver sido reconciliada recentemente, pode editar o valor da anotação.forceReconcile Defina-o para qualquer valor numérico, que é o carimbo de data/hora da última atualização da anotação. O único objetivo dessa anotação é fornecer um campo que podemos atualizar para forçar uma nova conciliação.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Recolha o motor de base de dados e os registos de auditoria

Os registos do motor da base de dados e os registos de auditoria estão disponíveis como ficheiros no pod da base de dados (que requer acesso de raiz):

  • obs/diagnostic/postgresql.log
  • obs/diagnostic/postgresql.audit
DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE ${DB_POD} -it -- /bin/bash

Quando estiver ligado ao contentor da base de dados:

ls -l /obs/diagnostic/

Exemplo de saída:

drwx--S--- 2 postgres postgres    4096 Aug 13 10:22 archive
-rw------- 1 postgres postgres  256050 Aug 13 13:25 postgresql.internal
-rw------- 1 postgres postgres 1594799 Aug 13 13:25 postgresql.log

Recolha métricas de bases de dados e pods de bases de dados

O operador do AlloyDB Omni fornece um conjunto de métricas básicas para o motor do AlloyDB Omni e o pod que o aloja. As métricas estão disponíveis como pontos finais do Prometheus na porta 9187. Para aceder aos pontos finais, tem de identificar o nome do pod para o pod da base de dados através da etiqueta DBCluster e iniciar o encaminhamento de portas da seguinte forma:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward -n DB_CLUSTER_NAMESPACE ${DB_POD} 9187:9187

Aceda às métricas do pod da base de dados

Noutro terminal:

curl http://localhost:9187/metrics | grep HELP

Para mais informações sobre a monitorização, consulte o artigo Monitorize o AlloyDB Omni.

Também pode configurar o Prometheus para extrair as métricas no seu cluster do Kubernetes. Consulte a configuração de deteção de serviços do Prometheus Kubernetes para ver detalhes.