apple / swift-metrics

Metrics API for Swift
https://apple.github.io/swift-metrics/
Apache License 2.0
655 stars 64 forks source link

Logging metrics factory #70

Open glbrntt opened 4 years ago

glbrntt commented 4 years ago

When adding metrics to an application or framework it would be useful to have some indication of the metrics emitted during execution to serve as a basic sanity check ("when I do this does metric X get emitted?").

Providing a metrics factory which prints to stdout/stderr whenever a value is recorded would be helpful for this case. Is this something we think we should provide in swift-metrics?

ktoso commented 4 years ago

Sounds like a useful one -- I have a similar thing in my projects where it can capture the emitted metrics and assertions can be performed on them.

I do agree that it's useful, but I'm also on the side that swift-metrics (and swift-log) should contain no implementations, all backends should be external libs, even if small ones IMHO and these libs are best to remain as little impl and opinionated as possible (main reason being that this is a tremendously slippery slope, once we add a small thing, and another small thing, people get used to "the lib has things" and more and more stuff gets added).

I'm supportive, but would love to find a way we can put those not as the part of "the API project". If it's too difficult for such under the apple/ namespace perhaps we could use the swift-server org or some other idea?

MrLotU commented 4 years ago

Fully agree with @ktoso here.

Great idea but probably not best suited to be included in the swift-metrics project directly

glbrntt commented 4 years ago

I do agree that it's useful, but I'm also on the side that swift-metrics (and swift-log) should contain no implementations, all backends should be external libs, even if small ones IMHO and these libs are best to remain as little impl and opinionated as possible (main reason being that this is a tremendously slippery slope, once we add a small thing, and another small thing, people get used to "the lib has things" and more and more stuff gets added).

I totally get this and agree it's a slippery slope.

My concern is that putting this in another package would introduce a level of friction that would render it pointless: I wouldn't want to release a framework which depended on it (even if it was only in tests) and I probably wouldn't manually add/remove it from my package manifest whenever I wanted to do a quick sanity check. In all likelihood I'd end up copying and pasting it whenever I needed it.

glbrntt commented 4 years ago

@ktoso I was thinking about this a little over the weekend: maybe a more general purpose metrics-testing package could be a home for this.

ktoso commented 4 years ago

Hey there, sorry was offline for the last week.

You mean as separate target/library but inside this repo, and call it some EventCaptureTestMetricHandler? (the impl I use for logging I call "LogCapture" I guess, so thinking if the word capturing could make sense for the family of such handlers... the same for metrics/tracing/logging)

I still think it's a slippery slope to add more things here rather than make many smaller repos -- smaller repos put these "on level playing field" as any other person's implementation and show more intent that yes, there should be tons of implementations by various people, rather than in this repo as "the" one... but others maybe disagree. I'm kind of hoping it's not hard for us to spin new repos in swift-server org perhaps if we want to make such handlers available?

@weissi @tomerd wdyt?

glbrntt commented 4 years ago

I actually meant in a separate repo :)

ktoso commented 4 years ago

Oh awesome :-) Then I'm super supportive of it. Others may want to chime in, but sounds great to me.

MrLotU commented 4 years ago

Having a swift-metrics-tools kind of repository in the swift-server org sounds like a great idea to me.

👍

tomerd commented 4 years ago

sorry for the slow response here, for whatever reasons my email filtered our this thread.

I agree with everything that was said here. I also find myself needing this often in debugging context so would be nice to have a utility to bridge metrics into logs in that context. I also agree that a separate package/repo is the way to go. @glbrntt is this something you want to kick off?

glbrntt commented 4 years ago

Yeah, I'm happy to do that; I'll pitch something to the forums to help shape this.

glbrntt commented 4 years ago

fyi: https://forums.swift.org/t/metrics-extras/36616