Gérer et surveiller AlloyDB Omni

Sélectionnez une version de la documentation :

Cette page explique comment gérer les rôles utilisateur AlloyDB Omni, surveiller l'activité de votre serveur AlloyDB Omni, et mettre à jour ou supprimer votre installation AlloyDB Omni.

Gérer les rôles utilisateur

AlloyDB Omni utilise le même ensemble de rôles utilisateur PostgreSQL prédéfinis qu'AlloyDB pour PostgreSQL, avec les différences suivantes :

  • AlloyDB Omni inclut un rôle de super-utilisateur nommé alloydbadmin et un rôle de non-super-utilisateur nommé alloydbmetadata.

  • L'utilisateur postgres par défaut dispose d'un rôle de super-utilisateur.

  • Tous les autres rôles utilisateur prédéfinis n'ont aucun droit d'accès. Elles sont réservées pour une utilisation potentielle à l'avenir.

Configurer une base de données AlloyDB Omni

Comme pour AlloyDB pour PostgreSQL, il est recommandé de suivre ces étapes lors de la configuration d'une base de données :

  1. Définissez ou importez vos bases de données à l'aide du rôle utilisateur postgres. Dans une nouvelle installation, ce rôle dispose de privilèges de super-utilisateur et ne nécessite aucun mot de passe.

  2. Créez des rôles utilisateur disposant du niveau d'accès approprié aux tables de votre application, en utilisant à nouveau le rôle utilisateur postgres.

  3. Configurez votre application pour qu'elle se connecte à la base de données à l'aide de ces nouveaux rôles à accès limité.

Vous pouvez créer et définir autant de rôles utilisateur que nécessaire. Ne modifiez ni ne supprimez aucun des rôles utilisateur fournis avec AlloyDB Omni.

Pour en savoir plus, consultez Gérer les utilisateurs et les rôles AlloyDB Omni.

Surveiller AlloyDB Omni

La surveillance de votre installation AlloyDB Omni inclut la lecture et l'analyse des fichiers journaux AlloyDB Omni.

AlloyDB Omni exécuté sur Kubernetes fournit un ensemble de métriques de base disponibles en tant que points de terminaison Prometheus. Pour obtenir la liste des métriques disponibles, consultez Métriques AlloyDB Omni.

De plus, AlloyDB Omni exécuté sur Kubernetes expose des métriques à partir de ressources personnalisées utilisant kube-state-metrics (KSM). Pour activer les métriques de ressources personnalisées, consultez Surveiller les ressources personnalisées de l'opérateur AlloyDB Omni Kubernetes.

Serveur unique

Par défaut, pour récupérer les journaux AlloyDB Omni, exécutez la commande suivante :

Docker 

  docker logs CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Pour configurer le comportement de journalisation d'AlloyDB Omni, consultez Personnaliser votre installation AlloyDB Omni.

Podman 

  podman logs CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Pour configurer le comportement de journalisation d'AlloyDB Omni, consultez Personnaliser votre installation AlloyDB Omni.

Kubernetes

Trouver les fichiers journaux de votre cluster de bases de données

Les fichiers postgresql.audit et postgresql.log se trouvent dans le système de fichiers du pod de base de données. postgresql.audit n'est présent que si vous avez activé pgaudit.

Pour accéder à ces fichiers, procédez comme suit :

  1. Définissez une variable d'environnement contenant le nom du pod de base de données.

    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}'`

    Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données. Il s'agit du même nom de cluster de base de données que vous avez déclaré lors de sa création.

  2. Exécutez un shell sur le pod de base de données en tant que racine.

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

  3. Recherchez les fichiers journaux dans le répertoire /obs/diagnostic/ :

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

Lister les services de surveillance

v1.0

Lorsque vous créez un cluster de bases de données, AlloyDB Omni crée le service de surveillance suivant pour chaque CR d'instance du cluster de bases de données dans le même espace de noms :

al-INSTANCE_NAME-monitoring-system

Pour lister les services de surveillance, exécutez la commande suivante.

kubectl get svc -n NAMESPACE | grep monitoring

