Using bioyino as statsd-agent

[sti-jans]

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?

[Albibek]

Hi.

1. Yes. It pre-aggregates metrics for a short period and replicates them as snapshots to all nodes specified in config using an internal binary protocol. For cluster, obviously, it should be the cluster nodes, but you can add any node. Technically this is the same messages, that cluster nodes exchange between each other.

The example is simple, because there is only replication, no aggregation, no backend, no renames. Something like this (mentioning only important parameters) should work.

consensus = "none"
# absense of consensus and not being a leader will guarantee that nothing will be sent to backend,
# even connection will not be established.
start-as-leader = false

[carbon]
# interval is still meaningful, because it triggers some cleanup, but it can be left at a default vaule
interval = 30000

[network]
# a list of nodes to replicate metrics to 
nodes = [ "127.0.0.1:8181" ]
# how often to send snapshots
snapshot-interval = 1000 
# a maximum length of the snapshot queue, drops older snapshots in case remote node cannot receive them
max-snapshots = 1

2. Yes. Because writing to many requires a lot of complicated logic behind it. Imagine one of the backends going offline for example. There are many strategies for different use cases to handle this: duplicating, balancing, etc. For this reason we leave these to other solutions, like carbon-c-relay or our own solution (warning: it's still alpha and not in active development yet, but who knows, maybe it will someday)

[sti-jans]

Thanks for the answer!

What value for max-snapshots can I take to start with? Is the default value ok?

[Albibek]

Default value means to loose each snapshot. If you have ehough memory, it's usually better to have all the snapshots for the whole aggregation interval. The bigger value is totally useless and even destructive because these will be metrics for the previous period. Note, that metrics in the snapshot are still realtime, meaning there's no timestamp inside.

So for i.e. 30 seconds interval and snapshot taken every 1 second, max-snapshots should be between 1 and 30.