Maven Runtime Metrics System - MNG-6899

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

Maven Runtime Metrics System - MNG-6899

Enrico Olivelli
Hello community,
I am now ready to move forward with concrete steps for the implementation
of Maven Runtime Metrics.

This is the JIRA
https://issues.apache.org/jira/browse/MNG-6899

It links to my proof-of-concept branch on maven studies.
https://github.com/apache/maven-studies/tree/maven-metrics

In order to move forward I have to create an independent module/git
repository for the Maven Metrics Runtime API.
Currently I have it on maven-studies inside Maven Core but this is not
good, because I would like to use it in Plugins independently from the
version of Maven Core.
When you run the plugin on an old version of Maven all of the data will be
simply ignored.

My plan:
- create a git repository
- put there the first version of the API (maybe we can put there a simple
implementation of the API, but I could leave it off for the first release)
- release it to the public
- use it in Maven 3.7
- use it in Wagon and in Resolver and in other "interesting" modules/core
plugins

Best regards
Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics System - MNG-6899

rfscholte

On 9-5-2020 17:58:47, Enrico Olivelli <[hidden email]> wrote:
Robert

Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:

> Although I'm disappointed there's no spec group for this, having our own
> seems indeed the best choice, but here we will likely face similar issues
> where the API needs adjustments.
> So lets create the maven-metrics git repository
>


Shall I do it by myself or do I need help from a PMC?

For JIRA I think we can keep using Maven core project
Robert Scholte: 
No, I'll create a separate project for it too. This extension will have its own lifecycle, unrelated to the Maven lifecycle (and it won't be bundled)



>
>
> There are a few things I want to address:
> - Consider returning Optional when methods might return null.
>
Okay

> - Specify how to handle Collections and Maps, I think we should assume
> these are never null
>
Okay

> - Abstract classes versus default methods. Default methods were introduced
> to extend existing interfaces without breaking the contract. I already
> expected patterns to appear where default methods would replace abstract
> classes. I'm not saying it is a bad thing, but just to have consensus that
> we can do this.
>

I will think more about this

Thanks
Enrico


> thanks,
> Robert
>
> On 4-5-2020 17:00:39, Romain Manni-Bucau wrote:
> Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a
> écrit :
>
> > Hi,
> > In my humble opinion it is not the best way to implement own api when
> > similar api is already ready and maintained.
> >
> > There is another project used for metrics: micrometer, as we can see it
> is
> > a quite popular 2.3K stars, 500 forks on github
> > https://github.com/micrometer-metrics/micrometer
> >
> > Please consider similar situation with logging api used in maven, we have
> > different logging in plexus component, maven plugin api, maven core, ...
> > and now slf4j is try to replace old
> >
> > Why it is so important to you to be independent in this case?
> >
>
> Cause none is stable and it will be user facing (mojo dev) so it is key to
> create an API we - maven - can assume in time and not depend on vendors.
> Microprofile just proved it would have been a bad choice cause they broke
> the API quite drastically (I'm not blaming them, it is the microprofile
> contract for now but at maven stage it would have been a bad choice).
> This is not a ton of API and impl can rely on anything you want while fully
> isolated (proxy on API?) from the mojo/extensions classloader (otherwise it
> will conflict for sure).
>
>
> >
> > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a):
> >
> > > Robert
> > >
> > > Il Sab 2 Mag 2020, 15:11 Robert Scholte ha
> > scritto:
> > >
> > > > If I take a look at the pom of maven-metrics, I see no dependency on
> > > Maven.
> > > > And looking at
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > [
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > ]
> > > > This looks a lot like
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > [
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > ]
> > > >
> > > > So do we need to maintain our own Metrics API?
> > > >
> > >
> > > Yes it is really better.
> > >
> > > We will be in charge for this API, it will be a new API on which we
> will
> > > depend in many part of Maven core and in plugins.
> > > It is better to not depend on third party.
> > >
> > > There are other initiatives like microprofile metrics.
> > >
> > > The API itself is very small and we could add an implementation that
> uses
> > > micro profile. But we must be independent.
> > >
> > > Enrico
> > >
> > >
> > >
> > > > thanks,
> > > > Robert
> > > > On 2-5-2020 10:26:19, Enrico Olivelli wrote:
> > > > Hello community,
> > > > I am now ready to move forward with concrete steps for the
> > implementation
> > > > of Maven Runtime Metrics.
> > > >
> > > > This is the JIRA
> > > > https://issues.apache.org/jira/browse/MNG-6899
> > > >
> > > > It links to my proof-of-concept branch on maven studies.
> > > > https://github.com/apache/maven-studies/tree/maven-metrics
> > > >
> > > > In order to move forward I have to create an independent module/git
> > > > repository for the Maven Metrics Runtime API.
> > > > Currently I have it on maven-studies inside Maven Core but this is
> not
> > > > good, because I would like to use it in Plugins independently from
> the
> > > > version of Maven Core.
> > > > When you run the plugin on an old version of Maven all of the data
> will
> > > be
> > > > simply ignored.
> > > >
> > > > My plan:
> > > > - create a git repository
> > > > - put there the first version of the API (maybe we can put there a
> > simple
> > > > implementation of the API, but I could leave it off for the first
> > > release)
> > > > - release it to the public
> > > > - use it in Maven 3.7
> > > > - use it in Wagon and in Resolver and in other "interesting"
> > modules/core
> > > > plugins
> > > >
> > > > Best regards
> > > > Enrico
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics System - MNG-6899

