sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
import * as Sentry from "@sentry/browser";
|
|
|
|
import {HttpClient as HttpClientIntegration} from "@sentry/integrations";
|
|
|
|
import {BrowserTracing} from "@sentry/tracing";
|
|
|
|
import _ from "lodash";
|
|
|
|
|
|
|
|
import {page_params} from "./page_params";
|
|
|
|
|
|
|
|
type UserInfo = {
|
|
|
|
id?: string;
|
|
|
|
realm: string;
|
2023-03-07 21:48:35 +01:00
|
|
|
role?: string;
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
if (page_params.server_sentry_dsn) {
|
2023-03-07 21:43:47 +01:00
|
|
|
const url_matches = [/^\//, new RegExp("^" + _.escapeRegExp(page_params.webpack_public_path))];
|
|
|
|
if (page_params.realm_uri !== undefined) {
|
|
|
|
url_matches.push(new RegExp("^" + _.escapeRegExp(page_params.realm_uri) + "/"));
|
|
|
|
}
|
2023-03-07 21:48:35 +01:00
|
|
|
const sentry_key =
|
|
|
|
// No parameter is the portico pages, empty string is the empty realm
|
|
|
|
page_params.realm_sentry_key === undefined
|
|
|
|
? "www"
|
|
|
|
: page_params.realm_sentry_key === ""
|
|
|
|
? "(root)"
|
|
|
|
: page_params.realm_sentry_key;
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
const user_info: UserInfo = {
|
2023-03-07 21:45:53 +01:00
|
|
|
realm: sentry_key,
|
2023-03-07 21:48:35 +01:00
|
|
|
};
|
|
|
|
if (sentry_key !== "www") {
|
|
|
|
user_info.role = page_params.is_owner
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
? "Organization owner"
|
|
|
|
: page_params.is_admin
|
|
|
|
? "Organization administrator"
|
|
|
|
: page_params.is_moderator
|
|
|
|
? "Moderator"
|
|
|
|
: page_params.is_guest
|
|
|
|
? "Guest"
|
|
|
|
: page_params.is_spectator
|
|
|
|
? "Spectator"
|
2023-03-07 21:48:35 +01:00
|
|
|
: page_params.user_id
|
|
|
|
? "Member"
|
|
|
|
: "Logged out";
|
|
|
|
if (page_params.user_id) {
|
|
|
|
user_info.id = page_params.user_id.toString();
|
|
|
|
}
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
Sentry.init({
|
|
|
|
dsn: page_params.server_sentry_dsn,
|
|
|
|
environment: page_params.server_sentry_environment || "development",
|
|
|
|
|
|
|
|
release: "zulip-server@" + ZULIP_VERSION,
|
|
|
|
integrations: [
|
|
|
|
new BrowserTracing({
|
2023-03-07 21:43:47 +01:00
|
|
|
tracePropagationTargets: url_matches,
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
}),
|
|
|
|
new HttpClientIntegration({
|
|
|
|
failedRequestStatusCodes: [500, 502, 503, 504],
|
2023-03-07 21:43:47 +01:00
|
|
|
failedRequestTargets: url_matches,
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
}),
|
|
|
|
],
|
2023-03-07 21:43:47 +01:00
|
|
|
allowUrls: url_matches,
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
sampleRate: page_params.server_sentry_sample_rate || 0,
|
|
|
|
tracesSampleRate: page_params.server_sentry_trace_rate || 0,
|
|
|
|
initialScope: {
|
|
|
|
tags: {
|
2023-03-07 21:45:53 +01:00
|
|
|
realm: sentry_key,
|
sentry: Add frontend event monitoring.
Zulip already has integrations for server-side Sentry integration;
however, it has historically used the Zulip-specific `blueslip`
library for monitoring browser-side errors. However, the latter sends
errors to email, as well optionally to an internal `#errors` stream.
While this is sufficient for low volumes of users, and useful in that
it does not rely on outside services, at higher volumes it is very
difficult to do any analysis or filtering of the errors. Client-side
errors are exceptionally noisy, with many false positives due to
browser extensions or similar, so determining real real errors from a
stream of un-grouped emails or messages in a stream is quite
difficult.
Add a client-side Javascript sentry integration. To provide useful
backtraces, this requires extending the pre-deploy hooks to upload the
source-maps to Sentry. Additional keys are added to the non-public
API of `page_params` to control the DSN, realm identifier, and sample
rates.
2023-02-13 20:50:57 +01:00
|
|
|
server_version: page_params.zulip_version,
|
|
|
|
},
|
|
|
|
user: user_info,
|
|
|
|
},
|
|
|
|
});
|
|
|
|
}
|