- A suíte de produtos Grafana descontinua ou substitui com frequência componentes principais em ciclos curtos, criando uma estrutura difícil de operar no longo prazo
- A cada adoção de uma nova solução, o modo de configuração, a DSL, os charts Helm e os Operators mudam repetidamente, tornando difícil manter um ambiente estável
- Como a compatibilidade com o ecossistema do Prometheus Operator e seus CRDs não é completa,
ServiceMonitor e PodMonitor funcionam, mas recursos essenciais como AlertmanagerConfig ficam sem suporte
- O Mimir 3.0 passou a exigir dependência do Apache Kafka, aumentando muito a complexidade do cluster e a carga operacional
- No Grafana Cloud e em toda a suíte Mimir, Loki e Grafana, locais de configuração e endpoints mudam com facilidade, repetindo uma estrutura difícil de implantar uma vez e usar por muito tempo
Mudanças estruturais frequentes na suíte Grafana
- Funções centrais como Grafana Agent, Flow Mode e OnCall vêm sendo descontinuadas ou substituídas em 1–3 anos de forma recorrente
- A interface do Grafana baseada em Angular foi migrada para React, quebrando uma parte considerável dos dashboards existentes
- Alguns charts Helm já não recebem mais manutenção
Aumento de complexidade com a adoção do Alloy
- O Grafana Alloy, proposto como all-in-one, substituiu o Agent existente, mas teve problemas iniciais de estabilidade
- Usa uma DSL própria (semelhante a HCL), rompendo com o fluxo anterior baseado em YAML
- Com a adição do Alloy Operator, os componentes ficaram ainda mais complexos
Alinhamento incompleto com o ecossistema do Prometheus Operator
- Os padrões de monitoramento no K8s,
ServiceMonitor e PodMonitor, são suportados, mas
PrometheusRules exige configuração adicionalAlertmanagerConfig não é suportado- Como o Mimir usa seu próprio Alertmanager, surgem diferenças de versão e incompatibilidades de implementação
Introdução da dependência de Kafka no Mimir 3.0
- Embora o objetivo fosse maior escalabilidade do que antes,
- a adição obrigatória do Kafka aos componentes centrais elevou bastante a dificuldade operacional
- a passagem de uma instalação única via Helm para a coordenação de múltiplos componentes fez a complexidade crescer exponencialmente
Um ecossistema difícil de usar com estabilidade
- O endpoint de ingestão do Grafana Cloud ficou ainda mais difícil de localizar com a introdução de um novo sistema de gerenciamento
- O ciclo de upgrade e descontinuação dos principais componentes é rápido demais para organizações que querem “monitoramento chato e estável”
- Mais do que problemas da tecnologia em si, a forma de gestão do produto e a velocidade das mudanças acabam sendo os fatores centrais que reduzem a confiabilidade
5 comentários
O dashboard fornecido por padrão no InfluxDB também é razoavelmente útil para usos mais simples.
Concordo com os pontos de que o Grafana não é tão bom, mas existe alguma outra solução que vocês recomendariam que suporte várias fontes de dados tanto quanto o Grafana?
Não há exatamente uma alternativa clara, né.
Parece que na Grafana também havia muita gente querendo promoção ou enfeitar o currículo.
Opiniões do Hacker News
Eu também estou pensando seriamente em abandonar o Grafana de vez pelos mesmos motivos do autor
É cansativo ter que refazer dashboards todo ano, reconfigurar alertas e acompanhar recursos novos
Eu só queria ser avisado quando o serviço caísse e, a menos que a fonte de dados ou as métricas mudem, manter a mesma definição de dashboard por 10 anos
Antes havia só 4 ou 5 links principais na barra lateral, mas agora há submenu demais dentro dos menus, e ficou difícil até encontrar as funções básicas (dashboards, alertas)
É muito ineficiente ter que reaprender a UI toda vez para algo que eu vejo mais ou menos uma vez por mês
Quando a vida útil dos serviços é de só 2 ou 3 anos e você vai empilhando vários produtos, no fim parece que só cresce uma montanha de dívida técnica
É doloroso viver numa realidade em que algo grande precisa ser substituído a cada trimestre
O Mimir é um sistema projetado para lidar com métricas em uma escala completamente diferente
Nesse nível, Kafka realmente é necessário
Mas a maioria dos usuários não precisa desse nível de escalabilidade
Se você não está rodando o Mimir em um cluster Kubernetes dedicado, então é arquitetura exagerada
Na prática, faz mais sentido usar Prometheus
Ele funciona surpreendentemente bem até no modo de instância única, e escalar também é muito fácil
Já usei em várias organizações e projetos pessoais, e sempre fiquei satisfeito
Mas o Amazon Managed Prometheus da AWS é baseado em Cortex, e o OpenObserve já opera em escala de petabytes
O ideal seria algo simples de implantar como um binário único, compatível com OpenTelemetry, e que depois permita migrar para outro provedor OTEL
Se eu fosse montar uma nova solução baseada em OTEL, fico curioso sobre o que seria mais promissor como alternativa a Prometheus/Grafana
Para lidar com logs e traces, eram necessários mais componentes complexos
Então encontramos o GreptimeDB, que permite tratamento unificado de métricas, logs e traces
Coletamos com OpenTelemetry e visualizamos com Grafana
Como é possível criar dashboards com SQL, isso combina bem com as habilidades do time
Graças à estrutura simples, como engenheiro de plataforma isso me deixa satisfeito
Ele foi criado para resolver a complexidade do Grafana e do Elastic, e consegue lidar com logs, métricas, traces, dashboards e alertas em um único contêiner
(o autor é mantenedor do OpenObserve)
É open source, está sendo desenvolvido ativamente e a comunicação da equipe é boa
Muitos usuários estão migrando para ele para evitar a complexidade do Grafana, onde é preciso lidar diretamente com vários backends
(o autor é mantenedor do SigNoz)
Não entendo por que os desenvolvedores ficam mudando a configuração toda semana para correr atrás da tecnologia mais recente
Eu uso a combinação Grafana + Prometheus desde 2017, e ela ainda funciona bem
Atualizo só para versões LTS, uma vez a cada 1 ou 2 anos
Os dashboards continuam perfeitos e não há problema algum
Para a maioria das pessoas, essa combinação entediante, mas estável é a melhor opção
Queria perguntar se vocês estão simplesmente mantendo uma versão antiga
Existe algum construtor de dashboards open source que possa substituir o Grafana? Na empresa também usamos Grafana amplamente
Ou então dá para usar os templates de console do Prometheus ou os dashboards embutidos do VictoriaMetrics, mas os recursos são bem mais limitados
O dashboard do Grafana em si é bem agradável de usar com a combinação VictoriaMetrics + ClickHouse
Só lembro vagamente de nomes como RRD e Nagios
A mudança constante do Grafana acabou me deixando acostumado com isso
A cada major release algum dashboard quebra ou a UI muda, mas eu simplesmente passei a aceitar
O verdadeiro problema é o lock-in de PromQL no Prometheus
Se você mudar o nome das métricas, precisa alterar todas as regras, alertas e dashboards
O PromQL quase nunca gera erros além de erro de sintaxe, então é preciso validar com ferramentas como pint
Em implantações de servidor único, costumo usar Prometheus Pushgateway + Grafana como template de docker-compose
É simples e funciona bem, mas quando o volume de métricas cresce a complexidade explode
Se o Prometheus tivesse mantido um formato de transporte mais eficiente, esse problema seria menor
Se houvesse um formato binário de métricas compacto em vez do formato de texto, ele conseguiria lidar com centenas de milhões de labels sem dificuldade
O SigNoz é uma boa escolha e está sendo desenvolvido ativamente
Antes eu gastava muito com plataformas de observabilidade em nuvem, mas agora resolvo isso com SigNoz self-hosted em uma máquina da Hetzner por US$ 10 por mês
Prometheus e Grafana passaram a mirar, cada um, em uma solução full stack, e então o OTEL surgiu e deixou o cenário mais complicado
O OTEL é um protocolo para métricas, traces e logs, mas não existe um único banco de dados que suporte tudo isso
A maioria combina Prometheus (métricas) + OpenSearch (logs)
No fim, o OTEL acaba exigindo troca e reconfiguração de coletores