Plataforma de observabilidade multi-tenant operada desde dezembro de 2024, consolidando telemetria de infraestrutura heterogênea em 12+ clientes.
02. Operações de dados
SystemFrame
Plataforma de observabilidade multi-tenant para 12+ clientes e 390+ endpoints, com deploy GitOps e pipeline de alertas integrado a GLPI e ServiceNow.
K3s / Helm ArgoCD Prometheus
-60% MTTR / 50MIN -> 20MIN
-
01 Contexto
A plataforma monitora infraestrutura heterogênea de 12+ clientes: equipamentos Aruba e Meraki, mais Zabbix e GLPI já instalados no parque de cada um. Não havia telemetria consolidada -- cada cliente era uma ilha, e diagnosticar um incidente podia consumir um dia inteiro. Alerta chegava ao time, mas não virava ticket sozinho.
-
02 Ação
Assumi a camada de plataforma com K3s, Helm, ArgoCD e Ansible, sustentando deploy contínuo GitOps. Escrevi 5 exporters customizados para Aruba, Meraki, Zabbix e GLPI, consolidando 390+ endpoints em um formato único. Sobre isso montei o pipeline de alertas ligando Alertmanager a GLPI e ServiceNow, operando 296 regras, e ferramentas de análise sobre as APIs de Prometheus e VictoriaMetrics distribuídas em 2 zonas de disponibilidade.
-
03 Resultado
MTTR caiu de 50 para 20 minutos (-60%), e o tempo de diagnóstico de incidente saiu de 1 dia para 2 horas. O deploy GitOps acumulou mais de 3.500 execuções de CI/CD, com média de cerca de 8 deploys por dia útil.
-
04 Aprendizado
Exporter customizado é dívida de manutenção: cada um vira código próprio que acompanha mudança de firmware e de API do fornecedor. Valeu porque telemetria em formato único foi o que tornou as 296 regras possíveis -- sem isso cada cliente teria seu próprio conjunto de alertas. E alerta que não vira ticket automaticamente não reduz MTTR: o ganho veio da integração com GLPI e ServiceNow, não de detectar mais rápido.
Arquitetura
Cada componente carrega a decisão que foi tomada ali e o que ela custou.
Arraste para explorar o diagrama.
entradaserviçodadosexternoassíncrono
Clique em um componente para ver a decisão tomada ali e o que ela custou.
Ver todas as decisões em texto
- 5 exporters customizados
- Escrever exporters próprios para cada fonte, em vez de adotar um agente único de mercado ou aceitar os formatos nativos.
- Trade-off: Cada exporter é código que precisa acompanhar mudança de firmware e de API do fornecedor. Foi o que permitiu telemetria em formato único entre parques heterogêneos -- e sem isso as 296 regras não existiriam.
- Prometheus / VictoriaMetrics
- Manter VictoriaMetrics ao lado do Prometheus e distribuir em 2 zonas de disponibilidade.
- Trade-off: Dois sistemas de métrica para operar e entender em vez de um. Compra retenção mais longa e sobrevivência à queda de uma zona.
- Alertmanager
- Concentrar as 296 regras no Alertmanager e tratar deduplicação ali, antes de qualquer integração externa.
- Trade-off: As regras viram um artefato grande e centralizado, que exige disciplina para não virar bolo. Evita que cada integração reimplemente sua própria lógica de silenciamento.
- Ferramentas de análise
- Construir ferramentas de consulta sobre as APIs de Prometheus e VictoriaMetrics em vez de depender só de dashboard visual.
- Trade-off: Mais código interno para manter, fora do caminho do produto. Encurtou o diagnóstico de incidente de um dia para duas horas, porque investigar deixou de depender de montar painel na hora.
- ArgoCD
- Deploy por GitOps com ArgoCD e Helm, com o estado desejado versionado em vez de aplicado à mão.
- Trade-off: Toda mudança passa a exigir commit e sincronização, o que é mais lento para um hotfix pontual. Em troca, onboarding de cliente novo virou values de Helm, e o estado do cluster deixou de depender de quem aplicou o que.
- K3s + Helm
- K3s em vez de Kubernetes completo para sustentar o parque multi-tenant.
- Trade-off: Menos componentes de fábrica, então parte do que um cluster gerenciado entrega pronto precisou ser montada. Compensou pelo consumo de recurso menor por cliente e operação mais simples de manter.