O que você tem é um problema de autoridade. Usando o Whisper, cada banco de dados de séries temporais precisa pertencer a um único daemon de cache de carbono, ou você se depara com os problemas de consistência que está vendo. O relé de carbono tenta resolver esse problema enviando a mesma série temporal consistentemente para o mesmo terminal. Você pode fazer isso com o mecanismo de regras baseado em regex ou usando hashing consistente.
Minha recomendação seria não sobrecarregar o problema, escalar até que você não possa mais, e só então escalar. Temos um único relé de carbono que lida com 350.000 métricas a cada 60 segundos sem problemas em um único núcleo de EP Westmere de 5 anos de idade. Se você estiver usando hashing consistente, é uma operação de muito baixo custo para descobrir onde rotear uma métrica downstream. Se você estiver usando uma massa de regras de regex, haverá muitas correspondências de strings e poderá atingir um mural de desempenho muito mais rápido.
O banco de dados do Whisper não tem desempenho especial. Com toda a probabilidade, você vai atingir um gargalo de desempenho de E / S muito antes de o relé começar a causar problemas. Você está pensando demais em sua arquitetura.
Se e quando você realmente precisar se expandir além do que um único nó é capaz de fornecer, você pode rotear para um relé específico baseado na lógica de gerenciamento de configuração do cliente ou pode configurar um ELB que direcione para vários relés cada uma delas é executada no mesmo conjunto de regras e métricas de rota para os mesmos pontos de extremidade. Acredito que isso exigiria que você usasse correspondência baseada em regex, mas o hashing consistente também funcionaria se seus relés fossem da mesma versão; Eu nunca testei essa abordagem.
