Como um banco abriu a caixa-preta do CI/CD com GitLab, Prometheus e Grafana (e você pode fazer o mesmo)

Seus pipelines de CI/CD estão rodando no escuro? Em ambientes enterprise com GitLab Self-Managed, a ausência de métricas confiáveis transforma deploys em apostas — e as apostas, mais cedo ou mais tarde, cobram seu preço em atrasos, frustração e caos operacional.

O ponto cego: quando a API do GitLab não basta

O GitLab Self-Managed expõe informações via API, mas consumir esses dados em tempo real, cruzá-los com métricas de runners e armazená-los para análise histórica exige uma camada dedicada. Ferramentas de APM comerciais resolvem parte do problema — mas o custo e a complexidade de integração nem sempre cabem no orçamento ou no contexto regulatório.

A alternativa é uma stack open-source modular, que entrega:

• Métricas históricas de duração, status e tendências dos pipelines
• Correlação com uso real de recursos — CPU, memória, disco — dos nós que executam os runners
• Alertas configuráveis pela própria equipe, sem depender de times externos
• Visibilidade sobre as métricas DORA: frequência de deploy, lead time e drift de ambiente

Arquitetura: três pilares e um fluxo contínuo

O desenho segue o padrão clássico de observabilidade — coleta, armazenamento e visualização — com componentes de propósito específico. Nada de genérico, nada de improviso.

Os protagonistas da stack

• gitlab-ci-pipelines-exporter — agente open-source mantido por mvisonneau que consulta a API do GitLab com token read_api e expõe métricas no formato Prometheus. Duração de pipeline, status por job, tempo de fila, uso de artefatos, cobertura de testes, frequência de deploy e até desvios de configuração de ambiente.
• Node Exporter — coleta métricas de hardware e sistema operacional dos nós do Kubernetes.
• Prometheus — banco de séries temporais que armazena e consulta todas as métricas.
• Grafana — painéis pré-configurados que transformam números em gráficos acionáveis.

Fluxo essencial: GitLab → Exporter → Prometheus → Grafana. Todo o deploy fica isolado em um namespace próprio no Kubernetes, com Network Policy restringindo o tráfego entre componentes e bloqueando acessos externos indevidos.

Mãos na massa: deploy no Kubernetes sem atalhos

Você precisa de um cluster Kubernetes funcional e de um token de acesso à API do GitLab com permissão read_api. Os passos a seguir destacam as decisões de segurança que separam um teste de laboratório de uma implementação enterprise real.

1. Namespace e secret do token — com atenção redobrada

O isolamento começa no namespace. O token do GitLab jamais deve ser armazenado em texto puro.

⚠️ Em produção: utilize um operador de External Secrets com HashiCorp Vault ou AWS Secrets Manager. Faça rotação automática a cada 90 dias e crie um usuário GitLab dedicado com acesso restrito apenas aos projetos monitorados.

2. Deploy do exporter

O gitlab-ci-pipelines-exporter é configurado via variáveis de ambiente, apontando para a URL e token do GitLab. Simples, direto, sem mistério.

3. Prometheus: coleta das métricas

Com o Prometheus Operator, basta um ServiceMonitor. Sem ele, adicione o target manualmente no prometheus.yml. O Node Exporter normalmente já está sendo coletado se você tem um Prometheus padrão no cluster.

4. Grafana: dashboards como código

Os quatro painéis essenciais são provisionados automaticamente via ConfigMap com os JSONs prontos. Monte os ConfigMaps com a label grafana_dashboard: "1" e o Grafana os carregará sem intervenção manual.

5. Network Policy: isolamento é a regra

A política de rede garante que apenas o Prometheus acesse as métricas do exporter. Para o Grafana, configure um Ingress com TLS e autenticação forte — nunca exponha sem proteção.

Métricas que transformam suposição em decisão

Dados sem apresentação adequada são apenas ruído. Os painéis sugeridos formam o coração da solução e respondem às perguntas que realmente importam.

Pipeline Overview

• Duração do pipeline (média, p95, p99) — suas builds estão ficando mais lentas ao longo do tempo?
• Taxa de sucesso — percentual de pipelines bem-sucedidos por branch ou projeto
• Tempo de fila — quanto os jobs esperam por um runner disponível
• Distribuição de status — quantos jobs passando, falhando, cancelados ou pendentes

Job Performance

• Wall time vs. CPU time — identifica jobs que consomem muito processamento sem eficiência, candidatos imediatos a otimização
• Tamanho de artefatos — impacto real no armazenamento e no tempo de download
• Tendências de cobertura de testes — a qualidade do código evoluindo (ou não) diante dos seus olhos

Runner & Infraestrutura

• Utilização de runners — máximo de workers, quantos ocupados, quantos disponíveis
• Pressão sobre recursos dos nós — alerta quando CPU, memória ou disco estão no limite
• Atraso no agendamento — diferença entre criação do job e início da execução, sinal claro de falta de capacidade

Deployment Frequency (DORA)

• Frequência de deploy — quantas vezes a aplicação chega à produção
• Lead time — tempo do commit até o deploy efetivo
• Environment drift — compara a configuração real do ambiente com a declarada no GitLab

Segurança enterprise: o que nunca ignorar

Uma ferramenta poderosa se torna uma porta de entrada quando mal configurada. O guia original da GitLab alerta para pontos que precisam de endurecimento imediato.

Autenticação no Grafana

A configuração inicial permite acesso anônimo — útil para testes, inaceitável em produção. Desabilite imediatamente o auth.anonymous, integre com LDAP ou OAuth2 e exponha o Grafana apenas via HTTPS.

Proteção do token GitLab

Princípio do menor privilégio: token de acesso pessoal com escopo mínimo (read_api), associado a um usuário de serviço que enxerga apenas os projetos necessários. External Secrets. Rotação automática. Sem exceções.

Rate limiting da API

O exporter consulta a API periodicamente. Ajuste maximum_requests_per_second — um valor típico é 10 — para não sobrecarregar o GitLab e evitar bloqueios.

Rede segregada

Reforce a Network Policy. O Grafana deve ser acessado apenas por meio de Ingress com TLS e, idealmente, protegido por VPN corporativa.

Um caso real: como um banco abriu a caixa-preta

O guia da GitLab relata a jornada de uma instituição financeira com mais de 500 projetos ativos, múltiplos runners auto-escaláveis e rigorosos requisitos de auditoria.

Antes: o time de DevOps gastava horas toda semana analisando logs para encontrar gargalos. Falhas intermitentes eram um mistério — ninguém conseguia associá-las aos períodos de pico nos runners.

A stack open-source rodou por seis meses sem incidentes, validando sua robustez mesmo em ambiente regulado.

Olhando adiante: o futuro da observabilidade de CI/CD

A união de métricas de pipeline e infraestrutura é o presente. O futuro reserva três movimentos que vão redefinir essa prática:

1. Observabilidade preditiva com IA — modelos treinados em séries históricas capazes de prever falhas antes do commit, acionando ações corretivas automaticamente
2. OpenTelemetry como padrão — fluxo de CI/CD instrumentado com tracing distribuído, rastreando o impacto de cada alteração desde o push até a produção
3. Observabilidade como código — stack declarativa, versionada e auditável, eliminando a diferença entre ambientes e provendo uma única fonte da verdade

Resumo prático

A stack GitLab + Prometheus + Grafana em Kubernetes oferece observabilidade completa de CI/CD sem custo de licenciamento. Em uma tarde, você implanta o exporter, conecta ao Prometheus, provisiona os dashboards no Grafana e aplica as Network Policies. O resultado: métricas DORA visíveis, alertas inteligentes e a capacidade de otimizar pipelines com dados — não com achismos.

A visibilidade sobre o pipeline não é mais um luxo. É condição para sobreviver à próxima entrega. E, como você viu, está ao alcance de um simples kubectl apply. O guia completo está disponível na documentação oficial da GitLab — e a stack é inteiramente open-source.