Présentation
Ce check permet de surveiller Snowflake via l’Agent Datadog. Snowflake est un entrepôt de données analytique fourni en tant que SaaS et s’exécute entièrement sur une infrastructure cloud.
Cette intégration permet de surveiller l’utilisation des crédits, la facturation, le stockage, l’historique des requêtes et bien plus encore.
Remarque : les métriques sont recueillies par le biais de requêtes envoyées à Snowflake. Les requêtes transmises par l'intégration Datadog sont susceptibles d'être facturées par Snowflake.
Configuration
Suivez les instructions ci-dessous pour installer et configurer ce check lorsque l’Agent est exécuté sur un host.
Installation
Le check Snowflake est inclus avec le package de l’Agent Datadog.
Remarque : le check Snowflake n’est pas disponible dans l’Agent v6 basé sur Python 2. Pour utiliser Snowflake avec l’Agent v6, consultez la section Utiliser Python 3 avec l’Agent v6 de Datadog ou passez à l’Agent v7.
Configuration
Snowflake recommande d'accorder des autorisations à un rôle alternatif tel que `SYSADMIN`. En savoir plus sur le contrôle
du rôle ACCOUNTADMIN (en anglais).
Créez un rôle et un utilisateur spécifiques Datadog pour surveiller Snowflake. Dans Snowflake, exécutez les commandes suivantes pour créer un rôle personnalisé ayant accès au schéma ACCOUNT_USAGE.
Remarque : par défaut, cette intégration surveille la base de données SNOWFLAKE
et le schéma ACCOUNT_USAGE
. Consultez la section « Recueillir les données d’une organisation » pour découvrir comment surveiller le schéma ORGANIZATION_USAGE
.
Cette base de données est disponible par défaut et ne peut être consultée que par les utilisateurs disposant du rôle ACCOUNTADMIN
ou de tout rôle accordé par ACCOUNTADMIN.
use role ACCOUNTADMIN;
grant imported privileges on database snowflake to role SYSADMIN;
use role SYSADMIN;
Vous pouvez également créer un rôle personnalisé DATADOG
ayant accès à ACCOUNT_USAGE
.
-- Créer un nouveau rôle destiné à surveiller l'utilisation de Snowflake.
create role DATADOG;
-- Accorder des autorisations sur la base de données SNOWFLAKE au nouveau rôle.
grant imported privileges on database SNOWFLAKE to role DATADOG;
-- Accorder l'accès à l'utilisation de votre entrepôt de données par défaut au rôle DATADOG.
grant usage on warehouse <ENTREPÔT_DONNÉES> to role DATADOG;
-- Créer un utilisateur. Ignorez cette étape si vous avez déjà un utilisateur existant.
create user UTILISATEUR_DATADOG
LOGIN_NAME = UTILISATEUR_DATADOG
password = '<MOTDEPASSE>'
default_warehouse = <ENTREPÔT_DONNÉES>
default_role = DATADOG
default_namespace = SNOWFLAKE.ACCOUNT_USAGE;
-- Accorder le rôle de monitor à l'utilisateur.
grant role DATADOG to user <UTILISATEUR>;
Modifiez le fichier snowflake.d/conf.yaml
dans le dossier conf.d/
à la racine du répertoire de configuration de votre Agent pour commencer à recueillir vos données de performance Snowflake. Consultez le fichier d’exemple snowflake.d/conf.yaml pour découvrir toutes les options de configuration disponibles.
## @param account - string - required
## Name of your account (provided by Snowflake), including the platform and region if applicable.
## For more information on Snowflake account names,
## see https://docs.snowflake.com/en/user-guide/connecting.html#your-snowflake-account-name
#
- account: <ORG_NAME>-<ACCOUNT_NAME>
## @param username - string - required
## Login name for the user.
#
username: <USER>
## @param password - string - required
## Password for the user
#
password: <PASSWORD>
## @param role - string - required
## Name of the role to use.
##
## By default, the SNOWFLAKE database is only accessible by the ACCOUNTADMIN role. Snowflake recommends
## configuring a role specific for monitoring:
## https://docs.snowflake.com/en/sql-reference/account-usage.html#enabling-account-usage-for-other-roles
#
role: <ROLE>
## @param min_collection_interval - number - optional - default: 15
## This changes the collection interval of the check. For more information, see:
## https://docs.datadoghq.com/developers/write_agent_check/#collection-interval
##
## NOTE: Most Snowflake ACCOUNT_USAGE views are populated on an hourly basis,
## so to minimize unnecessary queries, set the `min_collection_interval` to 1 hour.
#
min_collection_interval: 3600
# @param disable_generic_tags - boolean - optional - default: false
# Generic tags such as `cluster` will be replaced by <integration_name>_cluster to avoid
# getting mixed with other integration tags.
# disable_generic_tags: true
In the default `conf.yaml`, the
min_collection_interval
is 1 hour.
Snowflake metrics are aggregated by day, you can increase the interval to reduce the number of queries.
Note: Snowflake ACCOUNT_USAGE views have a
known latency of 45 minutes to 3 hours.
Redémarrez l’Agent.
Recueillir les données d’une organisation
Par défaut, cette intégration surveille le schéma ACCOUNT_USAGE
. Vous pouvez toutefois la configurer pour qu’elle surveille les métriques liées à votre organisation.
Pour recueillir les métriques liées à votre organisation, définissez le champ schema sur ORGANIZATION_USAGE
et le champ min_collection_interval
sur 43200 dans la configuration de l’intégration. Ce paramètre permet de réduire le nombre de requêtes envoyées à Snowflake, la plupart des métriques affichant une latence pouvant aller jusqu’à 24 heures.
Remarque : pour surveiller les métriques liées à votre organisation, votre user
doit disposer du rôle ORGADMIN
.
- schema: ORGANIZATION_USAGE
min_collection_interval: 43200
Seules certaines métriques sont activées par défaut. Pour recueillir toutes les métriques liées à votre organisation, utilisez l’option de configuration metric_groups
:
metric_groups:
- snowflake.organization.warehouse
- snowflake.organization.currency
- snowflake.organization.credit
- snowflake.organization.storage
- snowflake.organization.contracts
- snowflake.organization.balance
- snowflake.organization.rate
- snowflake.organization.data_transfer
Vous pouvez également surveiller les métriques liées à votre compte en plus de celles liées à votre organisation :
instances:
- account: example-inc
username: DATADOG_ORG_ADMIN
password: '<MOTDEPASSE>'
role: SYSADMIN
schema: ORGANIZATION_USAGE
database: SNOWFLAKE
min_collection_interval: 43200
- account: example-inc
username: DATADOG_ACCOUNT_ADMIN
password: '<MOTDEPASSE>'
role: DATADOG_ADMIN
schema: ACCOUNT_USAGE
database: SNOWFLAKE
min_collection_interval: 3600
Recueillir les données de plusieurs environnements différents
Si vous souhaitez recueillir les données de plusieurs environnements Snowflake, ajoutez chaque environnement en tant qu’instance dans votre fichier snowflake.d/conf.yaml
. Par exemple, pour recueillir les données de deux utilisateurs nommés DATADOG_SYSADMIN
et DATADOG_USER
:
instances:
- account: example-inc
username: DATADOG_SYSADMIN
password: '<MOTDEPASSE>'
role: SYSADMIN
database: EXAMPLE-INC
- account: example-inc
username: DATADOG_USER
password: '<MOTDEPASSE>'
role: DATADOG_USER
database: EXAMPLE-INC
Configuration d’un proxy
Snowflake recommande de définir des variables d’environnement pour configurer un proxy.
Vous pouvez également définir proxy_host
, proxy_port
, proxy_user
et proxy_password
sous init_config
dans le fichier snowflake.d/conf.yaml.
REMARQUE : Snowflake met automatiquement en forme les configurations de proxy et définit les variables d’environnement de proxy standard. Ces variables ont une incidence sur l’ensemble des requêtes provenant des intégrations, y compris les services d’orchestration comme Docker, ECS et Kubernetes.
Connectivité privée dans la configuration Snowflake
Si une connectivité privée (par exemple AWS PrivateLink) est activée dans Snowflake, vous pouvez configurer l’intégration Snowflake en mettant à jour l’option de configuration account
et en appliquant le format suivant :
- account: <COMPTE>.<ID_RÉGION>.privatelink
Requêtes personnalisées Snowflake
L’intégration Snowflake prend en charge les requêtes personnalisées. Par défaut, elle interagit avec la base de données partagée SNOWFLAKE
et le schéma ACCOUNT_USAGE
.
Pour exécuter des requêtes personnalisées avec un autre schéma ou une autre base de données, ajoutez une autre instance au fichier d’exemple snowflake.d/conf.yaml et configurez les options database
et schema
.
Vérifiez que l’utilisateur et le rôle ont accès à la base de données ou au schéma indiqué.
Options de configuration
custom_queries
dispose des options suivantes :
Option | Obligatoire | Description |
---|
query | Oui | Le SQL à exécuter. Il peut s’agir d’une simple déclaration ou d’un script sur plusieurs lignes. Toutes les rangées des résultats sont évaluées. Utilisez le symbole pipe « |
columns | Oui | Liste représentant toutes les colonnes, triées par ordre séquentiel de gauche à droite.
Deux types d’informations sont obligatoires : -name : le suffixe à ajouter à metric_prefix afin de former un nom de métrique complet. Si le type est défini sur tag , la colonne est considérée comme un tag et appliquée à chaque métrique recueillie par cette requête. - type : la méthode d’envoi (gauge , count , rate , etc.). Cette option peut également être définie sur tag pour ajouter à chaque métrique de la rangée le nom et la valeur (<nom>:<valeur_rangée> ) de l’élément en tant que tag dans cette colonne. |
usage-metering-get-hourly-usage-for-lambda-traced-invocations | Non | La liste des tags statiques à appliquer à chaque métrique. |
Remarques
- Au moins un élément de
columns
doit correspondre à un type de métrique (gauge
, count
, rate
, etc.). - Le nombre d’éléments dans columns doit correspondre au nombre de colonnes renvoyées par la requête.
- L’ordre des éléments dans
columns
doit correspondre à celui des valeurs renvoyées par la requête.
custom_queries:
- query: select F3, F2, F1 from Table;
columns:
- name: f3_metric_alias
type: gauge
- name: f2_tagkey
type: tag
- name: f1_metric_alias
type: count
tags:
- test:snowflake
Exemple
La requête suivante compte toutes les requêtes de la vue QUERY_HISTORY
avec un tag comportant les noms de la base de données, du schéma et de l’entrepôt.
select count(*), DATABASE_NAME, SCHEMA_NAME, WAREHOUSE_NAME from QUERY_HISTORY group by 2, 3, 4;
Configuration
Voici un exemple de configuration de requêtes personnalisées dans instances
:
custom_queries:
- query: select count(*), DATABASE_NAME, SCHEMA_NAME, WAREHOUSE_NAME from QUERY_HISTORY group by 2, 3, 4;
columns:
- name: query.total
type: gauge
- name: database_name
type: tag
- name: schema_name
type: tag
- name: warehouse_name
type: tag
tags:
- test:snowflake
Validation
Pour vérifier le résultat, recherchez les métriques à l’aide de la vue Metrics Summary :

Validation
Lancez la sous-commande status de l’Agent et cherchez snowflake
dans la section Checks.
Données collectées
Remarque : seules les métriques des groupes de métriques suivants sont recueillies par défaut :
snowflake.query.*
,
snowflake.billing.*
,
snowflake.storage.*
et
snowflake.logins.*
.
Si vous souhaitez recueillir des métriques d’autres groupes, consultez l’exemple de fichier de configuration pour cette intégration.
Métriques
Événements
Snowflake n’inclut aucun événement.
Checks de service
Dépannage
Besoin d’aide ? Contactez l’assistance Datadog.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles :