But that takes storage space, the time to create it, etc. I agree that would be a good architecture though if a single proxy could handle the flow in real time, and I'd guess it could in most cases. Note that filtering happens right when the request hits carbon though, not after much processing. It never gets to the metric queue if it isn't whitelisted.
On Mon, Jan 10, 2011 at 12:13 PM, Jon Stevens <[email protected]> wrote: > I personally think that this should be done through a separate proxy > sitting in front of carbon-cache.py. It seems like by the time carbon > accepts the request and parses it, you might as well just record it. > -- > https://code.launchpad.net/~ziggy/graphite/whitelist/+merge/45710<https://code.launchpad.net/%7Eziggy/graphite/whitelist/+merge/45710> > You are the owner of lp:~ziggy/graphite/whitelist. > -- https://code.launchpad.net/~ziggy/graphite/whitelist/+merge/45710 Your team graphite-dev is requested to review the proposed merge of lp:~ziggy/graphite/whitelist into lp:graphite. _______________________________________________ Mailing list: https://launchpad.net/~graphite-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~graphite-dev More help : https://help.launchpad.net/ListHelp
