Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

internal/relay: support filtering at relay level #42

Open
sebastianco opened this issue May 25, 2016 · 2 comments
Open

internal/relay: support filtering at relay level #42

sebastianco opened this issue May 25, 2016 · 2 comments

Comments

@sebastianco
Copy link

Current implementation assumes all relays are interested in receiving the same stream of metric points. This is true when running in forwarder mode but not always true when running in aggregator mode. Supporting filtering configuration at relay level will allow one to specify which points should be forwarded/blocked for each relay.

E.g. Assuming one runs an aggregator which receives 100K points/s and is configured to forward to 4 relays. If we know that one of the relays is not interested in receiving metric X why not support filtering it out before sending the metric over the network. This can save bandwidth at the expense of additional CPU usage. The bandwidth saving is more obvious when one of the relays is interested only in metric X (which might represent a tiny fraction of the entire stream).

@masiulaniec
Copy link
Contributor

masiulaniec commented May 25, 2016

See also "subscriber-supplied aggregator-side filtering rules" in #23. I still think that the protocol extension described there is the right way to go.

@sebastianco
Copy link
Author

I would not tie the two together. #23 proposes an alternative way of configuration. We still need the functionality regardless from where an aggregator gets its relay configurations. Depending entirely on subscriber to push its filters and dedup preferences to an upstream publisher/aggregator reduces our flexibility in using this functionality in conjunction with relays which don't speak the new protocol version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants