A series of

  1. Sentry-go SDK Chinese Practice Guide
  2. Plan together according to official documents in Sentry For Go
  3. Snuba: Sentry’s new search infrastructure (based on ClickHouse)
  4. Sentry 10 K8S cloud native architecture exploration, fast access to Vue App in 1 minute
  5. Sentry(V20.12.1) K8S cloud native architecture exploration, play forward/back end monitoring and event log big data analysis, high performance + high availability + scalable + scalable cluster deployment
  6. Sentry(V20.12.1) K8S cloud native architecture exploration, Sentry JavaScript SDK three ways to install and load

Basic Options

The SDK can be configured using a variety of options. These options are largely standardized in the SDK, but there are some differences in how they better fit platform features. Options are set when the SDK is first initialized.

Options are passed as objects to the init() function:

Sentry.init({
  dsn: "https://[email protected]/0".maxBreadcrumbs: 50.debug: true});Copy the code

Common Options

List of common options across SDKS. These features are more or less the same across all SDKS, but there are some subtle differences to better support the platform. Options that can be read automatically from environment variables or from your ~/.sentryclirc file (SENTRY_DSN, SENTRY_ENVIRONMENT, SENTRY_RELEASE). For more information, see Working with Projects.

dsn

The DSN tells the SDK where to send the event. If this value is not provided, the SDK will try to read it from the SENTRY_DSN environment variable. If this variable also does not exist, the SDK will not send any events.

Fallback is not applied at runtime without a process environment such as a browser.

debug

Enable or disable debug mode. If debugging is enabled, the SDK will try to print useful debugging information if there is a problem sending events. The default is always false. It is generally not recommended to turn it on in production, although turning on debug mode does not raise any security issues.

release

Set release. Some SDKS will try to configure release automatically, but it is best to set release manually to ensure that it is synchronized with your Deploy Integrations or Source Map Uploads. The version name is a string, but Sentry detects certain formats, and they may be rendered differently. Learn more about how to send release data in the Releases document so that Sentry can tell you about regression between releases and identify potential sources.

By default, the SDK will try to read this value from the environment variable SENTRY_RELEASE (in the browser SDK, it will be read from window.sentry_release, if available).

environment

Set up the environment. This string is free-form and is not set by default. A release can be associated with multiple environments to separate them in the UI (consider staging, prod, or the like).

By default, the SDK will try to read this value from the SENTRY_ENVIRONMENT environment variable (except the browser SDK).

sampleRate

Configure the sampling rate for error events, ranging from 0.0 to 1.0. The default value is 1.0, which means 100% error events were sent. If set to 0.1, only 10% of error events are sent. Events are chosen at random.

maxBreadcrumbs

This variable controls the total amount of breadcrumbs that should be captured. The default value is 100.

attachStacktrace

When enabled, a stack trace is automatically attached to all recorded messages. Stack traces are always attached to exceptions; However, when this option is set, the stack trace is also sent with the message. For example, this option means that the stack trace is displayed next to all log messages.

This option defaults to off.

Grouping in Sentry is different for events with and without a stack trace. As a result, you get new groups when you enable or disable this Flag for certain events.

sendDefaultPii

If this Flag is enabled, certain personal identifying information (PII) will be added by Active Integrations. By default, no such data is sent. If possible, we recommend enabling this feature by default to send all such data, and using the ability to manage sensitive data to manually delete what you don’t want to send.

denyUrls

List of strings or regular expression patterns that match the wrong URL that should not be sent to Sentry. By default, all errors are sent. This is a “contains” that matches the entire file URL. So, if you add foo.com, it will also match at https://bar.com/myfile/foo.com. By default, all errors are sent.

allowUrls

A list of strings or a legacy alias for a regular expression pattern that matches the wrong URL, which should be sent specifically to Sentry. By default, all errors are sent. This is a “contains” that matches the entire file URL. So, if you add foo.com to the it, it will also match at https://bar.com/myfile/foo.com. By default, all errors will be sent.

autoSessionTracking

When set to true, the SDK will send session events to Sentry. All browser SDKS support this, and each page load sends a session to Sentry.

normalizeDepth

The Sentry SDK normalizes any context data to a given depth. Any key that contains data deeper than its structure is pruned and marked with its type ([Object] or [Array]) without further action. By default, walking has a depth of 3.

Integration Configuration

For many platforms, SDK integration can be configured with them. On some platforms, this is part of the init() call, while on others, a different pattern applies.

integrations

In some SDKS, this parameter is used to configure integration during library initialization. For more information, see our documentation for specific integrations.

defaultIntegrations

This can be used to disable integrations added by default. When set to false, default integrations are not added.

Hooks

These options can be used to hook the SDK in various ways to customize event reporting.

beforeSend

This function, called with sdK-specific event objects, can return the modified event object or nothing to skip reporting the event. For example, this can be used to manually strip the PII before sending.

beforeBreadcrumb

This function is called with an SDK-specific breadcrumb object before the breadcrumb is added to the scope. When nothing is returned from this function, the breadcrumb is removed. To pass the breadcrumb, return the first parameter, which contains the breadcrumb object. The callback usually gets a second parameter (called “hint”) that contains the original object that created the breadcrumb to further customize the appearance of the breadcrumb.

Transport Options

Transports is used to send events to Sentry. Transport can be customized to some extent to better support highly specific deployments.

transport

Switch out the transport used to send events. How it works depends on the SDK. For example, it can be used to capture events for unit testing, or to send events through more complex Settings that require proxy authentication.

Tracing Options

tracesSampleRate

A number between 0 and 1 that controls the percentage probability that a given transaction will be sent to the sentry. (0 means 0% and 1 means 100%) the same applies to all transactions created in the application. This or tracesSampler must be defined to enable tracing.

tracesSampler

A function is responsible for determining the percentage probability that a given transaction will be sent to Sentry. It will automatically be passed information about the transaction and the context in which it was created, and must return a number between 0(with a 0% chance of being sent) and 1(with a 100% chance of being sent). It can also be used to filter transactions, returning 0 for unwanted transactions. This or tracesSampleRate must be defined to enable tracking.

Releases & Health

A release is the version of the code deployed into the environment. When you provide Sentry with information about releases, you can:

  • Identify issues and regressions introduced in the new release
  • Predict which submission caused the problem and who might be responsible
  • Resolve the problem by including the problem number in the commit message
  • Receive email notifications when deploying code

In addition, Releases is used to apply Source maps to compressed JavaScript to view the original, unconverted source code.

Bind the Version

Include a release ID(usually called “version”) when configuring the client SDK. This ID is usually a Git SHA or custom version number.

Release names cannot:

  • Contains newlines or Spaces
  • Use a forward slash (/), backslash (\), period (.), or double period (.)
  • More than 200 characters

Releases for each organization are global; Add something project-specific in front of them to make them easier to distinguish.

Sentry.init({
  release: "[email protected]"});Copy the code

A common way to do this using JavaScript in a Node/ NPM environment is to use process.env.npm_package_version, as shown below:

Sentry.init({
  release: "my-project-name@" + process.env.npm_package_version,
});
Copy the code

How you make the version available to your code is up to you. For example, you can use environment variables that you set during the build process.

This marks each event with a release value. We recommend that you tell Sentry before deploying the new version, as this will release some new functionality, as described in the documentation on Releases. However, if you don’t, Sentry automatically creates a Release entity in the system the first time it sees an event with that release ID.

After configuring the SDK, you can install repository Integration or manually provide your own commit metadata for Sentry. Read the documentation on setting up distributions for more information about integration, associated commits, and telling Sentry when deploying distributions.

Release Health

Monitor Health of Releases by looking at user adoption, application utilization, crashes percentage, and session data. Release Health will provide insights into the impact of crashes and errors as they relate to the user experience, revealing trends for each new issue through Release details, charts, and filters.

After the SDK is initialized, the SDK automatically manages the start and end of the session.

Sentry.init({
  autoSessionTracking: true
});
Copy the code

