Implementação de statsd e grafite altamente acessível, acessível na Web e escalável

Question

Gostaria de configurar o statsd / graphite para que eu possa registrar aplicativos JS em execução em dispositivos HTML (ou seja, não em um ambiente de LAN contido e, possivelmente, com um grande volume de dados recebidos que não controle diretamente) .

Minhas restrições:

• ponto de entrada deve falar HTTP: isso é resolvido por um simples proxy HTTP-to-UDP-statsd (por exemplo, httpstatsd no github)
• deve resistir ao fracasso de um único servidor (para combater a lei de Murphy):
• deve ser escalável horizontalmente: webscale, baby! :)
• a arquitetura deve ser mantida tão simples (e barata) quanto possível
• meus servidores são máquinas virtuais
• os arquivos de dados serão armazenados em um dispositivo de arquivamento (com NFS)
• Eu tenho balanceadores de carga de hardware tcp / udp à disposição

Em resumo, o caminho dos dados: [cliente] - (http) - > [http2statsd] - (udp) - > [statsd] - (tcp) - > [grafite] - (nfs) - > [arquivador]

Minhas descobertas até agora:

• escalar a parte http2statsd é fácil (daemons sem estado)
• escalar a parte statsd não parece simples (acho que acabaria com valores incoerentes no grafite para dados agregados como sum, avg, min, max ...). A menos que o daemon HTTP faça hashing consistente para fragmentar as chaves. Talvez uma ideia ... (mas depois tem a pergunta HA)
• escalar a parte de grafite pode ser feito através de sharding (usando carbono-relay) (mas isso também não resolve a questão de HA). Obviamente, várias instâncias de sussurro não devem escrever o mesmo arquivo NFS.
• dimensionar a parte do arquivador não faz parte da pergunta (mas quanto menos E / S, melhor:)
• dimensionar o aplicativo da Web parece óbvio (embora eu não tenha testado), pois eles só lêem os dados do NFS compartilhado

Então, eu queria saber se alguém tinha experiências e práticas recomendadas para compartilhar com uma implantação sólida de statsd / grafite?

    

Answer 1

Há um proxy statsd com hashing consistente, o que torna possível espalhar o tráfego statsd entre vários agregadores statsd, cada um usando seu próprio conjunto de nomes de métricas. É um elemento de escalabilidade crucial em sua arquitetura, permitindo dimensionar os processos do statsd.

Grafite também é complicado, mas esperamos que você não precise de escala infinita e possa fazer muito bem sharding por serviço ou algum outro parâmetro estático.

A parte mais difícil é o dimensionamento da webapp, e isso depende muito de quais são suas consultas mais pesadas. No entanto, você sempre pode pré-agregar dados para os gráficos mais difíceis e se livrar da maior parte da carga.

Eu uso o HostedGraphite há algum tempo para evitar toda essa dor, esses caras implementaram seu próprio backend do Riak para o Carbon e fazem todo o dimensionamento lá.