-
Notifications
You must be signed in to change notification settings - Fork 1
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 internal monitoring server for metrics and profiling #3500
Conversation
@squaremo @bigkevmcd just adding your for visibility on the change. Feel free to review on marked as ready if you want but not needed. |
pkg/monitoring/profiling/pprof.go
Outdated
Enabled bool | ||
} | ||
|
||
func NewDefaultPprofHandler() (string, http.Handler) { |
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.
Exported, so should have a doc 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.
added 👍
pkg/monitoring/server.go
Outdated
|
||
// NewSever creates and starts a management server for all endpoints that we need to expose internally. For example metrics or profiling. | ||
func NewServer(opts Options) (*http.Server, error) { | ||
if !opts.Enabled { |
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 feels like this should be moved outside, so we only create the server if it's enabled?
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.
agree, it was odd. the proper check was put in the client side. removed here
// management server | ||
var monitoringServer *http.Server | ||
args.Log.Info("i am in server monitoring", "monitoring", args.MonitoringOptions) | ||
if args.MonitoringOptions.Enabled { |
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.
See below, maybe we shouldn't be creating the server if it's not enabled?
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 think this is covered by the previous comment. let me know in case not.
pkg/monitoring/server_test.go
Outdated
) | ||
|
||
func TestNewServer(t *testing.T) { | ||
require := require.New(t) |
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 don't think this is right, you're calling .Error
inside a sub-test which will trigger a subtest error?
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.
Thanks for the comment: could you expand a bit more. My idea here is to have a test case for unhappy path, in this case where a client tries to create a monitoring server without a valid address.
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 like it's fixed now?
Essentially, failing a *testing.T
from a parent test will cause the subtest to fail with an error.
package main
import (
"testing"
"github.com/stretchr/testify/require"
)
func TestHelloWorld(t *testing.T) {
require := require.New(t)
value := "testing errors"
t.Run("bad subtest", func(t *testing.T) {
require.Equal(value, "test")
})
t.Run("this subtest", func(t *testing.T) {
require.Equal(value, "another test")
})
}
$ go test .
--- FAIL: TestHelloWorld (0.00s)
subtest_test.go:14:
Error Trace: /Users/kevin/Source/Go/eneko/subtest_test.go:14
Error: Not equal:
expected: "testing errors"
actual : "test"
Diff:
--- Expected
+++ Actual
@@ -1 +1 @@
-testing errors
+test
Test: TestHelloWorld
--- FAIL: TestHelloWorld/bad_subtest (0.00s)
testing.go:1490: test executed panic(nil) or runtime.Goexit: subtest may have called FailNow on a parent test
FAIL
FAIL subtest-demo 0.176s
FAIL
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.
ohh yes, I see got it now ... that require was not supposed to be there. thanks for the explanation 🙏
- name: http-metrics | ||
containerPort: {{ .Values.metrics.service.port }} | ||
{{- if .Values.monitoring.enabled }} | ||
- name: {{ .Values.monitoring.service.name }} |
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 .Values.metrics.enabled }} | ||
- port: {{ .Values.metrics.service.port }} | ||
targetPort: {{ .Values.metrics.service.port }} | ||
{{- if .Values.monitoring.enabled }} |
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.
👍🏻
Added also docs to the PR and here weaveworks/weave-gitops#4089 |
@bigkevmcd please let me know whether |
Closes #3228
What changed?
Why was this change made?
We wanted to be able to release profiling feature but we could not cause it was in the same public endpoint as the API.
How was this change implemented?
Refactored the existing metrics server to be more general for monitoring purposes. Initially called management server but renamed to monitoring server as the term is already overloaded in our context.
Refactored the configuration around this also.
How did you validate the change?
Tilt:
/metrics
endpoint/debug/pprof
endpointor, explain why there are no new tests
this test is border-line between integration and unit https://github.com/weaveworks/weave-gitops-
enterprise/pull/3500/files#diff-c426c36708aa75ac5531273cbf747c1cdda4953cee6346db63de5e392e6fb87c
there tests that fail without the change?
Added and refactored some existing ones
Release notes
We have updated configuration values embedding
metrics
undermonitoring
. In case youhave disabled metrics in your helm release values previously by setting:
You should update it to have he same behavior
Please review monitoring for more info.
Documentation Changes
weaveworks/weave-gitops#4089
Other follow ups
Not identified