Améliorer l'observabilité à l'aide de métriques de surveillance personnalisées

Sélectionnez une version de la documentation :

Vous pouvez utiliser des métriques personnalisées dans l'opérateur Kubernetes AlloyDB Omni pour définir et collecter des métriques spécifiques à une application en exécutant des requêtes SQL sur vos bases de données. Les métriques personnalisées utilisent la ressource personnalisée ObservabilityConfig pour définir les règles de collecte des métriques.

Configurer des métriques personnalisées à l'aide d'ObservabilityConfig

Le CR ObservabilityConfig se compose de deux sections principales, dbClusterRefs et customMetrics.

dbClusterRefs

Cette section contient une liste de références aux ressources DBCluster auxquelles s'applique cette configuration. Chaque ObservabilityConfig doit cibler un DBCluster dans le même espace de noms.

customMetrics

Cette section définit la configuration de base pour la collecte de métriques personnalisées, y compris les limites de ressources et les définitions de requêtes.

Limites de ressources (resourceLimits)

Pour protéger la base de données, le système applique des limites aux requêtes personnalisées. Si vous ne spécifiez pas ces limites dans le fichier manifeste, le système utilise les valeurs par défaut listées dans le tableau suivant.

Paramètre Description Par défaut Max Unités
workMemory Spécifie la valeur work_mem pour la connexion de base de données spécifique utilisée par l'agent de surveillance pour collecter ces métriques. Ce paramètre est local au processus de collecte des métriques et n'a aucune incidence sur le paramètre work_mem global configuré dans la spécification DBCluster. 4MB N/A KB, MB (par défaut : KB)
maxParallelWorkers Spécifie max_parallel_workers_per_gather pour la connexion à la base de données spécifique utilisée par l'agent de surveillance. Définissez cette valeur sur 0 pour désactiver l'exécution de requêtes parallèles et minimiser l'impact sur le processeur. Ce paramètre est local au processus de collecte des métriques et n'a aucune incidence sur la configuration globale de la base de données. 0 N/A Integer
statementTimeout Spécifie le statement_timeout pour la connexion de base de données spécifique utilisée par l'agent de surveillance. Cela limite la durée maximale d'exécution de chaque requête de métrique. Ce paramètre est local au processus de collecte des métriques et n'a aucune incidence sur la configuration globale de la base de données. 2s 30s ms, s (par défaut : ms)

Définitions de métriques personnalisées (definitions)

Chaque entrée de la liste definitions définit une requête et décrit comment interpréter ses résultats.

  • metricGroup : nom unique (en minuscules, avec des chiffres et des traits de soulignement) utilisé pour nommer les métriques.
  • database : nom de la base de données cible pour la requête. L'agent de surveillance établit une connexion à cette base de données spécifique pour exécuter la requête. Par conséquent, le schéma interrogé doit y exister.
  • query : instruction SQL SELECT valide. Seules les requêtes SELECT sont autorisées.
  • metrics : liste mappant les colonnes de résultats SQL aux types Prometheus :
    • usage: label : utilise la valeur de la colonne comme libellé Prometheus.
    • usage: gauge : exporte la valeur en tant que métrique jauge Prometheus.
    • usage: counter : exporte la valeur en tant que métrique de compteur Prometheus.

Sécurité et autorisations

L'opérateur AlloyDB Omni utilise l'utilisateur alloydbmonitor pour collecter les métriques. Par défaut, l'opérateur AlloyDB Omni crée cet utilisateur avec l'attribut LOGIN et lui attribue le rôle pg_monitor dans la base de données postgres.

Lorsque vous ajoutez des métriques personnalisées, assurez-vous que cet utilisateur dispose des autorisations supplémentaires appropriées :

  • Responsabilité de l'utilisateur : les administrateurs de base de données doivent accorder manuellement les droits SELECT à l'utilisateur alloydbmonitor pour toutes les tables, vues ou schémas d'application spécifiques utilisés dans vos requêtes personnalisées.
  • Vérification de sécurité des droits d'écriture : pour garantir l'intégrité du système et éviter toute modification accidentelle des données, l'opérateur AlloyDB Omni effectue une vérification de sécurité. Si le système constate que l'utilisateur alloydbmonitor dispose de droits d'écriture (par exemple, INSERT, UPDATE et DELETE) sur une base de données cible, il enregistre une erreur et refuse de collecter des métriques personnalisées à partir de cette base de données.

Exemple d'octroi d'autorisations

