Il giorno sab 14 mar 2020 alle ore 17:53 Romain Manni-Bucau
<[email protected]> ha scritto:
>
> Assuming maven core/boot is components, a component registry can instrument
> plugins and subclassloaders with classfiletransformers so maybe ok to keep
> it in the IoC.
Romain,
can please you elaborate more ?
I am thinking this this case:
class MyCoolCache {
private static final Counter counter =
MetricsSystem.getCounter("cacheHits");
public T get(K key) {
.... counter.increment();
}
}
I am a developer of a plugin and I want to set some metric to see the
runtime behaviour of my component, I don't want my class to play the
IoC game
You can see it like a "Logger". Loggers are not subject to IoC because
usually you may want a Logger absolutely everywhere and without
changing/refactoring your code.
If I want to add a "temporary" metric I don't want to need to change
constructors, add getters/setters....
Enrico
>
> Le sam. 14 mars 2020 à 15:14, Enrico Olivelli <[email protected]> a
> écrit :
>
> > I am starting this work.
> > I have pushed a copy of current maven core master to maven-studies.
> >
> > Then I have added my "maven-metrics" module.
> > This module contains only the API to be implemented by Metrics
> > Providers and a No-op implementation.
> >
> > You can find the draft API here.
> > https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics
> >
> > It is not final it is just the first import to git, I have to see some
> > real world Maven cases before designing the final one.
> >
> > Now I am going to instrument some Maven core subsystem and implement a
> > simple Metrics Provider in order to see some data.
> >
> > My very first problem is to boot the MetricsProvider and to give
> > access to it from any Java class and module.
> > Maven uses Dependency Injection and this is cool, but with this
> > approach you will not be able to instrument non-component classes,
> > like internal Caches or Network facilities.
> >
> > I am leaning towards using some kind of "global static reference"
> > (like a pure Java Singleton) to hold a reference to the Metrics
> > subsystem.
> >
> > By default the Metrics Provider will be the No-op implementation, so
> > third party tools won't see NULLs.
> >
> > in MavenCli I will "boot" (and manage the whole lifecycle) the Metrics
> > Provider and set this "global reference".
> >
> > The Metrics Provider API will be in the main Maven classloader and the
> > Metrics Provider will have to be loaded in the same
> > context/classloader.
> > Plugins and internal classes will use the API and not directly the
> > provider implementation.
> > I don't know how classloading works very well in the case of Maven/Plexus.
> >
> > Any suggestion is very appreciated.
> >
> > I have very very limited time for this work, but I see value and I
> > will move forward when I have cycles
> >
> > Cheers
> >
> > Enrico
> >
> >
> >
> > Il giorno ven 31 gen 2020 alle ore 00:27 <[email protected]> ha
> > scritto:
> > >
> > > maven-studies looks like the right location:
> > > https://github.com/apache/maven-studies
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > ----- Mail original -----
> > > De: "Enrico Olivelli" <[email protected]>
> > > À: "Maven Developers List" <[email protected]>
> > > Envoyé: Jeudi 30 Janvier 2020 04:31:14
> > > Objet: Re: Maven Runtime Metrics
> > >
> > > 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 <[email protected]> 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 <[email protected]> a
> > > > écrit :
> > > >
> > > > > Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[email protected]>
> > 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 <
> > [email protected]>
> > > > > > wrote:
> > > > > >
> > > > > > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> > > > > > > [email protected]> 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 <
> > > > [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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > --
> > > > > > +==============================+
> > > > > > | Bästa hälsningar,
> > > > > > | [sw. "Best regards"]
> > > > > > |
> > > > > > | Lennart Jörelid
> > > > > > | EAI Architect & Integrator
> > > > > > |
> > > > > > | jGuru Europe AB
> > > > > > | Mölnlycke - Kista
> > > > > > |
> > > > > > | Email: [email protected]
> > > > > > | URL: www.jguru.se
> > > > > > | Phone
> > > > > > | (skype): jgurueurope
> > > > > > | (intl): +46 708 507 603
> > > > > > | (domestic): 0708 - 507 603
> > > > > > +==============================+
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
