+1 generally since all extensions doing that report wrong data
-1 to use a mainstream impl if not shaded - it would just bring us new
conflicts i think.
Side note being: we can start we just counters so no lib is fine imho.

Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli <[email protected]> a
écrit :

> Hi,
> I would like to work on introducing an explicit support in Maven Core for
> recording "metrics".
> As far as I know (and I have still limited knowledge about the internals)
> you can write an "extension" and you can intercept main lifecycle events,
> and using these hooks you can try to record metrics.
> But my proposal is from another point of view and I want to go deeper.
>
> We are adding caches, making refactors....all good things, but we should
> have a way to track how Maven is behaving in a measurable manner.
>
> Usually in order to capture realtime metrics you are using some Metrics
> framework, like Prometheus, Dropwizards....and you attach your process to a
> metrics database and capture all of the values.
> Then you can process all of the data, realtime and/or offline, you can
> create dashboards, you can also fine tune your configuration or change your
> code.
>
> These frameworks deal with time series created by capturing  Counters,
> Summaries, Gauges.
>
> I would like to introduce an API to be used by Maven Core and by Plugin to
> expose internal metrics, like:
> - internal caches size
> - memory usage
> - disk reads/writes
> - network traffic
> - any kind of specific metric for plugins (like "number of tests executed",
> "number of files sent to javac...")
> - .... all of the usual stuff you track in order to understand wha's going
> on
>
> I am saying a Maven Metrics API because we must not stick to a single
> "provider" (say "DropWizard"), it will be a bad choice in the long term.
>
> The API will expose to Maven Core and to plugins a way to get access to
> Metrics and report useful values.
>
> @InjectMe
> MetricsProvider metrics;
>
> metrics.getCounter("javacFiles").add(....)
> metrics.getSummary("downloadTime").add(....)
>
> I don't want to go down into details as this is only a preliminary email
> but in my view we could let the user attach an "implementation" just by
> dropping in an "extension", in order not to ship with Maven Core a lot of
> third party dependencies.
>
> I have some "production" experience with this topic (actually I did
> something like that in my company and in ZooKeeper project) so I will be
> happy to prepare and share a design document.
>
> With this work we will open up the way to knowing how a Maven build works,
> with the 'time dimension', on the local machine of the developer but even
> on CI servers.
>
> Any comment is very welcome
>
> Regards
> Enrico
>

Reply via email to