Remplacez NAMESPACE par un espace de noms auquel appartient votre cluster.

L'exemple de réponse suivant montre les services al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system et al-4bc0-dbc-monitoring-system. Chaque service correspond à une instance.

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

Version < 1.0

Lorsque vous créez un cluster de bases de données, AlloyDB Omni crée les services de surveillance suivants dans le même espace de noms que le cluster de bases de données :

  • DB_CLUSTER-monitoring-db

  • DB_CLUSTER-monitoring-system

Pour lister les services de surveillance, exécutez la commande suivante.

kubectl get svc -n NAMESPACE | grep monitoring

Remplacez NAMESPACE par un espace de noms auquel appartient votre cluster.

L'exemple de réponse suivant affiche le al-2953-dbcluster-foo7-monitoring-system et le service 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

Afficher les métriques Prometheus depuis la ligne de commande

Le port 9187 est nommé metricsalloydbomni pour tous les services de surveillance.

  1. Configurez le transfert de port de votre environnement local vers le service de surveillance.

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

    Remplacez les éléments suivants :

    • MONITORING_SERVICE : nom du service de surveillance que vous souhaitez transférer, par exemple al-1060-dbc-monitoring-system.

    • NAMESPACE : espace de noms auquel appartient votre cluster.

    • MONITORING_METRICS_PORT : port TCP local disponible.

    La réponse suivante indique que les services sont transférés.

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

  2. Pendant l'exécution de la commande précédente, vous pouvez accéder aux métriques de surveillance via HTTP sur le port que vous avez spécifié. Par exemple, vous pouvez utiliser curl pour afficher toutes les métriques en texte brut :

    curl http://localhost:MONITORING_METRICS_PORT/metrics

Afficher les métriques à l'aide de l'API Prometheus

La clé de libellé alloydbomni.internal.dbadmin.goog/task-type et le port metricsalloydbomni sont disponibles par défaut pour tous les services de surveillance dans AlloyDB Omni. Vous pouvez les utiliser avec une seule ressource personnalisée serviceMonitor pour sélectionner tous les services de tous les espaces de noms de votre cluster de bases de données.

Pour en savoir plus sur l'utilisation de l'API Prometheus, consultez la documentation Prometheus Operator.

Voici un exemple de champ spec de la ressource personnalisée serviceMonitor qui inclut la clé de libellé alloydbomni.internal.dbadmin.gdc.goog/task-type et le port metricsalloydbomni. La ressource personnalisée serviceMonitor surveille et collecte tous les services Kubernetes dans tous les espaces de noms.

Pour en savoir plus sur la définition complète de ServiceMonitor, consultez la définition de ressource personnalisée ServiceMonitor .

v1.0

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

Version < 1.0 

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

Afficher les métriques à l'aide de Grafana

Pour obtenir une représentation visuelle des métriques dans AlloyDB Omni sur Kubernetes, utilisez le tableau de bord de surveillance. Le tableau de bord de surveillance repose sur une pile d'observabilité de base composée de Prometheus et Grafana. Pour configurer le tableau de bord de surveillance afin de collecter des métriques à partir d'AlloyDB Omni, procédez comme suit :

  1. Pour télécharger le tableau de bord Grafana, utilisez la commande wget :

    wget https://raw.githubusercontent.com/GoogleCloudPlatform/alloydb-omni-samples/refs/heads/main/monitoring-dashboards/grafana/alloydbomni_dashboard.yaml

  2. Vous devez télécharger et installer grafana-operator avant de déployer Grafana dans Kubernetes. Pour obtenir des instructions détaillées, consultez Installation.

  3. Ajoutez le libellé monitoring.dashboard/product=alloydb-omni à l'instance Grafana sur laquelle vous installez le tableau de bord :

    kubectl label grafana/GRAFANA_INSTANCE_NAME monitoring.dashboard/product=alloydb-omni -n NAMESPACE

    Remplacez les éléments suivants :

    • GRAFANA_INSTANCE_NAME : nom de l'instance Grafana dans laquelle vous placez le tableau de bord.
    • NAMESPACE : espace de noms dans lequel vous avez déployé l'opérateur Grafana.

  4. Pour appliquer la configuration du tableau de bord Grafana à votre cluster AlloyDB Omni sur Kubernetes, utilisez la commande suivante :

    kubectl apply -f alloydbomni_dashboard.yaml -n NAMESPACE

    Pour en savoir plus sur l'utilisation de l'opérateur Grafana, consultez la documentation de l'opérateur Grafana.

  5. Pour configurer Grafana afin qu'il utilise Prometheus comme source de données, consultez Sources de données.

  6. Pour vérifier que Grafana est correctement configuré, effectuez l'une des opérations suivantes :

    • Consultez la collection de panneaux Grafana sur le tableau de bord AlloyDB Omni.

    • Récupérez des informations sur le tableau de bord Grafana dans un cluster Kubernetes :

      kubectl get grafanadashboard alloydb-omni-dashboard -n NAMESPACE -o jsonpath='{.status.conditions[?(@.type=="DashboardSynchronized")].status}'

      Si la commande renvoie True, cela signifie que alloydb-omni-dashboard a été déployé sur l'instance Grafana.

Mettre à niveau AlloyDB Omni

Pour passer d'AlloyDB Omni 15.5.2 ou version antérieure à la version 15.5.4, suivez les instructions de la section Migrer d'une version antérieure d'AlloyDB Omni vers la dernière version.

Pour effectuer la mise à niveau à partir de la version 15.5.4 ou ultérieure :

  1. Redémarrez AlloyDB Omni à l'aide d'une nouvelle version d'image.

  2. Veillez à spécifier votre répertoire de données pour qu'il corresponde au chemin d'accès utilisé dans les versions précédentes d'AlloyDB Omni.

Désinstaller AlloyDB Omni

Serveur unique

Pour désinstaller AlloyDB Omni, arrêtez et supprimez le conteneur AlloyDB Omni à l'aide de la commande suivante :

Docker 

 docker container stop CONTAINER_NAME
   docker container rm CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Podman 

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Podman 

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Vous pouvez déplacer, archiver ou supprimer un répertoire de données externes selon que vous souhaitez ou non conserver vos données après la désinstallation d'AlloyDB Omni.

Kubernetes

Supprimer votre cluster de bases de données

Pour supprimer votre cluster de bases de données, définissez isDeleted sur true dans son fichier manifeste. Pour ce faire, utilisez la commande suivante.

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

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données. Il s'agit du même nom de cluster de base de données que vous avez déclaré lors de sa création.

Désinstaller l'opérateur AlloyDB Omni

Pour désinstaller l'opérateur Kubernetes AlloyDB Omni de votre cluster Kubernetes, procédez comme suit :

  1. Supprimez tous vos clusters de bases de données :

    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. Attendez que l'opérateur Kubernetes AlloyDB Omni supprime tous vos clusters de bases de données. Exécutez la commande suivante pour vérifier s'il reste des ressources de base de données :

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

  3. Supprimez les autres ressources créées par l'opérateur Kubernetes AlloyDB Omni :

    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. Désinstallez l'opérateur Kubernetes AlloyDB Omni :

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

  5. Nettoyez les secrets, les descriptions de ressources personnalisées et les espaces de noms associés à l'opérateur Kubernetes AlloyDB Omni :

    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

Redimensionner votre cluster de bases de données basé sur Kubernetes

Pour redimensionner le processeur, la mémoire ou le stockage de votre cluster de bases de données basé sur Kubernetes, mettez à jour le champ resources des fichiers manifestes qui définissent son pod. L'opérateur AlloyDB Omni applique immédiatement les nouvelles spécifications à votre pod de base de données.

Pour en savoir plus sur la syntaxe du fichier manifeste de l'opérateur AlloyDB Omni, consultez Créer un cluster de bases de données.

Les restrictions suivantes s'appliquent à la modification des ressources d'un cluster de bases de données en cours d'exécution :

  • Vous ne pouvez augmenter la taille d'un disque que si le storageClass spécifié est compatible avec l'expansion de volume.
  • mais pas la réduire.