Faça a gestão e a monitorização do AlloyDB Omni

Selecione uma versão da documentação:

Esta página descreve como gerir as funções de utilizador do AlloyDB Omni, monitorizar a atividade do seu servidor AlloyDB Omni e atualizar ou remover a sua instalação do AlloyDB Omni.

Faça a gestão das funções de utilizador

O AlloyDB Omni usa o mesmo conjunto de funções de utilizador do PostgreSQL predefinidas que o AlloyDB inclui, com as seguintes diferenças:

  • O AlloyDB Omni inclui uma função de superutilizador denominada alloydbadmin e uma função de não superutilizador denominada alloydbmetadata.

  • O utilizador postgres predefinido tem uma função de superutilizador.

  • Todas as outras funções de utilizador predefinidas não têm privilégios. Estão reservados para potenciais utilizações no futuro.

Tal como no AlloyDB, é uma prática recomendada seguir estes passos quando configurar uma base de dados:

  1. Defina ou importe as suas bases de dados com a postgres função de utilizador. Numa nova instalação, esta função tem privilégios de superutilizador e não requer palavra-passe.

  2. Crie novas funções de utilizador com o nível de acesso correto às tabelas da sua aplicação, novamente através da função de utilizador postgres.

  3. Configure a sua aplicação para se ligar à base de dados através destas novas funções de acesso limitado.

Pode criar e definir todas as novas funções de utilizador de que precisar. Não modifique nem elimine nenhuma das funções de utilizador com as quais o AlloyDB Omni é fornecido.

Para mais informações, consulte o artigo Gerir funções de utilizador do AlloyDB.

Monitorize o AlloyDB Omni

A monitorização da instalação do AlloyDB Omni implica a leitura e a análise dos respetivos ficheiros de registo.

Para ver uma lista das métricas disponíveis, consulte Métricas do AlloyDB Omni.

O AlloyDB Omni em execução no Kubernetes também tem um conjunto de métricas básicas disponíveis como pontos finais do Prometheus.

Kubernetes

Encontre os ficheiros de registo do cluster da base de dados

Pode encontrar os ficheiros postgresql.audit e postgresql.log no sistema de ficheiros do pod da base de dados. Para aceder a estes ficheiros, siga estes passos:

  1. Defina uma variável de ambiente que contenha o nome do pod da base de dados.

    export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

    Substitua DB_CLUSTER_NAME pelo nome do cluster da base de dados. É o mesmo nome do cluster da base de dados que declarou quando o criou.

  2. Execute um shell no pod da base de dados como raiz.

    kubectl exec ${DB_POD} -it -- /bin/bash

  3. Encontre os ficheiros de registo no diretório /obs/diagnostic/:

    • /obs/diagnostic/postgresql.audit
    • /obs/diagnostic/postgresql.log

Apresente serviços de monitorização

v1.0

Quando cria um cluster de base de dados, o AlloyDB Omni cria o seguinte serviço de monitorização para cada CR de instância do cluster de base de dados no mesmo espaço de nomes:

al-INSTANCE_NAME-monitoring-system

Para listar os serviços de monitorização, execute o seguinte comando.

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um espaço de nomes ao qual o seu cluster pertence.

A resposta de exemplo seguinte mostra os serviços al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system e al-4bc0-dbc-monitoring-system. Cada serviço corresponde a uma instância.

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

Versão < 1.0

Quando cria um cluster de base de dados, o AlloyDB Omni cria os seguintes serviços de monitorização no mesmo espaço de nomes que o cluster de base de dados:

  • DB_CLUSTER-monitoring-db

  • DB_CLUSTER-monitoring-system

Para listar os serviços de monitorização, execute o seguinte comando.

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um espaço de nomes ao qual o seu cluster pertence.

A resposta de exemplo seguinte mostra o serviço al-2953-dbcluster-foo7-monitoring-system e o serviço al-2953-dbcluster-foo7-monitoring-db.

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

Veja métricas do Prometheus a partir da linha de comandos

