Make metrics prefix configurable

[jnehlmeier]

Currently the pool name is used as metrics prefix with an added "pool" token.

We use InfluxDB to store & query metrics data and InfluxDB has the concept of tagging metric values so you can quickly query them using a SQL-like WHERE clause. Because metrics can only have a name these tags are computed from the metric name and thus our metrics have a pretty strict form: <measurement>.<tag-key>.<tag-value>......<field>. In addition to tags from metric names there might be global tags like the webapp's context path to distinguish metrics per webapp.

Currently we need to workaround that HikariCP appends a "pool" token to the pool name when constructing metrics. Also we would like to add some information to the pool name that should not result in a tag for metrics.

We could make our metric name parsing algorithm more complex but I think it would be better if you would decouple the the metric name from the pool name and let developers configure both at their will (the default can be as it is now). So ideally HikariCP should create metrics using something like MetricRegistry.name(hikariConfig.getPoolMetricsPrefix(), "Wait")

[brettwooldridge]

@jnehlmeier What is an example of an InfluxDB metric name under your scheme? When considering DropWizard metrics there is a naming convention that should be followed:

Every metric in a registry has a unique name, which is just a dotted-name string like
"things.count" or "com.example.Thing.latency"

Presumably you have something pulling metrics from DropWizard and inserting them into InfluxDB. Isn't that the better location to perform your application specific translation?

[jnehlmeier]

@brettwooldridge Of course we have a working solution but its more complex then it needs to just because we can not freely configure the metric prefix used by HikariCP. In addition I think you have to open up metric naming anyways because Metrics 4.0 will not only support String names for metrics but also an instance of class MetricName which supports tags (to avoid overly long metric names as in Metrics 3.x just to encode some data in them). But MetricName is immutable so if people want to add tags to the metrics of HikariCP you would need to add some API for it (see: #624 (comment))

Anyways in our reporting to InfluxDB we generally distinguish two kinds of metrics: single valued (counter, gauge) and multi valued (timer, histogram, meter). We do this because in InfluxDB we want to combined single valued metrics if they belong to the same measurement. Some examples:

• Timer: handler.host.1.vm.1.customer.1234.name.ComputeHandler.execution-timings
• Counter: handler.host.1.vm.1.customer.1234.name.ComputeHandler.completions
• Counter: handler.host.1.vm.1.customer.1234.name.ComputeHandler.failures

Now our reporter parses these strings assuming the form <measurement>.<tag-key>.<tag-value>......<metricName>. Then we would end up with two measurements in InfluxDB:

• handler_execution-timings (metric is multi valued so we use <measurement>_<metricName>)
  • tags: host, vm, customer, name
  • fields: min, max, mean, .... (all fields of Timer metric)
• handler (single valued metrics go straight into <measurement>)
  • tags: host, vm, customer, name
  • fields: completions, failures (the <metricName> of single valued metrics having the same <measurement> + tags)

Now lets look at HikariCP. Because metric names are tied to the pool name we construct a pool name like jdbc_pool.host.1.vm.1.db.customername. As a pool name itself its already pretty detailed because for a given VM on any host it would be enough to have a pool name like "jdbc_pool.customername" to make it distinguishable in JMX, right? Hikari then creates

• Gauge: jdbc_pool.host.1.vm.1.db.customername.pool.IdleConnections
• Gauge: jdbc_pool.host.1.vm.1.db.customername.pool.ActiveConnections
• Timer: jdbc_pool.host.1.vm.1.db.customername.pool.Wait

Because of this our parsing code is now a bit different then we would like it because we need to ignore "pool" to get our desired result in InfluxDB as described above. IF you ever change the Metric prefix in HikariCP we also might have to adjust our parsing code.

Ideally we would like to provide our own metric prefix and ideally the pool name and the metric name should be configureable independently.

[brettwooldridge]

@jnehlmeier Ok, I understand your usecase.

I would say that your choice of naming convention somewhat cuts across the grain of the design of HikariCP. Your "jdbc_pool" prefix is essentially a duplication of the "pool" component in the distinguished name used by HikariCP. It also cuts across traditional hierarchical component naming convention.

In nearly any "hierarchical" component naming system you find the "left-most" component name is "most distinguishing", followed by the next most, and proceeding to the right.

For example:

aws.us-west-1.host-1.vm-1.customername...

It would be "strange" to see a component hierarchy like:

texas.austin.us.university

compared to:

us.texas.austin.university

The assumption, based on hierarchical naming, is that a pool name of aws.us-west-1.host-1.vm-1.customername (or some variation) would be used, with HikariCP appending ".pool" for pool metrics.

The "pool" component is added as a guard against breaking changes in the future if, for example, we want to introduce different connection-based metrics under a "connection" component.

[jnehlmeier]

@brettwooldridge I have just seen that Hikari also allows setting a MetricsTrackerFactory. Never realized it or it wasn't available in the Hikari version we used back in the days. Looks like we could now just implement our own DropwizardMetricsTracker and choose whatever metric name we want? If thats true and you stick to this approach for a future "connection" component then I guess this issue can be closed.