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 <eolive...@gmail.com> a écrit :
Il Dom 10 Mag 2020, 17:49 Robert Scholte <rfscho...@apache.org> 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