A porta 9187 é denominada metricsalloydbomni para todos os serviços de monitorização.

  1. Configure o encaminhamento de portas do seu ambiente local para o serviço de monitorização.

    kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni

    Substitua o seguinte:

    • MONITORING_SERVICE: o nome do serviço de monitorização que quer encaminhar, por exemplo, al-1060-dbc-monitoring-system.

    • NAMESPACE: o espaço de nomes ao qual o cluster pertence.

    • MONITORING_METRICS_PORT: Uma porta TCP disponível local.

    A resposta seguinte mostra que os serviços estão a ser encaminhados.

    Forwarding from 127.0.0.1:9187 -> 9187
Forwarding from [::1]:9187 -> 9187

  2. Enquanto o comando anterior é executado, pode aceder às métricas de monitorização através de HTTP na porta que especificou. Por exemplo, pode usar curl para ver todas as métricas como texto simples:

    curl http://localhost:MONITORING_METRICS_PORT/metrics

Veja métricas através da API Prometheus

A chave de etiqueta alloydbomni.internal.dbadmin.goog/task-type e a porta metricsalloydbomni estão disponíveis por predefinição para todos os serviços de monitorização no AlloyDB Omni. Pode usá-los em conjunto com um único recurso personalizado serviceMonitor para selecionar todos os serviços para todos os espaços de nomes no cluster da base de dados.

Para mais informações sobre a utilização da API Prometheus, consulte a documentação do operador Prometheus.

Segue-se um exemplo do campo spec do recurso personalizado serviceMonitor que inclui a chave da etiqueta alloydbomni.internal.dbadmin.gdc.goog/task-type e a porta metricsalloydbomni. O recurso personalizado serviceMonitor monitoriza e recolhe todos os serviços do Kubernetes em todos os espaços de nomes

Para mais informações sobre a definição completa de ServiceMonitor, consulte a definição de recursos personalizados de ServiceMonitor .

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

Versão < 1.0 

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

Atualize o AlloyDB Omni

Para atualizar do AlloyDB Omni 15.5.2 ou anterior para a versão 15.5.4, siga as instruções em Migre de uma versão anterior do AlloyDB Omni para a versão mais recente.

Para atualizar a partir da versão 15.5.4 e posteriores:

  1. Reinicie o AlloyDB Omni com uma nova versão da imagem.

  2. Certifique-se de que especifica o diretório de dados para corresponder ao mesmo caminho usado em versões anteriores do AlloyDB Omni.

Desinstale o AlloyDB Omni

Kubernetes

Elimine o cluster da base de dados

Para eliminar o cluster da base de dados, defina isDeleted como true no respetivo manifesto. Pode fazê-lo com o seguinte comando.

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

Substitua DB_CLUSTER_NAME pelo nome do cluster da base de dados. É o mesmo nome do cluster da base de dados que declarou quando o criou.

Desinstale o AlloyDB Omni Operator

Para desinstalar o operador do Kubernetes do AlloyDB Omni do seu cluster do Kubernetes, siga estes passos:

  1. Elimine todos os clusters de base de dados:

    for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
done
done

  2. Aguarde que o operador do Kubernetes do AlloyDB Omni elimine todos os clusters de base de dados. Use o seguinte comando para verificar se restam recursos da base de dados:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

  3. Elimine outros recursos que o operador do Kubernetes do AlloyDB Omni criou:

    kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

  4. Desinstale o operador do Kubernetes do AlloyDB Omni:

    helm uninstall alloydbomni-operator --namespace alloydb-omni-system

  5. Limpe os segredos, as descrições de recursos personalizados e os espaços de nomes relacionados com o AlloyDB Omni Kubernetes Operator:

    kubectl delete certificate -n alloydb-omni-system --all
kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
kubectl delete crd -l alloydb-omni=true
kubectl delete ns alloydb-omni-system

Redimensione o cluster de base de dados baseado no Kubernetes

Para redimensionar a CPU, a memória ou o armazenamento do cluster de base de dados baseado no Kubernetes, atualize o campo resources dos manifestos que definem o respetivo pod. O operador do AlloyDB Omni aplica imediatamente as novas especificações ao seu pod da base de dados.

Para mais informações sobre a sintaxe do manifesto do operador AlloyDB Omni, consulte o artigo Crie um cluster de base de dados.

Aplicam-se as seguintes restrições à modificação dos recursos de um cluster de base de dados em execução:

  • Só pode aumentar o tamanho de um disco se o storageClass especificado suportar a expansão do volume.
  • Não pode diminuir o tamanho de um disco.