Feature Request: Include logger in issue signature

Feedback
1

Please add the logger name to the signature of an issue.
We use Apache Camel in our Java apps, and errors logged from different camel routes end up merged because they have the same stack. The logger name is the route name, so adding this to the issue definition would keep issues from different routes separate.

2

Most Sentry SDKs do this by default: there is a first-class logger attribute. I’d raise an issue with whatever client you’re using (e.g. on GitHub).

3

Hi Ben,

The issue is not with the client, as logger is correctly set (I’m using raven-java).
If two events with different loggers have the same stack trace, they are being combined as a single issue in sentry.io.

Thanks
Jon

4

Ah, I see. If you haven’t already, please see Rollups and Sampling for more on this.

@bretthoerner – is it possible to set some kind of callback in raven-java where a user could update the fingerprint property to account for logger?

5

@jonmcewen We actually just merged a temporary fix for this on Sentry (more robust one coming as we evolve grouping): https://github.com/getsentry/sentry/commit/bda469fc8de6bf24087728d5f6ca76a472698e7f

Basically, if your stacktrace is the same but the message is different, they should no longer be grouped. This should go out in the next deploy.

6

I think I’m running into this same issue still. I’m using the SentryAppender in the Java log4j 1.x package and we have some places in the code where we just log plain strings
such as logger.error('something bad happened with objectId: ' + objectId) and it aggregates completely different messages all together, even with different logger names.

I was going to look into adding some fingerprinting logic, but it seems like, by default, the messages shouldn’t be grouped together if they are from different loggers.

EDIT:

Quote from https://docs.sentry.io/learn/rollups/
“If a stacktrace or exception is involved in a report, then grouping will only consider this information.”

I wonder if that might be the issue, this is the stacktrace (only 1 line) I see from all those logger.error(String) calls grouped together:

 at org.apache.commons.logging.impl.SLF4JLog.error(SLF4JLog.java:200)

** EDIT 2**

I opened up a GitHub issue specific to the log4j integration here:
https://github.com/getsentry/sentry-java/issues/534

7

This actually has negative effects in some languages, but in general if we can do stacktrace + uninterpolated message that’s a really strong heuristic. The problem comes when you involve any interpolated message.