Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide base Metrics story from Scannable #1123

Closed
smaldini opened this issue Mar 12, 2018 · 2 comments
Closed

Provide base Metrics story from Scannable #1123

smaldini opened this issue Mar 12, 2018 · 2 comments
Assignees
Labels
type/enhancement A general enhancement
Milestone

Comments

@smaldini
Copy link
Contributor

Explore :

  • domain for metrics (look at spring integration and others)
  • Metrics Flux, Mono, ParallelFlux and Scheduler
  • Built from Scannable
  • Export JMX ? Expose Public ?
  • Use operator / hooks / tag feature ?
@smaldini smaldini added the warn/api-change Breaking change with compilation errors label Mar 12, 2018
@smaldini smaldini added this to the 3.2.0.RELEASE milestone Mar 12, 2018
@smaldini smaldini added type/enhancement A general enhancement and removed warn/api-change Breaking change with compilation errors labels Mar 12, 2018
@simonbasle simonbasle self-assigned this Mar 12, 2018
@simonbasle simonbasle added the status/need-design This needs more in depth design work label Mar 12, 2018
@simonbasle
Copy link
Member

simonbasle commented May 1, 2018

  • activate by placing .metrics() in a Flux chain
  • alternatively activate globally as a hook
  • uses the operator to gather metrics from the immediate upstream, computed from the perceivable events (don't care about the events further up the chain)
  • override to give a tag/name to the metrics specifically?
  • implement as a InnerOperator that detects if Micrometer is there at runtime
  • fallback to a very dumbed down gather and store method for when there is nothing, a bit like with logging (SL4FJ vs Console)

What to gather:

  • time from subscribe to termination
  • average time between onNext
  • number of onNext (derived from onNext timer)
  • number of onError (derived from s-to-t timer + tag)
  • number of onComplete (derived from s-to-t timer + tag)
  • number of cancel (derived from s-to-t timer + tag)
  • Scheduler-related? (eg. number of publishOn/subscribeOn/execution context switches)?
  • timer between request calls

simonbasle added a commit that referenced this issue May 1, 2018
simonbasle added a commit that referenced this issue May 2, 2018
simonbasle added a commit that referenced this issue May 2, 2018
simonbasle added a commit that referenced this issue May 9, 2018
@simonbasle simonbasle modified the milestones: 3.2.0.RELEASE, 3.2.0.M2 May 17, 2018
simonbasle added a commit that referenced this issue May 18, 2018
This commit adds a `metrics()` operator to Flux and Mono, which is
no-op if the Micrometer library is not on the classpath.

If it is, the upstream events are captured and various instrumentation
are performed.

The operator is Fuseable and uses the information provided by the
`name()` and `tags()` operators, if used.

Meter names are stored as private constants in the FluxMetrics class
for reference.
@simonbasle simonbasle modified the milestones: Backlog, Backburner Jul 12, 2018
@simonbasle simonbasle removed the status/need-design This needs more in depth design work label Aug 10, 2018
@simonbasle
Copy link
Member

This has been mostly fixed by #1183 (commit 425bf5c), we have a follow-up issue for schedulers backed by executor services (#1201) and will open further issues as relevant (eg. for the JMX access and auto conversion of Scannable, which I don't think is very relevant as Metrics need to be actively gathered)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants