Auto-configure Micrometer's HumioMeterRegistry

[jkschneider]

See micrometer-metrics/micrometer#840 and specifically HumioMetricsExportAutoConfiguration.

[wilkinsona]

The Map<String, String> property with a default value throws up an interesting scenario for the configuration property metadata. I've opened #14813 to see what we can do about that.

[snicoll]

As I’ve indicated in that issue, if there are standard tags, I’d like to see a dedicated structure with those tags listed + a map for additional ones. Hopefully that one will not have a default key in it.

[wilkinsona]

There are, AFAIK, no standard tags. They’re just arbitrary key-value pairs. I wonder if it may actually be better if there was no default and we required the user to specify one or more tags.

[snicoll]

IMO a raw map with a default value is a smell so I agree we should do something before adding this.

[wilkinsona]

I wonder if it may actually be better if there was no default and we required the user to specify one or more tags.

The user need not even do that as Humio will accept events with no tags. I'm not sure that a default #name=micrometer tag adds much value so, given that a tag isn't required, I think we should clear the default. That seems quite reasonable to me, particular given that we're using the sandbox repository by default.

WDYT, @jkschneider? Could the default for tags be changed in Micrometer?

[jkschneider]

The default needs to stay. Tags in Humio don't mean the same thing as tags in other monitoring systems. Our typical notion of a tag maps to an attribute in Humio. Tags in Humio serve to uniquely identify the datasource to which all metrics will be added.

They loosely indicate that there should not be more than several datasources per organization without presenting us with a hard limit. Adding a single key/value pair identifier serves to make all Micrometer metrics flow to one datasource, differentiating them at least from log-based ingestion, etc.

IMO a raw map with a default value is a smell

I'm open to suggestions, but in this case the contract is literally an arbitrary set of key value pairs used to uniquely identify a datasource, and a datasource should be identified.

[jkschneider]

For example, here is a Humio query:

#name = "micrometer"
| name = http_server_requests
| eval(avg=sum/count)
| timechart(uri, function=[max(avg)])

• #name = "micrometer" selects the datasource
• name = http_server_requests selects the metric

Without a default "tag", there is no way to select the datasource.

[wilkinsona]

Thanks, Jon. I already understood the purpose of tags in Humio. I still don’t really understand the current default and whether or not we think it’ll serve most people’s purposes.

#name=micrometer feels like leaking an implementation detail about the source of the ingested events. As such, I imagine it’s some that many people will want to change. That’s little more than an hunch though. Either way, for those that do want to configure their own tags, things are further complicated by having to understand whether any tags that are configured via properties or yaml will add to or replace the default.

If we believe there’s a requirement for at least one tag to be configured, could the default not be an empty map and then fail-fast at startup if no tags are configured? That would guide users in the right direction, avoid confusion around replacing or adding to the default and would also deal with the case where the user provides a custom HumioConfig with no tags.

[wilkinsona]

Without a default "tag", there is no way to select the datasource.

When experimenting earlier I observed that Humio automatically adds a tag based on the name of the repository so it should be possible to select the data source even when no tags have been configured on the application side.