http://code.dlang.org/packages/dstatsd

StatsD allows to collect statistics about any application by using counters, gauges and more through UDP.

Usage:

auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server

s(Counter("Foo")); // increment counter "Foo"
s.inc("Bar"); // increment counter "Foo"

s(Counter("Args"), // send stats to Args, H, and timeA
  Counter("H", someIntValue),  // in one UDP message
  Timer("timeA", someTimeInMS)
);

{
  auto a = ScopeTimer("args", s); // automatic time collection
}

On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
> http://code.dlang.org/packages/dstatsd
>
> StatsD allows to collect statistics about any application by using counters, gauges and more through UDP.
>
> Usage:
>
> auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server
>
> s(Counter("Foo")); // increment counter "Foo"
> s.inc("Bar"); // increment counter "Foo"
>
> s(Counter("Args"), // send stats to Args, H, and timeA
>   Counter("H", someIntValue),  // in one UDP message
>   Timer("timeA", someTimeInMS)
> );
>
> {
>   auto a = ScopeTimer("args", s); // automatic time collection
> }

I didn't even know that this existed, and I have a feeling that soon I'll wonder how I lived without it. Awesome!

Atila

On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
> http://code.dlang.org/packages/dstatsd
>
> StatsD allows to collect statistics about any application by using counters, gauges and more through UDP.
>
> Usage:
>
> auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server
>
> s(Counter("Foo")); // increment counter "Foo"
> s.inc("Bar"); // increment counter "Foo"
>
> s(Counter("Args"), // send stats to Args, H, and timeA
>   Counter("H", someIntValue),  // in one UDP message
>   Timer("timeA", someTimeInMS)
> );
>
> {
>   auto a = ScopeTimer("args", s); // automatic time collection
> }

Never heard about this either, I ignore node.js stuff.  I was just reading this interesting post on tracing/profiling a couple days ago: is it efficient enough to find some of these tail latency issues?

http://danluu.com/perf-tracing/

Given even Dtrace doesn't always work, Statsd is not going to work for all of those either, but I wonder if it will work sometimes.

Btw, pretty damning of HN/reddit that neither has that tracing link, which is why I don't read those stupid sites.

On 10/11/2016 04:13 PM, Joakim wrote:
> On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
>> http://code.dlang.org/packages/dstatsd
>>
>> StatsD allows to collect statistics about any application by using counters, gauges and more through UDP.
>>
>> Usage:
>>
>> auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server
>>
>> s(Counter("Foo")); // increment counter "Foo"
>> s.inc("Bar"); // increment counter "Foo"
>>
>> s(Counter("Args"), // send stats to Args, H, and timeA
>>   Counter("H", someIntValue),  // in one UDP message
>>   Timer("timeA", someTimeInMS)
>> );
>>
>> {
>>   auto a = ScopeTimer("args", s); // automatic time collection
>> }
> 
> Never heard about this either, I ignore node.js stuff.  I was just reading this interesting post on tracing/profiling a couple days ago: is it efficient enough to find some of these tail latency issues?

Stats aggregation usually has nothing to do with fine tuned performance profiling - it is application defined way to monitor relevant metrics of runtime behavior. For example, one can aggregate metrics for web app request processing latencies to monitor if those stay within expected margin - but if issue is spotted, it won't help much in debugging _why_ it has happened.

On Tuesday, 11 October 2016 at 13:22:48 UTC, Dicebot wrote:
> On 10/11/2016 04:13 PM, Joakim wrote:
>> On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
>>> [...]
>> 
>> Never heard about this either, I ignore node.js stuff.  I was just reading this interesting post on tracing/profiling a couple days ago: is it efficient enough to find some of these tail latency issues?
>
> Stats aggregation usually has nothing to do with fine tuned performance profiling - it is application defined way to monitor relevant metrics of runtime behavior. For example, one can aggregate metrics for web app request processing latencies to monitor if those stay within expected margin - but if issue is spotted, it won't help much in debugging _why_ it has happened.

Sure, it's not meant for tracing but monitoring, but if it is efficient enough you could repurpose it to specifically instrument for certain slow paths you're seeing.  The question is: how efficient is it?

On Tuesday, 11 October 2016 at 12:47:55 UTC, Atila Neves wrote:
> I didn't even know that this existed, and I have a feeling that soon I'll wonder how I lived without it. Awesome!

I had the exact same feeling

the backend/view for it:

https://github.com/kamon-io/docker-grafana-graphite