Environments

The Sentry automatically creates the environment when it receives an event with the environment tag. The environment is case sensitive. The environment name cannot contain newlines, Spaces, or slashes, the string “None”, or more than 64 characters. You cannot delete environments, but you can hide them.

Sentry.init({
  environment: "production"});Copy the code

Environments helps you better filter issues, Releases, and User feedback in the Problem Details page of Sentry. IO, You can learn more about this in Documentation that Covers Using Environments.

Filtering and Sampling Events

Adding Sentry to your application can give you a lot of valuable information about errors and performance. A lot of information can be helpful — as long as it’s right and in a reasonable amount.

The Sentry SDK provides several configuration options to help you control this, allowing you to both filter out unwanted events and get a representative sample from them.

Note: Sentry UI also provides a way to filter events using Inbound Filters. However, we recommend that you filter at the client level, because this eliminates the overhead of sending events that you don’t really need.

Filtering Error Events

Use the beforeSend callback method and configure, enable or disable Integrations, and configure your SDK to filter error events.

Using beforeSend

All Sentry SDKS support the beforeSend callback method. BeforeSend is called immediately before events are sent to the server, so this is the final place where you can edit its data. It accepts the event object as a parameter, so you can use it to modify the event’s data or delete it completely (by returning NULL), depending on the custom logic and data available on the event.

Sentry.init({
  // ...

  beforeSend(event, hint) {
    const error = hint.originalException;
    if (
      error &&
      error.message &&
      error.message.match(/database unavailable/i)
    ) {
      event.fingerprint = ["database-unavailable"];
    }
    returnevent; }});Copy the code

Also note that breadcrumbs can be filtered, as described in Our Breadcrumbs Documentation.

Event Hints

The before-send callback passes both event and the second argument hint, which contains one or more hints.

Typically, HINT saves the original exception to extract additional data or to influence the grouping. In this case, if some type of exception is caught, force the fingerprint to a normal value:

Sentry.init({
  // ...

  beforeSend(event, hint) {
    const error = hint.originalException;
    if (
      error &&
      error.message &&
      error.message.match(/database unavailable/i)
    ) {
      event.fingerprint = ["database-unavailable"];
    }
    returnevent; }});Copy the code

When an SDK creates an event or breadcrumb for a transport, the transport is usually created from some source object. For example, error events are typically created from logging or exception instances. For better customization, the SDK sends these objects to specific callbacks (beforeSend, beforeBreadcrumb, or the event handler system in the SDK).

Using Hints

  1. beforeSend / beforeBreadcrumb
  2. eventProcessors

The Event and breadcrumb hints are objects that contain various information for putting events or breadcrumbs together. Typically, Hints keeps the original exceptions so you can extract additional data or influence groupings.

For events, such as Event_id, originalException, syntheticException (internally used to generate a cleaner stack trace), and any other arbitrary data that you attach.

For breadcrumbs, the use of Hints depends on the implementation. For XHR requests, the Hint contains the XHR object itself. For user interactions, hints contain DOM elements, event names, and so on.

In this example, if some type of exception is caught, fingerprint is forced to a common value:

Sentry.init({
  // ...

  beforeSend(event, hint) {
    const error = hint.originalException;
    if (
      error &&
      error.message &&
      error.message.match(/database unavailable/i)
    ) {
      event.fingerprint = ["database-unavailable"];
    }
    returnevent; }});Copy the code

Hints for Events

originalException

  • The original exception that causes the Sentry SDK to create the event. This is useful for changing the way the Sentry SDK groups events or extracts additional information.

syntheticException

  • When a string or non-error object is raised, Sentry creates a composite exception so that you can get a basic stack trace. This exception is stored here for further extraction of data.

Hints for Breadcrumbs

event

  • For breadcrumbs created through browser events, the Sentry SDK typically provides the event as a hint to the breadcrumbs. For example, this can be used to extract data from the target DOM element into breadcrumbs.

level / input

  • For intercepting the breadcrumbs created from the console log. This preserves the raw input data for the original console log level and logging functionality.

