O problema começa com um paradoxo operacional claro: os dados de uso das unidades de GPU no ambiente da Adobe eram coletados a cada segundo dentro de um Prometheus central, mas as equipes que arcavam com o custo dessas unidades não conseguiam visualizar diretamente suas métricas. Segundo os engenheiros Bingi Narasimha Karthik e Ramkumar Nagaraj, isso levou à descoberta de uma unidade de GPU que permaneceu com uso zero durante 11 dias, alocada e em execução, mas invisível para a equipe responsável por ela.
O material publicado no blog da CNCF em 9 de setembro de 2026 não apresenta um novo produto comercial, mas explica um padrão prático para criar acesso autônomo e seguro às métricas em clusters Kubernetes multi-inquilino. A ideia central é colocar uma camada intermediária ciente dos locatários diante do Prometheus central e, depois, conceder a cada equipe uma fatia selecionada de seus dados, com a opção de copiar esses dados para um Prometheus próprio.
Por que não basta abrir o Prometheus central?
Os autores consideram que conceder às equipes permissão de leitura no endpoint de consulta do Prometheus central esbarra em dois problemas. O primeiro é de segurança, pois o endpoint de consulta do Prometheus não tem consciência dos namespaces; quem consegue executar uma consulta PromQL poderia, em teoria, solicitar dados de outras equipes, como taxas de requisições ou planos de capacidade.
O segundo problema é o desempenho. O armazenamento central atende às métricas de toda a frota, e consultas longas ou mal dimensionadas feitas por centenas de engenheiros podem consumir recursos e aumentar o tempo de resposta para todos. Portanto, abrir o armazenamento compartilhado não resolve o problema de visibilidade; pode, em vez disso, acrescentar à própria arquitetura o risco de vazamento de dados e o problema do vizinho barulhento.
Uma camada intermediária com três responsabilidades
O projeto propõe uma camada fina diante do Prometheus que desempenha três funções interligadas:
- Identificação: autenticar o solicitante e descobrir a qual locatário ele pertence.
- Isolamento: restringir cada consulta ao namespace do locatário, aplicando a restrição antes que a consulta chegue ao Prometheus, para que ela não possa ser contornada por meio do PromQL.
- Entrega: copiar periodicamente um conjunto selecionado de métricas do locatário para um Prometheus próprio quando necessário.
O caminho de leitura usa o Nginx para balanceamento de carga e, em seguida, o kube-rbac-proxy para autenticação e autorização. Depois disso, as solicitações chegam ao proxy, que descobre os servidores Prometheus por meio da API do Kubernetes e reúne os resultados dos servidores saudáveis. Já o caminho de escrita usa remote write para enviar as métricas selecionadas ao Prometheus do locatário. Em ambientes de alta disponibilidade, os dados são enviados a todas as réplicas por meio dos nomes DNS dos Pods.
O isolamento começa na identidade e termina nos dados
O kube-rbac-proxy usa a identidade do Kubernetes e o RBAC para determinar quem fez a solicitação e, depois, repassa a identidade do locatário como uma afirmação de namespace. O prom-label-proxy aplica o isolamento no momento da consulta, reescrevendo a solicitação para adicionar um seletor de namespace antes de enviá-la ao Prometheus. Dessa forma, o isolamento não é apenas uma política recomendada ao usuário, mas uma restrição aplicada a todas as consultas.
A fonte também menciona medidas de proteção do próprio proxy, como executá-lo como usuário não root com o identificador UID 65534, usar um sistema de arquivos raiz somente para leitura, remover todas as capacidades adicionais, impedir a elevação de privilégios e conceder-lhe uma conta de serviço com o mínimo possível de permissões.
O que muda, na prática, em custo e desempenho?
O isolamento não se limita a impedir a visualização dos dados de outras equipes. A configuração metricIsolation permite aplicar um filtro de namespace já na etapa de coleta das métricas, de modo que o Prometheus do locatário armazene apenas as séries que lhe pertencem. Segundo a experiência dos autores, o número de séries armazenadas para um locatário típico pode cair cerca de 97%, de mais de 10 mil séries para algumas centenas.
Essa redução significa um armazenamento menor, consultas mais rápidas e menor custo de armazenamento, além de reduzir a possibilidade de vazamento de dados, pois as métricas desnecessárias nem sequer chegam ao armazenamento privado. O projeto também diminui a pressão sobre o Prometheus central, pois os painéis e alertas diários passam a ser executados nos armazenamentos dos locatários, em vez de depender continuamente do armazenamento compartilhado.
A operação autônoma precisa de limites claros
A equipe define um recurso personalizado no Kubernetes chamado MetricAccess, que especifica o namespace, as métricas solicitadas, o destino do remote write e o período de coleta. Os locatários podem escolher nomes de métricas específicos, expressões regulares ou seletores PromQL. O Prometheus de destino precisa habilitar o recebimento de remote write por meio de web.enable-remote-write-receiver, enquanto o restante da arquitetura continua baseado nos componentes usuais do Prometheus e do Kubernetes.
O material apresenta seis tipos de consultas úteis, incluindo o uso médio de GPU por namespace, a contagem de unidades com uso inferior a 5% durante uma hora, a porcentagem de memória utilizada, o consumo de energia, a detecção de unidades ocupadas sem tráfego de requisições e a identificação de requisições enquanto as unidades de GPU permanecem ociosas. O exemplo usa métricas do tipo DCGM, com o alerta de que os nomes precisam ser adaptados ao exportador efetivamente utilizado.
A experiência confirma que a operação autônoma não significa remover as barreiras. Os conjuntos selecionados de métricas e os diferentes períodos de coleta funcionam como cotas que limitam a carga. Além disso, a opção de remote write deve ser reservada às equipes que realmente mantêm painéis e alertas, enquanto o acesso restrito no momento da consulta pode ser suficiente para equipes pequenas.
Leitura da certi.news
A mudança importante aqui não é adicionar outra ferramenta de monitoramento, mas transferir o controle da visibilidade da equipe de plataforma, sozinha, para o locatário, mantendo o isolamento sob o controle da infraestrutura. Isso resolve simultaneamente um problema de segurança, um problema de custo e um problema de desempenho. A solução, porém, não é automática: a seleção de métricas, o controle de cardinalidade, o tratamento de novas tentativas, a escrita em réplicas de alta disponibilidade e a fixação das versões dos exportadores são responsabilidades operacionais contínuas.
Além disso, os resultados numéricos apresentados, incluindo a redução de cerca de 97% nas séries, referem-se à experiência dos autores e a um «locatário típico», não constituindo uma garantia geral para todos os clusters. Por isso, o padrão deve ser testado com os nomes das métricas, o volume de séries e os períodos de coleta específicos de cada ambiente antes de ser adotado em larga escala. O projeto está disponível sob a licença Apache 2.0, e o material inclui um link para o repositório prometheus-multi-tenant-proxy no GitHub.