-
Notifications
You must be signed in to change notification settings - Fork 28
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
Instrument the instance and shell using Swift Metrics #56 #70
Conversation
This added testing infra for the metrics and I'll finish up adding all metrics soon as I'd like to put them to good use. |
Example metrics:
|
import SWIMTestKit | ||
import XCTest | ||
|
||
final class SWIMNIOMetricsTests: RealClusteredXCTestCase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fully integration tested metrics, yay! 🥳
@@ -9,6 +9,7 @@ var targets: [PackageDescription.Target] = [ | |||
dependencies: [ | |||
"SWIM", | |||
"SWIMNIOExample", | |||
"SwiftPrometheus", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only in the example, since it has an easy way to just "print" metrics to CLI
/// Object containing all metrics a SWIM instance and shell should be reporting. | ||
/// | ||
/// - SeeAlso: `SWIM.Metrics.Shell` for metrics that a specific implementation should emit | ||
public struct Metrics { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We list all metrics we offer here.
It's a good pattern to document them like this, and also -- thanks to this, rather than ad hoc creation when used, we're able to nicely test and mock them, even if there are many instances in the same process. We would not be able to do this if we went with super global stuff.
case .unreachable: | ||
unreachables += 1 | ||
case .dead: | ||
() // dead is reported as a removal when they're removed and tombstoned, not as a gauge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deads are not counted, as they are removed already; however notice that we do count the tombstones
|
||
self.metrics.incarnation.record(self.incarnation) | ||
self.metrics.localHealthMultiplier.record(self.localHealthMultiplier) | ||
self.metrics.updateMembership(self.members) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
important to set some initial values, not to be completely empty and confusing when people look at it
+testkit move testing utilities to shared module, since we need to reuse them implement more metrics, failures and timing intervals
comment out in example by default cleanup
Please have a look as well if the metrics (all listed here https://github.com/apple/swift-cluster-membership/pull/70/files#r498088594 ) look good. I think that's the main things we care about, @budde 👍 -- Sanity check for style and testing how we instrument such systems welcome; Mostly pinging since this is the first time we introduce more instrumentation into any of our OSS packages, and I believe this general pattern is the right to suggest and apply as we instrument other systems too, open to opinions though! I'll follow up a bit in another project where and then merge and release this SWIM update as a minor bump. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Co-authored-by: Yim Lee <yim_lee@apple.com>
Thank you for reviews everyone! |
Motivation:
SWIM is a great example of a very internal piece of clusters which should expose metrics well.
And there's all kinds of types of metrics, gauges for the membership, counters for total messages etc, and recorders for how many data we sent etc.
In this PR trying to explore the best patterns for instrumenting such middleware with swift-metrics.
Modifications:
Still work in progress
Result: