Hello David, 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 based buffer. 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. dev.servers.hostname.servicename.test1min prod.servers.... prod.network.hostname.servicename.5min prod.apps.hostname.servicename.1sec And bclermont's pull request is to modify dynamically the hostname or servicename. 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. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