response / input

  • Breadcrumbs used to create from HTTP requests. This holds the response object (from the FETCH API) and the input parameters of the FETCH function.

request / response / event

  • Breadcrumbs used to create from HTTP requests. It holds request and response objects (from the node HTTP API) as well as node events (response 或 error).

xhr

  • For passing the old versionXMLHttpRequestBreadcrumbs created by the API through HTTP requests. This will preserve the original XHR object.

Decluttering Sentry

You can construct a list of allowed domains, which may throw acceptable exceptions. For example, if your script is loaded from cdn.example.com and your site is example.com, you can set allowUrls to:

If you want to block specific urls forever, you can also use denyUrls.

Prior to version 5.17.0, allowUrls and denyUrls were called whitelistUrls and blacklistUrls, respectively. These options are still supported for backward compatibility reasons, but they will be removed in version 6.0. For more information, see our Inclusive Language Policy.

In addition, our community has compiled lists of common ignore rules for everyday work (e.g., Facebook, Chrome extensions, etc.). It would be useful to review these to see if they apply to you. Here is the original gist. This is not the default for our SDK; This is just the highlight of an extensive example.

Sentry.init({
  ignoreErrors: [
    // Random plugins/extensions
    "top.GLOBALS".// See: http://blog.errorception.com/2012/03/tale-of-unfindable-js-error.html
    "originalCreateNotification"."canvas.contentDocument"."MyApp_RemoveAllHighlights"."http://tt.epicplay.com"."Can't find variable: ZiteReader"."jigsaw is not defined"."ComboSearch is not defined"."http://loading.retry.widdit.com/"."atomicFindClose".// Facebook borked
    "fb_xd_fragment".// ISP "optimizing" proxy - `Cache-Control: no-transform` seems to
    // reduce this. (thanks @acdha)
    // See http://stackoverflow.com/questions/4113268
    "bmi_SafeAddOnload"."EBCallBackMessageReceived".// See http://toolbar.conduit.com/Developer/HtmlAndGadget/Methods/JSInjection.aspx
    "conduitPage",].denyUrls: [
    // Facebook flakiness
    /graph\.facebook\.com/i.// Facebook blocked
    /connect\.facebook\.net\/en_US\/all\.js/i.// Woopra flakiness
    /eatdifferent\.com\.woopra-ns\.com/i./static\.woopra\.com\/js\/woopra\.js/i.// Chrome extensions
    /extensions\//i./^chrome:\/\//i.// Other plugins
    /127\.0\.0\.1:4001\/isrunning/i.// Cacaoweb
    /webappstoolbarba\.texthelp\.com\//i./metrics\.itunes\.apple\.com\.edgesuite\.net\//i,]});Copy the code

Sampling Error Events

To send a representative sample of errors to Sentry, set the sampleRate option in your SDK configuration to a number between 0 (0% of errors sent) and 1 (100% of errors sent). This is a static ratio that will hold for all errors. For example, to sample 25% of errors:

Sentry.init({ sampleRate: 0.25 });
Copy the code

Note: Error sampling rate is not dynamic. Changing it requires redeployment. In addition, setting the SDK sampling rate limits the visibility of the event source. Setting a rate limit for the project (discarding events only at high volumes) may be more appropriate for your needs.

Filtering Transaction Events

To prevent certain transactions from being reported to Sentry, you can use the tracesSampler configuration option, which allows you to provide a function to evaluate the current transaction and remove it if it is not the one you want. (It also allows you to sample different transactions at different rates.)

Note: tracesSampler and tracesSampleRate configuration options are mutually exclusive. If you define a tracesSampler to filter out certain transactions, you must also handle unfiltered transactions by returning the rate at which you want them to be sampled.

The simplest form (for filtering only) looks like this:

Sentry.init({
  // ...

  tracesSampler: samplingContext= > {
    if ("...") {
      // Drop this transaction, by setting its sample rate to 0%
      return 0;
    } else {
      // Default sample rate for all others (replaces tracesSampleRate)
      return 0.1; }}; });Copy the code

To learn more about the tracesSampler option, refer to the SDK’s Performance Docs.

Sampling Transaction Events

For Sentry performance monitoring, we recommend sampling your data for two reasons. First, although the overhead involved in capturing a single trace is minimal, capturing a trace for each page load or each API request has the potential to add unwanted load to the system. Second, enabling sampling allows you to better manage the number of events sent to Sentry, so you can adjust your number according to your organization’s needs.

When selecting a sampling rate, the goal is not to collect too much data, but to collect enough data to draw meaningful conclusions. If you are unsure what rate to choose, start with a low value and gradually increase it as you learn more about traffic patterns and volumes until you find a rate that balances performance and traffic with data accuracy.

To sample transactions, set the tracesSampleRate configuration option to a number between 0(0% of transactions sent) and 1(100% of transactions sent), or set the tracesSampler option to a function that returns this number, This number varies from transaction to transaction.

For example, setting the tracesSampleRate option to 0.2 will cause the SDK to send only 20% of the possible transaction events:

Sentry.init({
  // ...

  tracesSampleRate: 0.2});Copy the code

Alternatively, you can provide a tracesSampler function that samples different transactions at different rates:

Sentry.init({
  // ...

  tracesSampler: samplingContext= > {
    // Examine provided context data (including parent decision, if any) along
    // with anything in the global namespace to compute the sample rate or
    // sampling decision for this transaction

    if ("...") {
      // These are important - take a big sample
      return 0.5;
    } else if ("...") {
      // These are less important or happen much more frequently - only take 1%
      return 0.01;
    } else if ("...") {
      // These aren't something worth tracking - drop all transactions like this
      return 0;
    } else {
      // Default sample rate
      return 0.1; }}; });Copy the code

To learn more about the tracesSampler option, check out the SDK’s Performance Docs.

Shutdown and Draining

The default behavior of most SDKS is to send events asynchronously in the background over the network. This means that some events may be lost if the application is unexpectedly shut down. The SDK provides a mechanism to deal with this situation.

The close method optionally accepts a timeout in milliseconds and returns a promise that will be resolved when all pending events flush or the timeout begins.

Sentry.close(2000).then(function() {
  // perform something after close
});
Copy the code

When close is called, the current client is no longer available. It is important to only call Close before closing the application.

Alternatively, the flush method empties the event queue while keeping the client enabled for continued use.

Default Integrations

All of Sentry’s SDKS provide integrations that extend the functionality of the SDK.

By default, System Integrations are enabled for integration into the standard library or the interpreter itself. They are documented, so you can either know what they are doing or disable them if they cause problems.

Enabled by Default

InboundFilters

Import name: Sentry.Integrations.InboundFilters

With this integration, you can ignore specific errors based on the type, message, or URL in a given exception.

By default, it ignores errors starting with Script Error or Javascript error: Script error.

To configure this integration, use the ignoreErrors, denyUrls, and allowUrls SDK options directly. Keep in mind that denyURL and allowURL are only valid for caught exceptions, not raw message events.

FunctionToString

Import name: Sentry.Integrations.FunctionToString

This integration allows the SDK to provide the original function and method names, even if our error or breadcrumb handler wraps them.

TryCatch

Import name: Sentry.Integrations.TryCatch

This integration encapsulates the native Time and Events APIs (setTimeout, setInterval, requestAnimationFrame, AddEventListener/removeEventListener) in a try/catch block async exception handling.

Breadcrumbs

Import name: Sentry.Integrations.Breadcrumbs

This integration encapsulates the native API to capture breadcrumbs. By default, the Sentry SDK wraps all apis.

Available options:

{ beacon: boolean; // Log HTTP requests done with the Beacon API
  console: boolean; // Log calls to `console.log`, `console.debug`, etc
  dom: boolean; // Log all click and keypress events
  fetch: boolean; // Log HTTP requests done with the Fetch API
  history: boolean; // Log calls to `history.pushState` and friends
  sentry: boolean; // Log whenever we send an event to the server
  xhr: boolean; // Log HTTP requests done with the XHR API
}
Copy the code

GlobalHandlers

Import name: Sentry.Integrations.GlobalHandlers

This integration attaches global handlers to catch uncaught exceptions and unhandled rejections.

Available options:

{
  onerror: boolean;
  onunhandledrejection: boolean;
}
Copy the code

LinkedErrors

Import name: Sentry.Integrations.LinkedErrors

This integration allows you to configure link errors. They are recursively read to the specified limit and lookups are performed by a specific key. By default, the Sentry SDK sets the limit to 5 and uses the key cause.

Available options:

{
  key: string;
  limit: number;
}
Copy the code

UserAgent

Import name: Sentry.Integrations.UserAgent

This integration attaches User-Agent information to events, which allows us to properly categorize and tag them with specific operating system (OS), browser, and version information.

Modifying System Integrations

To disable system integration, set defaultIntegrations: false when init() is called.

To override their Settings, provide a new instance with the configure to Integrations option. For example, close the browser to capture console call: integrations: [new Sentry. Integrations. Breadcrumbs (} {the console: false)].

Removing an Integration

This example removes the default enabled integration for adding breadcrumbs for events:

Sentry.init({
  // ...

  integrations: function(integrations) {
    // integrations will be all default integrations
    return integrations.filter(function(integration) {
      returnintegration.name ! = ="Breadcrumbs"; }); }});Copy the code

Pluggable Integrations

These pluggable integrations are snippets of code that add functionality to a particular application and/or framework. We document them so you can see what they do, and you can enable them.

How to Enable

Install the @Sentry/Integrations package and provide a new instance with your configuration options to Integrations. Once the SDK is loaded, plug-ins are included.

Example:

import * as Sentry from "@sentry/browser";
import { ReportingObserver as ReportingObserverIntegration } from "@sentry/integrations";

Sentry.init({
  dsn: "___PUBLIC_DSN___".integrations: [new ReportingObserverIntegration()],
});
Copy the code

ExtraErrorData

Import name: Sentry.Integrations.ExtraErrorData

This integration extracts all non-native attributes from the error object and attaches them to the event as extra data.

Available options:

{
  // limit of how deep the object serializer should go. Anything deeper than limit will
  // be replaced with standard Node.js REPL notation of [Object], [Array], [Function] or
  // a primitive value. Defaults to 3.
  depth: number;
}
Copy the code

CaptureConsole

Import name: Sentry.Integrations.CaptureConsole

This integration captures all Console API calls and redirects them to Sentry using captureMessage calls. It then refires to preserve the default native behavior.

{
  // array of methods that should be captured
  // defaults to ['log', 'info', 'warn', 'error', 'debug', 'assert']
  levels: string[];
}
Copy the code

Dedupe

Import name: Sentry.Integrations.Dedupe

This integration allows for deduplication of certain events. It might help if you receive a lot of repeated errors. Note that Sentry will only compare stack traces and fingerprints.

Debug

Import name: Sentry.Integrations.Debug

With this integration, you can examine the contents of the processed event, which is passed to beforeSend and effectively sent to the Sentry SDK. Whenever registered, it will always run as the final integration.

Available options:

{
  // trigger DevTools debugger instead of using console.log
  debugger: boolean;

  // stringify event before passing it to console.log
  stringify: boolean;
}
Copy the code

RewriteFrames

Import name: Sentry.Integrations.RewriteFrames

This integration allows you to apply transformations to each frame of the stack trace. In the Streamlined scenario, you can use it to change the name of the file framework, or you can give it an iterative function to apply any arbitrary transformation.

On Windows machines, you must use the Unix path and skip the volume number in the root option to enable it. For example, C:\\Program Files\\Apache\ WWW does not work, but /Program Files/Apache/ WWW does.

Available options:

{
  // root path that will be appended to the basename of the current frame's url
  root: string;

  // function that takes the frame, applies a transformation, and returns it
  iteratee: (frame) = > frame;
}
Copy the code

ReportingObserver

Import name: Sentry.Integrations.ReportingObserver

This integration hooks into the ReportingObserver API and sends captured events to Sentry. It can be configured to handle only specific problem types.

Available options:

{
  types: <'crash'|'deprecation'|'intervention'> []; }Copy the code

Custom Integrations

Add a custom integration in JavaScript using the following format:

// All integration that come with an SDK can be found on Sentry.Integrations object
// Custom integration must conform Integration interface: https://github.com/getsentry/sentry-javascript/blob/master/packages/types/src/integration.ts

Sentry.init({
  // ...

  integrations: [new MyAwesomeIntegration()],
});
Copy the code

rrweb: Session Replays

Sentry provides integration with RRWeb’s proof-of-Concept toolkit for recording and replaying user sessions. This can be useful when diagnosing complex user behavior in feature-rich, single-page applications.

For information about available hints, see Hints in JavaScript

Playback using Attachments.

Configuration

First, you need to add @sentry/ rrWeb and rrWeb packages:

npm install --save @sentry/rrweb rrweb
Copy the code

Next, register the integration using the Sentry SDK. This will vary depending on the framework you use:

import * as Sentry from "@sentry/browser";
import SentryRRWeb from "@sentry/rrweb";

Sentry.init({
  dsn: "___PUBLIC_DSN___".integrations: [
    new SentryRRWeb({
      / /... options}),].// ...
});
Copy the code

For more information on configuration, see @sentry/ rrWeb Project on GitHub.

After capturing a Replay of the event, you can see that the event is visible under Issue Details under the Event’s Replay section.

Sampling

To meet your organization’s needs, you might want to sample replays. The easiest way to do this is to make a sampling decision when initializing the Sentry SDK. For example, here’s how Sentry itself uses sampling to capture only samples of employees:

const hasReplays = getCurrentUser().isStaff;

let integrations = [];
if (hasReplays) {
  console.log("[sentry] Instrumenting session with rrweb");
  integrations.push(new SentryRRWeb());
}

Sentry.init({
  dsn: "___PUBLIC_DSN___",
  integrations,
});

Sentry.setTag("rrweb.active", hasReplays ? "yes" : "no");
Copy the code

You will notice that we also set the rrWeb. active tag, which helps us identify events with replay attached, because we would not have been able to find them otherwise. Once configured, you will be able to simply use rrWeb.active :yes in search queries.

Sentry Testkit

When building tests for your application, you want to assert that the correct flow-tracking or error is being sent to Sentry, rather than actually sending it to the Sentry server. This way, you won’t flood the Sentry with error reports during test runs or other CI operations.

Note: Wix, a Sentry partner, is responsible for maintaining Sentry Testkit.

Sentry Testkit is a Sentry plug-in that allows intercepting Sentry reports and further checking the data being sent. It allows Sentry to work natively in your application, and by overriding the transport mechanism of the default Sentry, reports are not actually sent, but are logged locally to memory. This way, a report of the record can be retrieved later for your own use, validation, or any other use in your local development/test environment.

Installation

npm install sentry-testkit --save-dev
Copy the code

Using in tests

const sentryTestkit = require("sentry-testkit");

const { testkit, sentryTransport } = sentryTestkit();

// initialize your Sentry instance with sentryTransport
Sentry.init({
  dsn: "___PUBLIC_DSN___".transport: sentryTransport,
  / /... other configurations
});

// then run any scenario that should call Sentry.catchException(...)

expect(testkit.reports()).toHaveLength(1);
const report = testkit.reports()[0];
expect(report).toHaveProperty(/ *... * /);
Copy the code

You can also see more usage examples in the Testing section of the Sentry-TestKit repository.

Testkit API

Sentry Testkit consists of a very simple and straightforward API. You can see the full API description and documentation in Sentry Testkit Docs.

Chinese documents have been synchronized to:

  • getsentry.hacker-linner.com
I am for less. Wechat: uuhells123. Public account: Hacker afternoon tea. Thank you for your support 👍👍👍!Copy the code