Monitorar o uso usando tags

Para monitorar o custo e atribuir com precisão o uso do Databricks às unidades de negócios e equipes da sua organização (para estornos, por exemplo), o senhor pode adicionar o tags personalizado ao espaço de trabalho e ao recurso compute. Databricks recomenda o uso de tabelas de sistema (Public Preview) para view dados de uso. Consulte Referência da tabela do sistema de uso faturável.

Esses tags se propagam tanto para o uso logs quanto para AWS EC2 e AWS instâncias do EBS para análise de custos. Observação: os dados da tag podem ser replicados globalmente. Não use tag nomes ou valores que possam comprometer a segurança de seu recurso. Por exemplo, não use nomes tag que contenham informações pessoais ou confidenciais.

tags objects e recurso

O senhor pode adicionar o tags personalizado para os seguintes objetos gerenciados pelo Databricks:

Objeto	interface de tags (UI)	interface de tags (API)
Workspace	N/A	account API
Pool	UI do pool no site Databricks workspace	API do pool de instâncias
Para todos os fins e Job compute	compute UI no site Databricks workspace	API de clusters
Armazém SQL	SQL warehouse UI no site Databricks workspace	API de armazéns

Aviso

Não atribua um tag personalizado com o key Name a um cluster. Cada cluster tem uma tag Name cujo valor é definido pela Databricks. Se o senhor alterar o valor associado ao key Name, o cluster não poderá mais ser rastreado pelo Databricks. Como consequência, o cluster pode não ser encerrado depois de se tornar parado e continuará a incorrer em custos de uso.

Tags padrão

Databricks adiciona o seguinte default tags para todos os fins compute:

tag key	Valor
`Vendor`	Valor constante: `Databricks`
`ClusterId`	ID interna de Databricks do cluster
`ClusterName`	Nome do cluster
`Creator`	Nome de usuário (endereçoemail ) do usuário que criou o cluster

Em Job clusters, Databricks também se aplica o seguinte default tags:

tag key	Valor
`RunName`	Nome do Job
`JobId`	ID do Job

Databricks adiciona o seguinte default tags a todo o pool:

tag key	Valor
`Vendor`	Valor constante: `Databricks`
`DatabricksInstancePoolCreatorId`	ID interno do Databricks do usuário que criou o pool
`DatabricksInstancePoolId`	ID interna do pool do Databricks

No compute usado pelo lakehouse monitoramento, o Databricks também aplica o seguinte tags:

tag key	Valor
`LakehouseMonitoring`	verdadeiro
`LakehouseMonitoringTableId`	ID da tabela monitorada
`LakehouseMonitoringWorkspaceId`	ID do site workspace onde o monitor foi criado
`LakehouseMonitoringMetastoreId`	ID do metastore onde existe a tabela monitorada

Tags serverless compute cargas de trabalho

Para atribuir o uso do serverless compute a usuários, grupos ou projetos, o senhor pode usar políticas de orçamento. Quando um usuário recebe uma política de orçamento, seu uso do serverless é automaticamente marcado com o tags da política. Consulte Atributo serverless uso com políticas orçamentárias.

Propagação de tags

As tags são propagadas para as instâncias do AWS EC2 de forma diferente, dependendo do fato de o cluster ter sido criado ou não a partir de um pool.

Se um cluster for criado a partir de um pool, suas instâncias de EC2 herdarão apenas o costume e default workspace tags e pool tags, não a tag de cluster. Portanto, se o senhor quiser criar o clusters a partir de um pool, certifique-se de atribuir todas as tags de cluster personalizadas necessárias ao workspace ou pool.

Se um cluster não for criado a partir de um pool, suas tags se propagarão como esperado para as instâncias do EC2.

cluster e pool tags se propagam para os relatórios de uso doDBU , independentemente de o cluster ter sido criado ou não a partir de um pool.

Se houver um conflito de nomes em tag, Databricks default tags terá precedência sobre tags personalizado e pool tags terá precedência sobre Cluster Tag.

Limitações

A chave e os valores da tag só podem conter letras, espaços, números ou os caracteres +, -, =, ., _, :, /, @. As tags que contêm outros caracteres são inválidas.
Se o senhor alterar os nomes ou valores das chaves do site tag, essas alterações serão aplicadas somente após a reinicialização do site cluster ou a expansão do site pool.
Se as tags personalizadas do cluster entrarem em conflito com as tags personalizadas de um pool, o cluster não poderá ser criado.
Pode levar até uma hora para que o site workspace tags personalizado seja propagado após qualquer alteração.
Não é possível atribuir mais de 20 tags a um recurso workspace.

Práticas recomendadas de marcação

Como as tags podem ser inseridas manualmente, sua organização deve padronizar seu par key-value. Databricks recomenda o desenvolvimento de uma política comercial para key e a nomeação de valores que o senhor possa compartilhar com todos os usuários.
Todos os recursos devem ser marcados com uma chave geral que atribua o uso a uma unidade de negócios ou projeto. Por exemplo, um recurso do Job compute criado pela equipe financeira para seu orçamento anual pode incluir as tags business-unit:finance e project:annual-budget.
Para percepções mais granulares, atribua tags usando uma chave de alta especificidade. Por exemplo, o senhor pode criar chaves com base em funções, produto, serviço ou clientes.
Quando aplicável, os administradores do workspace devem aplicar as tags usando as políticas do compute e as políticas de orçamento. Consulte Aplicação de tags personalizadas.

tag aplicação com IAM role

Para garantir que determinados tags sejam sempre preenchidos quando o recurso compute for criado, é possível aplicar uma política IAM específica ao account's primary IAM role (aquele criado durante a configuração do account; entre em contato com o administrador do AWS se precisar de acesso). A política IAM deve incluir declarações explícitas de negação para valores obrigatórios e opcionais da chave tag. A criação do cluster falhará se as tags necessárias com um dos valores permitidos não forem fornecidas.

Por exemplo, se o senhor quiser aplicar as tags Department e Project, com apenas valores especificados permitidos para a primeira e um valor não vazio de forma livre para a segunda, poderá aplicar uma política de IAM como esta:

{
  "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": "?*"
        }
      }
    }
  ]
}

Ambas as ações ec2:RunInstances e ec2:CreateTags são necessárias para cada tag para uma cobertura eficaz dos cenários em que há clusters que têm apenas instâncias sob demanda, apenas instâncias pontuais ou ambas.

Dica

A Databricks recomenda que o senhor adicione uma declaração de política separada para cada tag. A política geral pode se tornar longa, mas é mais fácil de depurar. Consulte a Referência de operadores de condição de política de IAM para obter uma lista de operadores que podem ser usados em uma política.

Os erros de criação de cluster devido a uma política de IAM mostram um encoded error message, começando com:

Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster.

A mensagem é codificada porque os detalhes do status da autorização podem constituir informações privilegiadas que o usuário que solicitou a ação não deve ver. Consulte DecodeAuthorizationMessage API (ou CLI) para obter informações sobre como decodificar essas mensagens.