tiedotguy
tiedotguy
The protocols the same, just a different code interface right?
The target address should be customizable, and not just restricted to a realm. If this is picked up, it makes sense to start from the DD backend because it's already...
Yep - that's intended for debugging, it's basically logging the decoded udp packet, not the aggregated data on flush.
Benchmarking indicates it's slightly better to use a regular buffered chan. I initially avoided that to reduce fan-in pressure, however it appears to be unnecessary as there's enough work done...
The hazard with flushing is good, as it allows us to create back pressure, by not pushing new maps until processing of the old ones is done.
That'd be great!
I'm not familiar with the Prom SDK in go, but my approach would be to create an appropriate PromStatser (which also includes the necessary Handler) in `createStatser`, then propagate that...
You don't need to worry about Metric/EventHandler, that would be for making a prom backend (#285), this is purely for internal metrics. I would suggest approaching this in two steps....
The model UDP model doesn't translate directly to TCP as you've discovered. I suspect the errors you're seeing aren't due to flush, but rather your client is disconnecting - when...
Hi It's possible, if the metrics are badly tagged (ie, with ephemeral data like a request id or a timestamp), then those will build up in memory over time. It...