Eu gostaria de configurar o statsd / grafite para poder registrar aplicativos JS em execução em dispositivos HTML (ou seja, não em um ambiente LAN contido e, possivelmente, com um grande volume de dados recebidos que eu não controle diretamente).
Minhas restrições:
- o ponto de entrada deve falar HTTP: isso é resolvido por um simples proxy HTTP-para-UDP-statsd (por exemplo, httpstatsd on github)
- deve resistir à falha de um único servidor (para combater a lei de Murphy :)
- deve ser escalável horizontalmente: escala da web, bebê! :)
- a arquitetura deve ser mantida o mais simples (e barata) possível
- meus servidores são máquinas virtuais
- os arquivos de dados serão armazenados em um dispositivo de arquivador (com NFS)
- 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:
- é fácil dimensionar a parte http2statsd (daemons sem estado)
- escalar a parte statsd não parece simples (acho que acabaria com valores incoerentes em grafite para dados agregados como sum, avg, min, max ...). A menos que o daemon HTTP faça hash consistente para fragmentar as chaves. Talvez uma ideia ... (mas depois há a pergunta sobre HA)
- O dimensionamento da parte de grafite pode ser feito através de sharding (usando relé de carbono) (mas isso também não resolve a questão da HA). Obviamente, várias instâncias de sussurro não devem gravar o mesmo arquivo NFS.
- escalar a parte do arquivador não faz parte da questão (mas quanto menos IO, melhor :)
- dimensionar o aplicativo da Web parece óbvio (embora eu não tenha testado), pois eles apenas lêem os dados compartilhados do NFS
Então, eu queria saber se alguém teria experiências e práticas recomendadas para compartilhar para uma implantação sólida de statsd / grafite?
http
high-availability
scalability
graphite
statsd
David142
fonte
fonte
Respostas:
Existe um proxy statsd com hash consistente, que permite 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 que você dimensione processos statsd.
O grafite também é complicado, mas espero que você não precise de escala infinita e possa fazer sharding por serviço ou algum outro parâmetro estático.
A parte mais difícil é dimensionar o aplicativo da web e depende muito de quais são suas consultas gráficas 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.
Estou usando o HostedGraphite há algum tempo para evitar toda essa dor, esses caras implementaram seu próprio back-end Riak para Carbon e fazem todo o dimensionamento lá.
fonte