Hello! If I understand correctly, the sampling rate is not supported like in other statsd implementations. Bioyino does not "restore" the original value ​​in proportion to the sample rate? For example, after sending metric:1|c|@0.01 I expect to receive metric 100

Hi, can I add prefix for metrics per type? For example: If metric type timer - add prefix stats.timers If metric type count - add prefix stats If gauges - add statsd.gauges

Thanks!

The last symbol of the last tag is chaotically replaced

Sent tag values

test_corrupted_tags;y=y;x=x
test_corrupted_tags;y=yyyyyy;x=xxxx
test_corrupted_tags;y=yyy;x=xxx

Received

test_corrupted_tags;x=x;y=x
test_corrupted_tags;x=xxxx;y=yyyyyx
test_corrupted_tags;x=xxx;y=yyx

IMPORTANT: tags must be sent in reversed order (for example y before x)

All versions affected: 0.6, 0.7.2, 0.8.0

It's a little hard to reproduce and depends from some factors Here is config which makes it possible:

bufsize = 1500
multimessage = true
mm-packets = 10
buffer-flush-time = 0
buffer-flush-length = 16384

(It's possible with other values too, but needs more time to happens)

Here some commands to save time and speed up testing

while true; do for x in x xx xxx xxxx xxxxx xxxxxx xxxxxxx xxxxxxxx xxxxxxxxxx; do for y in y yy yyy yyyy yyyyy yyyyyy yyyyyyy yyyyyyyy yyyyyyyyy yyyyyyyyyy; do echo "test_corrupted_tags;y=$y;x=$x:1|c" | nc -u 127.0.0.1 8125; echo -n "."; done; done; echo; done

nc -k -l -p 2003 | grep test_corrupted_tags | grep -v -P "test_corrupted_tags;x=x+;y=y+ "

Please fix )

thread 'bioyino_udp0' panicked at 'assertion failed: self.remaining_mut() >= src.remaining()', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-0.4.11/src/buf/buf_mut.rs:230:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::begin_panic
   6: bytes::buf::buf_mut::BufMut::put
   7: <futures::future::chain::Chain<A, B, C>>::poll
   8: futures::task_impl::std::set
   9: tokio_current_thread::CurrentRunner::set_spawn
  10: <tokio_current_thread::scheduler::Scheduler<U>>::tick
  11: <tokio_current_thread::Entered<'a, P>>::block_on
  12: <std::thread::local::LocalKey<T>>::with
  13: <std::thread::local::LocalKey<T>>::with
  14: <std::thread::local::LocalKey<T>>::with
  15: <std::thread::local::LocalKey<T>>::with
  16: tokio::runtime::current_thread::runtime::Runtime::block_on

I can reproduce the panic at my setup. Do you need some additional information to fix it up?

This major release introduces more flexibility for choosing metric aggregates, a big internal async/await rewrite and some more features.

See CHANGELOG for details.

The current example of the config is incorrect by 50 percent. Can you give the minimum working config for building from the master? Maybe there is a key in to generate a configuration example? An interesting option with raft protocol.

Hello. We have cluster of three node: node1, node2, node3. Let's say, that statsd metrics are sent only to node1. When we turn off server node2, node1 start to send to carbon more rarely - one time per 1-2 minutes. When i commented option "nodes" in block "[network]" on node1, all started to be ok. I think, problem near tcp timeouts when node1 try to communicate with node2 for exchange (or aggregation) metrics. node1, node2 and node3 in different networks. So, tcp timeouts not limited by arp request timeouts.

Here screenshot from graphite. Blue dots - it's all that's left from line. First time (11:50 - 12:05) - i try to understand, what happening. Second (12:11 - 12:17) - i commented "nodes" and trying to test the idea

Config:

verbosity = "warn"
n-threads = 8
w-threads = 8
task-queue-size = 1024
start-as-leader = false
stats-interval = 10000
stats-prefix = "resources.monitoring.bioyino"
consensus = "internal"
[metrics]
count-updates = true
update-counter-prefix = "resources.monitoring.bioyino.updates"
update-counter-suffix = ""
update-counter-threshold = 200
fast-aggregation = false
[carbon]
address = "127.0.0.1:2003"
interval = 10000
connect-delay = 250
connect-delay-multiplier = 2
connect-delay-max = 10000
send-retries = 30
[network]
listen = "0.0.0.0:8125"
peer-listen = "0.0.0.0:8136"
mgmt-listen = "0.0.0.0:8137"
bufsize = 1500
multimessage = true
mm-packets = 100
mm-async = false
buffer-flush-time = 3000
buffer-flush-length = 65536
greens = 4
async-sockets = 4
nodes = ["192.168.2.2:8136", "192.168.3.3:8136"]
snapshot-interval = 1000
[raft]
start-delay = 5000
this-node = "192.168.1.1:8138"
nodes = {"192.168.1.1:8138" = 1, "192.168.2.2:8138" = 2, "192.168.3.3:8138" = 3}
[consul]
start-as = "disabled"
agent = "127.0.0.1:8500"
session-ttl = 11000
renew-time = 1000
key-name = "service/bioyino/lock"

Different realization of StatsD has different naming scheme

Add option for rename some names with regex or simple string pattern, like

{ "^percentile." = "p", "^min$" = "lower", "^max$" = "upper" }

Hello. For metrics "XXX" with type "ms" bioyino generate metric "XXX.count". It send to carbon pure count of recieved packets every "interval" miliseconds. "interval" - setting from config file. I use it for get "packet per second" value this way: scale(XXX.count, 0.1) (i have interval = 10000). I ask to create another metric - count_ps (float) with value = count * 1000 / interval (from config). With it will no need to use "scale" for every "pps" metric. I think, it will be very usefull and handy - easy way to get "packets per second" value.

I am on 0.3.3 branch and during compiling I am getting next error:

cargo build --release && strip target/release/bioyno

   Compiling tokio-reactor v0.1.6
error[E0658]: use of unstable library feature 'thread_local_state': state querying was recently added (see issue #27716)
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-reactor-0.1.6/src/sharded_rwlock.rs:158:18
    |
158 |     REGISTRATION.try_with(|reg| reg.index).unwrap_or(0)
    |                  ^^^^^^^^

error: aborting due to previous error

error: Could not compile `tokio-reactor`.

To learn more, run the command again with --verbose.

I am on Ubuntu 16.04 with rustc 1.25.0 (standardf repo version). Do I need newer one?

https://github.com/palfrey/bioyino/runs/3273000488?check_suite_focus=true running rustc 1.56.0-nightly (574d37568 2021-08-07)

error: internal compiler error: unexpected concrete region in borrowck: ReEarlyBound(0, 'a)
Error:    --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/bioyino-metric-0.3.1/src/parser.rs:48:1
    |
48  | / pub fn metric_stream_parser<'a, I, F>(max_unparsed: usize, max_tags_len: usize) -> impl Parser<I, Output = ParsedPart<F>, PartialState = ...
49  | | where
50  | |     I: 'a + combine::StreamOnce<Token = u8, Range = &'a [u8], Position = PointerOffset<[u8]>> + std::fmt::Debug + RangeStream,
51  | |     I::Error: ParseError<I::Token, I::Range, I::Position>,
...   |
150 | |     ))
151 | | }
    | |_^
    |
    = note: delayed at compiler/rustc_mir/src/borrow_check/region_infer/opaque_types.rs:88:44

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:1065:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think this is https://github.com/rust-lang/rust/issues/83190 and I've added a note about this there

We have an issue with metric of gauge type. We expect behavior as described at statsd server's documentation

If the gauge is not updated at the next flush, it will send the previous value.

Expected behavior

Let's say we send gaugor:5|g, so we would get gaugor metric with value of 5 on first flush. Later if we don't send any gaugor update we still would get gaugor metric with value of 5 on second flush. Or if we send gaugor:+10|g we would get gaugor metric with value of 15 at second flush.

Actual behavior

We send gaugor:5|g, we get gaugor metric with value of 5 at first flush. Later if we don't send any gaugor update we wouldn't get any gaugor metric on second flush at all. Or If we send gaugor:+10|g we would get gaugor metric with value of 10 on second flush.

Consequence

This behavior also affects gauge relative updates, i.e. sending gaugor:+5|g or gaugor:-5|g to update existing gaugor value by specified difference. It is impossible to update existing gauge, because it is forgotten after every flush.

Hello!

I want to clarify some details.

1. Did I understand correctly that if we use bioyino as a statsd-agent, it can write its data to the cluster via the peer port over tcp? Maybe you have an example of bioyino configuration as agent?
2. Now bioyino can only write to one carbon backend over tcp?

Hi! We plan to use bioyino in our infrastructure. And we have a couple of questions:

1. What could be the problems if we put bioyino in kubernetes (besides consensus management)?
2. Do you plan to make bioyino operator for kubernetes? Or maybe you have some ideas that we can use.

Hi. Is it possible to configure bioyino to send metrics every 10 seconds regardless buffers config, like original statsd ? I have problem on docker, metrics are not delivered to backend most often.