The hook_tick time based flushing should be kept as it ensures timely
updates to carbon.
The buffering limit should use a buffer size instead of a time function.
We can use your code from the other broker module to implement a size
As for buffering to disk, it would have to be done to minimize the
blocking impact on the broker. Writing to disk takes time. So it could
buffer blobs to be flushed to disk until a max size. I think
implementing this is overall a good idea but care must be taken.
I do not quite follow you concerning the metrics.
My understanding was that the GRAPHITE_POST metric should be used to
specify non default retention and/or update rate. (ex. 5min, 5min, test5min)
GRAPHITE_PRE is more useful to organize metrics for usability.
And bclermont's pull request is to modify dynamically the hostname or
The important thing concerning the metrics, is that the frontends know
what the names of the metrics are between the host/services and what is
stored in Graphite.
ps. the new development branch has some super capacities to decide in a
rule based manner what type of database/update_frequency/retention_rate
should be created based on the metric name.
In satellite.py, scheduler.py, satelittelink.py, etc.
The Pyro import is sometimes imported as pyro, and sometimes as Pyro.
In the case of a pyro import, it is then assigned to Pyro = pyro.Pyro.
What's the deal here. Shouldn't we be only using imports as Pyro? Was
there a special reason to have both pyro and Pyro available.
When calling pyro traceback, do we need to put it in a try statement or
can we not directly call it. It didn't seem to help in issue 404 that it
was in a try statement it borked anyway.
logger.error (blah condition and tracebackPyro3 or tracebackPyro4)
exp = blah condition and tracebackPyro3 or tracebackPyro4)
Get latest updates about Open Source Projects, Conferences and News.