AlloyDB Omni の管理とモニタリング

このページでは、AlloyDB Omni ユーザーロールの管理、AlloyDB Omni サーバーのアクティビティのモニタリング、AlloyDB Omni インストールの更新または削除の方法について説明します。

ユーザーロールを管理する

AlloyDB Omni は、AlloyDB for PostgreSQL に含まれる事前定義された PostgreSQL ユーザーロールと同じセットを使用しますが、次の違いがあります。

  • AlloyDB Omni には、alloydbadmin という名前のスーパーユーザー ロールと、alloydbmetadata という名前の非スーパーユーザー ロールが含まれています。

  • デフォルトの postgres ユーザーにはスーパーユーザー ロールがあります。

  • 他の事前定義されたユーザーロールには権限がありません。将来の使用のために予約されています。

AlloyDB と同様に、データベースを設定する際は次の手順に沿うことをおすすめします。

  1. postgres ユーザーロールを使用してデータベースを定義またはインポートします。新規インストールでは、このロールにはスーパーユーザー権限があり、パスワードは必要ありません。

  2. 再度、postgres ユーザーロールを使用して、アプリケーションのテーブルへの適切なアクセス権を持つ新しいユーザーロールを作成します。

  3. これらの新しい限定アクセスロールを使用して、データベースに接続するようにアプリケーションを構成します。

新しいユーザーロールは、必要な数だけ作成して定義できます。AlloyDB Omni に付属するユーザーロールは変更または削除しないでください。

詳細については、AlloyDB Omni のユーザーとロールを管理するをご覧ください。

AlloyDB Omni をモニタリングする

AlloyDB Omni のインストールのモニタリングには、AlloyDB Omni ログファイルの読み取りと分析が含まれます。

Kubernetes で実行される AlloyDB Omni には、Prometheus エンドポイントとして使用できる一連の基本指標があります。使用可能な指標のリストについては、AlloyDB Omni の指標をご覧ください。

さらに、Kubernetes で実行されている AlloyDB Omni は、kube-state-metrics(KSM)を活用してカスタム リソースの指標を公開します。カスタム リソース指標を有効にするには、AlloyDB Omni Kubernetes オペレーター カスタム リソースをモニタリングするをご覧ください。

単一のサーバー

デフォルトでは、AlloyDB Omni のログを取得するには、次のコマンドを実行します。

Docker

  docker logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、AlloyDB Omni のインストールをカスタマイズするをご覧ください。

Podman

  podman logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、AlloyDB Omni のインストールをカスタマイズするをご覧ください。

Kubernetes

データベース クラスタのログファイルを探す

postgresql.audit ファイルと postgresql.log ファイルは、データベース Pod のファイル システムにあります。postgresql.audit は、pgaudit を有効にしている場合にのみ存在します。

これらのファイルにアクセスする手順は次のとおりです。

  1. データベース Pod の名前を含む環境変数を定義します。

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

    DB_CLUSTER_NAME は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

  2. データベース Pod でルートとしてシェルを実行します。

    kubectl exec ${DB_POD} -it -- /bin/bash
  3. /obs/diagnostic/ ディレクトリでログファイルを探します。

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

モニタリング サービスを一覧表示する

v1.0

データベース クラスタを作成すると、AlloyDB Omni は同じ Namespace 内のデータベース クラスタのインスタンス CR ごとに次のモニタリング サービスを作成します。

al-INSTANCE_NAME-monitoring-system

モニタリング サービスを一覧表示するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンスの例は、al-1060-dbc-monitoring-systemal-3de6-dbc-monitoring-systemal-4bc0-dbc-monitoring-system サービスを示しています。各サービスは 1 つのインスタンスに対応します。

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

バージョン 1.0 未満

データベース クラスタを作成すると、AlloyDB Omni はデータベース クラスタと同じ Namespace に次のモニタリング サービスを作成します。

  • DB_CLUSTER-monitoring-db

  • DB_CLUSTER-monitoring-system

モニタリング サービスを一覧表示するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンス例は、al-2953-dbcluster-foo7-monitoring-system サービスと 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

コマンドラインから Prometheus 指標を表示する

すべてのモニタリング サービスで、ポート 9187 の名前は metricsalloydbomni です。

  1. ローカル環境からモニタリング サービスへのポート転送を設定します。

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

    次のように置き換えます。

    • MONITORING_SERVICE: 転送するモニタリング サービスの名前(例: al-1060-dbc-monitoring-system)。

    • NAMESPACE: クラスタが属する Namespace。

    • MONITORING_METRICS_PORT: ローカルで使用可能な TCP ポート。

    次のレスポンスは、サービスが転送されていることを示しています。

    Forwarding from 127.0.0.1:9187 -> 9187
    Forwarding from [::1]:9187 -> 9187
    
  2. 上記のコマンドが実行されている間、指定したポートの HTTP 経由でモニタリング指標にアクセスできます。たとえば、curl を使用すると、すべての指標を書式なしテキストとして表示できます。

    curl http://localhost:MONITORING_METRICS_PORT/metrics
    

Prometheus API を使用して指標を表示する

alloydbomni.internal.dbadmin.goog/task-type ラベルキーと metricsalloydbomni ポートは、AlloyDB Omni のすべてのモニタリング サービスでデフォルトとして使用できます。これらを 1 つの serviceMonitor カスタム リソースとともに使用すると、データベース クラスタ内のすべての Namespace のすべてのサービスを選択できます。