Pour accorder un accès en lecture seule à toutes les tables du schéma public d'une base de données nommée warehousedb, vous devez exécuter la commande suivante :

psql -h <var>DB_CLUSTER_ENDPOINT</var> -U <var>DB_ADMIN_USER</var> -d warehousedb
warehousedb=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO alloydbmonitor;

Exemple de fichier manifeste

L'exemple de fichier manifeste suivant configure l'agent de surveillance pour qu'il se connecte à la base de données postgres et qu'il suive les statistiques de transaction à l'aide de la vue système pg_stat_database.

apiVersion: alloydbomni.dbadmin.goog/v1
kind: ObservabilityConfig
metadata:
  name: obs-metrics
spec:
  dbClusterRefs:
    - dbcluster-sample
  customMetrics:
    resourceLimits:
      workMemory: "4MB"
      maxParallelWorkers: 0
    definitions:
      - metricGroup: database
        database: "postgres"
        query: |
          SELECT
            curr_db, xact_commit, xact_rollback
          FROM pg_stat_database WHERE datname IS NOT NULL
        metrics:
          - name: curr_db
            desc: "Database name"
            usage: label
          - name: xact_commit
            desc: "Transactions committed"
            usage: counter
          - name: xact_rollback
            desc: "Transactions rolled back"
            usage: counter

Documentation de référence sur les métriques

Cette section fait référence aux métriques générées par la fonctionnalité de métriques personnalisées.

Résultats des métriques générées

Cet exemple de fichier manifeste exporte les métriques au format Prometheus suivant :

# HELP alloydb_omni_custom_database_xact_commit_total Transactions committed
# TYPE alloydb_omni_custom_database_xact_commit_total counter
alloydb_omni_custom_database_xact_commit_total{database="postgres",curr_db="testdb1",dbcluster="dbcluster-sample",dbcluster_type="Primary",dbinstance="n/a",dbinstance_type="n/a",dbnamespace="mc",dbnode="76d3-dbcluster-sample",dbnode_type="Primary"} 382069 1774388549568
# HELP alloydb_omni_custom_database_xact_rollback_total Transactions rolled back
# TYPE alloydb_omni_custom_database_xact_rollback_total counter
alloydb_omni_custom_database_xact_rollback_total{database="postgres",curr_db="testdb1",dbcluster="dbcluster-sample",dbcluster_type="Primary",dbinstance="n/a",dbinstance_type="n/a",dbnamespace="mc",dbnode="76d3-dbcluster-sample",dbnode_type="Primary"} 4364 1774388549568

Libellés standards

Chaque métrique personnalisée inclut automatiquement les libellés standards suivants : database, dbcluster, dbcluster_type, dbinstance, dbinstance_type, dbnamespace, dbnode et dbnode_type. Pour en savoir plus sur ces libellés, consultez Libellés de métriques AlloyDB Omni.

Métriques de collecte de métriques

Ces métriques indiquent l'état de chaque cycle de collecte de métriques. Vous trouverez des messages d'erreur détaillés, y compris la requête spécifique qui a expiré ou échoué, dans les journaux du conteneur de l'agent de surveillance.

# HELP alloydb_omni_monitor_custom_metrics_errors_total Total number of errors encountered during execution of the custom query
# TYPE alloydb_omni_monitor_custom_metrics_errors_total counter
alloydb_omni_monitor_custom_metrics_errors_total{metricGroup="database",dbcluster="dbcluster-sample",dbnode="...",...} 0 1773703411350

Avant d'utiliser des métriques personnalisées, tenez compte des points suivants :

  • Seules les instructions SELECT sont autorisées. Le système rejette toute instruction qui tente de modifier des données. Exécutez et vérifiez manuellement les résultats et les performances de votre requête avant de les inclure dans la configuration des métriques personnalisées.
  • Concevez chaque requête SQL pour qu'elle renvoie un nombre minimal de lignes de résultats. Nous vous recommandons de spécifier moins de cinq lignes et une seule ligne. Cela permet de s'assurer que les métriques et les libellés dérivés des résultats de la requête n'entraînent pas une cardinalité excessive, ce qui peut avoir un impact négatif sur les performances du système de surveillance.
  • Optimisez les requêtes et assurez-vous qu'elles ne nécessitent pas de ressources excessives. Utilisez resourceLimits pour protéger votre base de données.
  • Chaque requête doit renvoyer des lignes avec une combinaison unique de valeurs de libellé.