Use labels for metrics #444

Merged
fyrchik merged 1 commit from dstepanov-yadro/frostfs-node:fix/wc_metrics_labels into master 2023-07-26 21:07:59 +00:00

Closes #424
Closes #432

Closes #424 Closes #432 * The names of the metrics have been changed in accordance with https://prometheus.io/docs/practices/naming/ * Added use of labels for the same metrics * Embedding replaced with fields
dstepanov-yadro changed title from Use labels for metrics to WIP: Use labels for metrics 2023-06-13 12:07:40 +00:00
dstepanov-yadro force-pushed fix/wc_metrics_labels from 13621abe10 to d11c0cb878 2023-06-13 13:58:40 +00:00 Compare
dstepanov-yadro force-pushed fix/wc_metrics_labels from d11c0cb878 to 321dd2e464 2023-06-13 16:09:50 +00:00 Compare
dstepanov-yadro changed title from WIP: Use labels for metrics to Use labels for metrics 2023-06-14 08:12:02 +00:00
acid-ant approved these changes 2023-06-14 08:35:29 +00:00
@ -0,0 +11,4 @@
if !v.Valid {
return ""
}
return fmt.Sprintf("%v", v.Bool)
Member

Ca we use strconv.FormatBool() here?

Ca we use `strconv.FormatBool()` here?
Author
Member

fixed

fixed
acid-ant marked this conversation as resolved
dstepanov-yadro force-pushed fix/wc_metrics_labels from eb944e1a4a to 540dd8a7e0 2023-06-14 09:15:46 +00:00 Compare
Owner

Please, resolve conflicts.

Please, resolve conflicts.
dstepanov-yadro force-pushed fix/wc_metrics_labels from 540dd8a7e0 to 2a8e05e070 2023-06-14 12:04:42 +00:00 Compare
Author
Member

Please, resolve conflicts.

Done

> Please, resolve conflicts. Done
fyrchik approved these changes 2023-06-14 14:37:27 +00:00
@ -64,3 +64,3 @@
func (m *writeCacheMetrics) Get(d time.Duration, success bool, st writecache.StorageType) {
m.metrics.AddGetDuration(m.shardID, success, d, st.String())
m.metrics.AddMethodDuration(m.shardID, "Get", success, d, st.String())
Owner

Why Get and not get or GET? (just a question)

Why `Get` and not `get` or `GET`? (just a question)
Author
Member

Because it is just method name with capital letter

Because it is just method name with capital letter
fyrchik marked this conversation as resolved
@ -0,0 +30,4 @@
}
}
func (m *shardIDModeValue) SetMode(shardID string, mode string) {
Owner

So we have const shardID and mode labels and create a new metric for each.
Why not just have variable labels?
Also IMO readonly{shard="abc"} + degraded{shard="abc"} is enough -- this is what we are interested in, so instead of 4 metrics for each shard we have 2.

So we have const `shardID` and `mode` labels and create a new metric for each. Why not just have variable labels? Also IMO `readonly{shard="abc"}` + `degraded{shard="abc"}` is enough -- this is what we are interested in, so instead of 4 metrics for each shard we have 2.
Author
Member

Why not just have variable labels?

Agree, fixed

Also IMO readonly{shard="abc"} + degraded{shard="abc"} is enough

So we have 2 metrics instead of 1, because we have label "mode" with string value

> Why not just have variable labels? Agree, fixed > Also IMO readonly{shard="abc"} + degraded{shard="abc"} is enough So we have 2 metrics instead of 1, because we have label "mode" with string value
fyrchik marked this conversation as resolved
@ -17,3 +11,1 @@
treeService *treeServiceMetrics
epoch prometheus.Gauge
gc *gcMetrics
engine *engineMetrics
Owner

I think I get why you do not like embedding, by why adding a pointer here?

I think I get why you do not like embedding, by why adding a pointer here?
Author
Member

For consistency with other code.

For consistency with other code.
Owner

With what code?

With what code?
fyrchik marked this conversation as resolved
fyrchik requested review from fyrchik 2023-06-14 14:37:55 +00:00
dstepanov-yadro force-pushed fix/wc_metrics_labels from 2a8e05e070 to 26b305f82b 2023-06-14 15:33:14 +00:00 Compare
dstepanov-yadro added 1 commit 2023-06-14 15:41:07 +00:00
[#424] metrics: Rename mode to mode_info
All checks were successful
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/push/pre-commit Pipeline was successful
69b788a90b
To follow best practice.

Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
Author
Member

Also renamed mode -> mode_info because it is pseudo-metric: https://prometheus.io/docs/practices/naming/

Also renamed `mode` -> `mode_info` because it is pseudo-metric: https://prometheus.io/docs/practices/naming/
Owner

@dstepanov-yadro it is said that pseudo-metric provides info about the binary, shard mode is a valid runtime state, it is not about the binary. Am I missing something here?

@dstepanov-yadro it is said that pseudo-metric provides info about the _binary_, shard mode is a valid runtime state, it is not about the binary. Am I missing something here?
fyrchik reviewed 2023-06-15 11:54:45 +00:00
@ -0,0 +22,4 @@
}
func (m *shardIDModeValue) SetMode(shardID string, mode string) {
m.modeValue.DeletePartialMatch(prometheus.Labels{
Owner

So in theory we can receive no metrics for an existing shard here?
Probably not very important, but may be this is "easily" fixable?

So in theory we _can_ receive no metrics for an existing shard here? Probably not very important, but may be this is "easily" fixable?
Owner

Like, receiving 2 may be better -- we are transitioning between states anyway.

Like, receiving 2 may be better -- we are transitioning between states anyway.
Author
Member

Yes, we can receive no metric for shard for some period of time when mode changes. We can use GaugeFunc to get continous graph.
But i think it is the limitation of Go client for Prometheus, because GaugeFunc doesn't support removing, so deleted shard will be presented until restart.

Yes, we can receive no metric for shard for some period of time when mode changes. We can use `GaugeFunc` to get continous graph. But i think it is the limitation of Go client for Prometheus, because `GaugeFunc` doesn't support removing, so deleted shard will be presented until restart.
fyrchik approved these changes 2023-06-15 11:54:48 +00:00
Author
Member

@dstepanov-yadro it is said that pseudo-metric provides info about the binary, shard mode is a valid runtime state, it is not about the binary. Am I missing something here?

Agree, but i think we can extend this point to mode value. I think it will be clever use text label value instead of some magic number.

> @dstepanov-yadro it is said that pseudo-metric provides info about the _binary_, shard mode is a valid runtime state, it is not about the binary. Am I missing something here? Agree, but i think we can extend this point to mode value. I think it will be clever use text label value instead of some magic number.
fyrchik merged commit 69b788a90b into master 2023-06-15 14:10:28 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#444
No description provided.