Is the name `spring-metrics` confusing?

[checketts]

I foresee two primary modules in this project. The Spring aspect that leverages actuator, etc makes sense being called spring-metrics, however the other aspect is similar to slf4j and really is just a metrics-facade.

I would love to be able to encourage all Java project to leverage the facade benefits, even if they aren't using Spring and I wouldn't want the name to drive them away.

Ideas:

• metrics-interface (maybe shortened to mi4j, but then it looks like leet speak 'miaj'), also is pretty generic,
• meterize - Memorable and unique, also leverages the 'meter' terminology well
• dendro - Out in left field, but 'dendrochronology' is the science of measuring tree growth via rings. (trees grows a lot during the 'Spring') ... yeah a stretch.

I realize that optional deps can keep the modules flexible, but it does feel like if the 2 concerns are made explicit it could save confusion in the long run.

I favor meterize, and spring-metrics, even though the names aren't parallel.

I don't think this is urgent, just wanted to make sure we had this conversation.

[spencergibb]

We're pretty boring with naming here at spring 😜. The initial targets are spring, spring-boot and spring-cloud. @dussab @philwebb thoughts?

[checketts]

I'm fine with boring naming. I just know there are some folks that have an unreasonable 'allergic' reaction to Spring and would love to be able to shim their metrics in those projects/libraries.

I know that @jkschneider has approached it so far keeping Spring as an optional dep and it would be awesome to make that an official initial target.

I'm prepping a non-spring sample project (similar to the example in the JavaDoc here: https://github.com/prometheus/client_java/blob/master/simpleclient_jetty/src/main/java/io/prometheus/client/jetty/JettyStatisticsCollector.java#L15) So we can demonstrate how it would be leverage in that ecosystem.

[jkschneider]

This is a worthwhile conversation to have. So far spring-related things are constrained to a handful of classes.

Honestly, I'm a bit afraid of this:

I imagine that the chief developers on Spectator and Prometheus would each suppose that their metrics clients are already sufficiently general to be adopted as a facade over various backends given the right dependencies and such, and they are in many ways.

There is at least one good reason to shop this particular API as an SLF4J-like instrumentation solution: Spring has an interest in having an instrumentation API whose chief aim is to support as diverse of a set of metrics backends as possible.

Even if we were given unrestrained access to contribute additional backends to an existing instrumentation API like Spectator or Promtheus' simpleclient, their heart will always be in supporting Atlas and Prometheus, respectively. It's really the moral or motivational hazard that drove me to think of writing another API (or really just taking the best parts of both).

[jkschneider]

I guess it might be educational to hear more about the origin of opentracing.io. Is there any corollary here? @adriancole

[spencergibb]

I think on of the main benefits of moving metrics out of boot was so other spring projects that don't rely on boot (data, security, etc...) could have a consistent metrics story. When users arrive to boot, it gets auto-configuration, actuator, etc...

[jkschneider]

@philwebb expressed an early reservation about the optional dependency on boot a couple days ago. This should be a subject of our SF meeting in late June. I'll icebox this issue until then.

[smaldini]

I'd be happy for reactor to consume a facade to produce metrics for end-to-end reactive streams too :)

[philwebb]

Some brainstorming:

• Instrumental
• Metrix
• Measured
• Yardstick
• Quantify
• Metro
• Mouton

[smaldini]

Taking on the old school shortening which usually passes the SEO test

• Msrd
• Obsrvr
• Istrmtl

[jkschneider]

Random measurement devices:

• Micrometer
• Protractor
• Astrolabe

[spencergibb]

telemetry

[smaldini]

I liked Micrometer and Telemetry, they only suffer their common name on SEO:

• Datameter
• Datametry (relatively SEO free)
• Signalmetry
• Signalmeter
• Telemetrix
• Photonprobe
• Photonmeter

Hopefully it will refine quickly :D 👍

[checketts]

I really like telemetry. For seo, make it officially 'telemetry commons'

[jkschneider]

I think we're going to settle on micrometer. Not perfect for SEO, perhaps, but has the advantage of being easy to spell. Excellent suggestion, @philwebb.

Telemetry sounds good, but is also a synonym sometimes used to describe the whole space of application metrics, so might be confusing in that sense.

[spencergibb]

I assume the github org will stay spring-projects? and the groupId org.springframework.*?

[jkschneider]

Nope, will move the github org and group.

[jkschneider]

New github org, name, website, docs, Slack team. Phew... I hope the name micrometer is good enough.

[checketts]

Well done! Now to determine if I pronounce it 'my-crow-meter' or 'my-crom-ehter'

[spencergibb]

The later https://en.wikipedia.org/wiki/Micrometer

not

https://en.wikipedia.org/wiki/Micrometre

[jkschneider]

Wow, that's definitive @spencergibb.

[spencergibb]

Yes, I am a nerd with mad wikipedia skilz

[spencergibb]

Actually, I was just curious what the pronunciation of the measuring instrument actually was.

[checketts]

Rhymes with chronometer since it is a measurer not a unit of measurement. Thanks @spencergibb