You got my point right. I wasn't aware what is being sent so I now
understand you already took care (partially?) of the issue. But is it only
averages that are being generated for the buckets? I usually find
(configurable) percentiles much more useful. We use statsd timings for this
purpose (
https://github.com/etsy/statsd/blob/master/docs/metric_types.md#timing),
which calculates percentiles, average (mean), standard deviation, sum,
lower and upper bounds for the flush interval.
-Thomas
2013/4/9 Travis Bear <travis_bear@...>
> Thanks Thomas.
>
> I think you make a good point about the documentation being incomplete on
> the topic of what exactly is sent to Graphite. What happens is that g2g
> sends separate summary info (actions per second and various timing metrics)
> for every test defined in the Grinder script. It also creates a special
> "All Transactions" transaction so you can see the big picture of
> what's happening. I'll update the documentation with this info as soon as
> I have time. On a related note, I also think the documentation could
> benefit from having an example graph or two for people to look at.
>
> I'm not sure I follow your point about losing precision when the SuT is
> under load > 1TPS. g2g actually does some of the same kinds of things that
> statsd does, just not necessarily in real time. It groups every Grinder
> transaction into a bucket that covers a configurable length of time.
> Totals for each bucket are computed, averaged, and forwarded to Graphite.
> Assuming you configure your g2g bucket duration to cover the same amount
> of time that your Graphite carbon interval is set for, you shouldn't lose
> anything (beyond the normal loss of information that happens when you
> average many numbers together). Does that make sense, or am I missing your
> point?
>
> Your d3 approach sounds interesting, it would be fun to see an example of
> that some time.
>
>
> -Travis
>
>
>
>
>
> ------------------------------
> *From:* Thomas Falkenberg <falkenbt@...>
>
> *To:* Travis Bear <travis_bear@...>; grinder-use <
> grinder-use@...>
> *Sent:* Monday, April 8, 2013 3:48 AM
>
> *Subject:* Re: [Grinder-use] Announcing Grinder to Graphite
>
> Hi Travis,
>
> cool stuff. From the doc I couldn't find which metrics are being actualle
> sent to graphite. That might be interesting for other users.
> Have you considered using statsd? Otherwise you lose a lot of precision
> with carbon if you load your SuT with more than 1 TPS (since carbons max
> resolution is 1 sec). With statsd you would get at least percentiles, max,
> min etc.
>
> a little OT:
> We moved a bit away from graphite for overview-like reports but gather
> statistics seperately now within the grinder process and flush them after
> the run to a REST Api as JSON so they can be easily processed by d3.
> We also send our grinder logs in json-format to logstash (near realtime)
> so we have every single request (e.g. for outlier-analysis) available and
> can create histograms (elastic search provides this out of the box).
> Plus we store a unique request ID (coming back from the SuT) with each
> log-entry which we can trace through the SuT, but this is specific to our
> SuT (but a good practice.)
>
> We use graphite a lot for correlating metrics but we have our SuT send the
> metrics itself, not the grinder (anymore). But of course this is also
> specific.
>
> If anyone is interested I could share more info, we're pretty happy with
> this solution.
>
> -Thomas
>
>
>
> 2013/4/4 Travis Bear <travis_bear@...>
>
>
> Thanks Gary.
>
> You'd normally want to configure g2g's reporting interval to match the
> time interval Graphite's carbon cache is running at --which is set in
> /opt/graphite/config. Values between ten seconds and a minute would be
> typical.
>
> -Travis
>
>
> ------------------------------
> *From:* Gary Mulder <flyingkiwiguy@...>
> *To:* Travis Bear <travis_bear@...>; grinder-use <
> grinder-use@...>
> *Sent:* Thursday, April 4, 2013 1:12 AM
> *Subject:* Re: [Grinder-use] Announcing Grinder to Graphite
>
> On 4 April 2013 05:21, Travis Bear <travis_bear@...> wrote:
>
>
> Grinder to Graphite is now available on Bitbucket
> https://bitbucket.org/travis_bear/grinder_to_graphite
>
>
> What is it?
>
> Grinder to Graphite (g2g) is a tool that analyzes the logs from
> yourGrinder tests,
> and sends the data into Graphite where it can be visualized in a variety
> of ways.
>
> Realtime test data may be sent to Graphite while your Grinder run is in
> progress,
> or it may be sent to Graphite after your test is completed.
>
>
> Great job Travis!
>
> What is the sample resolution (bucket size?) you are sending to Graphite?
>
> I know I promised similar for OpenTSDB, and have yet to deliver...
>
> Regards,
> Gary
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> grinder-use mailing list
> grinder-use@...
> https://lists.sourceforge.net/lists/listinfo/grinder-use
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> grinder-use mailing list
> grinder-use@...
> https://lists.sourceforge.net/lists/listinfo/grinder-use
>
>
|