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

Instrumenting gorm SQL logging with otelgorm and otelzap #66

Open
igrayson opened this issue Jul 21, 2022 · 4 comments
Open

Instrumenting gorm SQL logging with otelgorm and otelzap #66

igrayson opened this issue Jul 21, 2022 · 4 comments

Comments

@igrayson
Copy link
Contributor

igrayson commented Jul 21, 2022

Hi. First, thanks for the great work instrumenting these libs!

I came across this issue while setting up otelgorm and otelzap.

Problem: when configuring gorm with both otelgorm and an otelzap logger, the otelzap logger will not emit span events or add span attributes (like a trace_id), for SQL logging.

I.e., configure gorm with:

	db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
		Logger: gormLogger, // a thin wrapper around otelzap to fit gorm's logger interface.
	})

        db.Use(otelgorm.NewPlugin())
        
        db.WithContext(someCtx).Exec("select 1")

I think this happens because: gorm calls otelgorm before calling its configured logger (see here), so:

  1. otelgorm does its job and ends the span
  2. when called to log the statement's SQL, otelzap checks if the span is recording (it's not), skips its job and emits an uninstrumented log.

I see two ways to fix this:

  • Update gorm to be able to log before running callbacks. I can see why this would be hard.
  • Do not use gorm's Logger config to log SQL. Instead create a gorm.Plugin to log SQL, carefully configuring it to run before otelgorm.

The second one is a hack the user might build if (1) instrumented SQL logging is very important and (2) we can't change gorm.

@igrayson
Copy link
Contributor Author

igrayson commented Jul 21, 2022

Ultimately we're not blocked by this. We don't want to log fully unredacted SQL, so we won't enable gorm's Logger in production — and we don't really need tracing in pre-production.

@igrayson
Copy link
Contributor Author

igrayson commented Jul 21, 2022

Another way to mitigate this: change otelzap to always add trace_id to zap.Logger calls, if it's available — even if the span is no longer recording. This seems like a generally good thing to do.

@vmihailenco
Copy link
Member

Do not use gorm's Logger config to log SQL. Instead create a gorm.Plugin to log SQL, carefully configuring it to run before otelgorm.

Using a gorm.Plugin sounds like a proper solution here if you want queries with trace ids in your logs.

even if the span is no longer recording

I'd assume trace id to be zero if span is not recording.

@igrayson
Copy link
Contributor Author

igrayson commented Jul 22, 2022

I'd assume trace id to be zero if span is not recording.

It remains available. Before I tried otelzap, we had a small hook to add it without checking isrecording().

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

No branches or pull requests

2 participants