Despliegue de estadísticas y grafito de alta disponibilidad, accesible en la web y escalable


17

Me gustaría configurar statsd / graphite para poder registrar aplicaciones JS que se ejecutan en dispositivos HTML (es decir, no en un entorno LAN contenido, y posiblemente con un gran volumen de datos entrantes que no controlo directamente).

Mis limitaciones:

  • el punto de entrada debe hablar HTTP: esto se resuelve mediante un simple proxy HTTP-to-UDP-statsd (por ejemplo, httpstatsd en github)
  • debe resistir la falla de un solo servidor (para combatir la ley de Murphy :)
  • debe ser escalable horizontalmente: escala web, bebé! :)
  • La arquitectura debe ser lo más simple (y barata) posible
  • mis servidores son máquinas virtuales
  • los archivos de datos se almacenarán en un dispositivo archivador (con NFS)
  • Tengo equilibradores de carga de hardware tcp / udp a disposición

En resumen, la ruta de datos: [cliente] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [grafito] - (nfs) -> [archivador]

Mis hallazgos hasta ahora:

  • escalar la parte http2statsd es fácil (demonios sin estado)
  • escalar la parte de statsd no parece sencillo (supongo que terminaría con valores incoherentes en grafito para datos agregados como sum, avg, min, max ...). A menos que el demonio HTTP realice un hashing consistente para fragmentar las claves. Tal vez una idea ... (pero luego está la pregunta de HA)
  • El escalado de la parte de grafito se puede hacer mediante fragmentación (usando el relé de carbono) (pero eso tampoco resuelve la pregunta de HA). Obviamente, varias instancias de susurro no deberían escribir el mismo archivo NFS.
  • escalar la parte del archivador no es parte de la pregunta (pero cuanto menos IO, mejor :)
  • escalar la aplicación web parece obvio (aunque no lo he probado) ya que solo leen los datos compartidos de NFS

Entonces, me preguntaba si alguien tenía experiencias y mejores prácticas para compartir para una implementación sólida de estadísticas / grafito.


Al leer los comentarios en el blog de Etsy sobre StatsD, escriben que alimentan a StatsD 10,000-30,000 métricas cada 10 segundos. Sugeriría vincular un cliente http2statsd a un servidor de estadísticas y compartirlo si el número de métricas enviadas a estadísticas se convierte en un cuello de botella.
pkhamre

¿Implementaste esto al final? Si es así, ¿podría compartir detalles?
gf_

Respuestas:


1

Hay un proxy de estadísticas con hashing consistente, que hace posible distribuir el tráfico de estadísticas entre múltiples agregadores de estadísticas, cada una con su propio conjunto de nombres de métricas. Es un elemento crucial de escalabilidad en su arquitectura, que le permite escalar procesos estadísticos.

El grafito también es complicado, pero es de esperar que no necesite una escala infinita y pueda hacer un fragmentado fino por servicio u otro parámetro estático.

La parte más difícil es escalar la aplicación web, y depende mucho de cuáles son sus consultas gráficas más pesadas. Sin embargo, siempre puede agregar previamente datos para gráficos más difíciles y deshacerse de la mayor parte de la carga.

He estado usando HostedGraphite durante bastante tiempo para evitar todo este dolor, estos muchachos han implementado su propio backend Riak para Carbon y hacen todo el escalado allí.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.