-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
metrics: introduce go-metrics-interface #3189
Conversation
6aff024
to
b5fd41d
Compare
} | ||
|
||
func arcCached(bs Blockstore, lruSize int) (*arccache, error) { | ||
func newARCCachedBS(bs Blockstore, ctx context.Context, lruSize int) (*arccache, 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.
convention is to place the context first, i think that even though the blockstore is the primary object we should still respect that.
Updated. |
47d568c
to
98bf4c4
Compare
bc.Invalidate() | ||
go bc.Rebuild(ctx) | ||
|
||
go func() { |
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 there a quick way to check if we even have metrics enabled? It would be nice if metrics were turned off, this goroutine wouldnt exist.
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.
Yeah, had the same idea, I will add method to go-metrics-interface to check if there was some impl injected.
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.
might even be cool to wrap this sort of behaviour in a metrics.Periodic
type method.
This LGTM. I'm definitely on board with doing things this way. Some notes for future metrics to add (maybe i should make this an issue?)
|
This option could really use other feature of prometheus: labels, but for that I will have to figure out how to wrap it nicely first. |
Alright, so i'm gonna merge this. But since there are a few tweaks we want to make to the interface, lets hold off on pushing it into packages outside this repo (to avoid the pain of massive amounts of updating) |
Wait a sec. |
Updated to not run bloom fillrate collector when metrics aren't active. |
return | ||
case <-t.C: | ||
fill.Set(bc.bloom.FillRatio()) | ||
if metrics.Active() { |
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.
Is this some sort of global? That feels very wrong to me. Why arent we checking if the context has metrics injected into it and using that as a way to tell if we have metrics 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.
Context is used to define full name of the metrics.
This checks if there is metrics collector injected into go-metrics-interface.
The collector is global.
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.
ooooh.... hrm.. I misunderstood how this all worked then. I was under the impression we were avoiding globals entirely by using the contexts to pass metrics down through to where they would be collected.
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.
This is still okay, Its just less testable and composable than i was hoping.
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.
We could do that, but then we won't be able to use metrics from libp2p as the goprocess doesn't support WithValue
/Value
.
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 general: don't use statics. If you run multiple IPFS daemons, the
metrics may clash. If the lib FORCES you to use a global, then add a
guaranteed-unique prefix. Ideally with a local variable that internally
uses the global, threaded through with the context. - but I don't care enough about this case to force it, if it's way easier
and safe to have thousands of IPFS daemons in the same process, and nothing
will clash, fine.
On Wed, Sep 7, 2016 at 9:10 PM Jeromy Johnson [email protected]
wrote:
In blocks/blockstore/bloom_cache.go
#3189 (comment):bc.Invalidate() go bc.Rebuild(ctx)
- go func() {
<-bc.rebuildChan
t := time.NewTicker(1 \* time.Minute)
for {
select {
case <-ctx.Done():
t.Stop()
return
case <-t.C:
fill.Set(bc.bloom.FillRatio())
- if metrics.Active() {
This is still okay, Its just less testable and composable than i was
hoping.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ipfs/go-ipfs/pull/3189/files/0fa592196ed0f0429ef5a734e4efc17e2f8e0cb9..bb405f316a3819a4dba1d972dca8a547ea80fcb0#r77885221,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoRleigomIjiQWwSzrGwiXL5YAXpYks5qnwxCgaJpZM4J1L0L
.
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.
Metrics you get will be a bit meaningless (as they will be combined) but we install the collector in cmd/ipfs/daemon.go
so someone using ipfs as a lib can use different collector.
I can also make ipfs use subscope if there is one passed to context in which NewNode then you will be able to pass scope in which given IPFS nodes should be created.
94917e2
to
7f77cc5
Compare
@@ -359,8 +360,7 @@ func daemonFunc(req cmds.Request, res cmds.Response) { | |||
} | |||
|
|||
// initialize metrics collector | |||
prometheus.MustRegisterOrGet(&corehttp.IpfsNodeCollector{Node: node}) | |||
prometheus.EnableCollectChecks(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.
why was enableCollectChecks removed?
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 was removed from API and enabled by default.
Where do we actually fill the interface? I see the old prometheus stuff... but i think i'm missing where we actually add prometheus as a collector for your metrics package |
https://github.com/ipfs/go-ipfs/pull/3189/files#diff-54f2c4a5481de30b8ccb59ad5b6588b3R31 I am using |
@Kubuxu i'm not sure i'm comfortable with injecting things that way... It should be an explicit thing we do in an init function of whatever code we import it from. also need rebasing here |
The single purpose of go-metrics-prometheus is to be injected into go-metrics-interface, this pacakge doesn't export any other symbols. I will change it. |
b5c89d3
to
184b72c
Compare
That was one hello of a rebase. We really need to do something with this. |
I'm not super on board with the way this does metrics... but since it is an improvement on the current situation, we can merge it in. Some action items to move forward after this:
|
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
ARC cache is influenced by requests and bloom isn't This means that if bloom is able to remove some requests caching them in ARC is pointless. License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
so the context is first one License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
License: MIT Signed-off-by: Jakub Sztandera <[email protected]>
184b72c
to
9cbeffa
Compare
Rebased it once more |
Alright, lets get this in. Thanks @Kubuxu! Better metrics for everyone! |
metrics: introduce go-metrics-interface This commit was moved from ipfs/kubo@f23cd5c
It makes introducing metrics much easier.
The interface itself doesn't depend on prometheus, that means it is very light and without it (or other implementation) acts as a general noop.
Importing go-metrics-prometheus injects prometheus implementation.
Usage:
There are three most improtant functions in go-metrics-interface:
metrics.New(name, helptext)
- creates new metrics with given name and helptextmetrics.NewCtx(ctx, name, helptext)
- creates new metrics with given name and helptext in scope defined in the contextmetric.CtxSubScope(ctx, name)
- returns context that is a subscope of scope defined in current ctxAs you can see it uses
context.Value
for passing the scope name of the metrics. In my opinion it is one of the better solutions as context is already required in many places, and it introduction in constructors chains isn't bad either.Current problem I have is that
goprocess
doesn't have something likecontext.Value
so passing scopes throughgoprocess
is something I haven't figured out yet but it can be done later.//cc @whyrusleeping @lgierth