📚 Integração de Custos do New Relic na Plataforma Finopping

Organização: Grupo Boticário
Tipo: Decisão de Arquitetura — Coleta e Visualização de Custos
Status: 🚧 Em andamento

---

📑 Índice

1. Contexto e Motivação
2. Problemática
3. Soluções Avaliadas para Extração de Dados
4. Solução Adotada
5. Modelo de Custo e Conversão
6. Arquitetura da Solução
7. Estrutura Futura de Visualização
8. Lições Aprendidas e Riscos

---

1. 📊 Contexto e Motivação

Contexto

O Grupo Boticário possui um contrato ativo com o New Relic para observabilidade de suas aplicações, com custo anual estimado entre R$ 14 e R$ 16 milhões. Atualmente, esse custo não está integrado à plataforma de FinOps (Finopping), onde o monitoramento financeiro de custos de cloud é centralizado.

Objetivo Central

Integrar a gestão dos custos do New Relic à Finopping, oferecendo:

• ✅ Transparência granular: visibilidade do consumo por Squad, e não apenas por Value Stream ou conta
• ✅ Suporte estratégico: dados concretos para otimizações e futuras negociações contratuais
• ✅ Rastreabilidade: correlacionar consumo de ingestão com as aplicações e times responsáveis

---

2. 🔍 Problemática

Granularidade do Tagueamento

A visão atual de consumo no New Relic é agregada por Value Stream ou conta. O projeto exige a abertura de custos por Squad, o que depende de um esforço de tagueamento nas aplicações.

O padrão de tagueamento adotado segue o modelo Alquimia (IDs internos do GB). Entretanto, após discovery identificou-se que:

⚠️ Somente aplicações nascidas no Alquimia possuem, com certeza, as tags desejadas.

Estratégia de Contorno

Como mitigação para o escopo inicial:

• A primeira entrega utilizará apenas dados de aplicações vindas do Alquimia (com tags corretas)
• Será disponibilizado um comparativo com a quantidade de registros sem tagueamento correto, evidenciando o gap
• Para aplicações sem tag_squad, será avaliado um DE-PARA a nível de FinOps, mapeando AppName vindo do NR para as informações equivalentes de Squad presentes nas bases da Finopping

---

3. 🔍 Soluções Avaliadas para Extração de Dados

Opção 1: Visão Consolidada pelo Time de Observabilidade (Preferida ✅)

Acordo: O time de Observabilidade do New Relic disponibilizará uma visão diária (período D-1) do consumo com as seguintes granularidades:

Campo	Descrição
AccountId	ID da conta no NR
AccountName	Nome da conta no NR
Squad	Tag de squad (somente apps Alquimia)
System	Sistema ao qual a app pertence (somente apps Alquimia)
AppName	Nome da aplicação
IngestionMetrics	Ingestão de métricas (GB)
IngestionLogs	Ingestão de logs (GB)
IngestionTraces	Ingestão de traces (GB)
IngestionTransactions	Ingestão de transações (ZERO se OpenTelemetry; > 0 se NR Agent)

⚠️ Pendente: Aguardando retorno do time de Observabilidade para validar se a visão consolidada com esse nível de detalhe é tecnicamente viável.

Vantagens

• ✅ Menor complexidade operacional para o time de FinOps
• ✅ Dados já consolidados e tratados
• ✅ Granularidade adequada por Squad e AppName
• ✅ Sem limitações de processamento de query

Desvantagens

• ❌ SLA (Service Level Agreement) e formato de entrega a ser definido

---

Opção 2: Extração Manual via New Relic NerdGraph API

Mecanismo: Consulta diretamente à API GraphQL do New Relic (api.newrelic.com/graphql) nas principais tabelas de consumo: Log, Metric, Span e Transaction.

Query de referência:

SELECT bytecountestimate()/10e8 AS 'GB'
FROM Metric
FACET entity.name
SINCE 1 hour ago

Campos mapeados nessa abordagem:

Campo	Descrição
squad	Tag de squad
vs	Value Stream
team	Time responsável
tier	Nível/criticidade
ambiente	Ambiente (prod, hml…)
account	Conta NR
service	Serviço/aplicação

Vantagens

• ✅ Independência do time de Observabilidade
• ✅ Controle total sobre o processo de coleta

Desvantagens

• ❌ A função bytecountestimate() possui limitação de processamento
• ❌ Necessidade de orquestrar 24 queries diárias (uma por hora) e consolidá-las em um resultado único
• ❌ Maior complexidade de implementação e manutenção
• ❌ Maior risco de inconsistência nos dados consolidados

---

4. ✅ Solução Adotada

Decisão

Opção 1 (Visão consolidada pelo time de Observabilidade) como caminho prioritário.

A extração via NerdGraph (Opção 2) será utilizada como fallback caso a Opção 1 não seja viável tecnicamente.

Justificativa

• ✅ Menor custo operacional: evita orquestração de múltiplas queries
• ✅ Qualidade dos dados: entregue por quem gerencia o contrato NR
• ✅ Escalabilidade: não há limitações de processamento na query
• ✅ Foco no problema de negócio: o time de FinOps foca na visualização e não na extração

---

5. 💰 Modelo de Custo e Conversão

Variáveis de Custo do Contrato

O custo do New Relic é baseado em três variáveis:

1. Ingestão de dados ← foco desta primeira entrega
2. Usuários full
3. Sintéticos (monitores)

Parâmetros de Cálculo

Parâmetro	Valor	Responsável pela definição
Custo por GB ingerido	U$ 0,32/GB	Elidijane Magave & Tiffany Panegalli
Taxa de câmbio (USD/BRL)	U$ 1 = R$ 5,44	Câmbio utilizado para faturamento da nota
Custo contrato anual	R$ 14~16 milhões	—

Visualização para o Usuário Final

• Os squads visualizarão seu consumo em Gigabytes (GB)
• O custo monetário equivalente será calculado internamente pela plataforma
• Será exibido um comparativo entre o consumo do squad e o total do contrato (proporcionalizado mensalmente)

---

6. 🏗️ Arquitetura da Solução

Visão Geral

Componentes

🗄️ Tabela BigQuery: newrelic_consumption_daily

• Armazenamento centralizado dos dados de consumo diário
• Colunas a definir conforme caminho de coleta escolhido (Opção 1 ou 2)
• Serve como fonte única de verdade para o backend e visualizações

⚙️ Lambda Cronjob (D-1)

• Executado diariamente com dados do dia anterior (D-1)
• Responsável por:
• Coletar dados do New Relic (via Opção 1 ou 2)
• Aplicar DE-PARA de AppName → Squad para apps sem tagueamento
• Mapear e transformar colunas
• Persistir na tabela BigQuery

🔀 BFF (Backend for Frontend)

• Consome a tabela newrelic_consumption_daily do BigQuery
• Monta as visões necessárias para o MFE
• Aplica as conversões de GB → valor monetário

🖥️ MFE — Visão Diária New Relic

• Interface para visualização do consumo do Grupo Boticário no New Relic
• Funcionalidades previstas:
• Gráfico de consumo com divisão temporal
• Segmentação por Squad, Value Stream, AppName e demais dimensões disponíveis
• Comparativo com o total do contrato (R$ 14~16MM anual / 12 meses)
• Indicador percentual do quanto cada Squad consome do total

---

7. 🔮 Estrutura Futura de Visualização

Escopo da Primeira Entrega

Item	Status
Coleta de dados de ingestão (GB)	🚧 Em andamento
Tabela BigQuery newrelic_consumption_daily	🚧 Em andamento
Lambda Cronjob D-1	🚧 Em andamento
BFF para consumo do BigQuery	🔲 Planejado
MFE Visão Diária New Relic	🔲 Planejado
DE-PARA AppName → Squad (apps sem tag)	🔲 A validar
Visão de usuários full e sintéticos	🔲 Futuro

Premissas

• Aplicações sem tag_squad serão marcadas separadamente e exibirão o gap de tagueamento, caso não seja possível realizar tratativa DE-PARA.
• A integração com usuários full e sintéticos está fora do escopo desta primeira entrega

---

8. 💡 Lições Aprendidas e Riscos

✅ Decisões Acertadas

1. Priorizar a visão consolidada do time de Observabilidade reduz drasticamente a complexidade técnica
2. Escopo inicial reduzido (somente apps Alquimia) permite uma entrega de valor mais rápida
3. Comparativo de gap de tagueamento incentiva os times a regularizarem suas tags

⚠️ Riscos Identificados

Risco	Probabilidade	Impacto	Mitigação
Opção 1 não ser viável pelo time de Observabilidade	Média	Alto	Fallback para Opção 2 (extração via NerdGraph)
Apps sem tagueamento correto representarem parcela significativa	Alta	Médio	DE-PARA + exibição do gap para pressionar tagueamento
Mudança no modelo de precificação do contrato NR	Baixa	Alto	Monitoramento contratual pela área responsável

---

📝 Metadados

Documento criado: Junho 2026
Última atualização: Junho 2026
Autores: Gabriel Pepe & Elidijane Magave
Versão: 1.0.0
Status: 🚧 Em andamento

---

📊 Finopping + New Relic — Transparência de custos de observabilidade para todos os squads!