-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[processor/attributes] Support attributes set by server authenticators #9420
[processor/attributes] Support attributes set by server authenticators #9420
Conversation
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.
LGTM, just the documentation could be a bit better. Thanks for this PR!
@jpkrohling I added logger to the Thanks for suggestions to the docs. I just noticed there is a relevant issue, thanks for linking it to the PR. |
@@ -86,7 +86,7 @@ func TestAttributes_InsertValue(t *testing.T) { | |||
}, | |||
} | |||
|
|||
ap, err := NewAttrProc(cfg) | |||
ap, err := NewAttrProc(cfg, 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.
I won't block the PR for this unless @pmm-sumo agrees with me, but I would prefer the test to be passing zap.NewNop() instead of nil. Remember that your test code shows the good practice for consumers of the main code, and by passing nil, you are sending the message that nil is OK, when it really isn'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.
Sure, I don't have a preference here. Gonna update.
func NewAttrProc(settings *Settings) (*AttrProc, error) { | ||
var attributeActions []attributeAction | ||
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) { | ||
if logger == 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.
I think now we might assume that logger is never 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.
Yeah, it was never nil
and that's why passing nil
previously worked. I don't want this to fail if nil
is passed. :)
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 good to check for nil, but not sure about the outcome: you do want to have access to a logger, it's not an optional parameter, so, you should return an error if it's 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.
I agree, this seems to be unrelated, consider to split a separate PR.
There is a race detected by tests which seems to be related to open-telemetry/opentelemetry-collector#4939. Not sure. Asked about this here: https://cloud-native.slack.com/archives/C01N6P7KR6W/p1651007898391749 |
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 all looks good to me - very similar to what I planned to implement when filing #9241, except that I didn't anticipate the logging changes. Please let me know if I can help get this merged.
@rkukura I probably just need someone to rerun unit tests to get over the flaky ones. Thanks. |
Tests restarted |
func NewAttrProc(settings *Settings) (*AttrProc, error) { | ||
var attributeActions []attributeAction | ||
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) { | ||
if logger == 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 good to check for nil, but not sure about the outcome: you do want to have access to a logger, it's not an optional parameter, so, you should return an error if it's nil.
d9230ae
to
42fa321
Compare
PR rebased |
@jpkrohling Thanks. |
@jpkrohling What is left to get it merged? |
Juraci is now on parental leave :) But since we have 3 approvals (including two from approvers/contributors) and passing tests, I'm marking this as |
func NewAttrProc(settings *Settings) (*AttrProc, error) { | ||
var attributeActions []attributeAction | ||
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) { | ||
if logger == 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.
I agree, this seems to be unrelated, consider to split a separate PR.
@pmm-sumo there are lots of unrelated changes, and some random configurations for logger (why do we need sampling here and not in other places? add debug logs if too many, record metrics, etc.) |
@bogdandrutu There was a suggestion to log invalid atrribute types if they are returned by ServerAuthenticator: #9420 (comment) I don’t care much about sampling and can drop it. It was taken from the suggestion in one of the comments above. I will reduce this PR to changes I originally introduced and leave further changes to maintainers who have a better idea than me. |
@svrakitin it is not about "better idea than me", it is about keeping the PRs focus on what we want to implement :) |
Good point @bogdandrutu, apologies for messing up with tagging and thanks for bringing this up. On the sampled logger thing, I believe it stems from this comment. I mentioned sampled logging since this was something brought to my attention in the past (don't recall which PR but I can look it up for context). In principle, I think that user should know that something is wrong and because of that So we have two paths here:
I was inclined towards the latter (in a separate PR). There are some components doing that already and I was aiming at doing the cleanup after this get merged. Before I open the issue wanted to check what is your preference @bogdandrutu |
42fa321
to
a147333
Compare
I reduced this PR to the initial set of changes. Let's address how we warn users in a separate PR then. |
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 PR looks much better now, @pmm-sumo please re-approve since you are familiar, and add the label again
open-telemetry#9420) Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com> Co-authored-by: Alex Boten <aboten@lightstep.com>
Description:
Support looking up attributes from
client.Info.Auth
which is set by extensions implementingconfigauth.ServerAuthenticator
. This way we can attach authentication of the exporter (e.g. OIDC subject) to the telemetry.User can refer to these attributes by prefixing keys with
auth.
when usingfrom_context
:For consistency I added
metadata.
prefix to refer to actual metadata/header keys. This prefix is optional for backwards compatibility.Testing:
I added tests to
attraction
package which has actual extraction logic.Closes #9241