We currently only relay to a mock or to carbon. We should also consider the use case of wanting to have a downstream statsgod service that we can send to. This would require solving the following challenges:
How do we handle things like timers with calculated values? We might have to avoid aggregation with this case and just send all metrics downstream. We do have some advantage in being able to write many metrics on one connection separated by the newline character.
What type of connection do we use? Using a TCP connection pool would certainly be the most efficient, but if the downstream relay is handling many upstream clients, this might backfire by blocking other clients. Perhaps just TCP with multiple metrics per connection.
The main goal would be to gain efficiency by letting upstream statsgod services do a portion of the work. Unless we can gain a significant improvement in performance by doing this, it might not make sense.
We currently only relay to a mock or to carbon. We should also consider the use case of wanting to have a downstream statsgod service that we can send to. This would require solving the following challenges:
The main goal would be to gain efficiency by letting upstream statsgod services do a portion of the work. Unless we can gain a significant improvement in performance by doing this, it might not make sense.