Should our default log output be specific to stackdriver?

[dprotaso]

@dprotaso I still see some references to the stackdriver name like here:

pkg/logging/config.go

Line 58 in 952ee7d

loggingCfg := stackdriverConfig()

Shouldn't we remove it from the whole codebase? There are more from a quick search, detected via the IDE.

Originally posted by @skonto in #2183 (comment)

[evankanderson]

For logging, we're using https://github.com/blendle/zapdriver for configuration of zap, I think.

This has the following implications:

• There are a couple logging levels that get enriched, and renames the timestamp field from ts, also severity and message.
• Special logging for TraceContext and HTTP requests
• Additional detail beyond the Zap defaults for error reporting, which includes filePath, lineNumber, and functionName.

I don't have a strong feeling here; the extra exported fields seem handy to me, but if naming fields timestamp instead of ts causes other compatibility issues, I could be convinced to switch to a different standard. (I think the last discussion was "what standards are there for this?"; "not sure, Stackdriver is documented here"; "I can't easily find others with a web search, let's go for it")

This is still producing JSON-format logs; it's augmenting the JSON field data and possibly renaming some fields.

[evankanderson]

(Which is different than adding Stackdriver gRPCs clients to every binary)

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.