Beginners question: why is there not a metric named 'Timer'?

[Jason Wang]

Hello all,

The overwhelming good feedbacks from the docker community has brought me to Prometheus.  I am impressed by the simplistic design and hoping to be able to replace sensu + graphite with this in our small sized deployment. 

Just a quick question for now,  why is there not a 'Timer' metric? 

I have been using the "metrics" library (http://metrics.dropwizard.io/3.1.0/getting-started/#timers) to instrument my java programs and report to Graphite directly. 

I am also hoping to be able to write a "metrics-spring" port for Promethues client one day, if there isn't one already.

The "Metrics" metrics system features "Gauge", "Counter", "Timer" and "Histogram". The Timer metric is my most frequently used one by far. That seems to be natural to me: we all would like to know how your service performs in terms of timing, dont we.

So, for Prometheus, which one out of the four is most suited just to record the time?

 

• Counter
• Gauge
• Histogram
• Summary

Thanks,

Jason

[Matthias Rampke]

Hey,

we typically use histograms to record timings – in the Java client library there is even a Timer wrapper for it:

http://prometheus.io/client_java/io/prometheus/client/Histogram.Timer.html

The only caveat is that the buckets are fixed (per histogram – so you need to specify whatever is interesting to you) – this allows aggregating over them from many instances.

/MR

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Matthias Rampke
Engineer

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany | +49 173 6395215

Managing Director: Alexander Ljung | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg  | HRB 110657B

[Brian Brazil]

On Sat, Aug 22, 2015 at 11:31 AM, Matthias Rampke <m...@soundcloud.com> wrote:

Hey,

we typically use histograms to record timings – in the Java client library there is even a Timer wrapper for it:

http://prometheus.io/client_java/io/prometheus/client/Histogram.Timer.html

The only caveat is that the buckets are fixed (per histogram – so you need to specify whatever is interesting to you) – this allows aggregating over them from many instances.

 

You can find example usage here: http://prometheus.io/client_java/io/prometheus/client/Histogram.html There's also the Summary which has the same interface, but it's cheaper as it doesn't track distributions.

Timers are particular use subset of other metrics, so there's no explicit Timer class.

Brian

--

Brian Brazil

www.robustperception.io

[Jason Wang]

Thanks, saw that one, glad to have your confirmation thats the one to use.

/MR

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Matthias Rampke
Engineer

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany | +49 173 6395215

Managing Director: Alexander Ljung | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg  | HRB 110657B

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Daniel Barker]

Is there anything on the roadmap for annotations in the java client?

[Brian Brazil]

On Sat, Aug 22, 2015 at 11:59 PM, Daniel Barker <barke...@gmail.com> wrote:

Is there anything on the roadmap for annotations in the java client?

From what I know it'd require a java agent to mess around with bytecode, so that's not something easy to add or maintain and would likely pull in quite a few big dependencies (which is a problem for some users). If someone wants to look into making this work we can discuss it.

Brian

 

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Jason Wang]

I think we could use AOP to do that without bytecode level instrument. Both Guice and Spring support AOP for method interceptions. That should not be hard. 

--
You received this message because you are subscribed to a topic in the Google Groups "Prometheus Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/prometheus-developers/gnvvYvXVaGk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to prometheus-devel...@googlegroups.com.

[Brian Brazil]

On Thu, Aug 27, 2015 at 8:21 AM, Jason Wang <jason.l...@gmail.com> wrote:

I think we could use AOP to do that without bytecode level instrument. Both Guice and Spring support AOP for method interceptions. That should not be hard. 

From a quick look at the Guice docs, that's limited to heavy users of Guice doing injection on anything they want to monitor. Spring uses aspectj which appears to need a custom compiler.

These are both things that require significant changes to how users develop, so we can't assume that users have them or are willing to change their development practices to use them. Accordingly they could be optional extras, but not part of the core instrumentation client. 

If we want to offer something that almost any user can use, we'll need a java agent to change the bytecode.

Brian

 

On Sun, Aug 23, 2015 at 11:04 AM, Brian Brazil <brian....@robustperception.io> wrote:

On Sat, Aug 22, 2015 at 11:59 PM, Daniel Barker <barke...@gmail.com> wrote:

Is there anything on the roadmap for annotations in the java client?

From what I know it'd require a java agent to mess around with bytecode, so that's not something easy to add or maintain and would likely pull in quite a few big dependencies (which is a problem for some users). If someone wants to look into making this work we can discuss it.

Brian

 

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

--
You received this message because you are subscribed to a topic in the Google Groups "Prometheus Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/prometheus-developers/gnvvYvXVaGk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Jason Wang]

Makes sense. Thanks Brain. I think another function that would require explicit dependencies on Guice or Spring should be on a separate project, prometheus-client-guice etc. 

Just Off the topic, another beginners question, how do I configure the client to output the metrics reports to log files? I may want to log metrics to files as well as promethues servers, or one not the other. 

Thanks.

[Daniel Barker]

Are the dropwizard metrics manipulating byte code?

[Brian Brazil]

On Thu, Aug 27, 2015 at 11:30 AM, Jason Wang <jason.l...@gmail.com> wrote:

Makes sense. Thanks Brain. I think another function that would require explicit dependencies on Guice or Spring should be on a separate project, prometheus-client-guice etc. 

I think we could put something like that in the main repository as a different module. Having common annotations classes would probably be a good idea, though java annotations are effectively restricted to strings which is a bit limiting.

 

Just Off the topic, another beginners question, how do I configure the client to output the metrics reports to log files? I may want to log metrics to files as well as promethues servers, or one not the other. 

That's not a currently supported feature, but shouldn't be hard to do. You need to take the default registry and iterate over the result of metricFamilySamples(). https://github.com/prometheus/client_java/blob/master/simpleclient_common/src/main/java/io/prometheus/client/exporter/common/TextFormat.java should give you an idea of what's required. 

This would be a good thing to have as a submodule. Ultimately I'd like bridges out to all the other monitoring systems, so that if you instrument with a Prometheus client you get the rest for free for users yet to migrate.

Brian

--

Brian Brazil

www.robustperception.io

[Brian Brazil]

On Thu, Aug 27, 2015 at 11:35 AM, Daniel Barker <barke...@gmail.com> wrote:

Are the dropwizard metrics manipulating byte code?

I've not looked too deeply into this, but it seems the main way dropwizard does metrics is by checking if the method it calls has an annotation and if so performing the extra code. This means it works for route methods. Dropwizard does dependency injection, so it might be doing something there too. Beyond that you're looking at one of the guice or aspectj solutions. See  http://stackoverflow.com/questions/28499621/codahale-metrics-using-timed-metrics-annotation-in-plain-java

Brian

--

Brian Brazil

www.robustperception.io

[Jason Wang]

Not that I am aware of. 

Dropwizard metrics provides a set of annotation definitions (Timed, Gauge, Counted ... etc) in a standalone module. None of the Dropwizard core modules actually do anything with them. Its up to individual specific modules to put those annotations into usage. There are individual specific modules that use those annotation to instrument code. For example, the "Metrics-jersey2" module will support all those annotations to be used on Jersey rest services.  Thats probably the only one in the codebase that actually uses those annotations

For the metrics-jersey implementation, the annotation to registering process is done via event listener callbacks, as supported by Jersey. So no bytecode manipulation is needed.

There is project outside of Dropwizard codebase, "Metrics-Spring", use Spring AOP to intercept method calls and once found those annotations, will register corresponding metrics. So, again, no bytecode manipulation or java agent is needed.

So, as discussed with Brain, Prometheus clients may use similar structure. 

[Brian Brazil]

On Thu, Aug 27, 2015 at 1:15 PM, Jason Wang <jason.l...@gmail.com> wrote:

Not that I am aware of. 

Dropwizard metrics provides a set of annotation definitions (Timed, Gauge, Counted ... etc) in a standalone module. None of the Dropwizard core modules actually do anything with them. Its up to individual specific modules to put those annotations into usage. There are individual specific modules that use those annotation to instrument code. For example, the "Metrics-jersey2" module will support all those annotations to be used on Jersey rest services.  Thats probably the only one in the codebase that actually uses those annotations

For the metrics-jersey implementation, the annotation to registering process is done via event listener callbacks, as supported by Jersey. So no bytecode manipulation is needed.

That's limited to things that Jersey calls, you can't instrument any method with it. Instrumenting at all points of your application is where prometheus-style monitoring really shines.

There is project outside of Dropwizard codebase, "Metrics-Spring", use Spring AOP to intercept method calls and once found those annotations, will register corresponding metrics. So, again, no bytecode manipulation or java agent is needed.

I'd argue that having to use a different compiler counts as bytecode manipulation :)

It looks as though aspectj also has an option to work as a java agent, https://eclipse.org/aspectj/doc/released/faq.php#q:aspectj5ltw, so that may be the best route forward rather than having to write our own.

I'm open to PRs on all of this.

Brian

--

Brian Brazil

www.robustperception.io

[jimmi...@gmail.com]

Another option could be annotation processors, generating code at compile time with normal Java compiler. No runtime dependencies outside of the normal Prometheus client lib, just add annotations for compile time processing?

Cheers,
Jimmi

[Brian Brazil]

On Thu, Sep 24, 2015 at 4:54 PM, <jimmi...@gmail.com> wrote:

Another option could be annotation processors, generating code at compile time with normal Java compiler. No runtime dependencies outside of the normal Prometheus client lib, just add annotations for compile time processing?

From a read through the docs that can generate code for new classes, but not alter the annotated code so it doesn't seem to be of much use here. Am I missing something?

Brian

 

Cheers,
Jimmi

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

[Jimmi Dyson]

That is the normal use of it yes, but there are ways & means as evidenced by Project Lombok. Details of the approach at http://notatube.blogspot.co.uk/2010/11/project-lombok-trick-explained.html. There is potential for breakage, but it's worked for Lombok for a number of years now. But yeah it's probably not very good engineering practice to do it this way, even if it does work...

[Brian Brazil]

On Thu, Sep 24, 2015 at 5:20 PM, Jimmi Dyson <jimmi...@gmail.com> wrote:

That is the normal use of it yes, but there are ways & means as evidenced by Project Lombok. Details of the approach at http://notatube.blogspot.co.uk/2010/11/project-lombok-trick-explained.html. There is potential for breakage, but it's worked for Lombok for a number of years now. But yeah it's probably not very good engineering practice to do it this way, even if it does work...

Yeah, depending on undocumented compiler behaviour that's likely an oversight seems unwise.

Brian

 

On Thu, 24 Sep 2015 at 17:13 Brian Brazil <brian....@robustperception.io> wrote:

On Thu, Sep 24, 2015 at 4:54 PM, <jimmi...@gmail.com> wrote:

Another option could be annotation processors, generating code at compile time with normal Java compiler. No runtime dependencies outside of the normal Prometheus client lib, just add annotations for compile time processing?

From a read through the docs that can generate code for new classes, but not alter the annotated code so it doesn't seem to be of much use here. Am I missing something?

Brian

 

Cheers,
Jimmi

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Brian Brazil

www.robustperception.io

--

Brian Brazil

www.robustperception.io