DEV Community: Rahul Chhabria

Performance Monitoring and more updates to Sentry for Electron

Rahul Chhabria — Fri, 25 Mar 2022 22:18:22 +0000

For those who aren’t that familiar with it, Electron is an open-source framework that allows developers to build cross-platform desktop applications in JavaScript. Some of the most popular desktop applications like VS Code, Slack, Discord, and Atom, are all built in Electron.

While Electron makes it easy to build cross-platform applications, maintaining them is a whole other thing. You need to be aware of OS-specific challenges, the machines your applications are running on, and their configurations. Version 3.0 of our Electron SDK helps you get a handle on all these unknowns with more context on every error, insight into when a release starts to degrade, and enable distributed tracing to easily see where the most time in a transaction is spent.

Get started

Install

# Using yarn
yarn add @sentry/electron

# Using npm
npm install @sentry/electron

Configure

import * as Sentry from "@sentry/electron";
Sentry.init({ dsn: "https://examplePublicKey@o0.ingest.sentry.io/0" });

You need to call init in the main process and every renderer process you spawn.

With V3.0 of Sentry for Electron, you can automatically monitor application performance without any additional configuration. As well as, track crash-free sessions by release, and unlock more information for every issue like CPU details, display data, memory status, language details, and more. Check out the release notes here.

Electron Performance Monitoring

Errors are only half the story. Electron developers also need to know if their app responds quickly to user input on any machine or operating system. This type of visibility helps you see if objects load quickly when called—and, if not, then provide you with tools to solve what’s urgent, faster.

Sentry’s performance monitoring for Electron surfaces conditions that cause bottlenecks or latency issues for Electron renderer processes, along with a breakdown of operations within each transaction. So you can easily see which span is taking the longest and save yourself the frustration of clicking into every trace and span by getting operation details and insights on a silver platter.

Electron Release Health

Version 3.0 automatically captures session data to help you better understand how each app release is performing. Sentry calculates crash-free sessions, crash-free users, and version adoption by release. If a release inexplicably tanks your crash-free users, you can see the moment a release starts to degrade and get a list of new issues and failed transactions. Plus, we also provide a list of commit authors so you can skip git blame and just Slack your teammates who are best suited to fix the problem (that they created).

But hey, don’t know why there was a dramatic dip in crash-free sessions? This is fine. Click “Open in Discover” from any release details page; then, Sentry will automatically build and run a query for events by release to help you get to the root of any problem.

Explore whether multiple conditions contribute to an issue: does this only happen on a specific machine or operating system? Or does it affect all Linux machines? Or all Windows 11 users? Answer it quickly in Discover.

Discover also includes pre-built searches that help answer common questions about all your events, unique errors, and clients. And if you don’t like these thoughtful, hand-crafted, pre-built searches, you can modify them and save them to a custom dashboard.

Electron Error Monitoring

Understanding issues across various devices with access to different metadata, latencies, network issues, and upgrade cadences is hard and getting exponentially harder. Sentry for Electron 3.0 helps developers see what actually matters, solve issues faster with richer context, and learn continuously about their applications.

Not only will you see the user impact of each issue, but you’ll also get all the information you need to know about the machines the error happened on, like:

CPU (processor count, machine architecture)
Screen (density, resolution, height/width)
Memory
Language Details (locale details)

To wrap it up

Developers need visibility into when a user writes to disk, fetches media, loads an object in a given viewport—or, simply when a user tries to launch the app. Without this data, untreated performance problems and serious errors inevitably result in a poor user experience.

Update your Electron SDK to immediately know everything about the hardware, OS, screen orientation, network conditions, and device language settings for every issue caught and reported by Sentry. Solve issues with context and confidence and save time by not looking for obscure machines to recreate the problem. With the latest Electron SDK and Sentry, you can easily uncover the who, what, when, where, and why behind every issue.

Get started with Sentry for Electron and drop us a line on GitHub, Twitter, or our Discord. And if you’re new to Sentry, you can try it for free today or write to sales@sentry.io to get started.

Deprecation From U2F API to WebAuthn

Rahul Chhabria — Wed, 19 Jan 2022 01:48:03 +0000

By: Richard Ma

If you’re using the U2F API for registration and authentication of your U2F devices, you will notice a dire situation is coming soon: Google Chrome will no longer support U2F API after February 2022:

For anyone using U2F API in their web apps, like us at Sentry, their users who had 2FA enabled with U2F devices would not be able to sign in. To remedy this, there’s a shiny new specification written by the World Wide Web Consortium (W3C) and the Fast IDentity Online Alliance (FIDO) that will solve all our problems.

In this blog post, we will go into the weeds on migrating from U2F API to WebAuthn.

WebAuthn

WebAuthn is an API that allows web services to seamlessly integrate strong authentication into applications. With WebAuthn, web services can offer the user a choice of authenticators, such as security keys (Yubikeys, Titan Keys, for example) or built-in platform authenticators (biometric readers). In addition, it is supported by all the leading browsers — including Safari, which U2F API was not — and web platforms, which standardizes the integration of strong authentication. You can read more on WebAuthn’s website.

Migrating to WebAuthn From U2F API

Now, here’s the part you’re all here for, the migration to WebAuthn. Let’s break this down into two main parts:

Part 1: Authenticating existing U2F and new WebAuthn devices with WebAuthn

Step 1: Generating the challenge and state
Step 2: Creating PublicKeyCredential data
Step 3: Verifying the device

Part 2: Registering new devices with WebAuthn

Step 1: Generating the PublicKeyCredentialRpEntity and state
Step 2: Creating PublicKeyCredential data
Step 3: Registering the device

Part 1: Authentication

Let’s start with authentication so existing users can continue to log in. This is also important because newly registered WebAuthn devices can’t log in without a working WebAuthn login.

To understand the authentication flow, we can look at the following diagrams:

[Source left][12] [Source right][13]

We’ll be using Python for the backend APIs. The U2F API sequence (left) is very similar to the WebAuthn sequence (on the right). We simply have to replace three API calls: u2f.start_authentication() and u2f.finish_authentication() in the backend, and u2f.sign() in the frontend.

Let’s start with u2f.start_authentication(), which takes in the browser’s application ID and the currently registered devices.

The U2F API authentication process starts with the backend generating a challenge, an example of which is shown below:

{
  "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
  "challenge": "VwmGI-4…",
  "registeredKeys": [
      {
          "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
          "keyHandle": "cxSl4oQ…",
          "publicKey": "BP4Q8MR…",
          "transports": [
                "usb"
          ],
          "version": "U2F_V2"
      }
  ]
}

This challenge is sent to the browser where u2f.sign() takes the challenge as an input and returns a promise that is the result of:

verifying the application identity of the caller
creating a client data object and using the client data
the application ID
the key handle

This creates a raw authentication request message and sends it to the U2F device. The result of the promise should look like this:

{
    "keyHandle": "cxSl4oQ…",
    "clientData": "eyJ0eXA…",
    "signatureData": "AQAAAQ4…"
}

Once the result of the promise is sent to the server, we call U2f.complete_authentication() with the following two parameters: the original challenge data and the newly generated client data object passed in. This method will verify the device with the parameters and return the device info if it succeeded. From there, the server can allow the user to pass through the 2FA process.

Step 1: Generating the challenge and state

To start the migration process, let’s first replace u2f.start_authentication() with its counterpart. The data types that the WebAuthn API takes are not quite the same ones used in U2F API. In fact, one of the main pain points was converting the necessary fields into the correct data type.

We want to authenticate users on legacy U2F API and WebAuthn, so we will create an authentication server first. The following will create an authentication server using WebAuthn that is backwards compatible with U2F API:

webauthn_authentication_server = U2FFido2Server(
    app_id=u2f_app_id, 
    rp={
        "id": “sentry-webauthn.io”, 
        "name": "Sentry with WebAuthn"}
)

Your app_id will be the same value as before. The rp, or Relying Party, is an object that contains an ID, which is the hostname of the URL, and the name of your Relying Party.

Next, we need to generate a list of credentials, which is the same as the list of devices for U2F API. Keep in mind that the list of credentials will contain both WebAuthn and U2F API registered devices and that list needs to be manipulated.

credentials = []

for device in self.get_u2f_devices():
    if type(device) == AuthenticatorData:
        credentials.append(device.credential_data)
    else:
        credentials.append(create_credential_object(device))

The devices that are registered with WebAuthn have the type AuthenticatorData. For devices registered with U2F API, we need to create an AttestedCredentialData object for them to be compatible with WebAuthn. The following is the function we wrote that decodes the necessary parameters and creates the credential data:

def create_credential_object(registeredKey):
    return base.AttestedCredentialData.from_ctap1(
        websafe_decode(registeredKey["keyHandle"]),
        websafe_decode(registeredKey["publicKey"]),
    )

[Source of function][16]

With that, we can begin the registration process by calling register_begin() on the WebAuthn server that we created earlier, with credentials as its parameter. This will return a challenge and state.

The challenge is needed for the browser to perform authentication, but we will only use the PublicKey object within the challenge. In addition, you should store the state in your sessions, as it will be needed later.

challenge, state = self.webauthn_authentication_server.authenticate_begin(
    credentials=credentials
)
request.session["webauthn_authentication_state"] = state
return ActivationChallengeResult(
    challenge=cbor.encode(challenge["publicKey"])
)

We also encoded the challenge using the [FIDO2 CBOR][18] library, as we will be sending it to the frontend using JSON, which does not handle binary representation well on its own. On the frontend, we convert the JSON string back into a byte array and decode it to return the challenge to its original form.

Step 2: Creating PublicKeyCredential for authentication

To replace u2f.sign(), we can call its WebAuthn equivalent navigator.credentials.get() with the challenge data. This library is now native to modern browsers, so don’t worry about importing any libraries.

const challengeArray = base64urlToBuffer(
    challengeData.webAuthnAuthenticationData
);
const challenge = cbor.decodeFirst(challengeArray);

challenge.then(data => {
    webAuthnSignIn(data);
}).catch(err => {
    const failure = 'DEVICE_ERROR';
    Sentry.captureException(err);
    this.setState({
        deviceFailure: failure,
        hasBeenTapped: false,
    });
});

function webAuthnSignIn(publicKeyCredentialRequestOptions) {
    return navigator.credentials.get({
        publicKey: publicKeyCredentialRequestOptions,
    }).then(data => {
        // Send to backend
    })
}

When the promise is resolved after calling navigator.credentials.get(), we need to send the appropriate data to the backend to finish authentication. To convert the PublicKeyCredential that was obtained from navigator.credentials.get(), we can run it through the following function:

getU2FResponse(data) {
    if (data.response) {
        const authenticatorData = {
          keyHandle: data.id,
          clientData: bufferToBase64url(data.response.clientDataJSON),
          signatureData: bufferToBase64url(data.response.signature),
          authenticatorData: bufferToBase64url(data.response.authenticatorData),
        };
        return JSON.stringify(authenticatorData);
    }

    return JSON.stringify(data);
}

Step 3: Verifying the device

For the final step, we can pass the original challenge and this new response to the backend. We need to create a list of credentials to validate the device, then call authenticate_complete on the authentication server that was made earlier with the following parameters:

state: the value which we stored in session from start_authentication
credentials: list which we just generated
A websafe_decode for the following:
- credential_id: a “keyHandle” of the response object
- client_data: a “clientData” of the response object passed through fido2.client.ClientData
- auth_data: an “authenticatorData” of the response object passed through fido2.ctap2.authenticatorData
- signature: a “signatureData” of the response object

self.webauthn_authentication_server.authenticate_complete(
    state=request.session["webauthn_authentication_state"],
    credentials=credentials,
    credential_id=websafe_decode(response["keyHandle"]),
    client_data=ClientData(websafe_decode(response["clientData"])),
    auth_data=AuthenticatorData(websafe_decode(response["authenticatorData"])),
    signature=websafe_decode(response["signatureData"]),
)

If this function returns true, you are now fully authenticated and good to go!

For our deployment, this feature was behind a flag to manage the rollout and for error monitoring. (We recommend using Sentry 😉.) We deployed this feature independently from registration because the area of effect is limited in the event of an incident.

Congrats! The authentication part of the migration is finished.

Part 2: Registration

Similar to authentication, first, let’s take a look at the flow:

[Source left][12] [Source right][20]

The flow of registration is almost identical to that of the authentication process. The three components we need to deprecate in order to migrate to WebAuthn are u2f.begin_registration() and u2f.complete_registration() in the backend, and u2f.register() in the frontend.

Once again, we will start with u2f.begin_registration(). This API call takes in the u2f application ID and list of registered devices. This results in the following data being sent to the browser to begin the registration process:

{
    "appId": "https://your-webauthn-app/2fa/u2fappid.jso",
    "registerRequests": [
        {
            "challenge": "uexgFSl…",
            "version": "U2F_V2"
        }
    ],
    "registeredKeys": []
}

Similar to u2f.sign(), u2f.register() will take the previously generated results and return a promise that will look like the following if the device is registrable:

{
    "registrationData": "BQQ1xlC…",
    "version": "U2F_V2",
    "challenge": "Jkh_Tfo…",
    "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
    "clientData": "eyJ0eXA…"
}

Along with the previously generated challenge, this result is sent to the backend where u2f.complete_registration() takes in both parameters and generates the following data object:

{
    "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
    "keyHandle": "SnllNGC…",
    "publicKey": "BIs-gsW…",
    "transports": [
        "usb"
    ],
    "version": "U2F_V2"
}

You can save this dictionary and name of the device. They will be used for authentication.

Just like before, let’s replace u2f.begin_registration() with its counterpart. We need to create a FIDO2Server and import it from fido2.server. We don’t need to make it backward compatible, as all new devices will be registered with WebAuthn.

Step 1: Generating the PublicKeyCredentialRpEntity and state

We start with importing the fido2.webauthn library to create a PublicKeyCredentialRpEntity. To create the entity, we need to pass in the Relying Party’s ID and name. With the entity, we pass it into Fido2Server to set things up.

from fido2.server import Fido2Server
from fido2.webauthn import PublicKeyCredentialRpEntity

rp = PublicKeyCredentialRpEntity(rp_id, "Sentry")
webauthn_registration_server = Fido2Server(rp)

When the server is created, we can optionally pass in a list of registered devices to avoid duplicate registrations.

Next, we call register_begin() with:

user: dictionary with the user’s id, name, and display name
credentials: the list we just generated
user_verification: normally defaulted to discouraged

You should get a result similar to this:

  "publicKey": {
    "authenticatorSelection": {
      "userVerification": <UserVerificationRequirement.DISCOURAGED: "discouraged">},
      "challenge": b"\xe9)#\x86\xfa.\xa9\x82r\x86\xf7\x15e\xb5m\xdc"
                   b"\x1dR\xc4\x1b\xdb\xab\x94\x88\xb8\x94\xf43"
                   b"b\x03\xab\n",
      "excludeCredentials": [],
      "pubKeyCredParams": [
        {"alg": -7,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -8,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -37,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -257,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">}],
      "rp": {"id": "<$YOUR_APP>",
      "name": "Sentry"},
      "user": {"displayName": "<$YOUR_NAME>",
      "id": b"\x00",
      "name": "<$YOUR_APP>"
    }
  }
}

The registration data as seen above will be returned. Encode the registration data with the cbor.encode() method and base64 encode that to a string.

publicKeyCredentialCreate = cbor.encode(registration_data)
return b64encode(publicKeyCredentialCreate)

Set the state for later use in the session.
Interestingly, the data from WebAuthn is exactly the same from U2F API, despite looking different on first glance. WebAuthn sets the challenge in a byte array and the clientData in a COSE key object (which is a CBOR map), while U2F API uses an encoded string.

Step 2: Creating PublicKeyCredential for registration

Once the registration data is received by the browser, we convert the string into a buffer and decode it with this library. This gives us the data that will be used as the input parameter of navigator.credentials.create():

challenge, state = self.webauthn_authentication_server.authenticate_begin(
    credentials=credentials
)
request.session["webauthn_authentication_state"] = state

return ActivationChallengeResult(challenge=cbor.encode(challenge["publicKey"]))

webAuthnRegister(publicKey) {
    const promise = navigator.credentials.create({publicKey});
    this.submitU2fResponse(promise);
}

Step 3: Registering the device

We have reached the final step where we need to extract some data from the response from navigator.credentials.create(). The following are needed for register_complete():

state: from user sessions, set earlier after begin_registration()
client_data: from decoding the data’s cliendDataJSON and creating a ClientData Object with it
AttestationObject: from decoding the data’s attestationObject and creating an AttestationObject Object with it

data = json.loads(response_data)
client_data = ClientData(
    websafe_decode(data["response"]["clientDataJSON"])
)
att_obj = base.AttestationObject(
    websafe_decode(data["response"]["attestationObject"])
)

binding = webauthn_registration_server.register_complete(
    state, client_data, att_obj
)

ClientData should look like this:

{
    "type": "webauthn.create",
    "challenge": "_Uas89Y…",
    "origin": "https://<$YOUR_APP>",
    "crossOrigin": false
}

AttestationObject should look like this:

AttestationObject(
    fmt: 'none', 
    auth_data: AuthenticatorData(
        rp_id_hash: h'74cb1ce…5',
        flags: 0x41, 
        counter: 281, 
        credential_data: AttestedCredentialData(
            aaguid: h'0000000…', 
            credential_id: h'63af2c9…', 
            public_key: {...}
        ), 
        att_statement: {}, 
        ep_attr: None, 
        large_blob_key: None
    )
)

Registered device data:

AuthenticatorData(
    rp_id_hash: h'74cb1ce…',
    flags: 0x41, 
    counter: 281, 
    credential_data: AttestedCredentialData(
        aaguid: h'0000000…', 
        credential_id: h'63af2c9…', 
        public_key: {...}
    )
)

With that, you can save the registered device data. The registration process is complete.
Just like authentication, the deployment of this feature was behind a feature flag to manage the rollout. There were no database migrations needed as WebAuthn is backward compatible with U2F API.

That’s a wrap

With that, WebAuthn should be set up and you can purge U2F API from your codebase. If you have made it this far, we hope that this guide was useful to you. With some planning, you will make it in time before Chrome locks out users from your application. All the best!

—

Everything we do at Sentry is built in the open. Find us on GitHub.

Bytecode Transformations: The Android Gradle Plugin

Rahul Chhabria — Tue, 14 Dec 2021 23:05:18 +0000

By: Roman Zavarnitsyn

This is the first part of a blog post series about bytecode transformations on Android. In this part we’ll cover different approaches to bytecode manipulation in Java as well as how to make it work with Android and the Android Gradle plugin. In the next two parts we’ll dive into the actual bytecode, bytecode instructions and how we can modify the bytecode and inject our own instructions, using Room as an example. In the last part we’ll see how we can test our transformations and how it can influence Gradle build speed.

Detecting the slow spots in your app without having to write a single line of code is an intriguing idea, but is also not that easy to implement. At Sentry we wanted to provide the capability for Android users to automatically measure the execution time of database queries because oftentimes they can become a hidden bottleneck for app performance. Room is a widely-adopted ORM solution built by Google and is a go-to library for persistence for the majority of the Android developers, so it was an obvious choice for us to start with.

If we want database operations to show up in Sentry, we need to wrap them into special objects called Spans. In short, Spans are application events that have a start and end time and some metadata like operation name, description, etc. For example, this is how the performance breakdown looks for a popular open-source app tivi:

On the screenshot above, there’s a parent span ui.screen.interaction that contains multiple child spans, for instance, the network request span with a http.client operation, duration 225ms and a request url as a description. If you want to learn more about performance @ Sentry, check this post out.

Back to the topic, this all means we need to find a way to inject our code before and after Room executes its queries to measure their execution time. There’s a QueryCallback available in the Room API, but it’s invoked only before a query gets executed, so we couldn’t really utilize it.

Options

Since there’s no way to know when a SQL query starts and finishes at runtime, we started looking into compile-time solutions. There are a few well-known options in the JVM world available for bytecode weaving:

AspectJ: an AOP framework, which allows extending methods and plugging into their execution from outside of the target codebase.
ASM: a bytecode manipulation framework, which allows dealing with bytecode directly. For example, it’s used by R8 and D8 on Android for optimizing and dexing the bytecode.
Other higher-level abstractions like Javassist: are all based on ASM, but have a nicer and easier-to-understand APIs to deal with.

While it would be logical to pick something higher-level, considering we had no expertise in any of those, we’ve decided to look into how we could marry those with the Android Gradle plugin (AGP), as we are aiming to transform Android apps and need to support things like differe build types, flavours and so on. A quick search revealed that we could go with:

Gradle’s TransformAction: a plain Gradle API for transforming outputs. This is used, for example, for dexing, jetifying, and many other things that the Android Gradle plugin does.
AGP’s Transform: an old API from AGP that gives a list of inputs to be transformed, depending on the options provided. It also handles full/incremental builds automatically. Now deprecated in favor of the new API.
AGP’s transformClassesWith: the new API from AGP that allows registering an ASM ClassVisitor for visiting bytecode instructions and instrumenting .class files. It utilizes the aforementioned TransformAction to transform dependencies and provides a Gradle task that handles full/incremental builds automatically. Available from AGP version 4.2.0 and above.

The first option would require us to manually hook into the AGP process and deal with its artifacts, so we decided to look into options 2 and 3 and compare them, as they come directly from the vendor.

Previously, in the old AGP versions (pre-4.2.0), if one would like to instrument compiled classes, they would need to register their own Transform, traverse the input files and perform instrumentation for each of those files using ClassWriter from ASM. For each such Transform AGP would register a new Gradle task, so if you happen to have 10 transforms instrumenting your application, you would end up with 10 additional Gradle tasks doing almost the same thing - iterating over the changed files, reading the bytecode, applying their own transformations and writing the bytecode back.

This is horrible for the build speed and most of that can be commonized up until the point of actually instrumenting the bytecode.

The new transformClassesWith API tackles exactly that by providing a single API for registering ClassVisitors and abstracting away file iteration and reading/writing the bytecode. It collects all visitors in a single list and then, for each file, runs all of them in order of registering, meaning there’s just a single Gradle task running for all transformations.

We’ve decided to go with ASM + transformClassesWith pack, deliberately supporting only the new versions of AGP.

Note, that if you want to support bytecode transformations in lower AGP versions (below 4.2.0) you still need to use the old Transform API. However, you can perform an AGP version check at runtime and choose either a new or an old API depending on it. An example can be seen in the Hilt Gradle plugin.

Using new transform APIs

Registering AsmClassVisitorFactory

As this post is not about how to create Gradle plugins, I will skip the setup part, but in a nutshell, we have to implement the Plugin interface from Gradle and override a single method called apply, which is called when the Gradle plugin is applied to a project:

class SentryPlugin : Plugin<Project> {

    override fun apply(project: Project) {
        ...
    }
}

After that we have to listen when the Android Gradle plugin is applied to the project and retrieve the new AndroidComponentsExtension like this:

project.pluginManager.withPlugin("com.android.application") {
    val androidComponentsExtension =
    project.extensions.getByType(AndroidComponentsExtension::class.java)
    ...
}

The extension has a special onVariants method that configures the build variants:

androidComponentsExtension.onVariants { variant ->
    ...
}

Finally we can register our custom AsmClassVisitorFactory for the variant through transformClassesWith:

variant.transformClassesWith(
  SpanAddingClassVisitorFactory::class.java,
  InstrumentationScope.ALL
) { params ->
  if (extension.tracingInstrumentation.forceInstrumentDependencies.get()) {
    params.invalidate.setDisallowChanges(System.currentTimeMillis())
  }
  params.debug.setDisallowChanges(
    extension.tracingInstrumentation.debug.get()
  )
  params.tmpDir.set(tmpDir)
}

transformClassesWith accepts 3 parameters:

ClassVisitorFactory: a factory, which provides a ClassVisitor implementation and defines whether this visitor is interested in instrumenting a given class
InstrumentationScope: either ALL or PROJECT. Defines whether the instrumentation applies only for project files or for project files and their dependencies (e.g. jars). In our case, we were interested in instrumenting all Room queries, regardless of their origin, so we set it to ALL

If you’re using InsrumentationScope.ALL, beware that Gradle will cache the transformed artifacts across builds as long as the InstrumentationParameters do not change. This may come as a surprise while developing, as some of the classes coming from the dependencies might not show up for instrumentation. We found it useful to have a boolean parameter, which would invalidate the transform caches by simply setting System.currentTimeMillis and allow us to always receive all classes for instrumentation.

Configuration function to be applied before passing the necessary parameters for the ClassVisitorFactory

The InstrumentationParameters are the way to pass information from the plugin to the ClassVisitorFactory. They are being used as Gradle inputs, this means they contribute to the up-to-date checks of the task and should be properly annotated. For example, here we are setting a debug boolean as well as a tmpDir to use this information later and stream debug output of instrumentation into a file under the tmpDir.

Implementing AsmClassVisitorFactory

For the ClassVisitorFactory it’s necessary to implement 2 methods:

createClassVisitor which provides a custom ClassVisitor from ASM that does the actual visiting of bytecode instructions and transformation
isInstrumentable which defines whether a given class is applicable for instrumentation or not

It is also necessary to specify an implementation of InstrumentationParameters as a type for AsmVisitorFactory or use InstrumentationParameters.None in case there are no params.

abstract class SpanAddingClassVisitorFactory :
    AsmClassVisitorFactory<SpanAddingClassVisitorFactory.SpanAddingParameters> {

    interface SpanAddingParameters : InstrumentationParameters {

        @get:Input
        @get:Optional
        val invalidate: Property<Long>

        @get:Input
        val debug: Property<Boolean>

        @get:Internal
        val tmpDir: Property<File>
    }

    override fun createClassVisitor(
        classContext: ClassContext,
        nextClassVisitor: ClassVisitor
    ): ClassVisitor =
        TODO("If we return true from the isInstrumentable below, we should return a ClassVisitor that will inject our code for measuring the execution time")

    override fun isInstrumentable(classData: ClassData): Boolean =
        TODO("Determine if we are interested in instrumenting the given ClassData. For us it would mean a class annotated with @Dao")
}

Inside the isInstrumentable method, we determine whether we are interested in instrumenting the given ClassData and later return our custom ClassVisitor from the createClassVisitor method in case we are. Note, however, that it’s always a good practice to fall back to nextClassVisitor in case there’s no ClassVisitor for the given class, otherwise the Gradle build will fail.

Last, let’s look at the ClassData structure:

interface ClassData {
    /**
     * Fully qualified name of the class.
     */
    val className: String

    /**
     * List of the annotations the class has.
     */
    val classAnnotations: List<String>

    /**
     * List of all the interfaces that this class or a superclass of this class implements.
     */
    val interfaces: List<String>

    /**
     * List of all the super classes that this class or a super class of this class extends.
     */
    val superClasses: List<String>
}

It may seem to have everything to help us determine whether a class is suitable for instrumentation or not, but there’s a setback which we’ll cover in the next post.

Using the new AGP transform APIs with ASM looks like an obvious choice for bytecode manipulation for Android as it affects the build speed almost unnoticeable (we’ll cover that later), handles full/incremental builds on its own, and offers a great API surface via ASM at the same time.

In the next part, we’ll talk about Room internals, how we collected the methods for instrumentation, and what tools are available out there for dealing with ASM.

The code is available in the sentry-android-grade-plugin repo, specifically:

By the way, if you are already using the Sentry Android Gradle plugin, give this new Room instrumentation a try in version 3.0.0-beta.1 , we would appreciate your feedback via GitHub issues. If not, it’s time to start using Sentry — request a demo and try it out for free.

Development Environment Observability with Sentry

Rahul Chhabria — Fri, 19 Nov 2021 04:23:46 +0000

By: Armen Zambrano G.

At Sentry, we’re always looking for innovative ways to dogfood our product. Over the last year we added Sentry’s error monitoring to our developer environment so that we could better understand the health of it.

In this blog post I’m going to touch on how fragile local development environments can be, how we brought observability into what’s happening by introducing Sentry, and what outcomes it has driven for our engineering organization.

Development environments are fragile

As programmers, we typically spend a lot of time getting our local development environment set up: installing dependencies, managing multiple versions of an SDK or supporting tools, and so on.

Getting set up can take some time, however it’s usually straightforward because you’re starting from a clean slate. What becomes more challenging is when a previously good environment gets into a bad state. For example, you need a newer Python version for your virtualenv, a new library is missing, or your pre-commit hooks are out of date.

When things go wrong, it’s frustrating because your real work – building software – stops and you instead have to invest your time trying to unstick your environment. When the answer isn’t obvious, you have to go into Slack, ask for help, and hope that someone is around who can help you troubleshoot. And now you’ve interrupted their regular work too.

Getting alerted to problems during development

Typically, Sentry is used for monitoring software in production. When your software goes live in front of users, you want visibility to understand whether that software is operating successfully. Are there any errors? Is the performance acceptable?

However, for our Developer Productivity team, the local development environment used by our engineers is our production environment. Software engineers at Sentry are our users, and we similarly want to understand if the development tools we’re shipping are working successfully. For instance, are Python packages failing to install for some users?

What if we could be alerted when a developer’s environment goes bad? To figure this out, we instrumented Sentry into our local development toolchain.

When we don’t properly triage development environment issues, developers can suffer the pain for some time until they report it.

Instrumenting Bash scripts with Sentry

Our development environment is generally powered by a lot of Bash scripts (If you have other environments go to the platforms page and see if yours is supported). Those scripts do everything from installing Python versions, setting up Git commit hooks, prompting developers to update their dependencies, and so on.

To have visibility into what was happening in our Bash scripts, we turned to sentry-cli. Sentry-cli is a command line executable written in Rust that communicates with the Sentry API. Typically it’s used for administrative tasks like sending a test event from the shell, uploading source maps, or letting Sentry know about a new version of your software.

Sentry-cli also has an interesting feature: it provides a bash hook that detects unhandled failures in a bash script and automatically reports those failures to Sentry. In the example below, sentry-cli is initialized in a Bash script (see docs):

If the Bash script fails, an error event is sent to Sentry with a traceback, the values of any active environment variables, and the console output is captured as breadcrumbs.

Bash traceback showing the lines and scripts that were involved when the error occurred.

Sentry’s breadcrumb trail shows the emitted debug output that occurred before the failed Bash command

Monitoring our development environment users

Let’s fast forward: at this point we instrumented most of our development environment scripts with Sentry. Let’s look at what the flow for helping a co-worker bootstrapping their development environment is like.

As mentioned earlier, if a script failure is encountered, sentry-cli sends an error event to Sentry’s servers. This has the effect of creating an alert within Sentry, which gets broadcasted to our team channel on Slack.

From there, we click through the Slack link which takes us to the event inside Sentry. Then we can determine which engineer is facing the issue (this is taken from the $USER environment variable) as well as what the issue is from the console output.

Since we know who’s facing the issue and what kind of problem they’re facing, we can get in touch with the developer armed with some context and a readiness to help!

We can easily find the root cause of an issue that may be difficult to reproduce because we reached out to the engineer near the moment of occurrence and are invested in getting it fixed.

Here’s an example of an issue we had not been able to pinpoint for several months. Working with the engineer while they were investigating it lead to a fix.

The impact

Instrumenting our development environment with Sentry has allowed us to monitor the health of our development environment and respond more quickly when someone faces an issue. Over the last year, we’ve seen the following positive outcomes for the engineering organization:

We can help an engineer that is currently investigating an ongoing issue. This increases the chances of fixing the root cause of the issue and preventing others from facing the same problem rather than the issue being worked around (Not all engineers are comfortable solving their own dev env problems).
We can be notified of tooling regressions. It’s easier to fix a regression when you’re notified soon after having merged your code. Without alerting, a regression might take a while to be reported. For instance, a developer may work around the issue on multiple occasions a few weeks after the code at fault has landed.

This shows the development environment issues in the last three months and shows when regressions were introduced

Wrapping up

We have covered how instrumenting a development environment with Sentry can positively impact the productivity of your engineering organization by increasing the observability and decreasing the response time to issues.

Thanks for reading this post. If you want to try out Sentry without creating an account, visit the Sentry Sandbox and feel free to play with it!

Thanks to Billy Vong for paving the way with the bootstrapping code, Ben Vinegar for encouraging me to write this post, and for Zac Propersi’s managerial support.

Keep Gamers Gaming — Application Monitoring for Unity

Rahul Chhabria — Thu, 28 Oct 2021 16:48:42 +0000

By: Rahul Chhabria

Given the millions of registered Unity developers worldwide, Unity is arguably the most popular engine used to develop games. But, whether you’re building the latest FPS or a turn-based classic, you need visibility in how your game is performing on a gamer’s device.

More than 800 game development and platform companies rely on Sentry, from OutFit7 to Riot, Epic Games, and Unity. With Sentry, Unity and the rest of these organizations see the events (both errors and performance issues now) that actually matter, solve code issues quickly, and learn how each release performs over time.

To help Unity developers monitor their code across platforms and devices, we updated Sentry for Unity. Now you don’t have to figure out what device, the OS, seeing slow transactions, or deal with app version fragmentation when something goes wrong. This means that while your players are trying to catch them all, Sentry is catching all your errors and performance issues, and telling you how to fix them before they affect the player experience.

Performance Monitoring

Now, errors are only half the story. Unity developers also need to see if they’re providing a snappy and responsive gaming experience. That visibility means being able to know that your game is loading objects in a given viewport quickly and responding to user input as intended without any delay. Without this data, untreated performance problems can become serious errors. Performance, our aptly named performance monitoring solution, quickly highlights what occurred for a specific error or issue, the conditions that caused the bottleneck or latency issue, and the endpoints or operations that consume the most time.

If you’re feeling adventurous—and based on how many of you adopted early-access Sentry for Unity (> 500 teams, but who’s counting?), many of you are—you can now try Performance Monitoring for Unity in Early Access. Check out the docs or the performance tab in product to configure tracing.

Native Crash Reporting

For you iOS and Android game developers, there are some monitoring services that can report back when your game crashes—but events are usually just listed as an “abnormal session.” With this vague information, you’ll probably end up playing an extra fun round of 21 questions with your code and/or customer support. Alternatively, if you prefer to skip that guesswork, Sentry can tell you if a crash happens in the game or the native layer, like a plugin or native library you could be using.

Along with native iOS and Android crash reporting, you’ll have access to session data in real-time and know how a release impacts your users with metrics like crash-free sessions, crash-free users, and the overall health of a release. New Release management features like sorting & filtering releases and Adoption Stages give game developers all of the data to decide if the team is ready to push a new release. Did that bug-fix release work? Or are the new characters you added in the latest rev functioning and playable? You’ll know the answer to these questions and more, immediately.

Not everyone is playing your games at the same time, meaning traffic will likely vary and constantly fluctuate as their gameplay changes and increases. So with Sentry, developers can define percent-based alerts which adjust to changes in traffic, making sure you get notified of and effectively prioritize the most critical gamer experience issues.

Get Started

Install the Unity SDK via the Unity Package Manager using a Git URL pointing to Sentry’s SDK.

Unity developers can benefit from the rich context that Sentry provides by simply creating a Sentry project and pasting their DSN in Unity.

In the event players hit an unexpected issue—anything from your game failing to instantiate specific objects or simply corrupted savegames—Sentry will report on device type, orientation, battery level (if applicable), GPU state, CPU info, and everything about the software and OS that your game is running on. You may ask, “But what if someone is playing my game offline?” No problem—both with offline gaming and intermittent network connectivity, Sentry will phone home with these events after the connection restores.

If one of the best parts of your day is testing your game on nine different platforms to find where your gamers are having sub-optimal experiences—Sentry may, unfortunately, cut it short. But hey, if you still want to debug, that’s fine. Your secret is safe with me.

The number of devices your games run on is growing exponentially. Don’t collect a bunch of random devices and consoles just to recreate a single issue. Instead, use Sentry which automatically reports errors and performance issues as they happen, the platform on which they occur, and all the contexted needed to identify the root cause. Unless your player is complaing of a blurry screen when playing Rad Racer. We don’t have a boolean for isWearing3DGlasses.

We Gave $154,999.89 to Open Source Maintainers

Rahul Chhabria — Tue, 26 Oct 2021 21:37:31 +0000

By: Chad Whitacre

Sentry is an open source company. We started out in 2008 as a small open source side project, and we grew within the community for years before commercializing in 2012. We’ve worked hard to keep our full product as open source as possible, while scaling as a business. Considering our commitment to open source, we are grateful to be able to give back to the community (and what better time than during Hacktoberfest, amirite?).

(P.S. The good folks at Sustain brought us onto their podcast for a deep dive on this funding initiative. If you like what you’re reading here, mosey on over and check out the episode.)

Background

Sentry has a long history of sharing our business success with the open source community. We have supported the Python and Django Software Foundations since 2016 with donations totalling about $75,000. Over the years, we’ve also supported smaller projects like Vue.js, Django Rest Framework, and Psycopg. In 2019, we awarded a $10,000 grant to Techqueria, a nonprofit serving the largest community of Latinx in tech, for open source work on their website. And in 2020, the Sentry team was pleasantly surprised to receive a $10,000 grant from Indeed, which we matched and regifted to five projects in the Python and Rust ecosystems.

Outside of direct financial contributions, Sentry invests in the open source community in many ways: we donate SaaS credits to open source projects, sponsor conferences and meetups, and contribute patches to upstream projects. Additionally, Sentry has a general employee philanthropic donation-matching program in which open source foundations are eligible.

Sentry’s FOSS Fund 155

Indeed’s generous $10,000 donation to us was part of an industry initiative they launched called FOSS Fund Adopters; Microsoft and Salesforce are also on board. When we announced our matching regift, we also committed to increasing our own giving to open source, which we have now done with our own iteration that we’re calling FOSS Fund 155. We distributed $154,999.89 to 108 recipients, grouped under three line items:

Foundation memberships (52%),
Long-tail projects through GitHub Sponsors and Open Collective (36%), and
Internships for new contributors through Outreachy (13%).

Why that suspiciously specific amount? Well, napkin math suggests that tech companies receive approximately $2,000 of value from volunteer labor in the open source community, per engineer on staff. Sentry employs approximately 75 engineers, and 75 × $2,000 = $150,000, so that became our target budget. We bumped it up a bit to meet foundation membership fee thresholds. As to the 11¢ offset, we have currency conversion to thank.

One of our goals for FOSS Fund 155 is to contribute meaningfully. We believe that contributing $2,000 per engineer is a meaningful amount that fairly compensates the value we receive from open source volunteers.

Another of our goals is to lead by example within the industry. We want to raise the bar for how companies in the tech industry think about their financial relationships with the open source community. Transparency into companies’ open source contributions is valuable to the community and the industry, and to individuals making career decisions. Reporting this information per individual engineering contributor makes it easier to compare across companies.

Allocating Our Budget

All tech companies stand on the shoulders of community-supported open source giants, and Sentry is no exception. With this fund we prioritized support for our dependencies in order to strengthen our supply chain. But, more than that—Sentry itself was a volunteer-run project for many years. Yes, we took a commercial route, but we respect the many projects that have chosen a different path. Maintainers should be able to determine their own future, and financially supporting our community-managed dependencies makes that a bit more feasible for them.

By auditing our product architecture, we generated a list of seven major community-led open source projects that are foundational to our success: Python, Django, Rust, JavaScript, PostgreSQL, Apache, and Linux. These projects are all backed by formal non-profit foundations; we added an eighth foundation, the Open Source Initiative, to represent the open source community as a whole. We decided to allocate half of our budget (52%) to these eight foundations.

Another way we think about our goal to contribute meaningfully is in intentionally welcoming new contributors into the open source community. We ran a diversity-focused open source grant program in-house in 2019, and it was a great experience. However, we think we can make even more of an impact by partnering with an existing organization. Outreachy has a great track record of providing internships in open source to individuals from underrepresented backgrounds, so we allocated $19,500 (13%) to sponsor three interns to work on projects in our dependencies. Debian and LLVM were able to use the funds directly. Git asked us to redirect their portion to the Outreachy general fund.

Another of our goals for this funding program is to reinforce open source as part of Sentry’s company culture, so we involved our employees in allocating the remainder (36%) of our budget. We did some dependency analysis using the GitHub API to identify the community-led, fundable projects within the ecosystems we inhabit. We asked our employees to influence our contributions to these projects by voting on them, and also to nominate other projects that are meaningful to them. We ended up with a list of 97 projects to support, in addition to the eight foundations and the three internships.

Throughout this exercise, we filtered out open source projects that have strong corporate leadership (Sentry itself would be an example), as well as our employees’ side projects (since we already compensate them financially). This serves our goal to contribute meaningfully by directing our money where it can have the most impact. We also tried to balance breadth and depth, focusing larger amounts on some projects, while giving at least a little bit to every maintainer we identified.

In the end, we distributed $154,999.89 to 108 recipients: eight foundations, 97 individual projects, and three internship partners. Visit our GitHub Sponsors (GHS) and Open Collective (OC) profiles for the details; below is a summary (sorry it’s cut off on mobile).

Where the $154,999.89 Went

How the Money Got There

Looking Ahead

Our final goal for Sentry’s open source funding program is to sustain in a sustainable way. We feel good about what we were able to put together this year for Sentry’s FOSS Fund 155, and we will continue to iterate on our open source financial support as we continue to scale. Thank you to all of the maintainers out there—especially the volunteers. We appreciate you, and we look forward to financially supporting your work for many years.

Performance Monitoring in GraphQL

Rahul Chhabria — Tue, 31 Aug 2021 22:51:59 +0000

By: Enrique Fueyo

Enrique Fueyo Ramírez is the Co-founder and CTO of Lang.ai. Here’s how he and his team at Lang.ai instrumented performance monitoring for GraphQL resolvers.

Tech Stack

At Lang.ai we use Sentry in our systems for Error Monitoring and recently added Performance Monitoring
Lang.ai’s User Interface is a React App using a GraphQL API.
We use Apollo to connect the frontend and the GraphQL backend.

Problem

Some months ago we started experiencing some degradation in a few graphql queries. The queries were complex (big) queries and it was tricky to debug which part of the request was slowing down the response.

Goal

We wanted to monitor the performance of each Graphql Resolver.
Ideally, we wanted to monitor the performance of every resolver without explicitly adding it (we didn’t want to proactively add a start and stop lines of code all around our functions’ bodies).

Solution

Create a Sentry transaction for each graphql request.

Each Sentry transaction is initialized with its own context. Create a Transaction

import { Transaction } from "@sentry/types"

export interface Context {
  // ... other context fields for your context
  transaction: Transaction
}

export async function createContext(): Promise<Context> { {
  // ... create other context fields
  const transaction = Sentry.startTransaction({
    op: "gql",
    name: "GraphQLTransaction", // this will be the default name, unless the gql query has a name
  })
  return { transaction };
}

Add a span for each resolver

To intercept the life-cycle of each resolver and create and finish a span, we needed to create an Apollo Plugin.

import { ApolloServerPlugin } from "apollo-server-plugin-base"
import { Context } from "./context"

const plugin: ApolloServerPlugin<Context> = {
  requestDidStart({ request, context }) {
    if (!!request.operationName) { // set the transaction Name if we have named queries
      context.transaction.setName(request.operationName!)
    }
    return {
      willSendResponse({ context }) { // hook for transaction finished
        context.transaction.finish()
      },
      executionDidStart() {
        return {
          willResolveField({ context, info }) { // hook for each new resolver
            const span = context.transaction.startChild({
              op: "resolver",
              description: `${info.parentType.name}.${info.fieldName}`,
            })
            return () => { // this will execute once the resolver is finished
              span.finish()
            }
          },
        }
      },
    }
  },
}

export default plugin

And then we have to connect all the pieces on server initialization

import { ApolloServer } from "apollo-server-micro"

import { createContext } from "./context"
import SentryPlugin from "./sentry-plugin"

const apolloServer = new ApolloServer({
  // ... your ApolloServer options
  // Create context function
  context: ({ req, connection }) => createContext({ req, connection }),
  // Add our sentry plugin
  plugins: [SentryPlugin],
})

Once your server starts receiving requests it will send every transaction info to your configured Sentry account. You should see something like this:

And you can also see the detail of each individual transaction with its resolvers:

One last consideration

We could have created the transaction directly in the plugin, inside the requestDidStart function and omit any references to the Context. But, if we make the transaction accessible from the Context, each resolver can access it and we can create more spans inside the resolvers for more fine grained information.

Accessing the transaction from the resolver should also be helpful for Sentry’s Distributed Tracing.

Four Metrics Every Mobile Developer Should Care About

Rahul Chhabria — Tue, 24 Aug 2021 01:05:29 +0000

By: Philipp Hofmann

Slow apps frustrate users, which leads to bad reviews, or customers that swipe left to competition. Unfortunately, seeing and solving performance issues can be a struggle and time-consuming.

Most developers use profilers within IDEs like Android Studio or Xcode to hunt for bottlenecks and automated performance tests to catch performance regressions in their code during development. However, testing an application before it ships is not enough.

To catch the most frustrating performance issues, you need to explore what’s happening on your users’ devices. That means visibility into how fast your app starts, duration of HTTP requests, number of slow and frozen frames, how fast your views are loading, and more. With Sentry for Mobile, you can now easily monitor your iOS and Android app’s performance in real-time without additional setup (or accumulating a pile of testing devices).

Mobile Vitals

We believe there are four metrics every mobile team should track to better understand how their app is performing: Cold starts, warm starts, slow frames, and frozen frames. These four metrics, as a core part of Sentry’s performance monitoring, gives you the details you need to not only prioritize critical performance issues but trace the issue down to the root cause to solve them faster.

Measuring App Start

When a user taps on your app icon, it should start fast. On iOS, Apple recommends your app take at most 400ms to render the first frame. On Android, the Google Play console warns you when a cold start takes longer than 5 seconds or a warm start longer than 2 seconds.

Cold start: App launched for the first time after a reboot or update.
Warm start: App launched at least once and is partially in memory.

The exact definitions differ slightly per platform. For more details, please check out our iOS and Android docs.

No matter the platform, it is crucial that your app starts quickly to provide a delightful user experience. That’s why on iOS, Mac Catalyst, tvOS, and Android we track how long your app needs to draw your first frame. We grab this information and add spans for different phases of the app start. Here is an example from iOS:

On Android, it is trickier to hook into the initialization phases of the app start, and therefore we currently add one span from the application launch to the first auto-generated UI transaction. Still, this information is very useful and can help you to improve the duration of your app start.

Slow and Frozen Frames

Unresponsive UI, animation hitches, or just jank annoy users and degrade the user experience. Two measurements to track this unwanted experience are slow and frozen frames. A phone or tablet typically renders with 60 frames per second (fps).

The frame rate can also be higher, especially as 120 fps displays are becoming more popular. With 60 fps, every frame has 16.67 ms to render. If your app needs more than 16.67 ms for a frame, it is a slow frame.

Frozen frames are UI frames that take longer than 700 ms. An app that is running smoothly should not experience either. That’s why the SDK adds these two measurements to all transactions captured. The detail view of the transaction displays the slow, frozen, and total frames to the right.

Mobile Vitals are a core part of Sentry’s performance monitoring for mobile and unlocks more ways to spot bottlenecks and speed up your apps.

Mobile Performance Monitoring

The purpose of Sentry’s performance monitoring is to track your application’s performance across multiple services. To measure Mobile Vitals, the SDKs capture distributed traces consisting of transactions and spans.

Distributed tracing is a standard technology used for understanding what’s going on across distributed services, but it is still relatively new for mobile applications. A trace represents an operation you want to measure, like signing in or loading a view in your app. Both mentioned operations don’t only involve your app but also backend actions. Each trace consists of one or more transactions, which can contain one or more spans. For example, the trace of a login could then include a transaction of your app and two transactions of your backend services.

Every transaction contains several spans representing a single unit of work, like reading a file or querying the database. The spans have a parent-child relationship, meaning a span can have multiple children and grandchildren. Here’s an example trace, broken down into transactions and spans:

If you want to dig deeper into these concepts, check out Distributed Tracing 101 for Full Stack Developers by our very own, Ben Vinegar, VP of Engineering. For this blog post, let’s focus on transactions and take a look at an example creating a transaction with two child spans in Swift:

let transaction = 
    SentrySDK.startTransaction(name: "Load Messages", operation: "ui.load")

let getMessagesSpan = 
    transaction.startChild(operation: "http", description: "GET /my/api/messages")
getMessages()
getMessagesSpan.finish()

let renderMessagesSpan = 
    transaction.startChild(operation: "ui", description: "Render Messages")
renderMessages()
renderMessagesSpan.finish()

// Finishes the transaction and sends it to Sentry
transaction.finish()

After running the code we can take a look at the transaction in Sentry:

Creating rich transactions manually would require writing a lot of code. That’s why we’ve made things easier with auto instrumentation. You can save yourself the headache of writing and maintaining code while still accessing the performance insights you need.

Automatic Instrumentation

The automatic instrumentation lets you explore how long your views take to render, and HTTP requests need to finish. The SDK for Apple generates transactions for UIViewControllers on iOS, tvOS, and Mac Catalyst and creates spans for outgoing HTTP requests on all platforms. The SDK for Android captures transactions for Activities and Fragments and provides an integration for OkHttp. Sentry SDK for React Native can capture transactions automatically when using React Navigation router, and spans for both XHR and fetch requests. In the following months, we are working on adding support for Flutter.

Here is an example of an auto-generated transaction on iOS for a UIViewController. As we can see in the screenshot below, the SDK creates spans for each lifecycle method. In viewWillAppear, we fire off an HTTP request for which a span is added. Our SDKs don’t automatically add spans for querying the database (yet), but I’m interested in how long my query runs. Therefore I have to add a span manually. We can achieve this by using SentrySDK.span to access the current active span and call SentrySDK.span.startChild to create the desired child span.

With the above transaction, I learn where my bottlenecks in the UIViewController are. The viewDidLoad method looks suspicious because it takes around 70 ms to complete, and I should investigate it. After looking at the code, I realize that I’m doing remarkable I/O on the main thread, which of course, is a no-go, and need to fix it immediately. Moreover, loading some entries from the database takes way longer than the HTTP request to finish, which also looks dubious and requires further investigation. After moving the I/O in viewDidLoad to a background thread and adding an index to speed up my database query, the transaction looks way better now. Of course, the speed of the HTTP request will vary depending on the network conditions, but I cleared out the controllable bottlenecks, which speeds up my transaction from 250ms to around 20ms. This is a huge improvement.

The duration of a transaction can vary greatly because of many circumstances. Stepping through individual transactions doesn’t give you a clear picture to understand if your app gets faster or slows down. Therefore, we provide graphs to explore how the duration of a transaction changes over time.

Sentry also offers the possibility to explore slow, fastest, outlier, or recent transactions to find the misery or delight your users experience quickly.

Along with many other possibilities to explore your transactions, Sentry links the related errors captured during a transaction at the bottom of the transaction summary page.

Auto-generated transactions combined with manual transactions unlocks rich data so you can see Mobile Vitals as well as other metrics such as User Misery to give you a complete view into the performance of your application.

To learn more, check out our docs for Apple, Android, and React-Native and give automatic performance instrumentation on mobile a try. Watch out for beta releases of the Flutter GitHub repo. We have plans to add these features to Flutter soon.

Manage Releases with Sentry's Mobile App

Rahul Chhabria — Tue, 03 Aug 2021 19:00:04 +0000

By: Daniel Griesser

Once a year we let our imagination go wild for a whole week during our annual Hackweek event. It’s where we come up with product updates, like dark mode support, design them and implement prototypes.

The mobile engineering team came up with the idea for a Sentry mobile app that focuses on Release Health. We wanted to give developers a concise but comprehensive view of whether a release a release was healthy, errored, or experiencing abnormal crash sessions across multiple projects.

Because we wanted to bring this to both iOS and Android, and we only had a week to build a proof of concept we decided to build the app in Flutter. Oh by the way, we also have a Flutter SDK, it’s great.

Application Overview

Sessions

We fetch all projects from all your linked organizations that have session data. Every card represents one project and shows the name, organization, platform and a graph with the total session data over the last 24 hours. Below the cards the sessions are split up into healthy, errored, abnormal and crashed, all with individual graphs. There are also two cards showing crashfree sessions and users in percent.

Settings

In the settings screen users can view a list of all projects and favorite them. Those will show up first on the main screen. Apart from that, we show the usual suspects, like terms, sharing and logout, in the settings screen.

Widgets

Flutter takes the main concept of view rendering from react. The user interface is described using widgets which are derived from the applications state. When the state changes, the system creates the new widgets from it and only redraws the interface elements. You can head over to the widgets intro documentation to learn more about this.

Redux

We use Redux for state management. There is a central object holding the global application state. When an event in the application occurs, let’s say a reload of the session data, an action is dispatched.

This action then goes through multiple middlewares. In this case, it would go through our API middleware, where it would trigger a network request. This request would then itself trigger new actions when it (asynchronously) finishes with success or a failure. All those actions travel through other middlewares as well and finally reach the reducer.

The reducer is the only place where the global app state is mutated. In the sample above it would set a loading state when started and replace the loaded data upon success, or set an error state when there was a problem we want the user to know about.

Pros

• When state changes, widgets can be updated automatically. With the help of ViewModels implementing BLA, the Widget will only be rendered if the derived state changed. Neat!

• With the reducer it,s explicit where state is mutated

Cons

• The global state tends to get large quickly, even for such a small application. As the app will grow, we will have to think about how to best split this up.

• Some Flutter API relies on Futures which does not yet play well with the Redux concept. One example of this is the “RefreshIndicator” widget.

Sentry SDK

Of course we use our own Sentry SDK to check for issues. This was especially helpful during development, as we started out without sound null safety (more on that below) and were able to catch many issues with our SDK that would just show up in the console and could go easily unnoticed otherwise.

Custom Drawing

The prototype used a dependency with embedded ECharts for chart drawing. This made use of web views, so every chart we would draw would also embed a full blown web view into our widget hierarchy. We would quickly encounter performance issues as well as flickering UI when redrawing.

This was a great way for us to get started during hackweek, as we use this JS dependency in the Sentry web application, but it was clear to us that we would need to replace this for the production app.

We decided to draw the charts that our designers prepared for us in the Figma design ourselves with the help of the canvas API. Android developers will feel right at home with this API, as it is basically the same on Android. Flutter also uses Skia as the drawing library, so no surprise there.

So in just a couple of lines of code we were able to draw the charts that our designers came up with, including gradients and cubic lines (which we removed again). Drawing was faster, pixel perfect and we could also get rid of a large dependency.

Tooling

Android Studio

We mainly used Android Studio with the Flutter plugin for application development. This is especially convenient for Android developers, as they can use a familiar environment when starting out with Flutter applications. Of course, you have the freedom to use whichever editor you are comfortable with.

Fastlane

Fastlane is an open source tool written in Ruby. It is mostly used by the iOS community, but also works exceptionally well for Android. We use it locally to create release builds and ship them to the respective stores, as well as upload debug symbols to Sentry.

Static Analysis

We used the Dart analyzer during development. It helped us to keep track of code issues that might come up during development.

Sound Null Safety

We migrated the application to sound null safety during development when we were already pretty far along with the app. Luckily, the Flutter team came up with an incremental way to do this. So we were able to convert file by file and have a working application during migration. I’m sure there are some Swift developers reading this who remember migrating in the early days. Yeah, my deepest condolences, I have been there.

That’s a Wrap

Everything we do at Sentry is built in the open. Find us on GitHub.

We have many ideas for future releases of the application, but ultimately it should be a tool that users find useful. So we can’t wait to hear your feedback, please give it a try!

Download it now on the Apple App Store and Google PlayStore and become a part of our Flutter journey.

Why we shipped a Next.js SDK, and how you can use it

Rahul Chhabria — Thu, 10 Jun 2021 23:07:25 +0000

As you could probably tell from the title, we shipped an SDK for Next.js. This means you can capture errors, measure performance, manage releases, configure suspect commits, and automatically upload sourcemaps to view unminified JavaScript and TypeScript with zero(-ish) configuration.

Why was Next.js next on our list? Well, it’s one of the fastest-growing React frameworks and developers love it. Next.js provides a developer experience that helps with building features rapidly, seeing local changes quickly, and reducing build times.

"Next.js turns traditionally complex decisions into simple implementation details. Spinning up new pages with our existing React components and Material UI went from days to hours with Next."

– Sean Parmelee, Applications Architect, Care.com

To monitor Next.js projects in the past, you had to install our @sentry/node and @sentry/react SDKs — installing both and configuring your environment correctly was time-consuming and literally no fun. The new Next.js SDK does all that for you, and works swimmingly with our Webpack Plugin or sentry-cli to upload your source maps.

To get started with Sentry for Next.js, simply install the SDK:

yarn add @sentry/nextjs

And then configure:

npx @sentry/wizard -i nextjs

Configure performance monitoring by setting a tracesSampleRate when you initialize the SDK, in both sentry.client.config.js & sentry.server.config.js:

Sentry.init({
  // ...
  tracesSampleRate: 1.0
});

Once you’ve done that, frontend transactions will be captured automatically. To capture API request transactions, wrap your handlers in our withSentry helper. (Hint: If you’re already using our SDK to capture errors in those routes, you will have already done this. No extra configuration needed.)

import { * as Sentry } from ‘@sentry/nextjs’;
Sentry.init({ ... });

function handler(req, res) {
  // ...
}

export default Sentry.withSentry(handler);

You can quickly track down poor-performing APIs or slow database queries. With new features like Quick Trace, Trace View, and Suspect Tags, Sentry connects frontend issues to root causes in the backend and vice versa.

Trace View gives a waterfall view of a given transaction and dependencies across all projects on a single screen:

Early adopters of our SDK — like Stefen Alper, Co-Founder of eesel, a content search and centralization tool — are already using Sentry for Next.js to capture errors. Now they (and you) can also capture performance data.

"We moved to Next.js for the dev experience and the scalability. As longtime users of Sentry’s error monitoring offering, we’re looking forward to start monitoring performance and managing releases with Sentry’s new Next.js SDK."

–Stefen Alper, Co-Founder, eesel.app

Install our Next.js SDK and get a pretty good idea of which commit caused the issue and who is likely responsible, and automatically upload source maps so your stack trace looks like the original code you wrote. Also, join us on June 24th, 2021 for a live workshop on how to build, deploy, and monitor Next.js applications with Sentry and Netlify.

Performance Monitoring for Android Applications

Rahul Chhabria — Fri, 19 Mar 2021 01:40:15 +0000

Android is arguably the most ubiquitous operating system in the world. Whether it's a tablet, phone, folding phone, computer, TV, or IoT device, chances are you’ve interacted with Android OS. And to help developers get full visibility into how their customers experience Android's myriad applications, we’re extending Performance to Android.

Being an Android developer means thinking through countless scenarios. If something goes wrong, you need to imagine what that support ticket would look like. That means collecting everything from hardware model to software version, in addition to crucial details like screen orientation and battery level. Sentry provides all of that context out of the box — and has done so for some time. And if your users lose their connection while encountering an error, Sentry still captures these events so they can be reported back when the app restarts.

But errors are only half of the story. Android developers also need to see how their application performs. That means visibility into when a user writes to disk, fetches media, or loads an object in a given viewport. Without this data, untreated performance problems run the risk of becoming serious errors. But now that you have Sentry’s performance monitoring, you can finally connect your user’s frustrated taps to its poor-performing backend call.

To install the Android SDK, add it to your build.gradle file:

// Make sure mavenCentral is there.
repositories {
    mavenCentral()
}

// Enable Java 1.8 source compatibility if you haven't yet.
android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

// Add Sentry's SDK as a dependency.
dependencies {
    implementation 'io.sentry:sentry-android:4.3.0'
}

After you’ve completed setting up a project in Sentry, we'll give you a value — which we call a DSN or Data Source Name — to add to your AndroidManifest.xml file.

<application>
  <meta-data android:name="io.sentry.dsn" android:value="https://example@sentry.io/example" />
</application>

The current version of our Android SDK supports auto instrumentation activity rendering, which can be expanded on through custom instrumentation. Additionally, in the coming weeks, you’ll be able to automatically create spans for active transactions as well as record breadcrumbs for outgoing HTTP requests.

iOS developers: if you’re getting SDK envy, rest easy knowing that Performance is on the way for you as well.

Have a friend who wants to manage releases, solve issues faster, and speed up their mobile applications? Refer them to Sentry and we’ll give them — and you — three free months on our Team plan.

To start using Sentry with Android, configure the SDK. And if you’re new to Sentry, you can try it for free today.