← Back to team overview

graphite-dev team mailing list archive

Re: [Question #148357]: federated storage and complex wildcard targets = suboptimal

 

Question #148357 on Graphite changed:
https://answers.launchpad.net/graphite/+question/148357

Kevin Blackham posted a new comment:
I'm running on trunk rev 295, checked out 2010-09-17.  I intend to
update to fresh trunk soon.

I don't think the problem has to do with excessive find requests.
Caching them would be nice, but isn't related to my problem.  The find
expands into 11,400 matches, each being its own HTTP request.  What do
you think about the idea of a pickle request that is itself a wildcard?

I wrote some of my collectors to also store data with summaries, but
many of my data points are counters.  I can't do a derivative on a
sum/avg of a counter.  Counters frequently reverse in that case, as any
of these 760 processes (in the example of this "tds" app) die or get
restarted sometimes hourly.  I don't much like the idea of having my
collectors track last state and calcuate the derivative on their own.
Besides, as I move away from periodic polling and towards instrumented
code feeding into AMQP, summaries would be best served as a render-time
operation.

Maybe this carbon-aggregator will be able to take counter data and
derive diffs into summaries?

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.