A series of
- Sentry-go SDK Chinese Practice Guide
- Plan together according to official documents in Sentry For Go
- Snuba: Sentry’s new search infrastructure (based on ClickHouse)
- Sentry 10 K8S cloud native architecture exploration, fast access to Vue App in 1 minute
- 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
- 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
beforeSend
/beforeBreadcrumb
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 version
XMLHttpRequest
Breadcrumbs 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