Utilisez des tags pour attribuer et suivre l'utilisation
Cet article explique comment utiliser les tags pour attribuer l’utilisation du compute à des workspaces, des équipes, des projets ou des utilisateurs spécifiques, afin de prendre en charge le suivi des coûts et la budgétisation.
Il existe deux types de tags :
- Balises default : Appliquées automatiquement par Databricks aux ressources déployées dans le cloud. Ceux-ci fournissent des métadonnées de base comme le fournisseur, l'ID de cluster et le créateur.
- Tags personnalisés : tags définis par l'utilisateur que vous pouvez ajouter aux compute Ressources et aux charges de travail Serverless. Cela permet un suivi granulaire, des rapports et une budgétisation.
Les données des tags sont stockées en texte brut et peuvent être répliquées à l’échelle mondiale. N’utilisez pas de noms de tags, de valeurs ou de descripteurs qui pourraient compromettre la sécurité de vos ressources. Par exemple, n’utilisez pas de noms de tags, de valeurs ou de descripteurs contenant des informations personnelles ou sensibles.
Balises default
Databricks ajoute automatiquement des balises default aux ressources de compute qu'il déploie dans votre compte cloud. Ces tags attribuent l'utilisation à Databricks et fournissent des informations de base sur la ressource, telles que son nom, son ID et son créateur.
Les tags default se propagent automatiquement aux instances AWS EC2 et AWS EBS pour l'analyse des coûts.
Clés et valeurs de tag default
Databricks applique des tags default aux ressources de compute. Les clés de balise exactes dépendent du type de ressource.
All-purpose and Jobs compute
Databricks ajoute les tags default suivants aux computes classiques multifonctions et aux Jobs :
Clé de tag | Valeur |
|---|---|
| Valeur constante : |
| ID interne du cluster Databricks. |
| Nom du cluster |
| Nom d'utilisateur (adresse e-mail) de l'utilisateur qui a créé le cluster |
| Nom du Job (ne se propage que sur le compute des Jobs). Si vous utilisez l'API Jobs 2.0, cela équivaut à |
| ID du Job (se propage uniquement sur le compute des Jobs) |
Le compute utilisé par le profilage des données inclut ces tags supplémentaires :
Clé de tag | Valeur |
|---|---|
| vrai |
| ID de la table surveillée |
| ID du workspace où le moniteur a été créé |
| ID du métastore où la table surveillée existe |
SQL Warehouse
Databricks ajoute les balises default suivantes aux SQL warehouses.
Clé de tag | Valeur |
|---|---|
| Valeur constante : |
| ID interne Databricks du cluster sous-jacent |
| ID interne Databricks du SQL Warehouse |
| Nom d'utilisateur (adresse e-mail) de l'utilisateur qui a créé le warehouse |
Pool
Databricks ajoute les tags default suivants aux pools et aux ressources de compute créées par les pools.
Clé de tag | Valeur |
|---|---|
| Valeur constante : |
| ID interne Databricks de l'utilisateur qui a créé le pool |
| ID interne Databricks du Pool |
Tags personnalisés
Les tags personnalisés vous permettent d'attribuer l'utilisation du compute à des équipes, des projets ou des centres de coûts spécifiques avec plus de granularité que les tags default. Ces tags sont appliqués par les utilisateurs ou les administrateurs et se propagent à la fois aux logs d'utilisation de votre compte et aux ressources cloud applicables. Ces tags sont également utilisés pour créer et surveiller les budgets de votre compte Databricks.
Ressources prises en charge pour les tags personnalisés
Vous pouvez ajouter des tags personnalisés pour les objets suivants gérés par Databricks :
Objet | Interface de tagging (UI) | Interface de marquage (API) |
|---|---|---|
Espace de travail | N/A | |
Pool | Interface utilisateur des Pools dans le workspace Databricks | |
Calcul multifonction et Job compute | Interface utilisateur de compute dans le workspace Databricks | |
SQL Warehouse | Interface utilisateur du SQL Warehouse dans le Workspace Databricks | |
Instance de la base de données | Interface utilisateur d'instance de base de données dans le workspace Databricks. | |
Projet de mise à l'échelle automatique Lakebase | Application Lakebase dans le workspace Databricks |
N'attribuez pas de tag personnalisé avec la clé Name à un cluster. Chaque cluster possède un tag Name dont la valeur est définie par Databricks. Si vous modifiez la valeur associée à la clé Name, le cluster ne peut plus être suivi par Databricks. En conséquence, le cluster pourrait ne pas être arrêté après être devenu inactif et continuera d'engendrer des coûts d'utilisation.
Étiqueter les charges de travail Serverless Compute
Aperçu
Cette fonctionnalité est en aperçu public.
Pour attribuer l'utilisation du compute Serverless aux utilisateurs, groupes ou projets, vous pouvez utiliser les politiques d'utilisation Serverless. Lorsqu'un utilisateur se voit attribuer une politique d'utilisation Serverless, son utilisation Serverless est automatiquement taguée avec les tags personnalisés de sa politique. Les politiques d'utilisation Serverless peuvent être appliquées aux Notebooks, jobs, pipelines et Endpoints de diffusion de modèles Serverless.
L'utilisation du compute Serverless est enregistrée dans la table système d'utilisation facturable de votre compte. Les anciens rapports d’utilisation de DBU n’incluent pas l’utilisation Serverless ni les tags de politique d’utilisation Serverless.
Consultez l'attribution de l'utilisation avec les politiques d'utilisation serverless.
Propagation des tags
Les tags sont propagés aux instances AWS EC2 différemment selon que le cluster a été créé ou non à partir d'un Pool.
Si un cluster est créé à partir d'un Pool, ses instances EC2 héritent uniquement des balises d'espace de travail personnalisées et default et des balises de Pool, et non des Cluster Tag. Par conséquent, si vous souhaitez créer des clusters à partir d'un pool, assurez-vous d'attribuer tous les cluster tags personnalisés dont vous avez besoin au workspace ou au pool.
Les tags de cluster et de pool sont tous deux propagés aux rapports d'utilisation DBU, même si le cluster a été créé à partir d'un pool.
Résolution des conflits de tags
Lorsqu'un tag personnalisé (tag de Workspace, de cluster ou de Pool) a le même nom de clé qu'un tag Databricks par default, le tag personnalisé est automatiquement préfixé par x_ pendant la propagation. Le tag Databricks par default conserve son nom de clé d'origine.
Par exemple, Databricks applique un Cluster Tag par default vendor = Databricks à tous les clusters. Si vous ajoutez un tag de workspace personnalisé vendor = AWS Databricks, cela entre en conflit avec le tag par défaut vendor. Lorsqu'il est propagé aux rapports d'utilisation AWS, le tag de Workspace personnalisé devient x_vendor = AWS Databricks, tandis que le Cluster Tag par default reste vendor = Databricks.
Les tags personnalisés conflictuels ajoutés via des stratégies de compute ne se résolvent pas automatiquement avec le préfixe x_, ce qui entraîne l'échec du cluster ou du pool avec une erreur de paramètres non valides. Assurez-vous que vos politiques de compute n'ajoutent aucune clé de tag qui entre en conflit avec les clés de tag par default de Databricks.
Application des tags
Pour appliquer l'utilisation de tags personnalisés spécifiques, vous pouvez utiliser des politiques de compute. Voir l'application des balises personnalisées. Pour appliquer des tags personnalisés sur les workloads de calcul serverless, utilisez les politiques d'utilisation serverless.
Pour vous assurer que certaines balises sont toujours renseignées lorsque des ressources de compute sont créées dans un Workspace, vous pouvez appliquer une politique IAM spécifique au rôle IAM principal de votre Workspace (celui créé lors de la configuration du Workspace ; contactez votre administrateur AWS si vous avez besoin d'un accès). La politique IAM devrait inclure des déclarations de refus explicites pour les clés de tag obligatoires et les valeurs facultatives. La création de clusters échouera si les tags obligatoires avec l'une des valeurs autorisées ne sont pas fournis.
Par exemple, si vous souhaitez appliquer des tags Department et Project, avec des valeurs spécifiées uniquement autorisées pour le premier et une valeur de forme libre non vide pour le second, vous pourriez appliquer une politique IAM comme celle-ci :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MandateLaunchWithTag1",
"Effect": "Deny",
"Action": ["ec2:RunInstances", "ec2:CreateTags"],
"Resource": "arn:aws:ec2:region:accountId:instance/*",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:RequestTag/Department": ["Deptt1", "Deptt2", "Deptt3"]
}
}
},
{
"Sid": "MandateLaunchWithTag2",
"Effect": "Deny",
"Action": ["ec2:RunInstances", "ec2:CreateTags"],
"Resource": "arn:aws:ec2:region:accountId:instance/*",
"Condition": {
"StringNotLike": {
"aws:RequestTag/Project": "?*"
}
}
}
]
}
Les actions ec2:RunInstances et ec2:CreateTags sont toutes deux requises pour chaque balise pour une couverture efficace des scénarios dans lesquels il existe des clusters qui ont uniquement des instances à la demande, uniquement des instances spot, ou les deux.
Databricks vous recommande d’ajouter une instruction de politique distincte pour chaque tag. La politique globale peut devenir longue, mais elle est plus facile à déboguer. Consultez la Référence des opérateurs de conditions de politique IAM pour obtenir la liste des opérateurs pouvant être utilisés dans une politique.
Les erreurs de création de cluster dues à une politique IAM affichent un encoded error message, commençant par :
Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster.
Le message est encodé car les détails du statut d'autorisation peuvent constituer des informations privilégiées que l'utilisateur ayant demandé l'action ne devrait pas voir. Consultez l'API DecodeAuthorizationMessage (ou la CLI) pour plus d'informations sur la façon de décoder de tels messages.
Limitations
- Les clés et valeurs de tag ne peuvent contenir que des lettres, des chiffres ou les caractères
+,-,=,.,,,_,:,@. Les clés et valeurs de tag ne peuvent pas contenir d'espaces ou/. Les clés de tag ne peuvent pas se composer uniquement de.(un point), de..(deux points) ou de_index. Les tags qui ne répondent pas à ces exigences ne sont pas valides. Ces restrictions de caractères sont définies par AWS. - Si vous modifiez les noms ou les valeurs des clés de tag, ces modifications ne s'appliquent qu'après le redémarrage du cluster ou l'extension du Pool.
- Si les tags personnalisés du cluster entrent en conflit avec les tags personnalisés d'un pool, le cluster ne peut pas être créé.
- Cela peut prendre jusqu'à une heure pour que les tags de Workspace personnalisés se propagent après toute modification.
- Pas plus de 20 étiquettes ne peuvent être attribuées à une ressource Workspace.