Karl Heinz Marbaise-3

On 10.05.20 19:59, Romain Manni-Bucau wrote:

> Events vs metrics is an old topic.
> The choice between both is not only design but also about perf. In terms of
> design it brings the ability to export data without exposing it in code
> (events are public). It also avoid to expose a stable api of events and
> create coupling between plugin/exts and only require a single stable api
> which is very minimal (lot of projects kept their metric abstraction
> stable).
>
> Typically wagon should export metrics but if you fire an event per download
> progress it will be quite slow currently and you will allocate a lot of
> objects (or create contentions) just to increase a monotonic counter (a
> longadder concretely).
>
> So I think Enrico is right and we cant avoid metrics (I have to admit
> events are overcomplex to use for plugin/ext dev, see all profiling
> extensions,

 > not a single one works and report accurate data whereas metrics
> can miss some drilldown data but would be right).

Interesting point cause can you give some more details on which the
testimony is based that none of them works?

Can you explain a accurate implementation?

Kind regards
Karl Heinz Marbaise



>
> Now we can limit the surfacing api and start only by counters and gauges
> maybe and later add histogram, meters etc only if needed (not sure for mvn).
>
> Le dim. 10 mai 2020 à 19:32, Enrico Olivelli <[hidden email]> a écrit :
>
>> Il Dom 10 Mag 2020, 17:49 Robert Scholte <[hidden email]> ha
>> scritto:
>>
>>> Hi Enrico,
>>>
>>> These could all be solved by firing events.
>>>
>>
>> Yes
>> I see your point.
>> Unfortunately those are the first points that I have instrumented in order
>> to see some data.
>>
>>
>>> And there's another benefit: since there won't be an API, we don't need
>> to
>>> maintain it,or be afraid of mistakes.
>>>
>>
>> Exposed metrics won't be an API, or at least something to be maintained.
>> Each Maven version, component version, plugin version may expose any metric
>> is valuable for the component developer or for the users.
>>
>> Exposed metrics are not an extension point, it is not expected that a
>> MetricsProvider is able to alter the behaviour of Maven.
>> Events/Extension point must be maintained forever, but you can drop/add a
>> metric at each release. They are very low level tracking points in code.
>>
>> This is because I say that metrics are like loggers: you add logs where you
>> think it is useful, you can change log point at every version, there is not
>> strong contract with the user, logging implementation is totally pluggable.
>>
>> The Metrics API is mostly the contract with Metrics Provider developers.
>> It will be very stable, I don't think there will be many changes in the mid
>> term.
>> It is only about the ability to give a name to counters, summaries and
>> gauges.
>>
>> Having a simple implementation that dumps the final values at the end is
>> not the full power of this mechanism.
>>
>> You can attach Prometheus or any other time series based metrics database
>> and see the evolution of the build, this will be very useful for long
>> running builds and especially on CI or during component development.
>>
>> I will finish the implementation with Prometheus and try to create a
>> Grafana dashboard.
>>
>> It would be super useful that some Maven-internals experts could suggest
>> useful values to track during the execution of the build.
>>
>> I hope that explains better the value of the Metrics system.
>>
>> Thank you Robert for your feedback and help
>>
>> Enrico
>>
>>
>> To me this is the wrong approach to embed metrics.
>>>
7

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]