Sentry-java: 4.0.0 GA - Performance Monitoring

Created on 5 Jan 2021  路  12Comments  路  Source: getsentry/sentry-java

4.0.0 will GA the Java Performance API. That means both Android and Spring will have it, but spring includes also auto instrumentation.

Java main API:

  • [x] Add environment and release to all transactions #1147 (PR: https://github.com/getsentry/sentry-java/pull/1152)
  • [x] Delete the preview note (PR: https://github.com/getsentry/sentry-docs/pull/2833)
  • [x] Document connecting errors and spans (PR: https://github.com/getsentry/sentry-docs/pull/2833)
  • [x] Document changes in the transport (the new apache transport #1143) (PR: https://github.com/getsentry/sentry-docs/pull/2833)
  • [x] Document changes in the API once (#1165) and (https://github.com/getsentry/sentry-java/pull/1164) are merged, https://github.com/getsentry/sentry-docs/issues/2912
  • [x] traces-sampler-as-sampler is different for Java and Kotlin snippets https://github.com/getsentry/sentry-docs/issues/2850

Android:

  • [X] Alpha: Add docs for manual instrumentation (Make sure Kotlin samples are there) https://github.com/getsentry/sentry-docs/pull/2851
  • [X] Alpha: Verify it works properly with offline caching (always-on on Android)
  • [ ] On the samples in this repo, opt-in for performance with random sampling 1.0.

Spring:

  • [x] New Transport for Java backend: #1097 (PR: #1114, https://github.com/getsentry/sentry-java/pull/1136)
  • [x] Docs to point users to opt-in to the Apache transport (PR: https://github.com/getsentry/sentry-docs/pull/2833)
  • [ ] Add support to datasource-proxy and documentation (PR: #1095)
  • [x] Performance for Spring (non-boot) (PR https://github.com/getsentry/sentry-java/pull/1188)
  • [x] Performance docs for Spring instrumentation (currently only Spring Boot has it)

Discussions

performance

All 12 comments

Discuss new API to take callback and wrap the whole transaction (to be discussed on the 11th of Jan)

The proposal for this API:

Sentry.runTransaction("name", tx -> {
  // some code
});

Where runTransaction method would look like:

public static void runTransaction(String transactionName, Consumer<ITransaction> runnable) {
  ITransaction transaction = startTransaction(transactionName);
  try {
    runnable.accept(transaction);
    transaction.setStatus(SpanStatus.OK);
  } catch (Throwable e) {
    transaction.setThrowable(e);
    transaction.setStatus(SpanStatus.INTERNAL_ERROR);
  } finally {
    transaction.finish();
  }
}

With such simple API we don't give a an option to set different status on error, but it can be a good enough tradeoff.

Do we bind the transaction to the scope to integrations can find it? Seems like that could be done here, if we push a scope in there so it has its own isolated scope.

That would work on Java but not on Android (global hub mode).

We can add an overload that takes a configuration object later if we want to extend this API but I think by default we should push a scope and bind the transaction to it.

Which remind me that we bind it automatically and that needs to be removed, or at least configurable, and default false.

We can add an overload that takes a configuration object later if we want to extend this API but I think by default we should push a scope and bind the transaction to it.

Which remind me that we bind it automatically and that needs to be removed, or at least configurable, and default false.

Please elaborate. Currently when startTransaction is called we do stack.peek().getScope().setTransaction(transaction);, making this configurable on the startTransaction method level would make the API clumsy as we would need to add bunch of new overloaded methods.

@bruno-garcia can we close #1130 and use only this one? checkbox items will keep out of sync, I prefer a single source of truth.

Or to remove the Android items from here

Oh I just did it but realized that was for an alpha.

@marandaneto I'll just add the 2 points from that issue in here with a note (for the alpha) so we can focus on those for the next milestone (Android Performance Alpha release)

Oh I just did it but realized that was for an alpha.

@marandaneto I'll just add the 2 points from that issue in here with a note (for the alpha) so we can focus on those for the next milestone (Android Performance Alpha release)

urgh, yeah also missed the alpha subtitle, thx

@bruno-garcia what do you mean by Opt-in to the Java/Kotlin samples for performance? wouldn't it be the same as https://sentry-docs-git-feat-android-performance.sentry.dev/platforms/android/performance/ ?

@marandaneto I reworded it: Let's turn performance monitoring on on all our samples in this repo?

Clarify differences in API to align with .NET (and help build Flutter and iOS that come next): getsentry/sentry-dotnet#663 (PR: #1165)

Is there anything more we should clarify?

Clarify differences in API to align with .NET (and help build Flutter and iOS that come next): getsentry/sentry-dotnet#663 (PR: #1165)

Is there anything more we should clarify?

Checked the check box 馃コ we're close eh

We've GA'ed and everything that was required is done. Follow up tasks linked can be done on their own now.

@bruno-garcia 馃帀

Was this page helpful?
0 / 5 - 0 ratings