-
Notifications
You must be signed in to change notification settings - Fork 208
Expose piped stat metrics at ops metrics endpoint #2202
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
Conversation
|
The following ISSUES will be created once got merged. If you want me to skip creating the issue, you can use Details1. Implement builder to gather piped stats metrics in redis.This was created by todo plugin since "TODO:" was found in 78d42dd when #2202 was merged. cc: @khanhtc1202. |
pipecd-bot
left a comment
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.
|
Code coverage for golang is
|
|
Code coverage for golang is
|
| cmd.Flags().DurationVar(&s.gracePeriod, "grace-period", s.gracePeriod, "How long to wait for graceful shutdown.") | ||
| cmd.Flags().StringVar(&s.configFile, "config-file", s.configFile, "The path to the configuration file.") | ||
| cmd.Flags().StringVar(&s.gcloudPath, "gcloud-path", s.gcloudPath, "The path to the gcloud command executable.") | ||
| cmd.Flags().StringVar(&s.cacheAddress, "cache-address", s.cacheAddress, "The address to cache service.") |
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.
Ops' deployment need this too.
https://github.com/pipe-cd/pipe/blob/master/manifests/pipecd/templates/deployment.yaml#L96
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.
Nice catch 👍
Address by b967765 🙏
cmd/pipecd/ops.go
Outdated
| w.Write([]byte("ok")) | ||
| }) | ||
| admin.Handle("/metrics", t.PrometheusMetricsHandler()) | ||
| admin.Handle("/metrics", t.CustomedMetricsHandlerFor(psb)) |
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.
with this customed metrics handler, we ignore all other metrics exposed to the current ops metrics registry ( which currently is zero ). Will carefully handle those ops's metrics later 🙏
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.
nit: I feel the name should be -> CustomMetricsHandlerFor
|
Code coverage for golang is
|
| } | ||
| data = append(data, value) | ||
| } | ||
| return ioutil.NopCloser(bytes.NewReader(bytes.Join(data, []byte("\n")))), nil |
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.
iouti.NopClose is deprecated. Instead using io.NopCloser is preferable.
https://golang.org/pkg/io/ioutil/#NopCloser
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.
Well, why does it need to be an io.ReadCloser? Seems like io.Reader is enough.
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 want to carefully close the []byte stream on the hander side. Or is it unnecessary? 🤔
ref: https://github.com/pipe-cd/pipe/pull/2202/files#diff-c9b9fc9a691a60f03cc1d752ce9fac11e932d6a2867c984bd26923131704fdeaR152
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.
First, NopCloser.Close does nothing.
And with the current implementation of PipedStatsBuilder.Build(), all byte sequences are on the heap. So no need to do close operations at all.
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.
If you're planning to directly read from any kinds of stream like Redis in the future, then you will have to add the close operation.
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 see 👍 Since we will keep the GetAll interface which returns data ( not the reader or else to direct stream data ), it's safe to remove this unnecessary closer as you mentioned 🙏 Lets me address it 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.
Addressed on d448919 🙏
|
Code coverage for golang is
|
| } | ||
| data = append(data, value) | ||
| } | ||
| return bytes.NewReader(bytes.Join(data, []byte("\n"))), nil |
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.
it's alright to be later, adding a test for Build() makes it more clear.
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.
Sure, just added a simple test 6cad0a6 👀
|
Code coverage for golang is
|
| @@ -0,0 +1,180 @@ | |||
| # HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. | |||
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.
metricsdata -> testdata
| } | ||
| data = append(data, value) | ||
| } | ||
| return bytes.NewReader(bytes.Join(data, []byte(""))), nil |
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.
Use \n as the separator is safer for all cases.
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.
btw, an empty line between metrics is fine.
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.
got it 🙆♀️
|
Code coverage for golang is
|
| func (m *mockBuilderBackend) GetAll() (map[string]interface{}, error) { | ||
| out := make(map[string]interface{}, len(m.srcs)) | ||
| for _, file := range m.srcs { | ||
| data, err := ioutil.ReadFile(file) |
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.
ioutil package is entirely deprecated. Let's use os.ReadFile
https://golang.org/pkg/io/ioutil/#ReadFile
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.
Lets no ioutil, lol
028e358
| assert.NoError(t, err) | ||
| assert.NotNil(t, rc) |
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.
require package would be better because it stops test execution when it fails.
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.
To be honest, do we have convention of which check should be wrapped with require and which should be with assert 👀 I saw the require is used somewhere but mixed with assert 👀
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.
addressed on ac20e18
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.
In the case of nil and error, it's more likely to panic if proceeds. So we basically use require for NoError and NotNil.
|
Code coverage for golang is
|
|
Code coverage for golang is
|
|
Great work. |
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?: