graphite-dev team mailing list archive

[Ivan Pouzyrevsky <question178969@xxxxxxxxxxxxxxxxxxxxx>]

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

Ivan Pouzyrevsky posted a new comment:
Thanks for the detailed response, Chris!

Now it's my turn to apologize for the delayed response; I am currently
overwhelmed with other tasks than Graphite. Yet I am very glad that you
have provided such a detailed commentary on my write-up. It's nice to
hear that you're interested in our instance and I'm ready to conduct a
few benchmarks as soon as I return to tuning Graphite. Sounds like a
good plan to push our instance to the limit. :)

In the next iteration I'll try to update to the megacarbon branch and
tune MAX_UPDATES parameter in order to mitigate the need for my IO-
patch. But, once again, I'm currently hell-busy with routine tasks, so
I'll return to Graphite ASAP.

Oh, and since we've touched client-side, I have a question: what are the
best practices to guarantee data delivery to Graphite instances?
Background is as follows: we are interested in a system which will
eventually push all produced data to a Graphite instance even in
presence of timed network partitions.

Currently I'm thinking about implementing two queues in Diamond daemon:
first one resides in memory and used for pushing metrics to the carbon
daemons; in case of failure a metric is enqueued to the second,
persistent on-disk queue, which periodically flushed to the Graphite.

However, there is no explicit notion of failure in Graphite. What I was
thinking about is implementing another line protocol which sends acks
when the metric received. I'm curious, is it possible to use TCP acks
(in flow control mode) to provide the same delivery guarantees? I don't
know in details how Twisted works.

I'd like to hear your comments on this, because I have a feeling that
I'm reinventing the wheel. :)

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