Skip to content
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

Changes configuration logging to be reflect-based. #563

Merged
merged 3 commits into from
Jun 14, 2018
Merged

Conversation

hhhjort
Copy link
Collaborator

@hhhjort hhhjort commented Jun 14, 2018

Fixes #561

cirla
cirla previously approved these changes Jun 14, 2018
Copy link
Contributor

@cirla cirla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool! I really like the log by default but blacklist passwords, etc. (and I like that it's built to be extensible).

case reflect.Struct:
logStructWithLogger(v, prefix, logger)
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
logInt(v, prefix, logger)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem like logInt does anything that requires the reflect.Value, could this just be:

logger("%s: %d", prefix, v.Int())

along with the remaining cases?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it that way to resemble the struct case and be more easily extensible if we want further functionality in the future. I was initially expecting to need more than just one short line though, so if you really think it would be better inlined, I don't have a problem with that.

Copy link
Contributor

@dbemiller dbemiller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code itself looks awesome :). I'm still kicking myself for not thinking of this.

Few small maintenance requests before I'd feel comfortable merging it though.

@@ -0,0 +1,104 @@
package structlog
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this isn't exactly config, but... I'd still recommend keeping it in the config package for now.

Motivations being:

  1. We have no other use-cases on the radar in the near future.
  2. By using mapstructure, its usage is basically tied to Viper structs anyway.
  3. If we really generalized it enough to be reusable, it should probably be its own repo/project. However, it's tough to see what's "too specialized" in it until you have more use-csaes.

So... IMO, better to keep it in config until we have some more use-cases.

var mapregex *regexp.Regexp
var blacklistregexp []*regexp.Regexp

func init() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not (ever, if we can avoid it) use init() functions... they complicate the code's lifecycle, and tbh I have no idea what value they actually add. I'm not alone here either.

In this case, you can easily define them inline:

var mapregex *regexp.Regexp = regexp.MustCompile(`mapstructure:"([^"]+)"`)
var blacklistregexp []*regexp.Regexp = []*regexp.Regexp{
  regexp.MustCompile("password"),
}

(ironically, I understand that the article also recommends "no package-level variables" too. I think he's right about that in general, except that immutable/threadsafe ones like these are ok. If all package-level vars were bad, then we'd never declare consts either... which I think is a little ridiculous)

return fmt.Sprintf("%s.%s", prefix, field)
}

func logInt(v reflect.Value, prefix string, logger func(msg string, args ...interface{})) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm very sympathetic to small functions, but... these are only called once, aren't they? Subjective, but... I think the code reads better if they're inlined.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll modify

// LogGeneral will log nearly any sort of value, but requires the name of the root object to be in the
// prefix if you want that name to be logged. Structs will append .<fieldname> recursively to the prefix
// to document deeper structure.
func LogGeneral(v reflect.Value, prefix string) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be private now

Copy link
Collaborator Author

@hhhjort hhhjort Jun 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it the other way around. :) Oh, yes, don't even need logGeneral as public.

@cirla cirla merged commit b26e810 into master Jun 14, 2018
@dbemiller dbemiller deleted the log-struct branch June 14, 2018 16:39
maddapper added a commit to freestar-archive/freestarcapital-prebid-server that referenced this pull request Jun 26, 2018
* 'master' of https://github.com/prebid/prebid-server: (93 commits)
  Separated the bidder info from the endpoint (prebid#585)
  More granular adapter error metrics (prebid#550)
  Deleted the validate endpoint, and dead code files. (prebid#541)
  Deleted the /getuids endpoint. (prebid#531)
  Moved the cookie parsing into the actual ParseCookie function. (prebid#584)
  [adform adapter] Pass gdpr & digitrust to bid request (prebid#581)
  Adding  endpoint exposing prebid-server version (prebid#577)
  Infer imp.secure state (prebid#572)
  Changing custom parameter name (prebid#576)
  Adds map support to config logging. (prebid#573)
  Moves the metrics config under pbsmetrics where it should be rather than in the general config module. (prebid#571)
  Reorganizes the metrics code to support metrics submodules the same way we do in other sections. (prebid#568)
  Consolidates 2 metrics engine functions and fixes missing metric from… (prebid#558)
  Changes configuration logging to be reflect-based. (prebid#563)
  Cookie sync URL gdpr support for Brightroll adapter (prebid#562)
  Improve config logging & validation (prebid#560)
  Use the cache type to determine if no cache was available. (prebid#557)
  Fixed the validation logic on unbounded caches, and added tests. (prebid#556)
  Include binaries in releases (prebid#554)
  Defines defaults for all config options and removes pointers from the… (prebid#539)
  ...
katsuo5 pushed a commit to flux-dev-team/prebid-server-1 that referenced this pull request Dec 1, 2020
* Changes configuration logging to be reflect-based.

* Impliments various small improvements for clarity.

* Makes LogGeneral() private
katsuo5 pushed a commit to flux-dev-team/prebid-server-1 that referenced this pull request Dec 2, 2020
* Changes configuration logging to be reflect-based.

* Impliments various small improvements for clarity.

* Makes LogGeneral() private
katsuo5 pushed a commit to flux-dev-team/prebid-server-1 that referenced this pull request Dec 4, 2020
* Changes configuration logging to be reflect-based.

* Impliments various small improvements for clarity.

* Makes LogGeneral() private
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants