Skip to content

📌 Fluxo de Processamento e Validação de Tags

🔹 O que é o fluxo de tags?

O Fluxo de Processamento e Validação de Tags é o conjunto de processos automatizados responsáveis por:

  • Receber catálogos de tags válidas de diferentes origens (CSV no S3, API Alquimia).
  • Carregar e validar informações de custos multicloud (AWS e Azure) a partir do BigQuery.
  • Classificar os recursos quanto à correção, ausência ou inconsistência de tags.
  • Consolidar os dados em tabelas no RDS.
  • Enviar alertas automáticos para squads no Slack.

Esse fluxo garante que os custos sejam corretamente associados às dimensões de negócio (VS, Squad, Produto, Environment) e que desvios sejam monitorados com recorrência.

🔹 Quais são os processos principais?

Processo Lambda Frequência Entrada Saída
Carga de catálogo de contas ↔ tags fromToAccountTagsProcess Upload no S3 from-to-accounts-tags.csv FROM_TO_ACCOUNTS_TAGS_TABLE
Carga de catálogo de tags válidas (FinOps) validTagsFinOpsProcess Upload no S3 valid-tags-finops.csv VALID_TAGS_TABLE (origin=finops)
Carga de catálogo de tags válidas (Alquimia) updateAlquimiaValidTags 04:00 UTC (diário) API Alquimia VALID_TAGS_TABLE (origin=alquimia)
Classificação e cálculo de custos runTagReport 15:00 UTC (diário) BigQuery + VALID_TAGS_TABLE TAG_REPORT_TABLE
Envio de alertas para squads runTagAlerts 1º e 15 às 16:00 UTC TAG_REPORT_TABLE Slack (mensagens automáticas)

🔹 Como cada processo funciona?

🟢 Lambda: fromToAccountTagsProcess

Lambda: fromToAccountTagsProcess

  • ⏰ Trigger: Upload no S3 (from-to-accounts-tags.csv).

  • 📥 Entrada: Arquivo CSV com mapeamento de contas ↔ tags.

  • ⚙️ Processamento:

  • Limpa a tabela FROM_TO_ACCOUNTS_TAGS_TABLE.
  • Lê CSV em chunks de 10k.

  • Persiste registros no banco.

  • 💾 Destino: FROM_TO_ACCOUNTS_TAGS_TABLE (RDS).

  • 📤 Saída: Dados auxiliares para análises - não é dependência direta do fluxo central de validação.

🟢 Lambda: validTagsFinOpsProcess

Lambda: validTagsFinOpsProcess

  • ⏰ Trigger: Upload no S3 (valid-tags-finops.csv).

  • 📥 Entrada: Arquivo CSV com catálogo de tags válidas.

  • ⚙️ Processamento:

  • Limpa registros antigos em VALID_TAGS_TABLE (origin = 'finops').
  • Lê CSV em chunks de 10k.

  • Insere novos valores de referência de tags.

  • 💾 Destino: VALID_TAGS_TABLE (RDS).

  • 📤 Saída: Catálogo FinOps de tags válidas. Usado pelo runTagReport para validar registros.

🟢 Lambda: updateAlquimiaValidTags

Lambda: updateAlquimiaValidTags

  • ⏰ Agendamento: Todos os dias às 04:00 UTC.

  • 📥 Entrada: API Alquimia (via Apigee, com token).

  • ⚙️ Processamento:

  • Busca lista de VS ativos (spec.enabled = true).
  • Limpa VALID_TAGS_TABLE (origin = 'alquimia').

  • Insere novos registros de VS válidos.

  • 💾 Destino: VALID_TAGS_TABLE (RDS).

  • 📤 Saída: Catálogo Alquimia de tags válidas. Usado pelo runTagReport.

🟢 Lambda: runTagReport

