Add build_info metrics for jaeger components

[Ashmita152]

Signed-off-by: Ashmita Bohara [email protected]

Which problem is this PR solving?

Resolves #3062

Short description of the changes

Following this blog, exposing build_info metrics for every jaeger component.

Example for Jaeger Agent metrics endpoint:

( I have a local git tag as v1.32.0 hence version is showing that)

[codecov]

Codecov Report

Merging #3087 (51bf43e) into master (f23484b) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3087      +/-   ##
==========================================
- Coverage   95.96%   95.90%   -0.06%     
==========================================
  Files         236      236              
  Lines       10251    10251              
==========================================
- Hits         9837     9831       -6     
- Misses        345      349       +4     
- Partials       69       71       +2     

Impacted Files	Coverage Δ
cmd/collector/app/server/zipkin.go	73.07% <0.00%> (-3.85%)	⬇️
cmd/query/app/static_handler.go	95.16% <0.00%> (-3.23%)	⬇️
plugin/storage/integration/integration.go	77.34% <0.00%> (-0.56%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f23484b...51bf43e. Read the comment docs.

[jpkrohling]

I like this idea, but we went in a different direction with #1333. The main reason is this, seen in a comment from @yurishkuro:

Good idea. the only issue I foresee is that some metrics systems (in particular, Uber's M3) flush all metrics periodically, which results in the single data point in the time series db, thus if you're looking at the last hour of metrics and that point was earlier, you won't get any data.

Perhaps instead of metrics (which are meant for time series, even if gauges), these values are better exposed via expvar.

[Ashmita152]

Thank you @albertteoh @jpkrohling for the review. I will look at the PR associated with that issue and update it accordingly.

[Ashmita152]

On reading more about expvar, I have a question about it:

It looks like expvar is golang related endpoint rather than prometheus related endpoint. That means if we expose it via expvar, it is exposed at /debug/vars which doesn't seems to be consumable by prometheus (since it's not exposing in prometheus format)
As per the blog linked to the issue, they are trying to add version label to other timeseries using some kind of join. This will not be possible if we expose it as expvar.

Looking at other tools like prometheus, alertmanager, victoriametrics, they are exposing this build information as metrics rather than expvar.

I tried exposing the gauge as expvar which came something like this at http://localhost:14271/debug/vars

I am not sure what will be the right way.

[joe-elliott]

Responding to @jpkrohling/@yurishkuro 's comment, we use _info metrics regurlarly that are scraped by prometheus to build dashboards that include versioning information. I don't know the details of M3 but in Prometheus this series is always available to be joined against as long as the application is publishing it.

[Ashmita152]

Hi @jpkrohling @yurishkuro

May I ask for your review for this PR please.

Regards.

[jpkrohling]

Should we convert the ones from #1333 as well, in name of consistency?

[Ashmita152]

I don't have any strong opinion but I think command line flags should be kept as expvar unless they are changing dynamically during the runtime.

[jpkrohling]

At least one value might be changing: the dyn-queue-size value.