Skip to content

Support log name in StructuredLoggingHandler #842

Closed
@jstafford5380

Description

@jstafford5380

Is your feature request related to a problem? Please describe.

When configuring locally, i can set the logName by using client.setup_logging(name='my-api') and it works correctly. My logs show up as 'my-api' in the "select log name" dropdown in the log explorer. However, the moment I deploy it to GKE, it crashes stating the name argument is unexpected. Digging through the code, I noticed it is because, when deployed locally, it selects CloudLoggingHandler which accepts the name argument, but when it's deployed to GKE, it selects StructuredLoggingHandler which does not. This is frustrating for a couple reasons:

  1. It makes the code less portable because in order to avoid the error, the startup procedure needs to know where it's being deployed so it knows whether or not it should add the argument.
  2. If i don't set it, all of the logs show up in a log named 'python' which is confusing when you have multiple python components hosted in the same GCP project all logging to 'python'.
  3. I suppose I could just add a label to all logs with the application's name using logging.getLogger('my-api') but then that forces me to add extras to every log statement if I want to add labels to help further scope my logs.

Describe the solution you'd like
Support the log name in StructuredLoggingHandler. For comparison, our .NET solutions don't have this problem. It behaves the same way regardless of where it's deployed.

Describe alternatives you've considered
Point 3 of the problem statement. This is additionally problematic in a large enterprise where we're trying to build tools around log routing due to the inconsistency of how logs are partitioned. It's an inconsistent experience if nothing else.

Additional context

Metadata

Metadata

Assignees

Labels

api: loggingIssues related to the googleapis/python-logging API.priority: p2Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions