Expose Git and build information as metrics

[mafr]

Introduce new metrics git.info and build.info that expose some information from GitProperties and BuildProperties respectively, if available. This is the same info that /actuator/info provides, but represented as metrics, which allows for convenient integration in Grafana dashboards.

Using tags on a pseudo gauge seems to be the standard way of doing this; see for example Prometheus' go_info metric or Micrometer's own jvm.info metric (not yet included in Spring Boot).

Build runs locally, auto formatter has been applied, Checkstyle has no objections.

[wilkinsona]

See #12348 for some history on this topic and micrometer-metrics/micrometer#2221 for the addition of jvm.info to Micrometer.

[jonatan-ivanov]

I think this makes as much sense (if not more) as micrometer-metrics/micrometer#2221. Also, what everyone thinks (/cc @shakuzen) about adding a GitInfoMetrics and a BuildInfoMetrics class or maybe just BuildInfoMetrics (that does both) to Micrometer?
The users need to supply the data (e.g.: through ctor) but it would give a simple contract about what needs to be provided and what will be produced. The advantage of doing it is having the same naming convention across Micrometer users also for non spring boot apps.

[wilkinsona]

Thanks for taking a look, @jonatan-ivanov.

The advantage of doing it is having the same naming convention across Micrometer users also for non spring boot apps

That's quite a compelling advantage. +1 from me, FWIW.

[jonatan-ivanov]

How would you use this?
I'm not sure this is very usable with other metrics but it might be useful for setting up an alert to detect apps that were build against a commit before a certain date (e.g.: we made a company wide change that everyone needs to adopt and if your last change is before this date you did not).

[mafr]

We found this very handy on Grafana dashboards in development systems. Product owners often asked us whether a specific branch (or yesterday's fix) has already been deployed. I haven't used the commit time it in any type of reporting query yet.

As for why these tags and not others: For consistency reasons I decided to expose the exact information that Actuator's Info endpoint provides.

[jonatan-ivanov]

How would you use this?
I'm not sure this is very usable with other metrics but it might be useful for setting up an alert to detect apps that were build (or not) against certain branches (e.g.: everyone needs to build against main/release all the time).

[jonatan-ivanov]

I have the same thoughts as above for commit time.

[jonatan-ivanov]

This can be a little dangerous. Let's say one app has the all the git info, the other does not. If that happens you will end-up with the same metric name but different set of tags. This can lead to all sorts of issues and some backends does not or does not like to support this (e.g.: prometheus). I would return a default value like unknown or N/A if the value is missing but I would always want to have the same set of keys.

Here's is an example (ServiceA has all the details, ServiceB only has the commit id)

git_info{service="serviceA",branch="main",id="cafecafe",time="2022-04-26T18:39:18"} 1.0
git_info{service="serviceB",id="deadbeef"} 1.0

This can be problematic (see above), my proposal instead is:

git_info{service="serviceA",branch="main",id="cafecafe",time="2022-04-26T18:39:18"} 1.0
git_info{service="serviceB",branch="unknown",id="deadbeef",time="unknown"} 1.0

I have a sad but real-life example for this. If you use heroku in a way that it will build your app when you deploy, heroku removes the .git folder so the git plugin will fail. You can generate git.properties on your own but heroku will only tell you the commit id so the git info will be incomplete (this page might take some time to load).

[jonatan-ivanov]

If you do this, you can also simplify things above.

Gauge.builder("git.info", () -> 1L)
        .description("Project Git information").strongReference(true);
        .tag("branch", getOrDefault(props.getBranch()));
	.tag("id", getOrDefault(props.getShortCommitId()));
	.tag("time", getOrDefault(props.getCommitTime()));
	.register(registry);

[mafr]

Sounds good to me!

[jonatan-ivanov]

I would add a test for the case when one of the properties are not present.

[mafr]

Thanks for your feedback, everyone! If there's consensus on this, I'm happy to make a PR against Micrometer to add GitInfoMetrics and BuildInfoMetrics (with the suggested changes) and later adjust this PR to use them (maybe add JvmMetrics while I'm at it).

[shakuzen]

If this is worth doing, I agree something in Micrometer standardizing it irrespective of framework would be a worthwhile goal. I'm not sure exactly what it would look like, since there isn't a generic git/build info class like Boot has.

which allows for convenient integration in Grafana dashboards.

I'd like to better understand the use cases we're trying to enable to make sure we're doing it in the best way for most users. I talked to @jonatan-ivanov today a bit about my concern over how well these kinds of info metrics can be used across different metrics backends. Prometheus consistently seems to be the backend people requesting it are using, and I want to make sure it is useful in other backends as well. We can discuss that more in the Micrometer repo or Slack.

[wilkinsona]

Thanks, @shakuzen. I'll place this PR on hold until the discussion in the Micrometer repo or Slack has reached a conclusion. Could you please link to the discussion once it's begun as I'd like to follow along if I can.

[snicoll]

The observability team has been discussing this and we need some work on Micrometer first. Let's follow-up on the issue you've created there and we can revisit this once that completes. Thanks for the PR, in any case!