Support for other metrics frameworks

Description

Investigate if the driver could ship with helpers for other metrics frameworks (both collectors and reporters) that would facilitate usage of said frameworks. Also add documentation for usage and configuration of these frameworks.

Examples: Prometheus, Grafana, MicroProfile Metrics, Micrometer, etc.

Environment

None

Pull Requests

None

Activity

Show:
Bret McGuire
May 14, 2020, 1:29 AM

To clarify just a bit: we’re talking about supporting additional reporters for Dropwizard here. We’re not talking about replacing the entire MetricsRegistry impl with Micrometer or some other alternate metrics implementation.

 

Also worth pointing out: the Dropwizard ecosystem already has a number of reporters managed as third-party apps. See https://metrics.dropwizard.io/4.1.2/manual/third-party.html for a representative list. The Prometheus client isn’t listed there but the process should be similar… it pretty much boils down to something like:

 

  • Create the reporter

  • Pass the registry (obtained from a Session presumably)

  • Manage the reporters lifecycle (i.e. start it)

 

In addition to the third-party libs Dropwizard includes reporters for collectd (https://metrics.dropwizard.io/4.1.2/manual/collectd.html) and Graphite (https://metrics.dropwizard.io/4.1.2/manual/graphite.html).

 

Since this functionality is provided by the metric implemenetation we’re using and is largely configured within the user app itself I wonder how much of a role the driver has to play here. We can always document this info certainly, and I suppose we could expose some helpers, perhaps to avoid having to pull the metrics registry out of the Session. But I worry that we might wind up increasing our API considerably (here’s a method to add reporting to Graphite, here’s a method to add reporting to Prometheus etc.) which might e a maintenance headache down the road. Perhaps some docs which describe the process + some helpful links to the various reporters might be better… I don’t know, I can see an argument for both approaches.

 

One final note: Quarkus uses Microprofile metrics rather than the Dropwizard metrics lib so we’ll have to handle apps using our cassandra-quarkus extension as a special case.

Alexandre Dutra
May 16, 2020, 12:21 AM

we are talking about Dropwizard reporters when these are available, or as a last resort, about wrappers around MetricsRegistry that adapt its metrics to the target framework, pretty much as we’ve been doing for Micrometer in our contributions to Spring Boot and Microprofile Metrics in our Cassandra extension. It does not include, indeed, replacing the internals of the driver metrics implementation.

(and sorry, I expanded the scope of this epic to other frameworks than Prometheus)

Assignee

Unassigned

Reporter

Alexandre Dutra

Labels

PM Priority

None

Affects versions

None

Fix versions

None

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Major

Epic Name

Metrics