carbon c relay
3.8.1 (28-04-2024)
carbon-c-relay -f file config [ options ... ]
Karbon-C-Relay menerima, membersihkan, mencocokkan, menulis ulang, maju dan mengumpulkan metrik grafit dengan mendengarkan koneksi yang masuk dan menyampaikan pesan ke server lain yang ditentukan dalam konfigurasinya. Fungsionalitas inti adalah untuk merutekan pesan melalui aturan yang fleksibel ke tujuan yang diinginkan.
Carbon-C-Relay adalah program sederhana yang membaca informasi peruteannya dari sebuah file. Argumen baris perintah memungkinkan untuk mengatur lokasi untuk file ini, serta jumlah operator (utas pekerja) untuk digunakan untuk membaca data dari koneksi yang masuk dan meneruskannya ke tujuan yang tepat. File rute mendukung dua konstruksi utama: kelompok dan kecocokan. Metrik data host definisi pertama dapat dikirim ke, yang terakhir menentukan metrik mana yang harus dikirim ke cluster mana. Aturan agregasi dipandang sebagai pertandingan. Penulisan ulang adalah tindakan yang secara langsung mempengaruhi metrik pada titik di mana mereka muncul dalam konfigurasi.
Untuk setiap metrik yang diterima oleh relay, pembersihan dilakukan. Perubahan berikut dilakukan sebelum pertandingan, agregat, atau menulis ulang aturan melihat metrik:
[0-9a-zA-Z-_:#] , tetapi dapat ditimpa pada baris perintah. Perhatikan bahwa tag (bila ada dan diizinkan) tidak diproses dengan cara ini. Opsi-opsi ini mengontrol perilaku karbon-C-relay .
-v : Cetak string dan keluar versi.
-d : Aktifkan mode debug, ini mencetak statistik untuk stdout dan mencetak pesan tambahan tentang beberapa situasi yang dihadapi oleh relay yang biasanya terlalu bertele -tele untuk diaktifkan. Saat dikombinasikan dengan -t (mode uji) Ini juga mencetak rute rintik dan konten cincin yang konsisten.
-s : Aktifkan mode pengiriman. Dalam mode ini, statistik internal tidak dihasilkan. Sebaliknya, tekanan antrian dan penurunan metrik dilaporkan pada stdout. Mode ini berguna saat digunakan sebagai relai pengiriman yang 'pekerjaan mana hanya untuk meneruskan (satu set) relay utama. Statistik tentang relay pengiriman dalam kasus ini tidak diperlukan, dan dapat dengan mudah menyebabkan banjir metrik yang tidak diinginkan misalnya ketika digunakan pada setiap host secara lokal.
-S : Aktifkan mode seperti iostat di mana setiap detik keadaan statistik saat ini dilaporkan. Ini menyiratkan mode pengiriman -s .
-t : mode uji. Mode ini tidak melakukan routing sama sekali, tetapi malah membaca input dari Stdin dan mencetak tindakan apa yang akan diambil mengingat konfigurasi yang dimuat. Mode ini sangat berguna untuk menguji rute relai untuk sintaks ekspresi reguler dll. Ini juga memungkinkan untuk memberikan wawasan tentang bagaimana perutean diterapkan dalam konfigurasi yang kompleks, karena itu menunjukkan penulisan ulang dan agregat yang terjadi juga. Ketika -t diulang, relai hanya akan menguji konfigurasi untuk validitas dan keluar segera setelah itu. Setiap output standar ditekan dalam mode ini, membuatnya ideal untuk memulai skrip untuk menguji konfigurasi (baru).
-f -File Config : Baca Konfigurasi dari Config-File . Konfigurasi terdiri dari cluster dan rute. Lihat Sintaks Konfigurasi untuk informasi lebih lanjut tentang opsi dan sintaksis file ini.
-l Log-File : Gunakan file log untuk menulis pesan. Tanpa opsi ini, relai menulis baik ke Stdout dan Stderr . Saat masuk ke file, semua pesan diawali dengan MSG ketika mereka dikirim ke stdout , dan ERR ketika mereka dikirim ke Stderr .
-p Port : Dengarkan koneksi di port port. Nomor port digunakan untuk soket TCP , UDP dan UNIX sockets . Dalam kasus terakhir, file soket berisi nomor port. Default port ke tahun 2003 , yang juga digunakan oleh carbon-cache.py asli. Perhatikan bahwa ini hanya berlaku untuk default, ketika arahan listen ada di konfigurasi, pengaturan ini diabaikan.
-w Pekerja : Gunakan jumlah utas pekerja . Jumlah default pekerja sama dengan jumlah inti CPU yang terdeteksi. Masuk akal untuk mengurangi angka ini pada banyak mesin inti, atau ketika lalu lintas rendah.
-b Batchsize : Tetapkan jumlah metrik yang dikirim ke server jarak jauh sekaligus ke Batchsize . Ketika relai mengirimkan metrik ke server, itu akan mengambil metrik batchsize dari antrian metrik yang tertunda menunggu server itu dan mengirimnya satu per satu. Ukuran batch akan memiliki dampak minimal pada pengiriman kinerja, tetapi mengontrol jumlah kontensi kunci pada antrian. Standarnya adalah 2500 .
-q Queuesize : Setiap server dari konfigurasi tempat relai akan mengirim metrik ke, memiliki antrian yang terkait dengannya. Antrian ini memungkinkan gangguan dan semburan untuk ditangani. Ukuran antrian ini akan diatur ke antrian yang memungkinkan jumlah metrik untuk disimpan dalam antrian sebelum meluap, dan relai mulai menjatuhkan metrik. Semakin besar antrian, lebih banyak metrik dapat diserap, tetapi juga lebih banyak memori akan digunakan oleh relai. Ukuran antrian default adalah 25000 .
-L WALLS : Mengatur mount max kios ke kios sebelum relai mulai menjatuhkan metrik untuk server. Ketika antrian terisi, relai menggunakan mekanisme yang disebut Stalling untuk menandakan klien (menulis ke relai) dari acara ini. Khususnya ketika klien mengirimkan sejumlah besar metrik dalam waktu yang sangat singkat (meledak), stalling dapat membantu menghindari menjatuhkan metrik, karena klien hanya perlu melambat sebentar, yang dalam banyak kasus dimungkinkan (misalnya saat mengencangkan file dengan nc (1)). Namun, perilaku ini juga dapat menghalangi, penulis yang macet secara artifisial yang tidak dapat menghentikannya dengan mudah. Untuk ini kios dapat diatur dari 0 hingga 15 , di mana setiap kios dapat memakan waktu sekitar 1 detik pada klien. Nilai default diatur ke 4 , yang ditujukan untuk skenario gangguan sesekali dan upaya maksimal untuk tidak kehilangan metrik dengan memperlambat klien yang sedang.
-C CacertPath : Baca CA CERTS (untuk digunakan dengan koneksi TLS/SSL) dari jalur atau file yang diberikan. Saat tidak diberikan, lokasi default digunakan. Verfication yang ketat dari rekan dilakukan, jadi ketika menggunakan sertifikat yang ditandatangani sendiri, pastikan untuk memasukkan sertifikat CA di lokasi default, atau menyediakan jalur ke sertifikat menggunakan opsi ini.
-T Timeout : Menentukan batas waktu IO dalam milidetik yang digunakan untuk koneksi server. Standarnya adalah 600 milidetik, tetapi mungkin perlu meningkat ketika tautan WAN digunakan untuk server target. Nilai yang relatif rendah untuk batas waktu koneksi memungkinkan relai untuk dengan cepat menetapkan server tidak dapat dijangkau, dan dengan demikian strategi failover untuk menendang sebelum antrian berjalan tinggi.
-c Chars : Menentukan karakter yang berada di sebelah [A-Za-z0-9] diizinkan dalam metrik ke chars . Karakter apa pun yang tidak ada dalam daftar ini, digantikan oleh relai dengan _ (garis bawah). Daftar default karakter yang diizinkan adalah -_:# .
-m Panjang : Membatasi nama metrik yang panjangnya panjang. Setiap baris yang berisi nama metrik yang lebih besar dari ini akan dibuang.
-M Panjang membatasi input ke garis paling panjang byte. Setiap garis berlebih akan dibuang. Perhatikan bahwa -m harus lebih kecil dari nilai ini.
-H nama host : override nama host ditentukan oleh panggilan ke gethostname (3) dengan hostname . Nama host digunakan terutama dalam metrik statistik carbon.relays.<hostname>.<...>
-B Backlog : Mengatur Koneksi TCP Dengarkan Backlog ke Backlog Connections. Nilai default adalah 32 tetapi pada server yang menerima banyak koneksi bersamaan, pengaturan ini kemungkinan perlu ditingkatkan untuk menghindari koneksi yang ditolak kesalahan pada klien.
-U bufsize : Mengatur soket mengirim/menerima ukuran buffer dalam byte, untuk skenario TCP dan UDP. Saat tidak ada, default OS digunakan. Maksimum juga ditentukan oleh OS. Ukuran diatur menggunakan setsockopt dengan flags so_rcvbuf dan so_sndbuf. Pengaturan ukuran ini mungkin diperlukan untuk skenario volume besar, yang juga -B mungkin berlaku. Memeriksa RECV-Q dan nilai kesalahan menerima dari NetStat memberikan petunjuk yang baik tentang penggunaan buffer.
-E : Nonaktifkan koneksi yang masuk menganggur. Secara default relai melepaskan koneksi klien idle setelah 10 menit. Ini melakukan ini untuk mencegah sumber daya menyumbat ketika klien yang salah atau jahat terus membuka koneksi tanpa menutupnya. Ini biasanya mencegah kehabisan deskriptor file. Namun, untuk beberapa skenario, tidak diinginkan untuk koneksi idle untuk terputus, maka melewati bendera ini akan menonaktifkan perilaku ini.
-D : Deamonise ke latar belakang setelah startup. Opsi ini membutuhkan bendera -l dan -P untuk diatur juga.
-P Pidfile : Tulis PID proses relai ke file yang disebut Pidfile . Ini khususnya berguna ketika dikelompokkan dalam kombinasi dengan manajer init.
-O Threshold : Jumlah minimum aturan yang dapat ditemukan sebelum mencoba mengoptimalkan aturan. Standarnya adalah 50 , untuk menonaktifkan pengoptimal, gunakan -1 , untuk selalu menjalankan Optimiser Gunakan 0 . Optimiser mencoba mengelompokkan aturan untuk menghindari menghabiskan waktu yang berlebihan untuk ekspresi pencocokan.
File konfigurasi mendukung sintaks berikut, di mana komentar dimulai dengan karakter # dan dapat muncul pada posisi apa pun pada baris dan menekan input sampai akhir baris itu:
cluster <name>
< <forward | any_of | failover> [useall] |
<carbon_ch | fnv1a_ch | jump_fnv1a_ch> [replication <count>] [dynamic] >
<host[:port][=instance] [proto <udp | tcp>]
[type linemode]
[transport <plain | gzip | lz4 | snappy>
[ssl | mtls <pemcert> <pemkey>]]> ...
;
cluster <name>
file [ip]
</path/to/file> ...
;
match
<* | expression ...>
[validate <expression> else <log | drop>]
send to <cluster ... | blackhole>
[stop]
;
rewrite <expression>
into <replacement>
;
aggregate
<expression> ...
every <interval> seconds
expire after <expiration> seconds
[timestamp at <start | middle | end> of bucket]
compute <sum | count | max | min | average |
median | percentile<%> | variance | stddev> write to
<metric>
[compute ...]
[send to <cluster ...>]
[stop]
;
send statistics to <cluster ...>
[stop]
;
statistics
[submit every <interval> seconds]
[reset counters after interval]
[prefix with <prefix>]
[send to <cluster ...>]
[stop]
;
listen
type linemode [transport <plain | gzip | lz4 | snappy>
[<ssl | mtls> <pemcert>
[protomin <tlsproto>] [protomax <tlsproto>]
[ciphers <ssl-ciphers>] [ciphersuites <tls-suite>]
]
]
<<interface[:port] | port> proto <udp | tcp>> ...
</ptah/to/file proto unix> ...
;
# tlsproto: <ssl3 | tls1.0 | tls1.1 | tls1.2 | tls1.3>
# ssl-ciphers: see ciphers(1)
# tls-suite: see SSL_CTX_set_ciphersuites(3)
include </path/to/file/or/glob>
;
Beberapa cluster dapat didefinisikan, dan tidak perlu direferensikan oleh aturan kecocokan. Semua cluster menunjuk ke satu atau lebih host, kecuali cluster file yang ditulis ke file dalam sistem file lokal. host dapat berupa alamat IPv4 atau IPv6, atau nama host. Karena host diikuti oleh opsional : dan port, untuk alamat IPv6 untuk tidak ditafsirkan secara salah, baik port harus diberikan, atau alamat IPv6 yang dikelilingi oleh kurung, misalnya [::1] . Klausul transport dan proto opsional dapat digunakan untuk membungkus koneksi dalam lapisan kompresi atau enkripsi atau menentukan penggunaan UDP atau TCP untuk terhubung ke server jarak jauh. Saat menghilangkan koneksi default ke koneksi TCP biasa. type hanya bisa menjadi linemode saat ini, misalnya mode acar Python tidak didukung.
Nama host DNS diselesaikan ke satu alamat, sesuai dengan aturan preferensi dalam RFC 3484. any_of , kluster failover dan forward memiliki bendera useall eksplisit yang memungkinkan ekspansi untuk nama host yang diselesaikan ke banyak alamat. Menggunakan opsi ini, setiap alamat jenis apa pun menjadi tujuan cluster. Ini berarti misalnya bahwa alamat IPv4 dan IPv6 ditambahkan.
Ada dua kelompok jenis cluster, kelompok penerusan sederhana dan kelompok hashing yang konsisten.
forward dan file Cluster
Cluster forward dan file cukup mengirim semua yang mereka terima ke anggota yang ditentukan (alamat host atau file). Ketika sebuah cluster memiliki banyak anggota, semua metrik yang masuk dikirim ke semua anggota, pada dasarnya menduplikasi aliran metrik input di semua anggota.
any_of cluster
Cluster any_of adalah varian kecil dari cluster forward , tetapi alih -alih mengirim metrik input ke semua anggota yang ditentukan, ia mengirimkan setiap metrik yang masuk ke hanya satu anggota yang ditentukan. Tujuan dari ini adalah skenario seimbang beban di mana salah satu anggota dapat menerima metrik apa pun. Seperti yang disarankan any_of , ketika salah satu anggota menjadi tidak terjangkau, anggota yang tersedia yang tersisa akan segera menerima aliran metrik input penuh. Ini secara khusus berarti bahwa ketika 4 anggota digunakan, masing -masing akan menerima sekitar 25% dari metrik input. Ketika satu anggota menjadi tidak tersedia (misalnya gangguan jaringan, atau restart layanan), masing -masing 3 anggota sisanya akan menerima sekitar 25% / 3 = ~ 8% lebih banyak lalu lintas (33%). Atau, mereka akan menerima 1/3 input total. Saat merancang kapasitas cluster, orang harus memperhitungkan bahwa dalam kasus yang paling ekstrem, anggota akhir yang tersisa akan menerima semua lalu lintas input.
Cluster any_of secara khusus dapat berguna ketika cluster menunjuk ke relay atau cache lainnya. Ketika digunakan dengan relay lain, secara efektif memuat keseimbangan, dan segera beradaptasi dengan ketidakmampuan target. Saat digunakan dengan cache, ada detail kecil tentang cara kerja any_of , yang membuatnya sangat cocok. Implementasi router ini bukan untuk melakukan round-robin atas setiap anggota yang tersedia, tetapi menggunakan strategi hashing yang konsisten untuk memberikan metrik yang sama ke tujuan yang sama sepanjang waktu. Ini membantu cache, dan membuatnya lebih mudah untuk mengambil titik datapoint yang tidak berkomitmen (dari satu cache), tetapi masih memungkinkan untuk restart yang bergulir dari cache. Ketika seorang anggota menjadi tidak tersedia, tujuan hash tidak diubah, tetapi lalu lintas yang ditakdirkan untuk simpul yang tidak tersedia tersebar secara merata di atas node yang tersedia.
Cluster failover
Cluster failover seperti cluster any_of , tetapi menempel pada urutan di mana server didefinisikan. Ini untuk mengimplementasikan skenario failover murni antar server. Semua metrik dikirim ke paling banyak 1 anggota, jadi tidak ada hashing atau balancing yang terjadi. Misalnya, cluster failover dengan dua anggota hanya akan mengirim metrik ke anggota kedua ketika anggota pertama menjadi tidak tersedia. Segera setelah anggota pertama kembali, semua metrik dikirim ke simpul pertama lagi.
cluster carbon_ch
Cluster carbon_ch mengirimkan metrik ke anggota yang bertanggung jawab sesuai dengan algoritma hash yang konsisten seperti yang digunakan dalam relai karbon python asli. Beberapa anggota dimungkinkan jika replikasi diatur ke nilai lebih tinggi dari 1. Ketika dynamic ditetapkan, kegagalan salah satu server tidak mengakibatkan metrik dijatuhkan untuk server itu, tetapi metrik yang tidak terkirim dikirim ke server lain di cluster agar metrik tidak hilang. Ini paling berguna saat replikasi adalah 1.
Perhitungan hashring, yang mendefinisikan cara di mana metrik didistribusikan, didasarkan pada host server (atau alamat IP) dan instance opsional anggota. Ini berarti bahwa menggunakan carbon_ch dua target pada port yang berbeda tetapi pada host yang sama akan memetakan ke hashkey yang sama, yang berarti tidak ada distribusi metrik yang terjadi. Contohnya digunakan untuk memperbaiki situasi itu. Sebuah contoh ditambahkan ke anggota setelah port, dan dipisahkan oleh tanda yang sama, mis. 127.0.0.1:2006=a misalnya a . Contoh adalah konsep yang diperkenalkan oleh cache karbon python asli, dan perlu digunakan sesuai dengan konfigurasi itu.
Hash yang konsisten konsisten dalam arti bahwa penghapusan anggota dari cluster tidak boleh menghasilkan pemetaan ulang lengkap dari semua metrik ke anggota, tetapi sebaliknya hanya menambahkan metrik dari anggota yang dihapus ke semua anggota yang tersisa, kira-kira masing-masing mendapat bagian yang adil. Baliknya, ketika anggota ditambahkan, masing -masing anggota harus melihat subset metriknya sekarang ditujukan kepada anggota baru. Ini adalah keuntungan penting dibandingkan hash normal, di mana setiap penghapusan atau penambahan anggota (juga melalui misalnya perubahan alamat IP atau nama host mereka) akan menyebabkan pemetaan ulang penuh semua metrik pada semua metrik yang tersedia.
cluster fnv1a_ch
Cluster fnv1a_ch adalah peningkatan yang tidak kompatibel untuk carbon_ch yang diperkenalkan oleh karbon-C-relay. Ini menggunakan teknik hash yang berbeda (FNV1A) yang lebih cepat dari hambatan MD5 yang digunakan oleh carbon_ch . Lebih penting lagi, kelompok fnv1a_ch menggunakan host dan port untuk membedakan anggota. Ini berguna ketika beberapa target hidup pada host yang sama yang baru saja dipisahkan oleh port.
Karena properti instance tidak lagi diperlukan dengan fnv1a_ch dengan cara ini, digunakan untuk sepenuhnya mengganti host: port string yang akan dihitung hashkey. Ini adalah aspek penting, karena hashkey mendefinisikan metrik mana yang diterima anggota. Override semacam itu memungkinkan banyak hal, termasuk menyamar alamat IP lama misalnya ketika sebuah mesin dimigrasi ke perangkat keras yang lebih baru. Contohnya adalah 10.0.0.5:2003=10.0.0.2:2003 Di mana mesin di Alamat 5 sekarang menerima metrik untuk mesin yang ada di Alamat 2.
Saat menggunakan instance dengan cara ini bisa sangat berguna untuk melakukan migrasi dalam kelompok yang ada, untuk cluster pengaturan yang baru, instance memungkinkan untuk menghindari pekerjaan ini dengan menggunakan instance dari hari pertama untuk melepaskan lokasi mesin dari metrik yang diterimanya. Pertimbangkan misalnya 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac Di mana hash acak sebagai instance digunakan. Ini akan memungkinkan untuk mengubah port dan/atau alamat IP server yang menerima data sebanyak tanpa berurusan dengan warisan yang terlihat, dengan asumsi hash acak dipertahankan. Perhatikan bahwa karena nama instance digunakan sebagai input hash penuh, contoh sebagai a , b , dll. Kemungkinan akan menghasilkan distribusi hash yang buruk, karena hash mereka memiliki input yang sangat sedikit. Untuk alasan itu, pertimbangkan untuk menggunakan nama instance yang lebih lama dan sebagian besar berbeda seperti hash acak seperti yang digunakan dalam contoh di atas untuk perilaku distribusi hash yang lebih baik.
cluster jump_fnv1a_ch
Cluster jump_fnv1a_ch juga merupakan cluster hash yang konsisten seperti dua sebelumnya, tetapi tidak mengambil host anggota, port atau instance ke akun sama sekali. Ini berarti tipe cluster ini melihat urutan di mana anggota didefinisikan, lihat juga di bawah ini untuk lebih lanjut tentang urutan ini. Apakah ini berguna bagi Anda tergantung pada skenario Anda. Berbeda dengan dua jenis klaster hash yang konsisten sebelumnya, hash lompatan memiliki keseimbangan yang hampir sempurna atas anggota yang ditentukan dalam cluster. Namun, ini datang dengan mengorbankan tidak dapat menghapus anggota mana pun tetapi yang terakhir dari cluster tanpa menyebabkan pemetaan ulang lengkap semua metrik atas semua anggota. Apa artinya ini pada dasarnya adalah bahwa hash ini baik -baik saja untuk digunakan dengan kelompok yang konstan atau terus tumbuh di mana node yang lebih tua tidak pernah dihapus, tetapi sebagai gantinya diganti.
Jika Anda memiliki gugus di mana penghapusan node lama terjadi, hash lompatan tidak cocok untuk Anda. Jump hash bekerja dengan server dalam daftar yang dipesan. Karena pesanan ini penting, dapat dibuat eksplisit menggunakan instance seperti yang digunakan dalam jenis klaster sebelumnya. Ketika sebuah instance diberikan dengan anggota, itu akan digunakan sebagai kunci penyortiran. Tanpa contoh ini, pesanan akan seperti yang diberikan dalam file konfigurasi, yang mungkin rentan terhadap perubahan ketika EG dihasilkan oleh beberapa perangkat lunak manajemen konfigurasi. Dengan demikian, mungkin praktik yang baik untuk memperbaiki urutan server dengan contoh sehingga eksplisit apa node yang tepat untuk hash lompat. Seseorang dapat menggunakan angka untuk ini, tetapi menyadari bahwa penyortiran 1, 2 dan 10 hasil dalam 1, 10, 2, jadi lebih baik menggunakan sesuatu seperti P0001, P0002, P0010 sebagai gantinya.
Aturan kecocokan adalah cara untuk mengarahkan metrik yang masuk ke satu atau lebih cluster. Aturan kecocokan diproses dari atas ke bawah karena didefinisikan dalam file. Dimungkinkan untuk mendefinisikan beberapa pertandingan dalam aturan yang sama. Setiap aturan kecocokan dapat mengirim data ke satu atau lebih cluster. Karena aturan pertandingan "Fall Through" kecuali kata kunci stop ditambahkan, ekspresi pertandingan yang dibuat dengan cermat dapat digunakan untuk menargetkan beberapa cluster atau agregasi. Kemampuan ini memungkinkan untuk mereplikasi metrik, serta mengirim metrik tertentu ke kelompok alternatif dengan pemesanan yang cermat dan penggunaan kata kunci stop . blackhole cluster khusus membuang metrik yang dikirim ke sana. Ini dapat berguna untuk menyingkirkan metrik yang tidak diinginkan dalam kasus -kasus tertentu. Karena membuang metrik tidak ada gunanya jika pertandingan lain akan menerima data yang sama, kecocokan dengan sebagai tujuan kluster Blackhole, memiliki stop implisit. Klausul validation menambahkan cek ke data (apa yang muncul setelah metrik) dalam bentuk ekspresi reguler. Ketika ungkapan ini cocok, aturan kecocokan akan mengeksekusi seolah -olah tidak ada klausul validasi. Namun, jika gagal, aturan pertandingan dibatalkan, dan tidak ada metrik yang akan dikirim ke tujuan, ini adalah perilaku drop . Ketika log digunakan, metrik dicatat ke Stderr. Perawatan harus diambil dengan yang terakhir untuk menghindari banjir kayu. Ketika klausa validasi ada, tujuan tidak perlu ada, ini memungkinkan untuk menerapkan aturan validasi global. Perhatikan bahwa aturan pembersihan diterapkan sebelum validasi dilakukan, sehingga data tidak akan memiliki ruang duplikat. route using klausa digunakan untuk melakukan modifikasi sementara ke kunci yang digunakan untuk input ke rutinitas hashing yang konsisten. Tujuan utamanya adalah untuk merutekan lalu lintas sehingga data yang tepat dikirim ke instance agregasi yang dibutuhkan.
Menulis ulang aturan mengambil ekspresi reguler sebagai input agar sesuai dengan metrik yang masuk, dan mengubahnya menjadi nama metrik baru yang diinginkan. Dalam penggantian, backreferensi diizinkan untuk mencocokkan grup penangkapan yang ditentukan dalam ekspresi reguler input. Kecocokan server.(x|y|z). memungkinkan untuk menggunakan role.1. dalam substitusi. Jika diperlukan, notasi g{n} dapat digunakan sebagai ganti n di mana backreference diikuti oleh bilangan bulat, seperti g{1}100 . Beberapa peringatan berlaku untuk implementasi aturan penulisan ulang saat ini. Pertama, lokasi mereka di file config menentukan kapan penulisan ulang dilakukan. Penulisan ulang dilakukan di tempat, karena aturan yang cocok sebelum penulisan ulang akan cocok dengan nama asli, aturan pertandingan setelah penulisan ulang tidak lagi cocok dengan nama asli. Perawatan harus diambil dengan pemesanan, karena beberapa aturan penulisan ulang secara berurutan dapat terjadi, misalnya a digantikan oleh b dan b akan digantikan oleh c dalam aturan penulisan ulang yang berhasil. Peringatan kedua dengan implementasi saat ini, adalah bahwa nama metrik yang ditulis ulang tidak dibersihkan, seperti metrik yang baru masuk. Dengan demikian, titik -titik ganda dan karakter berbahaya potensial dapat muncul jika string penggantian dibuat untuk memproduksinya. Adalah tanggung jawab penulis untuk memastikan metriknya bersih. Jika ini adalah masalah untuk perutean, orang dapat mempertimbangkan untuk memiliki instance hanya menulis ulang yang meneruskan semua metrik ke instance lain yang akan melakukan routing. Jelas contoh kedua akan membersihkan metrik saat mereka masuk. Notasi backreference memungkinkan untuk merendahkan dan meningkatkan string pengganti dengan penggunaan simbol underscore ( _ ) dan carret ( ^ ) yang diikuti langsung setelah backslash. Misalnya, role._1. sebagai substitusi akan memberi huruf besar isi 1 . Dot ( . ) Dapat digunakan dengan cara yang sama, atau diikuti setelah garis bawah atau karet untuk menggantikan titik -titik dengan garis bawah dalam substitusi. Ini bisa berguna untuk beberapa situasi di mana metrik dikirim ke grafit.
Agregasi yang ditentukan mengambil satu atau lebih metrik input yang diungkapkan oleh satu atau lebih ekspresi reguler, mirip dengan aturan kecocokan. Metrik yang masuk dikumpulkan selama periode waktu yang ditentukan oleh interval dalam detik. Karena peristiwa mungkin tiba sedikit kemudian, waktu kedaluwarsa dalam detik menentukan kapan agregasi harus dianggap final, karena tidak ada entri baru yang diizinkan untuk ditambahkan lagi. Di atas agregasi beberapa agregasi dapat dihitung. Mereka dapat memiliki jenis agregasi yang sama atau berbeda, tetapi harus menulis ke metrik baru yang unik. Nama metrik dapat menyertakan referensi belakang seperti dalam penulisan ulang ekspresi, memungkinkan untuk aturan agregasi tunggal yang kuat yang menghasilkan dalam banyak agregasi. Ketika tidak ada send to Klausul yang diberikan, metrik yang diproduksi dikirim ke relai seolah -olah mereka diajukan dari luar, maka aturan cocok dan agregasi berlaku untuk itu. Perawatan harus diambil bahwa loop dihindari dengan cara ini. Untuk alasan ini, penggunaan klausa send to Didorong, untuk mengarahkan lalu lintas output jika memungkinkan. Seperti aturan pertandingan, dimungkinkan untuk mendefinisikan beberapa target cluster. Juga, seperti aturan pertandingan, kata kunci stop berlaku untuk mengontrol aliran metrik dalam proses pencocokan.
send statistics to dibangun sudah usang dan akan dihapus dalam rilis berikutnya. Gunakan konstruk statistics khusus sebagai gantinya.
Konstruksi statistics dapat mengontrol beberapa hal tentang statistik (internal) yang diproduksi oleh relai. send to Target dapat digunakan untuk menghindari loop router dengan mengirim statistik ke kluster tujuan tertentu. Secara default metrik diawali dengan carbon.relays.<hostname> , di mana nama host ditentukan saat startup dan dapat ditimpa menggunakan argumen -H . Awalan ini dapat diatur menggunakan prefix with klausa yang mirip dengan target aturan penulisan ulang. Pencocokan input dalam kasus ini adalah ekspresi reguler yang telah ditetapkan sebelumnya ^(([^.]+)(..*)?)$ Pada nama host. Dengan demikian, orang dapat melihat bahwa awalan default ditetapkan oleh carbon.relays..1 . Perhatikan bahwa ini menggunakan fitur penggantian ganti-dot-with-sunderscore dari aturan penulisan ulang. Mengingat ekspresi input, grup kecocokan berikut tersedia: 1 Seluruh nama host, 2 Nama host pendek dan 3 nama domain (dengan titik terkemuka). Mungkin masuk akal untuk menggantikan default dengan sesuatu seperti carbon.relays._2 Secara default, metrik diserahkan setiap 60 detik, ini dapat diubah menggunakan klausa pengiriman setiap reset counters after interval submit every <interval> seconds untuk mendapatkan set nilai yang lebih kompatibel dengan cache karbon.
Port dan protokol yang harus didengarkan oleh relai untuk koneksi yang masuk dapat ditentukan menggunakan arahan listen . Saat ini, semua pendengar harus dari tipe linemode . Kompresi opsional atau pembungkus enkripsi dapat ditentukan untuk port dan antarmuka opsional yang diberikan oleh alamat IP, atau soket unix berdasarkan file. Ketika antarmuka tidak ditentukan, antarmuka apa pun pada semua protokol IP yang tersedia diasumsikan. Jika tidak ada arahan listen , relai akan menggunakan pendengar default untuk port 2003 di TCP dan UDP, ditambah socket unix /tmp/.s.carbon-c-relay.2003 . Ini biasanya berkembang menjadi 5 pendengar pada sistem yang diaktifkan IPv6. Defaultnya cocok dengan perilaku versi sebelum v3.2.
Dalam hal konfigurasi menjadi sangat panjang, atau dikelola lebih baik dalam file terpisah, include Directive dapat digunakan untuk membaca file lain. File yang diberikan akan dibaca di tempat dan ditambahkan ke konfigurasi router pada saat dimasukkan. Hasil akhirnya adalah salah satu konfigurasi rute besar. Beberapa pernyataan include dapat digunakan di seluruh file konfigurasi. Posisi akan mempengaruhi urutan aturan seperti biasa. Waspadalah bahwa inklusi rekursif ( include dari file yang disertakan) didukung, dan saat ini tidak ada perlindungan untuk loop inklusi. Untuk apa yang layak, fitur ini kemungkinan paling baik digunakan dengan file konfigurasi sederhana (misalnya tidak include ke dalamnya).
Karbon-C-Relay berevolusi dari waktu ke waktu, pertumbuhan fitur sesuai permintaan karena alat terbukti stabil dan sesuai dengan pekerjaan dengan baik. Di bawah ini ikuti beberapa contoh konstruksi beranotasi yang dapat digunakan dengan relai.
Cluster dapat didefinisikan sebanyak yang diperlukan. Mereka menerima data dari aturan kecocokan, dan jenisnya menentukan anggota klaster mana yang akhirnya mendapatkan data metrik. Bentuk cluster paling sederhana adalah cluster forward :
cluster send-through
forward
10.1.0.1
;
Setiap metrik yang dikirim ke cluster send-through hanya akan diteruskan ke server di alamat IPv4 10.1.0.1 . Jika kita mendefinisikan beberapa server, semua server itu akan mendapatkan metrik yang sama, dengan demikian:
cluster send-through
forward
10.1.0.1
10.2.0.1
;
Hasil di atas dalam duplikasi metrik yang dikirim ke kedua mesin. Ini bisa berguna, tetapi sebagian besar waktu tidak. Jenis kluster any_of adalah forward , tetapi mengirimkan setiap metrik yang masuk ke salah satu anggota. Contoh yang sama dengan cluster seperti itu adalah:
cluster send-to-any-one
any_of 10.1.0.1:2010 10.1.0.1:2011;
Ini akan menerapkan skenario multipath, di mana dua server digunakan, beban di antara mereka tersebar, tetapi jika salah satu dari mereka gagal, semua metrik dikirim ke yang tersisa. Ini biasanya berfungsi dengan baik untuk relay hulu, atau untuk menyeimbangkan proses cache karbon yang berjalan pada mesin yang sama. Jika anggota mana pun menjadi tidak tersedia, misalnya karena restart bergulir, anggota lain menerima lalu lintas. Jika perlu memiliki kegagalan yang sebenarnya, di mana server sekunder hanya digunakan jika yang pertama turun, berikut ini akan menerapkan itu:
cluster try-first-then-second
failover 10.1.0.1:2010 10.1.0.1:2011;
Tipe ini berbeda dari dua jenis klaster hash yang konsisten:
cluster graphite
carbon_ch
127.0.0.1:2006=a
127.0.0.1:2007=b
127.0.0.1:2008=c
;
Jika seorang anggota dalam contoh ini gagal, semua metrik yang akan pergi ke anggota itu disimpan dalam antrian, menunggu anggota untuk kembali. Ini berguna untuk kelompok mesin cache karbon di mana diinginkan bahwa metrik yang sama berakhir di server yang sama selalu. Jenis cluster carbon_ch kompatibel dengan hash yang konsisten karbon, dan dapat digunakan untuk kelompok yang ada yang dihuni oleh relay karbon. Namun, untuk cluster baru, lebih baik menggunakan tipe cluster fnv1a_ch , karena lebih cepat, dan memungkinkan untuk menyeimbangkan alamat yang sama tetapi port yang berbeda tanpa nomor instance, dalam batasan untuk carbon_ch .
Karena kita dapat menggunakan beberapa cluster, kita juga dapat mereplikasi tanpa menggunakan tipe cluster forward , dengan cara yang lebih cerdas:
cluster dc-old
carbon_ch replication 2
10.1.0.1
10.1.0.2
10.1.0.3
;
cluster dc-new1
fnv1a_ch replication 2
10.2.0.1
10.2.0.2
10.2.0.3
;
cluster dc-new2
fnv1a_ch replication 2
10.3.0.1
10.3.0.2
10.3.0.3
;
match *
send to dc-old
;
match *
send to
dc-new1
dc-new2
stop
;
Dalam contoh ini semua metrik yang masuk pertama kali dikirim ke dc-old , kemudian dc-new1 dan akhirnya ke dc-new2 . Perhatikan bahwa tipe cluster dari dc-old berbeda. Setiap metrik yang masuk akan dikirim ke 2 anggota dari ketiga kelompok, sehingga mereplikasi total 6 tujuan. Untuk setiap cluster, anggota tujuan dihitung secara mandiri. Kegagalan kelompok atau anggota tidak mempengaruhi yang lain, karena semua memiliki antrian individu. Contoh di atas juga dapat ditulis menggunakan tiga aturan pertandingan untuk setiap DC, atau satu aturan pertandingan untuk ketiga DC. Perbedaannya terutama dalam kinerja, berapa kali metrik yang masuk harus dicocokkan dengan ekspresi. Aturan stop dalam aturan pertandingan dc-new tidak sepenuhnya diperlukan dalam contoh ini, karena tidak ada lagi aturan pertandingan berikut. Namun, jika kecocokan akan menargetkan subset tertentu, misalnya ^sys. , dan lebih banyak cluster akan didefinisikan, ini bisa diperlukan, seperti misalnya dalam contoh singkat berikut:
cluster dc1-sys ... ;
cluster dc2-sys ... ;
cluster dc1-misc ... ;
cluster dc2-misc ... ;
match ^sys. send to dc1-sys;
match ^sys. send to dc2-sys stop;
match * send to dc1-misc;
match * send to dc2-misc stop;
Seperti yang dapat dilihat, tanpa stop dalam aturan pertandingan DC2-SYS, semua metrik dimulai dengan sys. juga akan dikirim ke DC1-MISC dan DC2-MISC. Bisa jadi ini diinginkan, tentu saja, tetapi dalam contoh ini ada cluster khusus untuk metrik sys .
Misalkan akan ada beberapa metrik yang tidak diinginkan yang sayangnya dihasilkan, mari kita asumsikan beberapa perangkat lunak yang buruk/lama. Kami tidak ingin menyimpan metrik ini. Cluster blackhole cocok untuk itu, ketika lebih sulit untuk benar -benar membuat daftar putih semua metrik yang diinginkan. Pertimbangkan yang berikut:
match
some_legacy1$
some_legacy2$
send to blackhole
stop;
Ini akan membuang semua metrik yang diakhiri dengan some_legacy , yang seharusnya sulit untuk disaring. Karena pesanan penting, itu dapat digunakan dalam konstruksi seperti ini:
cluster old ... ;
cluster new ... ;
match * send to old;
match unwanted send to blackhole stop;
match * send to new;
Dalam contoh ini cluster lama akan menerima metrik yang tidak diinginkan untuk cluster baru. Jadi, urutan aturan terjadi penting untuk eksekusi.
Validasi dapat digunakan untuk memastikan data untuk metrik seperti yang diharapkan. Validasi global untuk jumlah yang adil (tidak ada titik mengambang) yang bisa:
match *
validate ^[0-9]+ [0-9]+$ else drop
;
(Perhatikan Escape with Backslash ruang, Anda mungkin dapat menggunakan s atau [:space:] sebagai gantinya, ini tergantung pada implementasi regex yang Anda konfigurasi.)
Klausul validasi dapat ada pada setiap aturan pertandingan, jadi pada prinsipnya, berikut ini valid:
match ^foo
validate ^[0-9]+ [0-9]+$ else drop
send to integer-cluster
;
match ^foo
validate ^[0-9.e+-]+ [0-9.e+-]+$ else drop
send to float-cluster
stop;
Perhatikan bahwa perilaku berbeda dalam dua contoh sebelumnya. Ketika tidak ada send to cluster yang ditentukan, kesalahan validasi membuat pertandingan berperilaku seperti kata kunci stop hadir. Demikian juga, ketika validasi berlalu, pemrosesan berlanjut dengan aturan berikutnya. When destination clusters are present, the match respects the stop keyword as normal. When specified, processing will always stop when specified so. However, if validation fails, the rule does not send anything to the destination clusters, the metric will be dropped or logged, but never sent.
The relay is capable of rewriting incoming metrics on the fly. This process is done based on regular expressions with capture groups that allow to substitute parts in a replacement string. Rewrite rules allow to cleanup metrics from applications, or provide a migration path. In it's simplest form a rewrite rule looks like this:
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server._1.2.3.34
;
In this example a metric like server.DC.role.name123 would be transformed into server.dc.role.name.name123 . For rewrite rules hold the same as for matches, that their order matters. Hence to build on top of the old/new cluster example done earlier, the following would store the original metric name in the old cluster, and the new metric name in the new cluster:
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server._1.2.3.34
;
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server.g{_1}.g{2}.g{3}.g{3}g{4}
;
The alternate syntax for backreference notation using g{n} instead of n notation shown above. Both rewrite rules are identical.
match * send to old;
rewrite ... ;
match * send to new;
Note that after the rewrite, the original metric name is no longer available, as the rewrite happens in-place.
Aggregations are probably the most complex part of carbon-c-relay. Two ways of specifying aggregates are supported by carbon-c-relay. The first, static rules, are handled by an optimiser which tries to fold thousands of rules into groups to make the matching more efficient. The second, dynamic rules, are very powerful compact definitions with possibly thousands of internal instantiations. A typical static aggregation looks like:
aggregate
^sys.dc1.somehost-[0-9]+.somecluster.mysql.replication_delay
^sys.dc2.somehost-[0-9]+.somecluster.mysql.replication_delay
every 10 seconds
expire after 35 seconds
timestamp at end of bucket
compute sum write to
mysql.somecluster.total_replication_delay
compute average write to
mysql.somecluster.average_replication_delay
compute max write to
mysql.somecluster.max_replication_delay
compute count write to
mysql.somecluster.replication_delay_metric_count
;
In this example, four aggregations are produced from the incoming matching metrics. In this example we could have written the two matches as one, but for demonstration purposes we did not. Obviously they can refer to different metrics, if that makes sense. The every 10 seconds clause specifies in what interval the aggregator can expect new metrics to arrive. This interval is used to produce the aggregations, thus each 10 seconds 4 new metrics are generated from the data received sofar. Because data may be in transit for some reason, or generation stalled, the expire after clause specifies how long the data should be kept before considering a data bucket (which is aggregated) to be complete. In the example, 35 was used, which means after 35 seconds the first aggregates are produced. It also means that metrics can arrive 35 seconds late, and still be taken into account. The exact time at which the aggregate metrics are produced is random between 0 and interval (10 in this case) seconds after the expiry time. This is done to prevent thundering herds of metrics for large aggregation sets. The timestamp that is used for the aggregations can be specified to be the start , middle or end of the bucket. Original carbon-aggregator.py uses start , while carbon-c-relay's default has always been end . The compute clauses demonstrate a single aggregation rule can produce multiple aggregates, as often is the case. Internally, this comes for free, since all possible aggregates are always calculated, whether or not they are used. The produced new metrics are resubmitted to the relay, hence matches defined before in the configuration can match output of the aggregator. It is important to avoid loops, that can be generated this way. In general, splitting aggregations to their own carbon-c-relay instance, such that it is easy to forward the produced metrics to another relay instance is a good practice.
The previous example could also be written as follows to be dynamic:
aggregate
^sys.dc[0-9].(somehost-[0-9]+).([^.]+).mysql.replication_delay
every 10 seconds
expire after 35 seconds
compute sum write to
mysql.host.1.replication_delay
compute sum write to
mysql.host.all.replication_delay
compute sum write to
mysql.cluster.2.replication_delay
compute sum write to
mysql.cluster.all.replication_delay
;
Here a single match, results in four aggregations, each of a different scope. In this example aggregation based on hostname and cluster are being made, as well as the more general all targets, which in this example have both identical values. Note that with this single aggregation rule, both per-cluster, per-host and total aggregations are produced. Obviously, the input metrics define which hosts and clusters are produced.
With use of the send to clause, aggregations can be made more intuitive and less error-prone. Consider the below example:
cluster graphite fnv1a_ch ip1 ip2 ip3;
aggregate ^sys.somemetric
every 60 seconds
expire after 75 seconds
compute sum write to
sys.somemetric
send to graphite
stop
;
match * send to graphite;
It sends all incoming metrics to the graphite cluster, except the sys.somemetric ones, which it replaces with a sum of all the incoming ones. Without a stop in the aggregate, this causes a loop, and without the send to , the metric name can't be kept its original name, for the output now directly goes to the cluster.
When configuring cluster you might want to check how the metrics will be routed and hashed. That's what the -t flag is for. For the following configuration:
cluster graphite_swarm_odd
fnv1a_ch replication 1
host01.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
host03.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
host05.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313
;
cluster graphite_swarm_even
fnv1a_ch replication 1
host02.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
host04.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
host06.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313
;
match *
send to
graphite_swarm_odd
graphite_swarm_even
stop
;
Running the command: echo "my.super.metric" | carbon-c-relay -f config.conf -t , will result in:
[...]
match
* -> my.super.metric
fnv1a_ch(graphite_swarm_odd)
host03.dom:2003
fnv1a_ch(graphite_swarm_even)
host04.dom:2003
stop
You now know that your metric my.super.metric will be hashed and arrive on the host03 and host04 machines. Adding the -d flag will increase the amount of information by showing you the hashring
When carbon-c-relay is run without -d or -s arguments, statistics will be produced. By default they are sent to the relay itself in the form of carbon.relays.<hostname>.* . See the statistics construct to override this prefix, sending interval and values produced. While many metrics have a similar name to what carbon-cache.py would produce, their values are likely different. By default, most values are running counters which only increase over time. The use of the nonNegativeDerivative() function from graphite is useful with these.
The following metrics are produced under the carbon.relays.<hostname> namespace:
metricsReceived
The number of metrics that were received by the relay. Received here means that they were seen and processed by any of the dispatchers.
metricsSent
The number of metrics that were sent from the relay. This is a total count for all servers combined. When incoming metrics are duplicated by the cluster configuration, this counter will include all those duplications. In other words, the amount of metrics that were successfully sent to other systems. Note that metrics that are processed (received) but still in the sending queue (queued) are not included in this counter.
metricsDiscarded
The number of input lines that were not considered to be a valid metric. Such lines can be empty, only containing whitespace, or hitting the limits given for max input length and/or max metric length (see -m and -M options).
metricsQueued
The total number of metrics that are currently in the queues for all the server targets. This metric is not cumulative, for it is a sample of the queue size, which can (and should) go up and down. Therefore you should not use the derivative function for this metric.
metricsDropped
The total number of metric that had to be dropped due to server queues overflowing. A queue typically overflows when the server it tries to send its metrics to is not reachable, or too slow in ingesting the amount of metrics queued. This can be network or resource related, and also greatly depends on the rate of metrics being sent to the particular server.
metricsBlackholed
The number of metrics that did not match any rule, or matched a rule with blackhole as target. Depending on your configuration, a high value might be an indication of a misconfiguration somewhere. These metrics were received by the relay, but never sent anywhere, thus they disappeared.
metricStalls
The number of times the relay had to stall a client to indicate that the downstream server cannot handle the stream of metrics. A stall is only performed when the queue is full and the server is actually receptive of metrics, but just too slow at the moment. Stalls typically happen during micro-bursts, where the client typically is unaware that it should stop sending more data, while it is able to.
connections
The number of connect requests handled. This is an ever increasing number just counting how many connections were accepted.
disconnects
The number of disconnected clients. A disconnect either happens because the client goes away, or due to an idle timeout in the relay. The difference between this metric and connections is the amount of connections actively held by the relay. In normal situations this amount remains within reasonable bounds. Many connections, but few disconnections typically indicate a possible connection leak in the client. The idle connections disconnect in the relay here is to guard against resource drain in such scenarios.
dispatch_wallTime_us
The number of microseconds spent by the dispatchers to do their work. In particular on multi-core systems, this value can be confusing, however, it indicates how long the dispatchers were doing work handling clients. It includes everything they do, from reading data from a socket, cleaning up the input metric, to adding the metric to the appropriate queues. The larger the configuration, and more complex in terms of matches, the more time the dispatchers will spend on the cpu. But also time they do /not/ spend on the cpu is included in this number. It is the pure wallclock time the dispatcher was serving a client.
dispatch_sleepTime_us
The number of microseconds spent by the dispatchers sleeping waiting for work. When this value gets small (or even zero) the dispatcher has so much work that it doesn't sleep any more, and likely can't process the work in a timely fashion any more. This value plus the wallTime from above sort of sums up to the total uptime taken by this dispatcher. Therefore, expressing the wallTime as percentage of this sum gives the busyness percentage draining all the way up to 100% if sleepTime goes to 0.
server_wallTime_us
The number of microseconds spent by the servers to send the metrics from their queues. This value includes connection creation, reading from the queue, and sending metrics over the network.
dispatcherX
For each indivual dispatcher, the metrics received and blackholed plus the wall clock time. The values are as described above.
destinations.X
For all known destinations, the number of dropped, queued and sent metrics plus the wall clock time spent. The values are as described above.
aggregators.metricsReceived
The number of metrics that were matched an aggregator rule and were accepted by the aggregator. When a metric matches multiple aggregators, this value will reflect that. A metric is not counted when it is considered syntactically invalid, eg no value was found.
aggregators.metricsDropped
The number of metrics that were sent to an aggregator, but did not fit timewise. This is either because the metric was too far in the past or future. The expire after clause in aggregate statements controls how long in the past metric values are accepted.
aggregators.metricsSent
The number of metrics that were sent from the aggregators. These metrics were produced and are the actual results of aggregations.
Please report them at: https://github.com/grobian/carbon-c-relay/issues
Fabian Groffen <[email protected]>
All other utilities from the graphite stack.
This project aims to be a fast replacement of the original Carbon relay. carbon-c-relay aims to deliver performance and configurability. Carbon is single threaded, and sending metrics to multiple consistent-hash clusters requires chaining of relays. This project provides a multithreaded relay which can address multiple targets and clusters for each and every metric based on pattern matches.
There are a couple more replacement projects out there, which are carbon-relay-ng and graphite-relay.
Compared to carbon-relay-ng, this project does provide carbon's consistent-hash routing. graphite-relay, which does this, however doesn't do metric-based matches to direct the traffic, which this project does as well. To date, carbon-c-relay can do aggregations, failover targets and more.
This program was originally developed for Booking.com, which approved that the code was published and released as Open Source on GitHub, for which the author would like to express his gratitude. Development has continued since with the help of many contributors suggesting features, reporting bugs, adding patches and more to make carbon-c-relay into what it is today.
