Penyebaran statsd dan grafit yang mudah diakses, dapat diakses oleh Web, dan dapat diskalakan

Saya ingin mengatur statsd / graphite sehingga saya dapat mencatat aplikasi JS yang berjalan pada perangkat HTML (mis. Tidak di lingkungan LAN yang terkandung, dan mungkin dengan volume besar data yang masuk yang tidak saya kontrol langsung).

Kendala saya:

titik masuk harus berbicara HTTP: ini diselesaikan dengan proxy HTTP-to-UDP-statsd sederhana (mis. httpstatsd di github)
harus menolak kegagalan satu server (untuk melawan hukum Murphy :)
harus terukur secara horizontal: webscale, sayang! :)
arsitektur harus dijaga sesederhana mungkin (dan semurah)
server saya adalah mesin virtual
file data akan disimpan pada alat filer (dengan NFS)
Saya memiliki penyeimbang beban perangkat keras tcp / udp siap membantu

Singkatnya, jalur data: [klien] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [graphite] - (nfs) -> [filer]

Temuan saya sejauh ini:

menskalakan bagian http2statsd itu mudah (daemon stateless)
penskalaan bagian statsd sepertinya tidak langsung (saya kira saya akan berakhir dengan nilai yang tidak jelas dalam grafit untuk data agregat seperti jumlah, rata-rata, minimum, maks ...). Kecuali jika daemon HTTP melakukan hashing yang konsisten untuk shard kunci. Mungkin sebuah ide ... (tapi kemudian ada pertanyaan HA)
penskalaan bagian grafit dapat dilakukan melalui sharding (menggunakan carbon-relay) (tapi itu tidak menyelesaikan pertanyaan HA juga). Jelas beberapa contoh bisikan tidak boleh menulis file NFS yang sama.
scaling bagian filer bukan bagian dari pertanyaan (tetapi semakin sedikit IO, semakin baik :)
penskalaan webapp tampaknya jelas (walaupun saya belum menguji) karena mereka hanya membaca data NFS yang dibagikan

Jadi saya bertanya-tanya apakah ada yang punya pengalaman dan praktik terbaik untuk berbagi untuk penyebaran statsd / graphite yang solid?

— David142
sumber

Membaca komentar di posting blog Etsy tentang StatsD, mereka menulis bahwa mereka memberi makan StatsD 10.000-30.000 metrik setiap 10 detik. Saya akan menyarankan menghubungkan satu klien http2statsd ke satu server statsd dan beling jika jumlah metrik yang dikirim ke statsd menjadi hambatan.

— pkhamre

Apakah Anda menerapkan ini pada akhirnya? Jika demikian, dapatkah Anda membagikan detail?

— gf_

Ada proxy statsd dengan hashing yang konsisten, yang memungkinkan penyebaran traffic statsd di antara beberapa agregator statsd, masing-masing menggunakan set nama metrik sendiri. Ini adalah elemen skalabilitas penting dalam arsitektur Anda, memungkinkan Anda untuk skala proses statsd.

Graphite juga rumit, tetapi mudah-mudahan Anda tidak perlu skala yang tak terbatas dan dapat melakukan sharding dengan layanan atau parameter statis lainnya.

Bagian tersulit adalah scaling webapp, dan itu sangat tergantung pada apa permintaan grafik terberat Anda. Namun Anda selalu dapat melakukan pra-agregat data untuk grafik yang paling sulit dan menyingkirkan sebagian besar beban.

Saya telah menggunakan HostedGraphite untuk beberapa waktu untuk menghindari semua rasa sakit ini, orang-orang ini telah mengimplementasikan backend Riak mereka sendiri untuk Karbon dan melakukan semua penskalaan di sana.

— DukeLion
sumber