Lambda: runTagReport

  • ⏰ Agendamento: Todos os dias às 15:00 UTC.

  • 📥 Entrada:

  • BigQuery (custos e tags de AWS e Azure).

  • RDS (VALID_TAGS_TABLE) como referência de validação.

  • ⚙️ Processamento:

  • Executa queries no BigQuery (últimos 7 dias).

  • Para cada registro:

    • Verifica se aceita tags (accept_tags).
    • Classifica situação: Não Tagueável / Sem Tags / Todas Corretas / Precisa Ajustes.
    • Valida vs, squad, product, environment contra VALID_TAGS_TABLE.
    • Calcula custos (correct_cost, incorrect_cost, no_tags_cost, no_taggeable_cost).
    • Persiste em chunks de 10k.

  • 💾 Destino: TAG_REPORT_TABLE (RDS).

  • 📤 Saída: Consolidação diária de tags/custos → usada por dashboards Finopping e pelo runTagAlerts.

🟢 Lambda: runTagAlerts

Lambda: runTagAlerts

  • ⏰ Agendamento: Dia 1 e 15 de cada mês às 16:00 UTC.

  • 📥 Entrada: TAG_REPORT_TABLE (RDS).

  • ⚙️ Processamento:

  • Para cada VS:
  • Soma custos (correct_cost, incorrect_cost, no_tags_cost).
  • Busca top 3 tags incorretas/vazias por dimensão (vs, squad, product, environment).
  • Monta mensagens formatadas.

  • Publica via webhook.

  • 💾 Consulta: TAG_REPORT_TABLE.

  • 📤 Saída: Relatórios automáticos enviados para canais Slack das squads.

🔗 Dependências entre etapas

  • VALID_TAGS_TABLE é alimentada por:
  • validTagsFinOpsProcess (S3/CSV, origem = finops).

  • updateAlquimiaValidTags (API, origem = alquimia).

  • runTagReport depende de VALID_TAGS_TABLE para validar os registros do BigQuery.

  • runTagAlerts depende de TAG_REPORT_TABLE, que só existe após a execução do runTagReport.
  • fromToAccountTagsProcess roda de forma independente (apoio, não é bloqueante).

🔹 Considerações Finais

📌 Observações sobre tabelas existentes

  • TAG_REPORT_ALL
  • Existe atualmente no RDS.
  • Não foi encontrada nenhuma referência a ela nas funções (runTagReport, runTagAlerts).

  • Sugere-se revisar se a tabela ainda tem propósito ou se pode ser descontinuada para evitar confusão.

  • FROM_TO_ACCOUNTS_TAGS_TABLE

  • É alimentada pelo Lambda fromToAccountTagsProcess.
  • Contudo, não foi encontrada utilização explícita nos fluxos principais (runTagReport ou runTagAlerts).
  • Pode estar sendo usada de forma indireta (consultas manuais ou relatórios adicionais).
  • Sugere-se validar com as squads se há dependência real dessa tabela.

🚀 Possibilidades Futuras

  • Centralização no GCP
  • Hoje o fluxo combina múltiplas origens: BigQuery (custos), S3 (catálogos) e RDS (persistência final).

  • Uma evolução natural seria migrar e centralizar todas as persistências no GCP (BigQuery como camada única de dados).

  • Benefícios:

    • Redução de complexidade (menos integrações S3 + RDS).
    • Maior escalabilidade e performance nas queries.
    • Unificação do pipeline de dados em um só provedor.
    • Menor latência para os relatórios.

  • Revisão de Catálogos de Tags

  • Consolidar a origem FinOps (S3/CSV) e Alquimia (API) em um pipeline único para alimentar tags válidas.

  • Garantiria menor redundância e validação unificada.

  • Governança e Observabilidade

  • Incluir métricas de execução dos Lambdas (tempo, volume de dados processados, erros) em dashboards de monitoramento.
  • Automatizar notificações em caso de falha na persistência (ex.: runTagReport não gerar dados em um dia).

✅ Conclusão

O fluxo atual atende ao propósito de validar e consolidar tags, porém:
- Existem tabelas que podem estar ociosas (TAG_REPORT_ALL, FROM_TO_ACCOUNTS_TAGS_TABLE).
- Há espaço para otimizar e simplificar a arquitetura com uma possível migração total para o GCP.
- Manter a documentação viva e revisar periodicamente os usos reais das tabelas garantirá clareza e evitará acúmulo de legados desnecessários.