Afinal, o que são essas tais labels?
A documentação do GCP define labels como uma "forma leve de agrupar recursos relacionados ou associados entre si".
Isso resume bem o conceito, mas a pergunta mais relevante é: "para que elas servem?"
O principal objetivo de colocar uma label em um recurso é conseguir rastrear facilmente quanto cada recurso custa nos seus dados de billing. Por padrão, todo serviço aparece no billing agrupado como um único item.
Por exemplo, um item da fatura referente a uma instância do Compute Engine pode aparecer assim: "Compute Engine Small Instance with 1 VCPU running in Americas: 15342.56 Hours."
Lendo isso, parece simples — até você lembrar que um mês tem em média 730 horas. Ou seja, várias instâncias rodaram naquele mês, mas quantas? Quais rodaram por quanto tempo, e em qual projeto? E olhar o relatório de billing no console do GCP também não ajuda muito.
Esses dados são quase impossíveis de extrair dos números que o Google mostra na fatura e no console. É aí que as labels entram em cena.
Quando você usa labels no seu projeto, o relatório de billing passa a aparecer mais ou menos assim:
Relatório de billing do GCP (alguns nomes foram removidos)
Repare como ele fica dividido por labels, o que torna a leitura muito mais fácil. Vou falar sobre a parte iris_name das labels mais adiante neste artigo.
Labels vs Tags
Uma distinção que precisa ficar clara logo de cara é a diferença entre labels e tags dentro do GCP.
Até pouco tempo, elas tinham uma relação quase de 1 para 1, mas agora são entidades separadas, à medida que o GCP evolui. A diferença atual é que tags servem para agrupar recursos a fim de aplicar uma política de rede, enquanto labels agrupam recursos para fins de billing e busca (e possivelmente outros usos no futuro).
Um exemplo: se você criar uma regra de firewall e adicionar uma target tag a essa regra, ela será aplicada a qualquer recurso que tenha a mesma network tag, como instâncias do Compute Engine. A principal diferença que a maioria vai perceber é a terminologia: o GCP agora usa tags para se referir a network tags (ou target tags, como as regras de firewall as chamam) e labels para o que antes era chamado coletivamente de tags.
Pode levar um tempo até essa nova terminologia se consolidar, então, quando ouvir falar em algo sendo "tagueado" no GCP, confira duas vezes se é uma tag ou uma label. Anos chamando tudo de "tag" tornam difícil quebrar o hábito quando, na verdade, queremos dizer label.
DoiT Console e Cloud Analytics
Um dos melhores segredos pouco comentados para gerenciar billing e custos no GCP é a seção Cloud Analytics do DoiT Console, uma ferramenta de descoberta e otimização de custos disponibilizada pela DoiT International ao público.
Com os relatórios, você obtém insights instantâneos sobre o billing do Google Cloud Platform, gerencia orçamentos, configura alocações de custo, recebe alertas de orçamento e de anomalias e ainda explora diferentes estratégias de otimização de custos.
Ao usar os relatórios, você ganha ainda mais visibilidade sobre seus custos do Google Cloud, com várias melhorias:
- Até 36 meses de dados históricos (vs. 3 a 6 meses)
- Tempo de carregamento e atualização de relatórios 100x mais rápido
- Quantidade ilimitada de user e system labels (vs. apenas um ou outro)
- Suporte a relatórios sobre créditos como SUDs ou CUDs
- Relatórios prontos
- Muito mais tipos de gráficos
- Relatórios otimizados para mobile
- Atualizações de relatórios agendadas regularmente por e-mail ou Slack
Observação: algumas dessas imagens podem estar desatualizadas, dada a grande quantidade de novos recursos adicionados ao DoiT Console desde a publicação original deste artigo.
Logo de cara, oferecemos um conjunto de relatórios pré-definidos para você usar imediatamente. Esses relatórios são compartilhados em toda a organização, para que você e seus times fiquem alinhados sem esforço.
Os Cloud Reports seguem a mesma lógica de uma tabela dinâmica e permitem criar relatórios altamente configuráveis com qualquer número de dimensões e métricas:
Configure os Cloud Reports apenas arrastando dimensões e métricas
Se você aplica labels nos seus recursos ou usa o Iris3 para gerá-las automaticamente, dá para extrair insights poderosos das informações de billing, como o custo do Google Cloud Storage por bucket:
Custo do GCS por bucket
A ferramenta oferece métricas por hora dos seus dados de billing, o que facilita identificar problemas ou picos causados por um deploy recente ou mudança de configuração.
Dados por hora facilitam acompanhar mudanças no seu ambiente em nuvem
Se você e seu time têm interesse em ter acesso ao DoiT Console (e a uma série de outras ferramentas) sem custo adicional, fale com a gente para saber mais sobre como se tornar cliente da DoiT International sem nenhum custo extra.
Boas práticas para labels
Abaixo, um conjunto de boas práticas compiladas pelo time de Customer Reliability Engineering da DoiT International sobre o uso de labels no GCP.
Antes de configurar labels, vale conhecer as restrições delas e a quais recursos podem ser aplicadas. Recomendo ler primeiro a documentação do Google sobre o assunto, até porque ela tende a mudar depois da publicação deste texto.
Nem todos os produtos têm suporte a labels, mas muitos que não estão listados na documentação suportam. Olhar as páginas de criação e edição das instâncias de um serviço é a melhor forma de descobrir se ele suporta labels ou não.
Sempre use labels
Às vezes, ao criar uma nova instância do Compute Engine ou uma imagem baseada em outra, esquecemos de colocar uma label, e isso só é lembrado quando o financeiro chega perguntando sobre alguma despesa na fatura.
Para evitar isso, garanta que faça parte do seu fluxo de trabalho aplicar uma label sempre que criar um recurso, e que isso também aconteça em qualquer criação automatizada.
Use uma ferramenta automatizada de labeling
Seguindo a dica anterior, o Iris3 é uma ferramenta open source recém-reescrita, desenvolvida por nós, da DoiT, para aplicar labels automaticamente nos recursos conforme eles são criados. Assim, você nunca deixa um recurso sem label.
Ela pode ser personalizada para funcionar com tipos adicionais de recursos, caso o tipo que você quer usar ainda não seja suportado.
Aplique labels para tudo o que precisar
Labels são pares chave-valor, então tire proveito disso e adicione quantos dados forem necessários.
Aqui vão alguns exemplos de labels para usar:
Nomes de ambiente
Marcar um recurso como pertencente a development, staging, testing, production etc. é sempre uma escolha segura, pois facilita muito buscar todos os recursos de produção depois para um relatório de billing.
Função
Se você tem um conjunto de recursos do Compute Engine atuando como servidores web, outro em um cluster GKE e outro como servidor de banco de dados, marque cada um conforme sua função.
Nome da aplicação Usar o nome da aplicação como label facilita agrupar recursos pelo projeto de negócio ou aplicação a que pertencem, o que torna mais simples analisar custos por aplicação.
Nome da região Se sua aplicação ou projeto se estende por várias regiões, adicionar o valor da região ajuda a ordená-las depois. Pode ser o nome da região do GCP, uma região lógica que você definiu na sua aplicação, ou uma label para cada um.
Criador do recurso Colocar o nome de quem criou o recurso em uma label ajuda a identificar depois quem criou o quê, em vez de precisar vasculhar audit logs que podem ou não ter sido retidos.
Owner ou mantenedor Marcar um recurso com o nome do owner ou mantenedor ajuda a saber quem contatar em caso de problema ou dúvida. Um exemplo comum é o time que possui ou mantém o recurso.
Código de custo, billing ou orçamento Algumas organizações têm códigos para diferentes despesas ou orçamentos. Adicionar isso à label facilita o trabalho dos administradores de billing ou auditores.
Departamento
Se o recurso pertence a um determinado departamento, adicioná-lo como label facilita rastreá-lo depois.
Nome do bucket (apenas Google Cloud Storage) Quem já precisou olhar um relatório ou fatura de billing do GCP sabe que ele agrupa todos os storage buckets em um único item. Isso é um pesadelo se você quer saber quanto cada bucket custa, então adicionar o nome do bucket como label em cada um permite desmembrar tudo em itens separados.
Nome do recurso associado Se você tem um recurso vinculado a outro, é uma boa prática adicionar uma label nomeando esse outro recurso. Exemplos podem ser um disco persistente vinculado a uma instância do Compute Engine ou a um cluster Dataproc. Um IP externo vinculado a um managed instance group do Compute Engine é outro ótimo exemplo.
Classificação de dados Esse é um caso de uso amplo, mas se você tem qualquer tipo de dado que precisa ser classificado em um bucket ou dataset do BigQuery, adicione uma label para indicar isso. Exemplos podem ser dados sob compliance regulatório, como HIPAA ou PCI, ou dados criptografados. Vale a pena marcar esses recursos para que, quando um executivo C-level perguntar quanto se gasta por mês para armazenar PHI (informações de saúde protegidas), a resposta apareça rapidamente.
Estado do recurso
Se um recurso está ativo, pendente para deleção, desabilitado etc., marcar dessa forma facilita muito ver quanto está sendo cobrado em recursos em um determinado estado.
Nome da pasta ou organização Se você usa pastas ou diferentes unidades organizacionais na sua estrutura, crie uma label para elas, de forma a saber depois quanto cada organização ou pasta custa.
Para uma boa discussão sobre esse tema e sobre estrutura organizacional no GCP, leia este ótimo artigo do meu colega.
Padronize as labels
Crie um conjunto padrão de labels para aplicar a cada recurso e mantenha a consistência. Pode fazer sentido ter um conjunto padrão de labels para cada tipo de recurso. Isso facilita muito a busca por recursos e também o rastreamento de conjuntos de recursos em um relatório de billing.
Mais uma vez, usar o Iris3 para fazer isso automaticamente facilita muito manter o padrão.
Busque recursos usando filtros e labels
Em todo o console, nas barras de filtro, se você começar a digitar a palavra labels, aparecerá uma opção em um dropdown. Depois de selecioná-la, comece a digitar o nome da label depois dos dois pontos e o autocompletar vai sugerir, permitindo filtrar por essa label específica.
No momento em que este artigo foi escrito, isso ainda não funciona na página do Cloud Storage.
Use Kubernetes labels no GKE
O GKE permite rotular cada nó de um cluster com a função de Kubernetes labels (localizada na página de Metadata, ao criar um cluster).
Dica: dentro do Kubernetes, você pode usar um seletor para escolher esses nós. Isso só vale para uso do GKE, não para clusters standalone.
Use labels nas suas queries de billing no BigQuery
Se você já usou o BigQuery como destino dos dados de billing, provavelmente viu um campo labels nas tabelas que ele cria. Cada label adicionada a um serviço aparece nesse campo para o recurso associado àquela linha. Usar esses dados permite uma exploração muito mais rica das informações no BigQuery.
Use labels nas suas Queues
Se você usa Pub/Sub para filas ou como parte de um workflow, crie uma label no seu tópico para indicar a qual aplicação ou workflow ele pertence. Esse é um custo frequentemente esquecido, especialmente entre usuários intensivos do Pub/Sub. Vale notar que, no momento em que este artigo foi escrito, o Pub/Sub Lite não suporta labels.
Mantenha sua política de labels atualizada
Ao atualizar ou lançar um novo projeto, ou ao usar um novo serviço no GCP, verifique se ele suporta labels. Se sim, atualize sua política de labels para incluí-lo ou adicione-o ao Iris3 para atualização automática.