Varnish Exporter

[rudi....@gmail.com]

Hello,

I would like to use Promethus to do alerting and gather data from a varnish cache instance (https://www.varnish-cache.org).

I did a bit of googling and the closest that I can find is using munin (https://github.com/munin-monitoring/contrib/blob/master/plugins%2Fvarnish4%2Fvarnish4_) and then the munin exporter but I was thinking that I would rather use the varnistat command and then write a custom varnish exporter that could parse the XML in Go.

I dont have ay experience in Go-lang but I thought it would be a nice holiday project.

Your thoughts?

Regards
Rudi

[Tobias Schmidt]

Great idea!
SoundCloud doesn't use Varnish anymore, but I'm happy to review your code.

Tobi

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

[Fabian Reinartz]

Hi Rudi,

Any new exporter is welcome. They are certainly good projects to get started with Go, too.

If you need any help or reviewing, feel free to write to the list again or join us on IRC.

Fabian

[jo...@adminotech.com]

Hi guys, not sure if this is relevant to you anymore. I also looked for a Varnish exporter and could not find one.

I decided to make one if you want to check it out https://github.com/jonnenauha/prometheus_varnish_exporter

You'll find more details in the readme. Was a quick one night project but should do the trick.

[Ben Kochie]

That's pretty great, thanks for making it.

If you want, we can link it from http://prometheus.io/docs/instrumenting/exporters/

[Brian Brazil]

On 20 February 2016 at 03:12, <jo...@adminotech.com> wrote:

Hi guys, not sure if this is relevant to you anymore. I also looked for a Varnish exporter and could not find one.

I decided to make one if you want to check it out https://github.com/jonnenauha/prometheus_varnish_exporter

You'll find more details in the readme. Was a quick one night project but should do the trick.

Thanks for doing this, you may want to read our guidelines for exporters to help make it as useful as possible: https://docs.google.com/document/d/1JapuiRbp-XoyECgl2lPdxITrhm5IyCUq9iA_h6jp3OY/edit

In particular you should be using ConstMetrics, rather than creating an abstraction on top of prometheus instrumentation and sharing state between scrapes (please, never ever create an abstraction on top of instrumentation). This will be simpler and eliminate the race condition in your current implementation.

Is there some reason you can't decode the json into a []varnishMetric directly?

To answer your question in the comment, the version number should go as a label on it's own metric and have the value 1.

Can you share some sample output? I'm confused as to what you're doing with labels, and as far as I can tell from the docs varnish doesn't expose anything that would require a label.

Brian

 

On Friday, December 11, 2015 at 10:30:09 PM UTC+2, Rudi Kramer wrote:
> Hello,
>
> I would like to use Promethus to do alerting and gather data from a varnish cache instance (https://www.varnish-cache.org).
>
> I did a bit of googling and the closest that I can find is using munin (https://github.com/munin-monitoring/contrib/blob/master/plugins%2Fvarnish4%2Fvarnish4_)  and then the munin exporter but I was thinking that I would rather use the varnistat command and then write a custom varnish exporter that could parse the XML in Go.
>
> I dont have ay experience in Go-lang but I thought it would be a nice holiday project.
>
> Your thoughts?
>
> Regards
> Rudi

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

[jo...@adminotech.com]

>
> Thanks for doing this, you may want to read our guidelines for exporters to help make it as useful as possible: https://docs.google.com/document/d/1JapuiRbp-XoyECgl2lPdxITrhm5IyCUq9iA_h6jp3OY/edit

Yeah I did skim trough that doc. I'll be honest with you, I tried to understand what kind of metrics (gauge, gauge vec, counter etc.) I should be using but am not sure if I understood the idea completely. I read the haproxy exporter a lot as the kind of stats are quite similar to haproxy. Seems like it is using GaugeVec all over the place except for the up/scrape num counters.

My current understanding is that GaugeVec should be used if I have eg. a metric called "varnish_main_fetch" with attached label code, that has the status code.

I'm also using GaugeVec for generic backend events like "varnish_backend_happy" and attaching each backends label (user provided name) and uuid (server generated) to the event.

Did I understand this correctly? When the same metric is done for multiple "things" i should use the same metric name, use gauge vec and set values to unique labels?

>
> In particular you should be using ConstMetrics, rather than creating an abstraction on top of prometheus instrumentation and sharing state between scrapes (please, never ever create an abstraction on top of instrumentation). This will be simpler and eliminate the race condition in your current implementation.

I did create a very thin abstraction for both what I get from varnish and what is sent to prometheus. The prometheus metric owning the gauge and adding some helper functions.

I don't see how this thin struct is any different than the map[int]Gauge being used in haproxy exported. Sure I added a bit more than a number but it helps me to resolve the metric that needs to be updated when I get new data from varnish. I wanted to do that -test mode that dumps resolved metrics on the screen. As far as I see once I create the metric/gauge it wont let me ask for the namespace, name, description etc. How would I accomplish this without doing some abstraction around the prometheus metric?

Is "ConstMetrics" something you provide or what? I cant find that from prom or client_golang packages.

Could you point me to the race condition if you spotted one? Both exporters handle their own mutex when modifying state. I did not go the route as the haproxy cvs reader did with channels, I feel that would have just made the code harder to read. The whole scrape on my VM takes 1-20 msec so I felt no need to do work in parallel, it would have very minimal gains.

Describe and Collect should both be safe to call concurrently, I do understand this as its essentially a HTTP handler.

>
> Is there some reason you can't decode the json into a []varnishMetric directly?
> To answer your question in the comment, the version number should go as a label on it's own metric and have the value 1.

Yeah, the use of reflection and fiddling there is unfortunate but minimal. I have yet to figure out a way to make a struct to read correctly the type of JSON that varnishstat emits. It has a single timestamp to mess the parsing, afaik the JSON package would emit a error at that point and not continue.

Here are examples from Varnish 3.x and 4.x output:
https://github.com/jonnenauha/prometheus_varnish_exporter/blob/master/varnish_test.go#L84-L97
https://github.com/jonnenauha/prometheus_varnish_exporter/blob/master/varnish_test.go#L44-L55

If you know a way to directly get that into a map[string]xMetric let me know.

I'll add that version thing. I parse major, minor, patch and commit revision so there is plenty of labels :)

>
>
> Can you share some sample output? I'm confused as to what you're doing with labels, and as far as I can tell from the docs varnish doesn't expose anything that would require a label.

Here is a -test run that will verify varnishstat, scrape it and dump stuff to stdout

https://dl.dropboxusercontent.com/u/3589544/code/prom/prometheus_varnish_exporter-test-mode.txt

Maybe this will give you better idea of how I'm using labels. One good example is the locks section of varnish. For example it emits

LCK.sms.colls
LCK.cli.colls
LCK.herder.colls
etc.

If I understood the label system correctly I'm combining all of these as a single GaugeVec "lck_colls" and each has unique "ident" label with value of sms, cli, herder etc. Is this how they should be used?

Another example is if you look for "main_fetch". This one I'm not sure if this is ok. I basically saw that there was a bunch of common fetch_xxx, so i trimmed the end and put the last identifier as a label.

[jo...@adminotech.com]

Here is the dump from /metrics https://dl.dropboxusercontent.com/u/3589544/code/prom/prometheus_varnish_exporter-http-metrics.txt

Maybe it tells you more as Prometheus folks. I also added the version as

varnish_version{major="3",minor="0",patch="5",revision="1a89b1f",version="3.0.5"} 1

Should this metric be sent on each Collect or if the value does not change, can it only be sent on the first query or something? I suppose it has to be sent every time, even if static so Prometheus wont think its absent.

[Brian Brazil]

On 20 February 2016 at 12:10, <jo...@adminotech.com> wrote:

>
> Thanks for doing this, you may want to read our guidelines for exporters to help make it as useful as possible: https://docs.google.com/document/d/1JapuiRbp-XoyECgl2lPdxITrhm5IyCUq9iA_h6jp3OY/edit

Yeah I did skim trough that doc. I'll be honest with you, I tried to understand what kind of metrics (gauge, gauge vec, counter etc.) I should be using but am not sure if I understood the idea completely. I read the haproxy exporter a lot as the kind of stats are quite similar to haproxy. Seems like it is using GaugeVec all over the place except for the up/scrape num counters.

My current understanding is that GaugeVec should be used if I have eg. a metric called "varnish_main_fetch" with attached label code, that has the status code.

That's a case to use a label, though it's more likely that that's a Counter than a Gauge. If you're unsure (which is often the case with exporters), you can use Untyped rather than trying to get it perfect. 

I'm also using GaugeVec for generic backend events like "varnish_backend_happy" and attaching each backends label (user provided name) and uuid (server generated) to the event.

Did I understand this correctly? When the same metric is done for multiple "things" i should use the same metric name, use gauge vec and set values to unique labels?

You understand correctly.

 

>
> In particular you should be using ConstMetrics, rather than creating an abstraction on top of prometheus instrumentation and sharing state between scrapes (please, never ever create an abstraction on top of instrumentation). This will be simpler and eliminate the race condition in your current implementation.

I did create a very thin abstraction for both what I get from varnish and what is sent to prometheus. The prometheus metric owning the gauge and adding some helper functions.

I don't see how this thin struct is any different than the map[int]Gauge being used in haproxy exported. Sure I added a bit more than a number but it helps me to resolve the metric that needs to be updated when I get new data from varnish.

The haproxy exporter is not a good example in this case. Even then, it's not adding an abstraction as it isn't proxying instrumentation methods through a new object.

 

I wanted to do that -test mode that dumps resolved metrics on the screen. As far as I see once I create the metric/gauge it wont let me ask for the namespace, name, description etc. How would I accomplish this without doing some abstraction around the prometheus metric?

The usual approach is to have a map from the name to the descriptor, see https://github.com/prometheus/node_exporter/blob/3d7658eea5586f0692de47045049a9113a7acfbd/collector/netdev_common.go for example.

 

Is "ConstMetrics" something you provide or what? I cant find that from prom or client_golang packages.

The above example covers this.

Could you point me to the race condition if you spotted one? Both exporters handle their own mutex when modifying state.

 In Collect() you modify several metrics before taking the lock. There's also no protection against Update() being run while Collect() is accessing VarnishExporter.metricsByName.

I did not go the route as the haproxy cvs reader did with channels, I feel that would have just made the code harder to read. The whole scrape on my VM takes 1-20 msec so I felt no need to do work in parallel, it would have very minimal gains.

The haproxy exporter doesn't work in parallel, and it's using the prometheus Go collector API in the standard way (with some minor indirection). As an exporter it should be using const metrics though.

 

Describe and Collect should both be safe to call concurrently, I do understand this as its essentially a HTTP handler.

>
> Is there some reason you can't decode the json into a []varnishMetric directly?
> To answer your question in the comment, the version number should go as a label on it's own metric and have the value 1.

Yeah, the use of reflection and fiddling there is unfortunate but minimal. I have yet to figure out a way to make a struct to read correctly the type of JSON that varnishstat emits. It has a single timestamp to mess the parsing, afaik the JSON package would emit a error at that point and not continue.

That would be a problem alright. You might be able to hack something with the inline modifier.

 

Here are examples from Varnish 3.x and 4.x output:
https://github.com/jonnenauha/prometheus_varnish_exporter/blob/master/varnish_test.go#L84-L97
https://github.com/jonnenauha/prometheus_varnish_exporter/blob/master/varnish_test.go#L44-L55

If you know a way to directly get that into a map[string]xMetric let me know.

I'll add that version thing. I parse major, minor, patch and commit revision so there is plenty of labels :)

It's usually best to put the three parts of the version number in one label, makes it easier to deal with as you almost always want to deal with it as a single string.

 

>
>
> Can you share some sample output? I'm confused as to what you're doing with labels, and as far as I can tell from the docs varnish doesn't expose anything that would require a label.

Here is a -test run that will verify varnishstat, scrape it and dump stuff to stdout

https://dl.dropboxusercontent.com/u/3589544/code/prom/prometheus_varnish_exporter-test-mode.txt

Maybe this will give you better idea of how I'm using labels. One good example is the locks section of varnish. For example it emits

LCK.sms.colls
LCK.cli.colls
LCK.herder.colls
etc.

If I understood the label system correctly I'm combining all of these as a single GaugeVec "lck_colls" and each has unique "ident" label with value of sms, cli, herder etc. Is this how they should be used?

I'd need to know more about the semantics of these to judge if a label is appropriate. These variable names are quite difficult to understand particularity if you aren't intimately familiar with varnish, I'd suggest improving them as you're doing munging anyway (e.g. varnish_lock_collisions_total{lock="sms"}).

The backends look like a clear case for labels.

 

Another example is if you look for "main_fetch". This one I'm not sure if this is ok. I basically saw that there was a bunch of common fetch_xxx, so i trimmed the end and put the last identifier as a label.

That looks like it might make sense as a label, presuming that the various values don't overlap.

Brian

 

>
>
> Brian
>  
>
>
>
>
> On Friday, December 11, 2015 at 10:30:09 PM UTC+2, Rudi Kramer wrote:
>
> > Hello,
>
> >
>
> > I would like to use Promethus to do alerting and gather data from a varnish cache instance (https://www.varnish-cache.org).
>
> >
>
> > I did a bit of googling and the closest that I can find is using munin (https://github.com/munin-monitoring/contrib/blob/master/plugins%2Fvarnish4%2Fvarnish4_)  and then the munin exporter but I was thinking that I would rather use the varnistat command and then write a custom varnish exporter that could parse the XML in Go.
>
> >
>
> > I dont have ay experience in Go-lang but I thought it would be a nice holiday project.
>
> >
>
> > Your thoughts?
>
> >
>
> > Regards
>
> > Rudi
>
>
>
> --
>
> 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

[jo...@adminotech.com]

Hmm, I'm now realizing I might have mixed labels and const labels with each other.

What is the difference between them in terms of .With and friends? I do understand that in const the value never changes, as this seems to be the case for me. Server name/id or the main_fetch code or other identifiers scraped from varnish never change. So I think I should be using const labels instead.

Will gaugeVec.With(prometheus.Labels{"ident":"mybackend1"}) work exactly the same no matter if its a const or "runtime changing" label?

One thing also I need to do better is runtime changes. User can add/remove backends to Varnish while the monitoring is running, my code should adapt to this.

I'm now looking into NewConstMetric stuff. I think this answers my question above. It can both describe and collect at the same time (done inside Collect). In this case I assume I will only describe the static always present up/version/scrapes metrics in Describe. This looks like a perfect solution for Varnish with it's runtime new/removed labeled metrics. I'll investigate this approach a bit more. Right now it would simply log a warning and drop it to the floor.

Looks like (in your example) the ConstMetric *Desc should still be shared by metric unique name/key between all Collect runs, its just that the *Metric gets always created on the spot.

On Saturday, February 20, 2016 at 2:46:10 PM UTC+2, Brian Brazil wrote:
> On 20 February 2016 at 12:10, <jo...@adminotech.com> wrote:
>
>
> >
>
> > Thanks for doing this, you may want to read our guidelines for exporters to help make it as useful as possible: https://docs.google.com/document/d/1JapuiRbp-XoyECgl2lPdxITrhm5IyCUq9iA_h6jp3OY/edit
>
>
>
> Yeah I did skim trough that doc. I'll be honest with you, I tried to understand what kind of metrics (gauge, gauge vec, counter etc.) I should be using but am not sure if I understood the idea completely. I read the haproxy exporter a lot as the kind of stats are quite similar to haproxy. Seems like it is using GaugeVec all over the place except for the up/scrape num counters.
>
>
>
> My current understanding is that GaugeVec should be used if I have eg. a metric called "varnish_main_fetch" with attached label code, that has the status code.
>
>
>
> That's a case to use a label, though it's more likely that that's a Counter than a Gauge. If you're unsure (which is often the case with exporters), you can use Untyped rather than trying to get it perfect. 

Yeah, some metrics only go up like counters but some also come down like gauges. Its a bit hard to resolve the type from the information Varnish provides. What kind of perf or otherwise impact does the ConstMetric valueType have? Whats the benefit of defining it as a gauge vs untyped?

>
> I'm also using GaugeVec for generic backend events like "varnish_backend_happy" and attaching each backends label (user provided name) and uuid (server generated) to the event.
>
>
>
> Did I understand this correctly? When the same metric is done for multiple "things" i should use the same metric name, use gauge vec and set values to unique labels?
>
>
>
> You understand correctly.
>  
>
>
> >
>
> > In particular you should be using ConstMetrics, rather than creating an abstraction on top of prometheus instrumentation and sharing state between scrapes (please, never ever create an abstraction on top of instrumentation). This will be simpler and eliminate the race condition in your current implementation.
>
>
>
> I did create a very thin abstraction for both what I get from varnish and what is sent to prometheus. The prometheus metric owning the gauge and adding some helper functions.
>
>
>
> I don't see how this thin struct is any different than the map[int]Gauge being used in haproxy exported. Sure I added a bit more than a number but it helps me to resolve the metric that needs to be updated when I get new data from varnish.
>
>
> The haproxy exporter is not a good example in this case. Even then, it's not adding an abstraction as it isn't proxying instrumentation methods through a new object.
>
>
>  I wanted to do that -test mode that dumps resolved metrics on the screen. As far as I see once I create the metric/gauge it wont let me ask for the namespace, name, description etc. How would I accomplish this without doing some abstraction around the prometheus metric?
>
>
>
> The usual approach is to have a map from the name to the descriptor, see https://github.com/prometheus/node_exporter/blob/3d7658eea5586f0692de47045049a9113a7acfbd/collector/netdev_common.go for example.
>  
>
>
>
> Is "ConstMetrics" something you provide or what? I cant find that from prom or client_golang packages.
>
>
>
> The above example covers this.
>
>
>
>
> Could you point me to the race condition if you spotted one? Both exporters handle their own mutex when modifying state.
>
>
>  In Collect() you modify several metrics before taking the lock. There's also no protection against Update() being run while Collect() is accessing VarnishExporter.metricsByName.

Thanks, you are right. I need to move that or guard the by name map separately. Though if I refactor to use the const metrics this bookkeeping should all go away.

[Brian Brazil]

On 20 February 2016 at 14:19, <jo...@adminotech.com> wrote:

Hmm, I'm now realizing I might have mixed labels and const labels with each other.

Const labels are something different again, you shouldn't really use them.

What is the difference between them in terms of .With and friends?

A normal metric is something you'd use as part of direct instrumentation, it handled things like bookkeeping and concurrency. What you're doing in an exporter isn't instrumentation, it's proxying metrics from another system so what you want to do is send on just a snapshot of the other system's metrics - and that's what ConstMetrics do (and what normal metrics are doing under the covers when there's a scape).

 

I do understand that in const the value never changes, as this seems to be the case for me. Server name/id or the main_fetch code or other identifiers scraped from varnish never change. So I think I should be using const labels instead.

Will gaugeVec.With(prometheus.Labels{"ident":"mybackend1"}) work exactly the same no matter if its a const or "runtime changing" label?

One thing also I need to do better is runtime changes. User can add/remove backends to Varnish while the monitoring is running, my code should adapt to this.

If you use ConstMetrics, that will work correctly with no extra work for you as there's no state shared between scrapes.

I'm now looking into NewConstMetric stuff. I think this answers my question above. It can both describe and collect at the same time (done inside Collect). In this case I assume I will only describe the static always present up/version/scrapes metrics in Describe.

"scrapes" is direct instrumentation (it's information about the exporter itself), so should use a normal metric. Personally I'd remove it to avoid confusion.

 

This looks like a perfect solution for Varnish with it's runtime new/removed labeled metrics. I'll investigate this approach a bit more. Right now it would simply log a warning and drop it to the floor.

Looks like (in your example) the ConstMetric *Desc should still be shared by metric unique name/key between all Collect runs, its just that the *Metric gets always created on the spot.

If you can share them across Collects that's handy, though that only works when you know the names of all the metrics in advance. You don't know that here, so I'd recommend creating the descriptors on the fly at every scrape.

Brian

--

Brian Brazil

www.robustperception.io

[jo...@adminotech.com]

I have rewrote the exporter to use const metrics. This simplified the codebase massively. All the bookkeeping between collects and figuring out the metrics before Describe is executed was a pain.

The new approach now also has the benefit of handling runtime changes to varnish like adding new backends.

I have removed the pretty pointless scrape num/fail counters. I left up and version as they were before. up will only go to zero if the varnishstat command fails. I noticed that it does not fail even if varnish is stopped, it keeps giving zero values. This wont make up go to zero, so its a bad indicator if varnish is actually up. Will have to device a way to detect if the server is up reliably.

If you could review the code again, its a lot shorter read now :)

Ben: I'd be glad if it gets added to the 3rd party exporter list so people can find it. I recon Google wont find that repo for a while :) I would still wait for some more code review and that I test this in production with out company varnish instances and graph something useful in Grafana.

[Brian Brazil]

On 20 February 2016 at 22:44, <jo...@adminotech.com> wrote:

I have rewrote the exporter to use const metrics. This simplified the codebase massively. All the bookkeeping between collects and figuring out the metrics before Describe is executed was a pain.

The new approach now also has the benefit of handling runtime changes to varnish like adding new backends.

I have removed the pretty pointless scrape num/fail counters. I left up and version as they were before. up will only go to zero if the varnishstat command fails. I noticed that it does not fail even if varnish is stopped, it keeps giving zero values. This wont make up go to zero, so its a bad indicator if varnish is actually up. Will have to device a way to detect if the server is up reliably.

If you could review the code again, its a lot shorter read now :)

A few things that you'll find in the doc:

Avoid a label called 'type', it's very generic. From a quick read of the docs, "server" may be better label than "id" as that's what the docs call it and it indicates what it's the id of.

You should not include a "total" field in a metric, as that'll break aggregation. If you have to have it (i.e. the sum is less than the total), give it a different metric name.

How you're specifying the host/port for the exporter to listen on is different from the other go exporters. You should standardise that, and grab a default port number as described in the doc.

Ben: I'd be glad if it gets added to the 3rd party exporter list so people can find it. I recon Google wont find that repo for a while :) I would still wait for some more code review and that I test this in production with out company varnish instances and graph something useful in Grafana.

Our current standard for adding an exporter to the list is that someone asks us to, so don't be afraid to send a PR.

--

Brian Brazil

www.robustperception.io

[Jonne Nauha]

A few things that you'll find in the doc:

Avoid a label called 'type', it's very generic. From a quick read of the docs, "server" may be better label than "id" as that's what the docs call it and it indicates what it's the id of.

I implemented a way to rename fq names and label keys. Its looking a bit better but still have generic "type" keys, "id" is gone now. Lock "target" somehow felt right, but thats pretty generic as well. Seems all I can come up with is generic ones :)

Here is a simplified dump of the data from /metrics https://dl.dropboxusercontent.com/u/3589544/code/prom/prometheus_varnish_exporter-http-metrics.txt 

 

You should not include a "total" field in a metric, as that'll break aggregation. If you have to have it (i.e. the sum is less than the total), give it a different metric name.

Ah, good point about the sum() etc. Fixed now for totals to have "_total" postfix without label.

 

How you're specifying the host/port for the exporter to listen on is different from the other go exporters. You should standardise that, and grab a default port number as described in the doc.

Alright, will do at some point.

 

[Brian Brazil]

On 21 February 2016 at 00:05, Jonne Nauha <jo...@adminotech.com> wrote:

A few things that you'll find in the doc:

Avoid a label called 'type', it's very generic. From a quick read of the docs, "server" may be better label than "id" as that's what the docs call it and it indicates what it's the id of.

I implemented a way to rename fq names and label keys. Its looking a bit better but still have generic "type" keys, "id" is gone now. Lock "target" somehow felt right, but thats pretty generic as well. Seems all I can come up with is generic ones :)

"lock" would make most sense for the locks, and for the counters you should have a _total suffix.

For the SMA stats, the label should probably be "storage". For the threads I'd go with "pool" (I'm guessing it's a threadpool). 

I don't think the session ones should be using a label, as they seem unrelated. Similarly with bans. varnish_main_bans_total looks to be a gauge, it shouldn't end in _total.

Fetch is tricky. I'd do something like a metric name of varnish_fetch_result_total with a label of result.

 

Here is a simplified dump of the data from /metrics https://dl.dropboxusercontent.com/u/3589544/code/prom/prometheus_varnish_exporter-http-metrics.txt 

 

You should not include a "total" field in a metric, as that'll break aggregation. If you have to have it (i.e. the sum is less than the total), give it a different metric name.

Ah, good point about the sum() etc. Fixed now for totals to have "_total" postfix without label.

As noted above, _total means something else by convention within prometheus. I'd drop them unless you know you need them.

Brian

 

 

How you're specifying the host/port for the exporter to listen on is different from the other go exporters. You should standardise that, and grab a default port number as described in the doc.

Alright, will do at some point.

 

--

Brian Brazil

www.robustperception.io