Prometheus API の使用方法については、Prometheus Operator のドキュメントをご覧ください。

alloydbomni.internal.dbadmin.gdc.goog/task-type ラベルキーと metricsalloydbomni ポートを含む serviceMonitor カスタム リソースの spec フィールドの例を次に示します。serviceMonitor カスタム リソースは、すべての Namespace 内のすべての Kubernetes Service をモニタリングして収集します。

ServiceMonitor の完全な定義については、ServiceMonitor カスタム リソース定義をご覧ください。

v1.0

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

バージョン 1.0 未満

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

Grafana を使用して指標を表示する

Kubernetes 上の AlloyDB Omni の指標を視覚的に表示するには、モニタリング ダッシュボードを使用します。モニタリング ダッシュボードは、Prometheus と Grafana で構成される基本的なオブザーバビリティ スタックに依存しています。AlloyDB Omni から指標を収集するようにモニタリング ダッシュボードを構成する手順は次のとおりです。

  1. Grafana ダッシュボードをダウンロードするには、wget コマンドを使用します。

    wget https://raw.githubusercontent.com/GoogleCloudPlatform/alloydb-omni-samples/refs/heads/main/monitoring-dashboards/grafana/alloydbomni_dashboard.yaml
    
  2. Kubernetes に Grafana をデプロイする前に、grafana-operator をダウンロードしてインストールする必要があります。詳細な手順については、インストールをご覧ください。

  3. ダッシュボードをインストールする Grafana インスタンスに monitoring.dashboard/product=alloydb-omni ラベルを追加します。

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

    次のように置き換えます。

    • GRAFANA_INSTANCE_NAME: ダッシュボードを配置する Grafana インスタンスの名前。
    • NAMESPACE: Grafana オペレーターをデプロイした Namespace。
  4. Grafana ダッシュボード構成を Kubernetes 上の AlloyDB Omni クラスタに適用するには、次のコマンドを使用します。

    kubectl apply -f alloydbomni_dashboard.yaml -n NAMESPACE
    

    Grafana オペレーターの使用方法については、Grafana オペレーターのドキュメントをご覧ください。

  5. Prometheus をデータソースとして使用するように Grafana を構成するには、Datasources をご覧ください。

  6. Grafana が正しく構成されていることを確認するには、次のいずれかを行います。

    • AlloyDB Omni ダッシュボードで Grafana パネルのコレクションを表示します。
    • Kubernetes クラスタの Grafana ダッシュボードに関する情報を取得します。

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

      コマンドが True を返した場合、alloydb-omni-dashboard は Grafana インスタンスに正常にデプロイされています。

AlloyDB Omni をアップグレードする

AlloyDB Omni 15.5.2 以前から 15.5.4 にアップグレードするには、以前のバージョンの AlloyDB Omni から最新バージョンに移行するの手順に沿って操作します。

15.5.4 以降からアップグレードするには:

  1. 新しいイメージ バージョンを使用して AlloyDB Omni を再起動します。

  2. データ ディレクトリは、以前のバージョンの AlloyDB Omni で使用されているパスと同じになるように指定してください。

AlloyDB Omni をアンインストールする

単一のサーバー

AlloyDB Omni をアンインストールするには、次のコマンドを使用して AlloyDB Omni コンテナを停止して削除します。

Docker

 docker container stop CONTAINER_NAME
   docker container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

Podman

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

Podman

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のアンインストール後にデータを保持するかどうか、保持する場合はどのように保持するかに応じて、外部データ ディレクトリを移動、アーカイブ、削除できます。

Kubernetes

データベース クラスタを削除する

データベース クラスタを削除するには、マニフェストで isDeletedtrue に設定します。これは次のコマンドで達成できます。

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

DB_CLUSTER_NAME は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

AlloyDB Omni オペレーターをアンインストールする

Kubernetes クラスタから AlloyDB Omni Kubernetes オペレーターをアンインストールする手順は次のとおりです。

  1. すべてのデータベース クラスタを削除します。

    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. AlloyDB Omni Kubernetes オペレーターがすべてのデータベース クラスタを削除するまで待ちます。データベース リソースが残っているかどうかを確認するには、次のコマンドを使用します。

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  3. AlloyDB Omni Kubernetes オペレーターによって作成された他のリソースを削除します。

    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. AlloyDB Omni Kubernetes オペレーターをアンインストールします。

    helm uninstall alloydbomni-operator --namespace alloydb-omni-system
  5. AlloyDB Omni Kubernetes オペレーターに関連する Secret、カスタム リソースの説明、Namespace をクリーンアップします。

    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

Kubernetes ベースのデータベース クラスタのサイズを変更する

Kubernetes ベースのデータベース クラスタの CPU、メモリ、ストレージのサイズを変更するには、Pod を定義するマニフェストの resources フィールドを更新します。AlloyDB Omni オペレーターは、新しい仕様をデータベース Pod にすぐに適用します。

AlloyDB Omni オペレーター マニフェストの構文の詳細については、データベース クラスタを作成するをご覧ください。

実行中のデータベース クラスタのリソースの変更には、次の制限が適用されます。

  • ディスクのサイズを増やすことができるのは、指定された storageClass がボリュームの拡張をサポートしている場合のみです。
  • ディスクサイズの縮小はできません。