Re: Maven Runtime Metrics

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Lennart Jörelid
Would it be possible to use an existing standard for the specification of
such a metrics API?
Something like a shaded version of Microprofile Metrics, where the API can
consist entirely of Annotations.
(There are programmatic approaches as well, but I suppose we are interested
in limiting the footprint of metrics within the Maven codebase as much as
possible).

... implying, of course, that we would need to make a Maven-specific
implementation as discussed above.

On Tue, Jan 28, 2020 at 10:17 AM Enrico Olivelli <[hidden email]>
wrote:

> Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> [hidden email]> ha scritto:
>
> > +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.
> >
>
> Totally agree.
> In my view any "impl" will be plugged with an "extension".
> We will provide only a default no-op implementation
>
> Enrico
>
>
>
> > Side note being: we can start we just counters so no lib is fine imho.
> >
> > Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli <[hidden email]> 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
> > >
> >
>


--

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Enrico Olivelli
I sound like to draft a prototype.

Any suggestion about which repository should contain this new Metrics API?


Enrico

Il Mar 28 Gen 2020, 13:54 Romain Manni-Bucau <[hidden email]> ha
scritto:

> technically we can shade microprofile, metrics/dropwizard or even sirona
> but maven requires quite a different model. A typical example is the expiry
> or weighted model will not fit the reporting maven needs (very long running
> instances vs "batch" like executions) and the weighted impl can be an issue
> but is spec-ed by MP (so the shaded impl would also have this unexpected
> impl)
>
> What about by just adding counters, enabling to inject them in mojos -
> maybe with a qualifier? - and then see if we need to move to something more
> widely used or not (but my past experiences kind of tend to show it is not
> needed).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 28 janv. 2020 à 13:42, Enrico Olivelli <[hidden email]> a
> écrit :
>
> > Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[hidden email]> ha
> > scritto:
> >
> > > Would it be possible to use an existing standard for the specification
> of
> > > such a metrics API?
> > >
> >
> > In my opinion we should have our own model, Maven will impose this new
> API
> > to plugins and we cannot depend on third party tools as Romain also said
> >
> > Okay for annotations
> >
> > Enrico
> >
> > Something like a shaded version of Microprofile Metrics, where the API
> can
> > > consist entirely of Annotations.
> > > (There are programmatic approaches as well, but I suppose we are
> > interested
> > > in limiting the footprint of metrics within the Maven codebase as much
> as
> > > possible).
> > >
> > > ... implying, of course, that we would need to make a Maven-specific
> > > implementation as discussed above.
> > >
> > > On Tue, Jan 28, 2020 at 10:17 AM Enrico Olivelli <[hidden email]>
> > > wrote:
> > >
> > > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> > > > [hidden email]> ha scritto:
> > > >
> > > > > +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.
> > > > >
> > > >
> > > > Totally agree.
> > > > In my view any "impl" will be plugged with an "extension".
> > > > We will provide only a default no-op implementation
> > > >
> > > > Enrico
> > > >
> > > >
> > > >
> > > > > Side note being: we can start we just counters so no lib is fine
> > imho.
> > > > >
> > > > > Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli <
> [hidden email]>
> > 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
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > --
> > > +==============================+
> > > | Bästa hälsningar,
> > > | [sw. "Best regards"]
> > > |
> > > | Lennart Jörelid
> > > | EAI Architect & Integrator
> > > |
> > > | jGuru Europe AB
> > > | Mölnlycke - Kista
> > > |
> > > | Email: [hidden email]
> > > | URL:   www.jguru.se
> > > | Phone
> > > | (skype):    jgurueurope
> > > | (intl):     +46 708 507 603
> > > | (domestic): 0708 - 507 603
> > > +==============================+
> > >
> >
>