Sentry
Իմացիր error-ների մասին, նախքան օգտատերերը կհայտնեն՝ կցված stack trace-ով, release-ով և կոնտեքստով։
30 վայրկյանում
Sentry-ն application monitoring service է, որը կենտրոնացած է error-ների վրա։ Հավելվածիդ SDK-ն որսում է exception-ները, ավելացնում կոնտեքստ (browser, օգտատեր, request, breadcrumb-եր՝ այն մասին, թե ինչ էր կատարվել դրանից առաջ) և ուղարկում Sentry, որը նույնական error-ները խմբավորում է issue-ների մեջ և քեզ alert է ուղարկում։ Release-ներով և source map-երով տեսնում ես քո սկզբնական կոդի ճշգրիտ տողը, թե որ commit-ն է բերել bug-ը և քանի օգտատիրոջ է այն ազդում։ Այն առաջարկում է նաև tracing, session replay, log-եր, cron և uptime monitoring։
Իմ ամենօրյա stack-ում չէ․ գիտեմ հիմնական գաղափարները և մանրամասները կսովորեմ, երբ նախագիծը դա պահանջի։
Ինչու է սա կարևոր
- Օգտատերերը հազվադեպ են bug-եր հայտնում․ նրանք պարզապես հեռանում են։ Error tracking-ը լուռ ձախողումները վերածում է alert-ների՝ բավարար մանրամասներով, որպեսզի արագ շտկվեն։
- Minify արված JavaScript-ի stack trace-երը անընթեռնելի են․ upload արված source map-երով Sentry-ն ցույց է տալիս սկզբնական ֆայլը, տողը և շրջակա կոդը։
- Release tracking-ը error-ները կապում է deploy-երի և commit-ների հետ, ուստի թիմը րոպեների ընթացքում կարող է տեսնել, որ «սա սկսվել է 1.4.2 տարբերակով», և rollback անել։
- Սկսելը էժան է (free tier և wizard, որը կարգավորում է հայտնի framework-երը), ահա թե ինչու այն հաճախ առաջին monitoring գործիքն է, որ թիմն ավելացնում է։
Ինչպես է աշխատում
01Ինչպես է այն աշխատում՝ event-ներ, issue-ներ և DSN
Երբ error է տեղի ունենում, հավելվածիդ Sentry SDK-ն այն որսում է որպես event՝ exception-ի տեսակը և հաղորդագրությունը, stack trace-ը և կոնտեքստը, ինչպես browser-ը և OS-ը, URL-ը, release-ը, environment-ը, user ID-ն, եթե թույլ ես տալիս, և breadcrumb-երը՝ վերջին գործողությունների կարճ ժամանակագրություն (click-եր, navigation, network request-ներ, console հաղորդագրություններ)։ SDK-ն այն ուղարկում է Sentry՝ օգտագործելով DSN, project-ին հատուկ URL, որը SDK-ին ասում է, թե ուր ուղարկել տվյալները։ DSN-ը սովորական իմաստով secret չէ, որովհետև այն կարող է միայն event-ներ ուղարկել, ուստի կարող է ապրել browser կոդում։ Այնուհետև Sentry-ն event-ին fingerprint է տալիս, հիմնականում ըստ stack trace-ի, և նման event-ները խմբավորում issue-ի մեջ։ Աշխատում ես issue-ների, ոչ թե միլիոնավոր event-ների հետ․ մեկ issue-ն ասում է՝ «TypeError CheckoutForm-ում, 312 event, 87 օգտատեր, առաջին անգամ՝ 1.4.2-ում»։ Չմշակված error-ները որսվում են ավտոմատ, իսկ մշակվածները հայտնում ես captureException-ով։
02Կարգավորում Next.js հավելվածում
Sentry-ի wizard-ը framework-երի մեծ մասը կարգավորում է մի քանի րոպեում․ այն տեղադրում է SDK-ն, ստեղծում config ֆայլեր և build-ում միացնում source map-երի upload-ը։ Next.js-ի համար այն ստեղծում է instrumentation-client.ts browser-ի համար, sentry.server.config.ts և sentry.edge.config.ts server runtime-երի համար, instrumentation.ts, որը բեռնում է դրանք և export անում onRequestError, և next.config-ը փաթաթում withSentryConfig-ով։ Մյուս պլատֆորմները նման են՝ @sentry/react, @sentry/node, sentry/sentry-laravel, @sentry/react-native։ Կարգավորումից հետո սահմանիր environment-ը և release-ը, production-ի համար իջեցրու trace sample rate-ը և որոշիր, թե օգտատիրոջ ինչ տվյալներ ես ուղարկում։ Ապա test error նետիր՝ համոզվելու, որ այն հասնում է ընթեռնելի stack trace-ով։
// instrumentation-client.ts (created by: npx @sentry/wizard@latest -i nextjs)
import * as Sentry from "@sentry/nextjs";
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
environment: process.env.NEXT_PUBLIC_APP_ENV ?? "development",
integrations: [Sentry.replayIntegration()],
tracesSampleRate: 0.1, // 10% of transactions in production
replaysSessionSampleRate: 0.0, // no replays for normal sessions
replaysOnErrorSampleRate: 1.0, // replay every session that hits an error
});
export const onRouterTransitionStart = Sentry.captureRouterTransitionStart;
03Release-ներ և source map-եր
Release-ը տարբերակի պիտակ է, որը կցվում է յուրաքանչյուր event-ի, սովորաբար Git commit SHA կամ semantic version։ Release-ներով Sentry-ն գիտի, թե երբ է issue-ն առաջին անգամ հայտնվել, կարող է issue-ն նշել «resolved in next release» և նորից բացել այն, եթե վերադառնա (regression), իսկ commit integration-ով առաջարկում է, թե որ commit-ն ու հեղինակն են հավանաբար առաջացրել այն։ Source map-երը minify արված production կոդը հետ են թարգմանում քո սկզբնական source-ի։ Upload արա դրանք build-ի ընթացքում bundler plugin-ով կամ sentry-cli-ով, ապա դրանք public մի սպասարկիր․ plugin-ները կարող են դրանք ջնջել upload-ից հետո։ Sentry-ն upload արված ֆայլերը համապատասխանեցնում է error-ներին bundle-ի մեջ ներդրված Debug ID-ներով, ինչը շատ ավելի հուսալի է, քան հին URL matching-ը։ Mobile հավելվածներին պետք է նույն գաղափարը՝ dSYM-ներ iOS-ի համար, ProGuard/R8 mapping ֆայլեր Android-ի համար և source map-եր React Native-ի JavaScript bundle-ի համար։
# CI step after the build (if not using a bundler plugin)
export SENTRY_AUTH_TOKEN=*** # from CI secrets, never committed
export SENTRY_ORG=your_org SENTRY_PROJECT=web
VERSION=$(git rev-parse --short HEAD)
npx @sentry/cli releases new "$VERSION"
npx @sentry/cli releases set-commits "$VERSION" --auto
npx @sentry/cli sourcemaps inject ./dist
npx @sentry/cli sourcemaps upload --release "$VERSION" ./dist
npx @sentry/cli releases finalize "$VERSION"
npx @sentry/cli deploys new --release "$VERSION" -e production
find ./dist -name "*.map" -delete
04Կոնտեքստի ավելացում՝ օգտատերեր, tag-եր և breadcrumb-եր
Առանց կոնտեքստի error-ը հանելուկ է։ Sentry.setUser-ով ավելացրու անանուն user ID, որպեսզի կարողանաս հաշվել տուժած օգտատերերին և գտնել մեկ հաճախորդի բոլոր error-ները, որը դիմում է support-ին։ Tag-եր ավելացրու այն բաների համար, որոնցով ուզում ես ֆիլտրել և որոնել՝ tenant-ի plan, feature flag, payment provider, հավելվածի locale։ Tag-երը index են արվում և պետք է ունենան արժեքների սահմանափակ հավաքածու։ Ավելի մեծ կառուցվածքային տեղեկության համար, որը կարդում ես միայն event-ի էջում, օգտագործիր context-ներ կամ extra data։ Breadcrumb-երը ավտոմատ գրանցվում են navigation-ի, click-երի, console-ի և network կանչերի համար․ կարևոր բիզնես քայլերի համար ավելացրու քո սեփականները։ Գաղտնիության հարցում գիտակցված եղիր․ մի ուղարկիր email-ներ, անուններ կամ token-ներ, եթե պատճառ և իրավական հիմք չունես, և զգայուն դաշտերը հեռացնելու համար օգտագործիր beforeSend։ Project settings-ում server-side data scrubbing-ը պաշտպանության երկրորդ շերտ է։
import * as Sentry from "@sentry/nextjs";
Sentry.setUser({ id: account.id }); // id only, no email
Sentry.setTag("plan", account.plan); // "free" | "pro" | "enterprise"
try {
await chargeCard(order);
} catch (err) {
Sentry.captureException(err, {
tags: { payment_provider: "stripe" },
contexts: { order: { id: order.id, total: order.total } },
});
throw err;
}
05Alert-ներ, աղմուկ և quota-ներ
Sentry-ն օգտակար է միայն այն դեպքում, եթե մարդիկ վստահում են նրա alert-ներին։ Սկսիր երեք տեսակից՝ նոր issue production-ում, regression (լուծված issue, որը վերադարձել է) և հաճախականության կամ տուժած օգտատերերի կտրուկ աճ։ Դրանք ուղարկիր պատասխանատու թիմի Slack channel՝ ownership կանոններով, որոնք հիմնված են ֆայլերի ճանապարհների կամ URL-ների վրա, և ինչ-որ մեկին page արա միայն մեծ ազդեցությամբ metric alert-ների համար, ինչպես crash-free session-ների անկումը կամ error rate-ը շեմից բարձր։ Աղմուկը ցածր պահիր․ հայտնի browser extension-ների error-ները անտեսիր ignoreErrors-ով և denyUrls-ով, legacy browser-ների և web crawler-ների համար օգտագործիր inbound filter-ներ և archive արա այն issue-ները, որոնք չես շտկելու։ Plan-ները ներառում են error-ների, span-երի, replay-ների և log-երի ամսական quota․ ցիկլի մեջ մեկ bug-ը կարող է այն սպառել մեկ ժամում։ Օգտագործիր spike protection և ըստ key-ի rate limit-ներ, sample արա transaction-ները և վճարովի plan-ներում ծախսի սահման դիր։
Օգտագործեք, երբ
- Ցանկացած production վեբ կամ mobile հավելված, որտեղ ուզում ես error-ների մասին իմանալ, նախքան օգտատերերը կբողոքեն։
- Minify արված կոդով frontend հավելվածներ, որտեղ ընթեռնելի stack trace-երի համար source map-եր են պետք։
- Թիմեր, որոնք հաճախ են deploy անում և ուզում են error-ները կապել release-ների, commit-ների և rollback-ների հետ։
- Mobile հավելվածներ, որոնց պետք են crash report-ներ, crash-free session-ների տոկոս և release health։
Մի՛ օգտագործեք, երբ
- Որպես միակ monitoring․ Sentry-ն չի փոխարինում uptime ստուգումներին, server metric-ներին, backup-ներին կամ log-երի պահպանմանը։
- Տվյալների խիստ residency կամ գաղտնիության կանոններ, որոնց hosted region-ները չեն համապատասխանում, եթե self-host չես անում։
- Երբ հիմնական նպատակը ենթակառուցվածքի խորը metric-ներն են և distributed tracing-ը շատ service-ների միջով․ OpenTelemetry-ն tracing backend-ով ավելի լավ է համապատասխանում։
Այլընտրանքներ
- Self-hosted Sentry
Նույն արտադրանքը քո սերվերներում Docker Compose-ով․ անվճար license, բայց ծանր stack է գործարկելու և upgrade անելու համար։
- GlitchTip
Թեթև open-source error tracker, համատեղելի Sentry SDK-ների հետ․ ավելի քիչ հնարավորություններ, շատ ավելի հեշտ self-host։
- Datadog / New Relic
Լիարժեք observability պլատֆորմներ՝ ներառված error tracking-ով․ ավելի լայն, ավելի թանկ։
- Firebase Crashlytics / Bugsnag
Ուժեղ mobile crash reporting․ Crashlytics-ը անվճար է և տարածված միայն mobile-ով զբաղվող թիմերում։
Լավագույն պրակտիկաներ
- Յուրաքանչյուր event-ի վրա սահմանիր environment և release․ որպես release օգտագործիր Git SHA-ն։
- Source map-երը (և dSYM-ները կամ mapping ֆայլերը) upload արա CI-ում և մի հրապարակիր դրանք։
- Ուղարկիր անանուն user ID, ոչ թե անձնական տվյալներ, և զգայուն դաշտերը մաքրիր beforeSend-ով։
- Production-ում sample արա performance trace-երը (հաճախ 5–20%), իսկ error-ների sampling-ը պահիր 100%։
- Սահմանիր ownership կանոններ, որպեսզի յուրաքանչյուր issue հասնի որևէ թիմի, և ամեն շաբաթ վերանայիր նոր issue-ները։
- Ֆիլտրիր հայտնի աղմուկը (browser extension-ներ, bot-եր, ընդհատված request-ներ), որպեսզի իրական error-ները աչքի ընկնեն։
- Միացրու spike protection և rate limit-ներ՝ quota-ն անվերահսկելի ցիկլերից պաշտպանելու համար։
Տարածված սխալներ
- Թողարկել առանց source map-երի և ստանալ stack trace-եր, որոնք ցույց են տալիս minify արված bundle-ի 1-ին տողը։
- Production-ում tracesSampleRate-ը թողնել 1.0 և quota-ն սպառել օրերի ընթացքում։
- Error-ները որսալ և «կուլ տալ» առանց captureException-ի, ուստի Sentry-ն դրանք երբեք չի տեսնում։
- Event-ների հետ ուղարկել email-ներ, token-ներ կամ ամբողջական request body-ներ՝ ստեղծելով գաղտնիության խնդիր։
- Յուրաքանչյուր event-ի համար alert ուղարկել ընդհանուր channel, մինչև բոլորը mute անեն այն։
Խորը վերլուծություն
06Sampling, quota-ներ և ծախսերի վերահսկում
Sentry-ն գանձում է ըստ ծավալի յուրաքանչյուր տվյալների կատեգորիայի համար՝ error-ներ, span-եր, replay-ներ, attachment-ներ, log-եր և monitor-ներ, յուրաքանչյուրը՝ ամսական quota-ով և ըստ ցանկության pay-as-you-go budget-ով։ Վերահսկումը տեղի է ունենում երեք շերտում։ SDK-ում՝ tracesSampler-ը (function) թույլ է տալիս sample անել ըստ route-ի, օրինակ՝ 100% checkout-ի համար, 1% health check-երի համար, 0 bot-երի համար, replaysOnErrorSampleRate-ը replay-ները պահում է միայն այնտեղ, որտեղ դրանք օգնում են, beforeSend-ը և beforeSendTransaction-ը դեն են նետում event-ները, որոնց մասին գիտես, որ աղմուկ են։ Project-ի մակարդակում՝ inbound filter-ներ, ըստ DSN key-ի rate limit-ներ և spike protection, որը ժամանակավորապես դեն է նետում event-ները, երբ ծավալը կտրուկ գերազանցում է նորմալը։ Organization-ի մակարդակում՝ ծախսի սահմաններ և alert-ներ։ Sampling-ի որոշումները trace-ի հետ տարածվում են sentry-trace և baggage header-ներով, ուստի frontend-ն ու backend-ը միասին են պահում կամ դեն նետում նույն trace-ը։
Sentry.init({
dsn: process.env.SENTRY_DSN,
tracesSampler: ({ name, inheritOrSampleWith }) => {
if (name.includes("/healthz")) return 0; // never trace health checks
if (name.includes("/checkout")) return 1.0; // always trace checkout
return inheritOrSampleWith(0.05); // follow parent, else 5%
},
beforeSend(event) {
if (event.request?.headers) delete event.request.headers["authorization"];
return event;
},
});
07Distributed tracing frontend-ի և backend-ի միջև
Երբ browser էջը կանչում է քո API-ն, Sentry-ի browser SDK-ն sentry-trace և baggage header-ներ է ավելացնում tracePropagationTargets-ին համապատասխանող ելքային request-ներին։ Backend SDK-ն կարդում է դրանք և շարունակում նույն trace-ը, ուստի մեկ trace-ը ցույց է տալիս էջի բեռնումը, fetch-ը, API handler-ը և SQL query-ները։ tracePropagationTargets-ը սահմանիր միայն քո սեփական API origin-ներով․ այս header-ները երրորդ կողմի domain-ներին ուղարկելը կարող է կոտրել նրանց CORS preflight-ը։ Քո API-ն նույնպես պետք է թույլատրի այս header-ները CORS-ում։ Server-rendered էջերի համար սերվերը ներդնում է trace meta tag-եր, որպեսզի browser-ը շարունակի սերվերի trace-ը։ Քանի որ JavaScript SDK-ն կառուցված է OpenTelemetry-ի վրա, այն հասկանում է նաև W3C traceparent-ը, և կարող ես այլ service-ներից OTel տվյալներ ուղարկել Sentry նրա OTLP endpoint-ով, ինչը Sentry-ն դարձնում է ավելի լայն OTel կառուցվածքի մաս, ոչ թե առանձին կղզի։
08Self-hosting, թե՞ SaaS
Sentry-ի կոդը հասանելի է Functional Source License-ով, և self-hosted distribution-ը աշխատում է Docker Compose-ով։ Այն փոքր չէ՝ Kafka, ClickHouse, PostgreSQL, Redis, Snuba, Relay, Symbolicator և բազմաթիվ worker-ներ, խորհուրդ տրվող նվազագույնը՝ մոտ 4 CPU core, 16 GB RAM գումարած swap և արագ սկավառակներ։ Պետք է upgrade անես կոնկրետ տարբերակներով՝ հերթականությամբ, backup անես Postgres-ը և ClickHouse-ը և monitor անես հենց stack-ը։ Որոշ նոր հնարավորություններ, ինչպես AI debugging agent-ը, միայն SaaS-ում են։ Self-hosting-ը իմաստ ունի տվյալների խիստ residency-ի կամ air-gapped միջավայրերի դեպքում, կամ այնպիսի ծավալի դեպքում, երբ license-ի խնայողությունը գերազանցում է ինժեների ժամանակը։ Թիմերի մեծ մասի համար SaaS-ը՝ EU կամ US data region-ով և server-side scrubbing-ով, ընդհանուր առմամբ ավելի էժան է։ Ավելի թեթև միջին տարբերակ է GlitchTip-ը, որն ընդունում է Sentry SDK-ի տվյալները շատ ավելի քիչ բաղադրիչներով։
Իրական իրավիճակներ
Error-ները գալիս են minify արված stack trace-երով
Խնդիր
Sentry-ն տեղադրված է Vite React հավելվածում, բայց յուրաքանչյուր stack trace ցույց է տալիս index-3f9a.js տող 1 և minify արված անուններ։
Ինչպես լուծել
Source map-երը upload կամ համապատասխանեցված չեն։ Vite-ում միացրու build.sourcemap (hidden source map-երը նորմալ են), ավելացրու @sentry/vite-plugin org-ով, project-ով և CI secret-ներից SENTRY_AUTH_TOKEN-ով, և թող այն ներդնի Debug ID-ներ ու upload անի, ապա output-ից ջնջիր .map ֆայլերը։ Համոզվիր, որ Sentry.init-ի release-ը համընկնում է plugin-ի ստեղծած release-ի հետ։ Deploy արա, test error առաջացրու և ստուգիր event-ի processing errors բաժինը, որը բացատրում է բացակայող կամ չհամապատասխանող map-երը։ Եթե դեռ չի ստացվում, օգտագործիր npx @sentry/cli sourcemaps explain event ID-ով։ Քայլը ավելացրու CI-ին, որպեսզի յուրաքանչյուր build ավտոմատ upload անի map-երը։
Ցիկլի մեջ bug-ը սպառում է ամսական quota-ն
Խնդիր
Նոր release-ը նույն error-ը նետեց հազարավոր անգամներ յուրաքանչյուր օգտատիրոջ համար րոպեում։ Հաջորդ առավոտ ամսվա error quota-ն սպառված էր, և այլ error-ներ դեն էին նետվում։
Ինչպես լուծել
Նախ rollback կամ hotfix արա bug-ը։ Sentry-ում համոզվիր, որ spike protection-ը միացված է, և տուժած project-ի DSN key-ի վրա rate limit դիր, օրինակ՝ րոպեում մի քանի հազար event։ SDK-ում շտկիր կոդի ճանապարհը, որը ցիկլով նորից նետում է error-ը, և դիտարկիր error-ների deduplication-ը client-ի կողմում․ Dedupe integration-ը դեն է նետում իրար հաջորդող նույնական event-ները։ Սահմանիր pay-as-you-go budget սահմանով, որպեսզի ապագա պիկը կլանվի առանց անսահմանափակ ծախսի։ Ավելացրու metric alert event-ների ծավալի վրա ըստ project-ի, որպեսզի աննորմալ պիկը րոպեների ընթացքում տեղեկացնի թիմին, այլ ոչ թե բացահայտվի ամսվա վերջում։
Mobile crash-ը կապել backend-ի խնդրի հետ
Խնդիր
React Native հավելվածը crash-եր է ցույց տալիս պատվերի էկրանին, բայց backend թիմն ասում է, որ իրենց API-ն կարգին է։
Ինչպես լուծել
Միացրու tracing-ը և՛ React Native SDK-ում, և՛ backend SDK-ում, և tracePropagationTargets-ը սահմանիր API-ի domain-ով, որպեսզի request-ները կրեն sentry-trace և baggage header-ներ։ Mobile build pipeline-ում upload արա JavaScript source map-երը և native debug ֆայլերը (dSYM-ներ, ProGuard mapping-ներ), որպեսզի crash-երը ընթեռնելի լինեն։ Հիմա բացիր crash-ը և հետևիր նրա trace-ին․ կարող ես տեսնել, որ API-ն վերադարձնում է 200՝ անսպասելի null դաշտով, որը հավելվածը չի մշակում։ Ավելացրու tag հավելվածի տարբերակի և API-ի տարբերակի համար։ Շտկումը հաճախ երկու տեղում է՝ պաշտպանողական parsing հավելվածում և contract test API-ի վրա։
Արագ ուղեցույց
- Framework-ի կարգավորում wizard-ով
npx @sentry/wizard@latest -i nextjs- Հայտնել մշակված error
Sentry.captureException(err)- Ուղարկել message event
Sentry.captureMessage("Payment webhook retried", "warning")- Կցել անանուն օգտատեր
Sentry.setUser({ id: account.id })- Ավելացնել որոնելի tag
Sentry.setTag("plan", "pro")- Upload անել source map-երը CI-ից
npx @sentry/cli sourcemaps inject ./dist && npx @sentry/cli sourcemaps upload --release "$VERSION" ./dist- Debug՝ ինչու source map-ը չաշխատեց
npx @sentry/cli sourcemaps explain <event-id>- Անտեսել browser extension-ների աղմուկը
denyUrls: [/extensions\//i, /^chrome:\/\//i]- Laravel-ի տեղադրում
composer require sentry/sentry-laravel && php artisan sentry:publish --dsn=<your-dsn>
Հարցեր և պատասխաններ
Q1Ի՞նչ է DSN-ը, և անվտա՞նգ է այն բացել browser-ում։
DSN-ը (Data Source Name) URL է, որը պարունակում է project-ի public key-ը և ID-ն և SDK-ին ասում է, թե ուր ուղարկել event-ները։ Այն թույլ է տալիս միայն event-ներ ուղարկել այդ project, ոչ թե տվյալներ կարդալ կամ կարգավորումներ փոխել, ուստի նախատեսված է browser և mobile հավելվածներում ներդրվելու համար։ Իրական secret-ը auth token-ն է, որն օգտագործում են sentry-cli-ը և build plugin-ները release-ներ ստեղծելու և source map-եր upload անելու համար․ այն պետք է մնա CI secret-ներում։ Բացված DSN-ի ռիսկը spam-ն է․ ինչ-որ մեկը կարող է կեղծ event-ներ ուղարկել և quota սպառել։ Նվազեցրու այն թույլատրված domain-ներով, ըստ key-ի rate limit-ներով և inbound filter-ներով։
Q2Ինչո՞ւ են source map-երը կարևոր, և ինչպե՞ս դրանք private պահել։
Production JavaScript-ը minify և bundle է արված, ուստի հում stack trace-ը ցույց է տալիս մի բան, ինչպես main.4f2a.js տող 1, սյունակ 48211, ինչն անօգուտ է։ Source map-երը այդ դիրքերը հետ են map անում սկզբնական ֆայլին, տողին և function-ին։ Sentry-ն դրանք օգտագործում է իր սերվերներում՝ ընթեռնելի stack trace-եր շրջակա կոդով ցույց տալու համար։ Source-դ private պահելու համար map-երը upload արա Sentry build-ի ընթացքում և մի deploy արա public սերվեր․ bundler plugin-ները կարող են դրանք ջնջել upload-ից հետո, կամ կարող ես .map ֆայլերը բացառել deploy-ից։ Յուրաքանչյուր ֆայլի մեջ ներդրված Debug ID-ները թույլ են տալիս Sentry-ին հուսալիորեն համապատասխանեցնել map-երը՝ առանց public URL-ների վրա հենվելու։
Q3Ինչպե՞ս է Sentry-ն error-ները խմբավորում issue-ների մեջ։
Յուրաքանչյուր event ստանում է fingerprint։ Default-ով այն հիմնված է stack trace-ի վրա, հիմնականում in-app frame-երի, այսինքն՝ քո կոդի, ոչ թե library-ների․ եթե stack trace չկա, այն հիմնվում է exception-ի տեսակի և հաղորդագրության վրա։ Նույն fingerprint-ով event-ները պատկանում են նույն issue-ին։ Երբեմն default-ը սխալ է․ տարբեր պատճառներից եկող մեկ ընդհանուր error-ը միավորվում է մեկ issue-ի մեջ, կամ դինամիկ հաղորդագրությունը հազարավոր issue-ներ է ստեղծում։ Դա շտկում ես project settings-ում fingerprint rule-երով և stack trace rule-երով կամ SDK-ում custom fingerprint սահմանելով, օրինակ՝ մեկ API client-ի բոլոր timeout-ները խմբավորելով ըստ endpoint-ի։
Q4Ո՞րն է տարբերությունը Sentry-ի error tracking-ի և tracing-ի միջև։
Error tracking-ը որսում է exception-ները և crash-երը stack trace-երով և կոնտեքստով, խմբավորում և alert է անում։ Tracing-ը (performance monitoring) span-եր է գրանցում էջերի բեռնման, navigation-ի, API request-ների և բազայի query-ների համար, ուստի տեսնում ես, թե որքան են տևում բաները և ուր է գնում ժամանակը, նույնիսկ երբ ոչինչ չի ձախողվում։ Sentry-ն կապում է դրանք․ error-ը կրում է trace ID-ն, ուստի կարող ես բացել ձախողված request-ը և տեսնել դրանից առաջ եղած դանդաղ query-ն։ Error-ները սովորաբար պահվում են 100%-ով, իսկ trace-երը sample են արվում, որովհետև դրանց ծավալը շատ ավելի մեծ է։ 8-րդ տարբերակից ի վեր Sentry-ի JavaScript SDK-ն ներսից օգտագործում է OpenTelemetry, ուստի կարող է աշխատել այլ OTel instrumentation-ի կողքին։
Q5Client-ը հարցնում է․ ինչո՞ւ վճարել Sentry-ի համար, եթե server log-եր ունենք։
Log-երը ասում են, թե ինչ է արել սերվերը, իսկ Sentry-ն ասում է, թե որ խնդիրներին են իրականում բախվում օգտատերերը և որքան հաճախ։ Frontend և mobile error-ների մեծ մասը ընդհանրապես չի հասնում server log-երին․ browser-ում կամ հավելվածում crash-ը տեղի է ունենում օգտատիրոջ սարքում։ Sentry-ն որսում է դրանք, հազարավոր event-ներ խմբավորում issue-ների կարճ ցանկի մեջ, ցույց է տալիս սկզբնական կոդի ճշգրիտ տողը, այն բերած release-ն ու commit-ը, քանի օգտատեր է տուժում, և replay, թե ինչ էր անում օգտատերը։ Այն alert է անում թիմին, երբ deploy-ից հետո նոր խնդիր է հայտնվում։ Սովորաբար դա bug-ը օրերով գուշակելուց վերածում է մեկ ժամվա շտկման, ինչը plan-ի արժեքը արագ է հետ բերում։
Սենիոր մակարդակի հարցեր
S1Ինչպե՞ս Sentry-ն օգտակար դարձնել մեծ կազմակերպության համար՝ աղմկոտ inbox-ի փոխարեն։
Առաջին տեղում կառուցվածքն ու ownership-ն են։ Ստեղծիր project-ներ յուրաքանչյուր deploy արվող հավելվածի համար, environment-ները (production, staging) և release-ները օգտագործիր հետևողականորեն և ավելացրու ownership կանոններ կամ code owners integration, որպեսզի յուրաքանչյուր issue ավտոմատ նշանակվի որևէ թիմի։ Alert արա կարևորի վրա՝ նոր issue-ներ production-ում, regression-ներ և metric alert-ներ error rate-ի կամ crash-free session-ների վրա՝ կապված SLO-ների հետ, ուղարկված պատասխանատու թիմի channel և page անելով միայն օգտատերերի վրա ազդող շեմերի դեպքում։ Աղմուկը նվազեցրու inbound filter-ներով, ignore rule-երով և հայտնի խմբերի համար fingerprint rule-երով։ Յուրաքանչյուր թիմում անցկացրու շաբաթական triage պարզ կանոնով՝ resolve, assign կամ archive՝ պատճառով։ Crash-free rate-ին ըստ release-ի հետևիր որպես release gate։ Trade-off-ը սկզբնական կոնֆիգուրացիայի աշխատանքն է, որը հետ է վճարվում alert-ների նկատմամբ վստահությամբ։
S2Sentry, թե՞ OpenTelemetry-ի վրա հիմնված stack․ մրցակիցնե՞ր են։
Դրանք համընկնում են, բայց տարբեր բաների վրա են կենտրոնացած։ OpenTelemetry-ն instrumentation ստանդարտ և pipeline է․ այն տալիս է տեղափոխելի trace-եր, metric-ներ և log-եր, բայց ոչ backend, ոչ issue grouping, ոչ workflow։ Sentry-ն developer workflow-ների շուրջ կառուցված արտադրանք է՝ grouping, regression-ներ, release health, suspect commit-ներ, replay-ներ և source map-երի մշակում, գումարած tracing։ Քանի որ նրա JavaScript SDK-ն ներսից աշխատում է OpenTelemetry-ի վրա, և Sentry-ն ընդունում է OTLP, դրանք լավ են համատեղվում․ OTel instrumentation backend service-ների համար՝ Collector-ով, որը trace-երը export է անում քո tracing backend, և Sentry frontend և mobile error-ների, crash-երի և replay-ների համար՝ ընդհանուր trace կոնտեքստով։ Ընտրիր ըստ հարցերի․ «որ կոդն է կոտրված օգտատերերի համար»-ը Sentry-ի համար է, «ուր է գնում latency-ն 30 service-ների միջով»-ը՝ OTel tracing backend-ի։
S3Ինչպե՞ս ես կառավարում գաղտնիությունը և GDPR-ը Sentry-ի և Session Replay-ի հետ։
Հավաքիր նվազագույնը։ Email-ի կամ անվան փոխարեն օգտագործիր ներքին user ID, PII-ի default հավաքումը անջատված պահիր և beforeSend-ում հեռացրու header-ները, cookie-ները, query string-երը և request body-ները, որոնք կարող են անձնական տվյալներ պարունակել։ Որպես անվտանգության ցանց միացրու server-side data scrubbing-ը և ընդլայնված scrubbing կանոնները։ Session Replay-ի համար պահիր default-ները, որոնք դիմակավորում են ամբողջ տեքստը և block անում մեդիան, և unmask արա միայն կոնկրետ անվտանգ տարրեր․ երբեք մի ձայնագրիր վճարման կամ բժշկական form-եր։ Ընտրիր EU data region-ը, եթե օգտատերերդ Եվրոպայում են, ստորագրիր data processing agreement-ը և retention-ը դիր այնքան կարճ, որքան օգտակար է։ Գաղտնիության քաղաքականության մեջ Sentry-ն փաստաթղթավորիր որպես processor։ Վերջում հարգիր համաձայնությունը․ replay-ը initialize արա միայն այն բանից հետո, երբ օգտատերը համաձայնի, եթե քո իրավական հիմքը դա պահանջում է։
Բառարան
- DSN
- Project-ի URL-ը և public key-ը, որը SDK-ին ասում է, թե ուր ուղարկել event-ները․ անվտանգ է ներդնել client-ներում։
- Event
- Մեկ որսված error, հաղորդագրություն կամ transaction՝ stack trace-ով, կոնտեքստով և breadcrumb-երով։
- Issue
- Մեկ fingerprint կիսող նման event-ների խումբ, որը թիմը triage և resolve է անում։
- Fingerprint
- Արժեքը, որով Sentry-ն որոշում է, թե որ event-ներն են պատկանում նույն issue-ին․ կարելի է կարգավորել։
- Breadcrumbs
- Error-ից առաջ գործողությունների ժամանակագրություն՝ click-եր, navigation, network կանչեր և console հաղորդագրություններ։
- Release
- Event-ներին կցված տարբերակի նույնացուցիչ, որը error-ները կապում է deploy-երի և commit-ների հետ։
- Debug ID
- Եզակի ID, որը ներդրվում է bundle-ների և source map-երի մեջ, որպեսզի Sentry-ն կարողանա դրանք հուսալիորեն համապատասխանեցնել։
- Session Replay
- Գաղտնիության համար դիմակավորված, վիդեոյի նման վերակառուցում այն բանի, թե ինչ էր անում օգտատերը error-ից առաջ։
- Spike protection
- Sentry-ի հնարավորություն, որը ժամանակավորապես դեն է նետում event-ները, երբ ծավալը հանկարծ շատ է գերազանցում նորմալը։
Շարունակեք սովորել
Պրոդուկտի գաղափար ունե՞ք։Եկեք ստեղծենք այն։
Պատմեք ձեր գաղափարի, պրոդուկտի կամ թիմի մասին։ Սովորաբար պատասխանում եմ մեկ աշխատանքային օրվա ընթացքում։