riemannx
v4.2.0
Klien Riemann yang ditampilkan sepenuhnya dibangun di atas keandalan Poolboy dan kekuatan Elixir yang luar biasa!
Riemannx adalah klien Riemann yang dibangun di Elixir, saat ini adalah satu -satunya klien di Elixir yang mendukung UDP dan TLS (serta TCP). Ada juga mode batching yang dapat Anda gunakan yang berfungsi dengan salah satu transportasi.
Ini memiliki opsi gabungan eksperimental yang memanfaatkan yang terbaik dari TCP dan UDP - dalam mode gabungan UDP adalah pendekatan yang disukai tetapi jika ukuran pesan melebihi set ukuran UDP maks TCP akan digunakan.
Seperti biasa, ada prasyarat yang diperlukan sebelum menggunakan Riemannx, sebagian besar dari ini jelas (elixir, erlang) tetapi berisi beberapa informasi tentang versi mana yang diuji dan didukung.
Saat ini semua versi Erlang ~> 18 didukung. Ini termasuk 20, 20.1 belum diuji tetapi saya memperkirakan tidak ada masalah besar di sana.
Diuji oleh Travis:
18.019.320.0Saya telah mencoba memastikan kompatibilitas dari 1.3.4 dan seterusnya dan akan terus melakukannya jika perlu. Kombinasi yang Diuji:
18.0 Elixir: 1.3.4 / 1.4.5 / 1.5.119.3 Elixir: 1.3.4 / 1.4.5 / 1.5.120.0 Elixir: 1.4.5 / 1.5.1Seperti yang sering terjadi, klien tidak berguna tanpa mitra server - untuk informasi lebih lanjut tentang Riemann, kunjungi http://riemann.io.
Klien hanya diuji pertempuran di: 0.2.11 . Dari versi 4.0.0 dari klien, Anda harus mengatur use_micro ke False jika Anda menggunakan versi Riemann lebih tua dari 0.2.13 dan tidak mengatur bidang waktu sendiri. Ini harus bekerja dengan 0.3.0 tetapi sekali lagi belum pernah diuji (siapa pun yang ingin bekerja pada tes integrasi saya akan sangat menghargainya).
Instalasi terjadi seperti perpustakaan elixir lainnya, tambahkan ke file campuran Anda dan sisanya adalah sejarah:
def deps do
[ { :riemannx , "~> 4.0" } ]
endPastikan Anda menambahkan Riemannx ke daftar aplikasi di file Mix.exs Anda juga, ini memastikannya dimulai dengan aplikasi Anda dan itu akan disertakan dalam rilis Anda (jika Anda menggunakan manajer rilis):
applications : [ :logger , :riemannx ] Untuk menggunakan Riemannx, yang perlu Anda lakukan adalah mengisi beberapa entri konfigurasi - setelah itu semuanya terjadi secara otomatis (simpan untuk pengiriman yang sebenarnya tentu saja). Di bawah ini adalah daftar opsi yang tersedia komprehensif:
config :riemannx , [
host: "localhost" , # The riemann server
event_host: "my_app" , # You can override the host name sent to riemann if you want (see: Host Injection)
send_timeout: 30_000 , # Synchronous send timeout
checkout_timeout: 30_000 , # Timeout for checking out a poolboy worker
type: :batch , # The type of connection you want to run (:tcp, :udp, :tls, :combined, :batch)
settings_module: Riemannx.Settings.Default # The backend used for reading settings back
metrics_module: Riemannx . Metrics.Default # The backend used for sending metrics
use_micro: true # Set to false if you use a riemann version before 0.2.13
batch_settings: [
type : :combined # The underlying connection to use when using batching.
size: 50 , # The size of batches to send to riemann.
interval: { 1 , :seconds } , # The interval at which to send batches.
limit: :infinity # The max limit of batches allowed in the batching queue
]
tcp: [
port : 5555 ,
retry_count: 5 , # How many times to re-attempt a TCP connection
retry_interval: 1000 , # Interval to wait before the next TCP connection attempt (milliseconds).
priority: :high , # Priority to give TCP workers.
options: [ ] , # Specify additional options to be passed to gen_tcp (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
pool_size: 5 , # How many TCP workers should be in the pool.
max_overflow: 5 , # Under heavy load how many more TCP workers can be created to meet demand?
strategy: :fifo # The poolboy strategy for retrieving workers from the queue
] ,
udp: [
port: 5555 ,
priority: :high ,
options: [ ] , # Specify additional options to be passed to gen_udp (NOTE: [:binary, sndbuf: max_udp_size()] will be added to whatever you type here as they are deemed essential)
max_size: 16_384 , # Maximum accepted packet size (this is configured in your Riemann server)
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
] ,
tls: [
port: 5554 ,
retry_count: 5 , # How many times to re-attempt a TLS connection
retry_interval: 1000 , # Interval to wait before the next TLS connection attempt (milliseconds).
priority: :high ,
options: [ ] , # Specify additional options to be passed to :ssl (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
]
] Riemannx mendukung dua metode send , satu tidak sinkron yang lain sinkron:
Pengiriman sinkron memungkinkan Anda untuk menangani kesalahan yang mungkin terjadi selama Kirim, di bawah ini adalah contoh yang menunjukkan bagaimana kesalahan ini terlihat dan apa yang terjadi pada pengiriman yang berhasil:
event = [ service: "riemannx-elixir" ,
metric: 1 ,
attributes: [ a: 1 ] ,
description: "test" ]
case Riemannx . send ( event ) do
:ok ->
"Success!"
[ error: error , msg: encoded_msg ] ->
# The error will always be a string so you can output it as it is.
#
# The encoded message is a binary blob but you can use the riemannx proto
# msg module to decode it if you wish to see it in human readable form.
msg = encoded_msg |> Riemannx.Proto.Msg . decode ( )
Logger . warn ( "Error: #{ error } Message: #{ inspect msg } " )
endPengiriman asinkron jauh lebih cepat tetapi Anda tidak pernah benar -benar tahu jika pesan Anda berhasil, dalam banyak kasus pengiriman semacam ini cukup aman dan untuk sebagian besar kasus penggunaan pilihan yang disarankan. Cukup sederhana untuk diimplementasikan:
event = [ service: "riemannx-elixir" ,
metric: 1 ,
attributes: [ a: 1 ] ,
description: "test" ]
Riemannx . send_async ( event )
# Who knows if it made it? Who cares? 60% of the time it works everytime!Catatan: Jika seorang pekerja tidak dapat mengirimkannya akan mati dan dimulai kembali memberikan kesempatan untuk kembali ke keadaan 'benar'. Pada kirim asinkron ini dilakukan dengan pencocokan pola: ok dengan perintah kirim, untuk pengiriman sinkron jika nilai pengembalian adalah kesalahan kami membunuh pekerja sebelum mengembalikan hasilnya.
Dukungan TLS memungkinkan Anda untuk menggunakan koneksi TCP yang aman dengan server Riemann Anda, untuk mempelajari lebih lanjut tentang cara mengatur ini, lihat di sini: lalu lintas Riemann yang aman menggunakan TLS
Jika Anda memilih untuk menggunakan TLS, Anda akan menggunakan pengaturan TCP murni, gabungan tidak didukung (dan tidak boleh) dengan TLS:
config :riemannx , [
host: "127.0.0.1" ,
type: :tls ,
tls: [
port: 5554 ,
retry_count: 5 , # How many times to re-attempt a TLS connection
retry_interval: 1000 , # Interval to wait before the next TLS connection attempt (milliseconds).
priority: :high ,
# SSL Opts are passed to the underlying ssl erlang interface
# See available options here: http://erlang.org/doc/man/ssl.html
# (NOTE: [:binary, nodelay: true, packet: 4, active: true] will be added to whatever you type here as they are deemed essential)
options: [
keyfile: "path/to/key" ,
certfile: "path/to/cert" ,
verify_peer: true
] ,
pool_size: 5 ,
max_overflow: 5 ,
strategy: :fifo
]
]Dengan asumsi Anda telah mengatur sisi server dengan benar, ini seharusnya semua yang Anda butuhkan untuk memulai.
Riemann memiliki konsep indeks yang dapat dipertanyakan yang memungkinkan Anda untuk mencari acara tertentu, indeks harus dibuat secara khusus di konfigurasi Anda jika tidak server akan mengembalikan kesalahan "tanpa indeks".
# Lets send an event that we can then query
Riemannx . send ( [ service: "riemannx" , metric: 5.0 , attributes: [ v: "2.2.0" ] ] )
# Let's fish it out
events = Riemannx . query ( 'service ~= "riemannx"' )
# [%{attributes: %{"v" => "2.2.0"}, description: nil, host: _,
# metric: nil, service: "riemannx", state: nil, tags: [],
# time: _, ttl: _}]Untuk informasi lebih lanjut tentang kueri dan fitur bahasa, lihat konsep inti.
Bagian ini berisi beberapa catatan tentang perilaku Riemannx yang mungkin menarik minat Anda atau menjawab pertanyaan yang Anda miliki tentang hal -hal tertentu.
Batching pada 4.0.0 adalah perilaku koneksi default - ukuran batch default adalah 50 dan interval setiap 1 detik. Batching berfungsi seperti itu:
Apa pun yang ada dalam antrian akan dikirim setiap interval.
Jika ukuran antrian mencapai ukuran batch yang ditetapkan itu akan disiram terlepas dari interval.
Batch akan dijatuhkan jika tidak ada pekerja yang tersedia untuk menangani batch kecuali checkout_timer diatur ke :infinity
Ada tipe baru yang disebut :batch dan kunci pengaturan yang disebut batch_settings: , di dalam batch_settings Anda dapat menentukan jenis untuk koneksi yang mendasarinya ( :tcp , :udp , :combined , :tls ). Seperti biasa digabungkan adalah default.
Secara opsional, nomor batas batch dapat ditentukan ( :limit ). Jika diatur, setelah antrian batching memiliki jumlah batch yang ditentukan, yaitu limit * batch_size , acara baru akan dijatuhkan sampai setidaknya satu batch dikirim. Nilai default adalah :infinity
Dari versi 0.2.13 dari Riemann, dimungkinkan untuk mengatur waktu dalam mikrodetik - Riemannx sekarang mendukung dan menggunakan bidang time_micros (kecuali Anda telah mengatur Time atau Time_Micros Field sendiri, Riemannx tidak akan menimpa itu). Jika Anda menggunakan versi Riemann yang lebih lama, itu hanya akan menggunakan bidang detik.
Catatan: Jika Anda mengatur waktu dan waktu_micros Riemann akan memprioritaskan waktu mikro dan riemannx tidak akan menimpa keduanya.
Kedengarannya lebih bagus dari itu tetapi pada dasarnya menggambarkan fungsionalitas yang menambahkan entri host ke acara Anda jika Anda belum menentukannya. Ada 3 cara untuk menentukan host:
LAKUKAN SEBELUM Anda mengirim acara (tambahkan: tombol host ke daftar kata kunci)
Tambahkan Kunci :event_host ke konfigurasi Anda.
Biarkan Riemannx melakukannya menggunakan :inet.gethostname() - Kami hanya menyebutnya sekali dan menyimpan hasilnya, itu tidak dipanggil pada setiap acara.
2 opsi terakhir adalah yang paling menguntungkan karena akan menjaga kode Anda tetap bersih.
Di klien ini ada kesempatan untuk menetapkan prioritas bagi pekerja Anda yang memungkinkan Anda menempatkan prioritas yang lebih tinggi atau lebih sedikit pada pengiriman statistik Anda ke Riemann.
Perbedaan pengaturan yang dibuat oleh prioritas sangat tergantung pada perangkat keras dan bagaimana Anda telah menetapkan prioritas Anda yang lain secara umum, info lebih lanjut dapat ditemukan di sini: http://erlang.org/doc/man/erlang.html#process_flag-2
Jika Anda mencoba mengatur prioritas ke: Max Riemannx akan meningkatkan runtimeError karena itu adalah ide yang mengerikan. Ini juga akan meningkatkan runtimeError jika Anda mencoba: foo karena itu juga ide yang mengerikan.
Migrasi ke 3.0 pada dasarnya hanyalah kasus mengubah tata letak konfigurasi Anda - semua opsi yang sama ada kecuali sekarang Anda memiliki kontrol lebih besar atas pekerja Anda di level jenis, ini sangat berharga saat menggunakan pengaturan gabungan yang Anda bisa, katakanlah, memiliki kumpulan pekerja TCP yang lebih kecil dan kumpulan pekerja UDP yang lebih besar alih -alih seperti sebelumnya (2x apa pun yang Anda berikan).
Anda dapat melihat tata letak baru ini di sini: config
Jika ada yang masuk akal di sini, jangan ragu untuk membuka masalah sehingga kami dapat memperluas readme untuk memperbaiki ketidakpastian.
Jika Anda ingin menyimpan pengaturan Anda di tempat lain, Anda dapat membuat pengaturan backend untuk membaca dari database misalnya. Lihatlah modul pengaturan default untuk panggilan balik yang diperlukan.
Ini bisa berguna jika Anda ingin menyimpan pengaturan di seluruh perusahaan di satu tempat.
Jangan ragu untuk membuka masalah jika Anda memiliki pertanyaan.
Riemannx mendukung pengiriman metrik dasar, Anda dapat membuat modul khusus untuk mendukung infrastruktur apa pun (grafit, masuknya dll.). Ada 3 panggilan balik saat ini:
udp_message_sent(size) - menginformasikan kapan pesan UDP dikirim dan memberikan ukuran pesan.tcp_message_sent(size) - menginformasikan kapan pesan TCP dikirim dan memberikan ukuran pesan.tls_message_sent(size) - menginformasikan kapan pesan TLS dikirim dan memberikan ukuran pesan. Kontribusi diterima dengan hangat, periksa bagian proyek untuk beberapa ide yang telah saya tulis dan untuk apa yang sedang berlangsung.
Repositori ini menggunakan alur kerja gitflow yang berarti semua PR harus diarahkan ke arah cabang pengembangan! . Di bawah ini adalah beberapa hal yang perlu dipertimbangkan sebelum membuat PR:
Saya ingin mempertahankan cakupan tes 100%! - Saya dapat membiarkan slide ini dalam kasus mendesak (bug dll.)
Untuk menghindari kekanak -kanakan Travis secara tidak perlu akan dihargai jika Anda memeriksa yang berikut secara lokal terlebih dahulu:
mix coveralls.html (bertujuan 100%)mix dialyzer (membutuhkan waktu dan saya menghargai Anda tidak dapat menguji semua versi Erlang/Elixir)Saya menganggap fitur klien ini lengkap, jika PR Anda memecahkan kompatibilitas ke belakang sepenuhnya atau mengubah perilaku/default yang sudah ada sebelumnya, saya menghargai kepala dan justifikasi Anda :).
Sebagian kode telah dipinjam dari klien Elixir-Riemann asli. Sebagian besar barang protobuf berasal dari sana.
