Sentry-java: Custom fingerprints in raven-log4j2

[cmboult]

The docs state that it is possible to override the default grouping by using a custom fingerprint (https://docs.sentry.io/learn/rollups/#custom-grouping). Is there a way to do this using log4j2? I can't seem to find it.

I'm looking for a way to make the grouping slightly less aggressive e.g. {fingerprint: ['{{ default }}', {{client_name}}]}. Where client_name has already been added as an extra tag by adding it to the ThreadContext.

[tkaemming]

You should be able set up your integration to do this automatically with a custom EventBuilderHelper implementation that adds the fingerprint. The helper will need to be registered with a custom RavenFactory. The HttpEventBuilderHelper provides a good example of how to modify an event before it's built, and you could probably model your implementation similarly.

[cmboult]

thanks @tkaemming this worked perfectly!

[rgriffith]

@cmboult I realize it's been a while, but can you by chance share your solution? I am looking to implement something similar to resolve an issue we're running into where our delegated Log4j logger causes basically everything to be grouped together.

[cmboult]

sure no problem @rgriffith.
So you need to build a custom EventBulderHelper implementation to add the fingerprint, something like this:

public class FingerprintEventBuilderHelper implements EventBuilderHelper {

    private static final String DEFAULT_FINGERPRINT = "{{ default }}";

    @Override
    public void helpBuildingEvent(EventBuilder eventBuilder) {
        String clientName = ThreadContext.get(CLIENT_NAME);
        if (clientName != null) {
            eventBuilder.withFingerprint(DEFAULT_FINGERPRINT, clientName);
        }
    }
}

This tells Sentry to separate by Client Name, so all similar events will be grouped like that.
You'll then need to register the helper with the Raven Instance like this:

public class FingerprintRavenFactory extends DefaultRavenFactory {

    @Override
    public Raven createRavenInstance(Dsn dsn) {
        Raven raven = super.createRavenInstance(dsn);
        raven.addBuilderHelper(new FingerprintEventBuilderHelper());
        return raven;
    }
}

and then register the factory like this:

RavenFactory.registerFactory(new FingerprintRavenFactory());

Hope that helps you out

[rgriffith]

Ah, I see the withFingerprint now.

I'm working with a custom DefaultSentryClientFactory for the new library (based on their docs) and have a similar setup, but for some reason I can't seem to get any events sent to Sentry. I added a breakpoint to the factory constructor and it's definitely loading and appears to be a connection, but breakpoints within the event builder helpers are not firing.

Also, trying to figure out how best to deal with the fingerprint, by client or by our delegated logger class (which is added automatically as a tag afaik). What is a typical value returned in your ThreadContext.get(CLIENT_NAME)?

Thanks again!

[bretthoerner]

but for some reason I can't seem to get any events sent to Sentry

Weird. If you enable debug logging for io.sentry.* I'm curious what you see from those loggers when you log an error (and on startup, I guess)?

And/or if you could paste all of the "Sentry-integration" related code from your project so I could get a better idea of what's going on.

[rgriffith]

Wow, I guess I need more coffee. I totally forgot to add my appender... Thanks for the help!

Back to the fingerprint, looking for any suggestions on how to better group our delegated Log4j loggers. I see there's a transaction and a logger tag coming through, wondering if passing something into the fingerprint would work for us, or if I need to do something with a MessageInterface. For reference, here are screenshots of two "grouped" events that are completely different (scope the message itself and the logger):

[bretthoerner]

So do you always lose the real stacktrace for your exceptions? I'm unfamiliar with delegated loggers.

[rgriffith]

Well, these may or may not have stacktraces. Some are simply more "generic" messages we're logging.

[bretthoerner]

If the stacktraces match then we pretty much always group them. Messages are largely ignored because it's very common for a user to expect something like "User 1 doesn't exist." to group with "User 2 doesn't exist". The message string is very opaque to us on the server side.

If you want to log messages with the same stacktrace and differentiate them it seems like you're going to have to provide a fingerprint.

[rgriffith]

Got it, and that's sort of where I'm stuck. Trying to figure out what would be best to provide in that fingerprint.

[rgriffith]

My initial thought was maybe that logger, since it contains the class in which the message was sent from. Not too sure, though.

[bretthoerner]

You'd just want to supply a (non-huge) unique value based on your message. If each message is truly unique, you could just hash it. Or if your messages have patterns, you could hash the parameterized message (like "User {} doesn't exist") if that's available to you?

Generally speaking, Sentry is better for crash reporting when a stacktrace or information other than a simple "log line" is available.

[bretthoerner]

It'd require changing your codebase, but you could also do the following:

try {
  throw new RuntimeException("YOUR LOG MESSAGE");
} catch (Exception e) {
  Sentry.capture(e);
}

You could make this a method that takes your log line as a param, and then at least Sentry would have a stacktrace to work with. It's a hack... to be sure...

[rgriffith]

Lots to consider, thanks for the suggestions @bretthoerner. That latest suggestion is basically what Log4J is giving us now, so I think we're good there. The bigger issue are those cases where there's no stack trace.

I'm thinking of either using the server name or that logger tag (if I can obtain it) for the fingerprint. I'm assuming using server name would result in the same errors on different servers no longer grouping together. Can you confirm if that may be the case?

[bretthoerner]

That's correct, although do you never run the same application on two
servers, or change server names? Seems suboptimal to group that way.

You might look into sunclassing the SentryAppender itself. You may be able
to get the logger info there and set the fingerprint directly in the
appender?

On Fri, Aug 11, 2017 at 6:17 AM Ryan Griffith [e-mail]
wrote:

Lots to consider, thanks for the suggestions @bretthoerner
https://github.com/bretthoerner. That latest suggestion is basically
what Log4J is giving us now, so I think we're good there. The bigger issue
are those cases where there's no stack trace.

I'm thinking of either using the server name or that logger tag (if I can
obtain it) for the fingerprint. I'm assuming using server name would result
in the same errors on different servers no longer grouping together. Can
you confirm if that may be the case?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry-java/issues/277#issuecomment-321797983,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAG2EgOhkvlgHgrBfAu78BYkYXM7Ohgks5sXEZlgaJpZM4K_KVu
.

[rgriffith]

Definitely things to consider. Thanks again @bretthoerner!