Use labels for metrics #444

Merged
fyrchik merged 1 commits 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)
Collaborator

Ca we use strconv.FormatBool() here?

Ca we use `strconv.FormatBool()` here?
Poster
Collaborator

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

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
Poster
Collaborator

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())

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

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

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) {

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.
Poster
Collaborator

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

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?
Poster
Collaborator

For consistency with other code.

For consistency with other code.

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
ci/woodpecker/pr/pre-commit Pipeline was successful Details
ci/woodpecker/push/pre-commit Pipeline was successful Details
69b788a90b
[#424] metrics: Rename mode to mode_info
To follow best practice.

Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
Poster
Collaborator

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/

@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{

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?

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

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

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
Poster
Collaborator

@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 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
There is no content yet.