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

feature request: support for dict_tracebacks #35

Open
g-- opened this issue Sep 20, 2024 · 3 comments
Open

feature request: support for dict_tracebacks #35

g-- opened this issue Sep 20, 2024 · 3 comments

Comments

@g--
Copy link

g-- commented Sep 20, 2024

Hi there! I appreciate this library as it's made it easier to integrate into stackdriver/gcp logging. One small feature request: support for structlog.processors.dict_tracebacks, or similar functionality included

I found when I had both dict_tracebacks and structlog_gcp enabled like this:

    structlog.configure(processors=[
        structlog.processors.dict_tracebacks,
        *(structlog_gcp.build_processors()),
    ])

stacktraces were rendered as dictionaries and then back into strings, so they'd show up as json strings both on the console and in gcp.

@multani
Copy link
Owner

multani commented Sep 20, 2024

Hey @g-- , you shouldn't need to use structlog.processors.dict_tracebacks at all: if you log an exception, it should be correctly rendered as a GCP-compatible log error.

See for instance this test:

def test_error(stdout, logger):
try:
1 / 0
except ZeroDivisionError:
logger.exception("oh noes", foo="bar")
msg = json.loads(stdout())
expected = {
"@type": "type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent",
"context": {
"reportLocation": {
"file": "/app/test.py",
"function": "test:test123",
"line": "42",
},
},
"logging.googleapis.com/sourceLocation": {
"file": "/app/test.py",
"function": "test:test123",
"line": "42",
},
"serviceContext": {
"service": "unknown service",
"version": "unknown version",
},
"foo": "bar",
"severity": "CRITICAL",
"message": "oh noes",
"stack_trace": "oh noes\nTraceback blabla",
"time": "2023-04-01T08:00:00.000000Z",
}
assert expected == msg

@g--
Copy link
Author

g-- commented Sep 23, 2024

That's true! But the stack_trace field is a string instead of a structured list of stack elements. And at the very least, I usually need to see the actual error message embedded in the stack trace. (Actually if you could pull the error message of the initial exception out as a top level element, that would be super handy!)

@multani
Copy link
Owner

multani commented Sep 23, 2024

The stack_trace will contains the plain text value of the exception.

If tou take this example:

        try:
            1 / 0
        except ZeroDivisionError:
            logger.exception("division by zero")

It shows like this into Cloud Logging:

And would also show the full error message with the stack trace correctly logged into Error Reporting:

I can check if you don't specify a message to the logger if the exception name can be put instead, but you could also do:

try:
    ...
except Exception as exc:
    logger.exception(str(exc))

But the stack_trace field is a string instead of a structured list of stack elements

What do you mean by that exactly? Are you looking to get all the details of the exceptions into separated fields in the log record?

Do you have an example to share how it would look like?

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