-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add stat framework to Propolis #147
Conversation
This won't build in CI because it still has a custom path to Crucible. |
From hypervisor huddle: How are the metrics that are recorded being stored in the database? Specifically, would it be "easy" for someone who wanted to look at IO over time (where perhaps there were several power cycles) to be able to read out data and construct a graph. The concern here is to be sure that we don't store our data in the database in a way that causes a common use of the data to be difficult to extract. |
This is covered in RFD 161. It's a bit complicated, since there are tables for tracking different parts of the timeseries (e.g., fields versus measurements). But the raw data is all stored contiguously in one of the measurement tables. For example, each measurement of the Nexus latency histograms, for one endpoint and response code, are stored ordered by time.
Easy is appropriately in scare-quotes there. The short answer is that you can get the raw data now, but there are no tools for anything beyond that. That work has just been scheduled behind other stuff. You've seen the |
If the DNS names are working for Oximeter, I'll add that in place of the hard coded address that is here now, but other than that, I think the general shape of this is ready for any comments. |
propolis/Cargo.toml
Outdated
@@ -21,7 +21,8 @@ viona_api = { path = "../viona-api" } | |||
usdt = { version = "0.3.2", default-features = false } | |||
tokio = { version = "1", features = ["full"] } | |||
futures = "0.3" | |||
crucible = { git = "https://github.com/oxidecomputer/crucible", rev = "fed3e8ca7762130ee146fc516a4ef6eed2b91629", optional = true } | |||
crucible = { git = "https://github.com/oxidecomputer/crucible", branch = "producemetric", optional = true } | |||
oximeter = { git = "https://github.com/oxidecomputer/omicron", branch = "main", optional = true } |
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.
Just to make sure I'm not misreading: it looks like oximeter
is only optional if crucible
is disabled; otherwise the Crucible module will be missing the ProducerRegistry
type. Is that right? (I'm trying to reason through how we might keep this module optional when we extend metrics collection to more than just Crucible.)
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.
I'm actually not 100% sure, but my intent here was trying to allow propolis standalone to build and not have to pull in both crucible and then oximeter.
Crucible needs to know about ProducerRegistry, and now propolis-server will also need to know about it, even if Crucible is not present.
Control of metric server is now determined at propolis-server start time, though the actual metrics endpoint won't start until the instance itself is started. An optional metric_addr arg if provided will indicate that a metrics endpoint will later be started. Remove metric field from InstanceProperties Updated smf manifest to support metric_addr config option.
No need to wrap things in Arc Mutex, and I don't have to keep track of producer_register outside of instance_ensure().
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.
Looks great from my end--thanks for the changes!
This now points to the latest crucible rev in main, where all required changes are. |
standalone/Cargo.toml
Outdated
@@ -27,3 +27,4 @@ slog-term = "2.7" | |||
default = ["dtrace-probes"] | |||
dtrace-probes = ["propolis/dtrace-probes"] | |||
crucible = ["propolis/crucible"] |
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.
Now that the crucible backend is using oximeter, shouldn't the feature list propolis/oximeter
itself here?
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.
Updated
propolis/Cargo.toml
Outdated
crucible = { git = "https://github.com/oxidecomputer/crucible", rev = "2add0de8489f1d4de901bfe98fc28b0a6efcc3ea", optional = true } | ||
oximeter = { git = "https://github.com/oxidecomputer/omicron", branch = "main", optional = true } |
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.
Since these are getting long, maybe define them as [dependencies.crucible]
style sections?
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.
Updated
@gjcolombo I merged with your changes like we discussed in chat. Let me know if that looks good. I tested these changes and stats are still produced and oximeter collects them. |
Looks good to me! |
This is an initial pass at putting some Oximeter stats into propolis, dragging Crucible along for the ride.
Feedback welcome about this strategy for metrics, and how might we improve it.
On instance create, a
ProducerRegistry
can be created that can be passed to libraries that wish to record stats. This allows Propolis to not have to know what stats a library wishes to register.A new struct,
InstanceMetrics
, has been added toContext
. This is used for tracking stats for an instance as well as containing theProducerRegistry
that libraries can use to register with Oximeter/Nexus for their own stats.A new optional
metrics
field inInstanceEnsureRequest
that, if is is present, tells propolis server if it should setup metrics at the provided registration address. The propolis CLI also has this same optional argument.The CrucibleBackend Volume::construct() now takes a
ProducerRegistry
that if present can beused to register metrics with Oximeter.
This requires changes in both crucible and omicron, and will have to be merged accordingly.
In this PR, we are creating a standalone metrics endpoint different from the propolis API.
Things that need completion or additional issues before we can merge this: