REST API exporter

[jonl...@gmail.com]

Hello!

I am impressed by how many exporters have been contributed. I have seen the guidelines on the format of the metrics that must be exposed by exporters, but I was hoping that there might be some thoughts on the quickest, most elegant route to creating an exporter for an existing application's REST API. Is there an exporter that could be easily adopted as a more generic "REST API exporter" for a system that exposes metrics across multiple REST endpoints? If not, after so many exporters have been contributed, is there a "best practice" or ideal stack to use when writing new exporters?

Jonathan

[Brian Brazil]

On 22 July 2016 at 21:51, <jonl...@gmail.com> wrote:

Hello!

I am impressed by how many exporters have been contributed. I have seen the guidelines on the format of the metrics that must be exposed by exporters, but I was hoping that there might be some thoughts on the quickest, most elegant route to creating an exporter for an existing application's REST API. Is there an exporter that could be easily adopted as a more generic "REST API exporter" for a system that exposes metrics across multiple REST endpoints? If not, after so many exporters have been contributed, is there a "best practice" or ideal stack to use when writing new exporters?

The best method isn't to write an exporter, but rather to directly instrument the application to expose the needed metrics. What language is your application written in? 

--

Brian Brazil

www.robustperception.io

[Jonathan Lee]

For my scenario, it's Java-based. I'll reach out to the developers to see if they are open to the idea of adding a Prometheus metrics endpoint.
However, this seems like a common use case... many closed-source applications have HTTP-based APIs, and it would be great to know how Prometheus could fit into a monitoring solution for those systems.

Jonathan

[Brian Brazil]

On 25 July 2016 at 18:35, Jonathan Lee <jonl...@gmail.com> wrote:

For my scenario, it's Java-based. I'll reach out to the developers to see if they are open to the idea of adding a Prometheus metrics endpoint.
However, this seems like a common use case... many closed-source applications have HTTP-based APIs, and it would be great to know how Prometheus could fit into a monitoring solution for those systems.

Basically you have to write a custom exporter every time, as the responses from the various applications aren't even vaguely standard.

Brian

 

Jonathan


On Friday, July 22, 2016 at 8:54:09 PM UTC-4, Brian Brazil wrote:

On 22 July 2016 at 21:51, <jonl...@gmail.com> wrote:

Hello!

I am impressed by how many exporters have been contributed. I have seen the guidelines on the format of the metrics that must be exposed by exporters, but I was hoping that there might be some thoughts on the quickest, most elegant route to creating an exporter for an existing application's REST API. Is there an exporter that could be easily adopted as a more generic "REST API exporter" for a system that exposes metrics across multiple REST endpoints? If not, after so many exporters have been contributed, is there a "best practice" or ideal stack to use when writing new exporters?

The best method isn't to write an exporter, but rather to directly instrument the application to expose the needed metrics. What language is your application written in? 

--

Brian Brazil

www.robustperception.io

--

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

[Jonathan Lee]

A custom exporter per application is understandable. However, the exporter consists of:
1) a method to query the API
2) converting the API responses to Prometheus-compatible metrics
3) a method to host the metrics via HTTP

The rules behind #2 seem well outlined on https://prometheus.io/docs/instrumenting/writing_exporters/
I think my general question is regarding the general consensus on what light-weight stack would achieve the end-to-end solution. I can achieve #1 on its own in nearly any scripting language, and there are many http server solutions out there capable of #3, but finding a light-weight stack to bind all three pieces together. I don't have an prior experience with the Go language, but it appears that by using Go, we can achieve all 3 points without any extra components?

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

[Brian Brazil]

On 27 July 2016 at 15:25, Jonathan Lee <jonl...@gmail.com> wrote:

A custom exporter per application is understandable. However, the exporter consists of:
1) a method to query the API
2) converting the API responses to Prometheus-compatible metrics
3) a method to host the metrics via HTTP

The rules behind #2 seem well outlined on https://prometheus.io/docs/instrumenting/writing_exporters/

Those are guidelines, and applying them requires human judgement and knowledge of the system in question. This can't be done automatically.

Brian

 

I think my general question is regarding the general consensus on what light-weight stack would achieve the end-to-end solution. I can achieve #1 on its own in nearly any scripting language, and there are many http server solutions out there capable of #3, but finding a light-weight stack to bind all three pieces together. I don't have an prior experience with the Go language, but it appears that by using Go, we can achieve all 3 points without any extra components?


On Monday, July 25, 2016 at 1:40:49 PM UTC-4, Brian Brazil wrote:

On 25 July 2016 at 18:35, Jonathan Lee <jonl...@gmail.com> wrote:

For my scenario, it's Java-based. I'll reach out to the developers to see if they are open to the idea of adding a Prometheus metrics endpoint.
However, this seems like a common use case... many closed-source applications have HTTP-based APIs, and it would be great to know how Prometheus could fit into a monitoring solution for those systems.

Basically you have to write a custom exporter every time, as the responses from the various applications aren't even vaguely standard.

Brian

 

Jonathan


On Friday, July 22, 2016 at 8:54:09 PM UTC-4, Brian Brazil wrote:

On 22 July 2016 at 21:51, <jonl...@gmail.com> wrote:

Hello!

I am impressed by how many exporters have been contributed. I have seen the guidelines on the format of the metrics that must be exposed by exporters, but I was hoping that there might be some thoughts on the quickest, most elegant route to creating an exporter for an existing application's REST API. Is there an exporter that could be easily adopted as a more generic "REST API exporter" for a system that exposes metrics across multiple REST endpoints? If not, after so many exporters have been contributed, is there a "best practice" or ideal stack to use when writing new exporters?

The best method isn't to write an exporter, but rather to directly instrument the application to expose the needed metrics. What language is your application written in? 

--

Brian Brazil

www.robustperception.io

--

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 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