在 Sentry的前端異常監控方案中以前咱們說過,Sentry的全局異常獲取方式有2種,window.onerror以及unhandledrejection。javascript
以unhandledrejection爲例 globalhandlers.ts中前端
addInstrumentationHandler({ // eslint-disable-next-line @typescript-eslint/no-explicit-any callback: (e: any) => { let error = e; // dig the object of the rejection out of known event types try { // PromiseRejectionEvents store the object of the rejection under 'reason' // see https://developer.mozilla.org/en-US/docs/Web/API/PromiseRejectionEvent if ('reason' in e) { error = e.reason; } // something, somewhere, (likely a browser extension) effectively casts PromiseRejectionEvents // to CustomEvents, moving the `promise` and `reason` attributes of the PRE into // the CustomEvent's `detail` attribute, since they're not part of CustomEvent's spec // see https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent and // https://github.com/getsentry/sentry-javascript/issues/2380 else if ('detail' in e && 'reason' in e.detail) { error = e.detail.reason; } } catch (_oO) { // no-empty } const currentHub = getCurrentHub(); const hasIntegration = currentHub.getIntegration(GlobalHandlers); const isFailedOwnDelivery = error && error.__sentry_own_request__ === true; // addEventListener的事件中直接throw Error的時候,shouldIgnoreOnError會爲true.即不會上報 // 緣由是在instrumentDOM方法中,用globalDOMEventHandler方法對監聽事件包了一層,使得ignoreOnError>0 if (!hasIntegration || shouldIgnoreOnError() || isFailedOwnDelivery) { return true; } const client = currentHub.getClient(); const event = isPrimitive(error) ? this._eventFromRejectionWithPrimitive(error) : eventFromUnknownInput(error, undefined, { attachStacktrace: client && client.getOptions().attachStacktrace, rejection: true, }); event.level = Severity.Error; addExceptionMechanism(event, { handled: false, type: 'onunhandledrejection', }); currentHub.captureEvent(event, { originalException: error, }); return; }, type: 'unhandledrejection', });
總體流程分爲如下幾個模塊講解java
try { // PromiseRejectionEvents store the object of the rejection under 'reason' // see https://developer.mozilla.org/en-US/docs/Web/API/PromiseRejectionEvent if ('reason' in e) { error = e.reason; } // something, somewhere, (likely a browser extension) effectively casts PromiseRejectionEvents // to CustomEvents, moving the `promise` and `reason` attributes of the PRE into // the CustomEvent's `detail` attribute, since they're not part of CustomEvent's spec // see https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent and // https://github.com/getsentry/sentry-javascript/issues/2380 else if ('detail' in e && 'reason' in e.detail) { error = e.detail.reason; } } catch (_oO) { // no-empty }
這一塊都是在作兼容性處理,適配不一樣瀏覽器中的錯誤類型git
const currentHub = getCurrentHub(); const hasIntegration = currentHub.getIntegration(GlobalHandlers); const isFailedOwnDelivery = error && error.__sentry_own_request__ === true; if (!hasIntegration || shouldIgnoreOnError() || isFailedOwnDelivery) { return true; }
這裏的hasIntergration是在判斷是否安裝了對應的全局監聽函數的插件(初始化的時候就會默認加載)
shouldIgnoreOnError : addEventListener的事件中直接throw Error的時候,shouldIgnoreOnError會爲true.即不會上報
緣由是在instrumentDOM方法中,用globalDOMEventHandler方法對監聽事件包了一層,使得ignoreOnError>0
isFailedOwnDelivery即判斷是否爲Sentry自身的請求錯誤,如果,則不上報。github
const client = currentHub.getClient(); const event = isPrimitive(error) ? this._eventFromRejectionWithPrimitive(error) : eventFromUnknownInput(error, undefined, { attachStacktrace: client && client.getOptions().attachStacktrace, rejection: true, });
export function isPrimitive(wat: any): wat is Primitive { return wat === null || (typeof wat !== 'object' && typeof wat !== 'function'); }
isPrimitive(error)即在判斷error是否爲原始數據類型
若爲原始數據類型,則處理比較簡單chrome
private _eventFromRejectionWithPrimitive(reason: Primitive): Event { return { exception: { values: [ { type: 'UnhandledRejection', // String() is needed because the Primitive type includes symbols (which can't be automatically stringified) value: `Non-Error promise rejection captured with value: ${String(reason)}`, }, ], }, }; }
若爲引用數據類型,核心處理函數在tracekit.ts爲typescript
stack = computeStackTraceFromStacktraceProp(ex); if (stack) { return popFrames(stack, popSize); }
具體就在computeStackTraceFromStacktraceProp,popFrames這2個函數中。segmentfault
function computeStackTraceFromStackProp(ex: any): StackTrace | null { if (!ex || !ex.stack) { return null; } const stack = []; const lines = ex.stack.split('\n'); let isEval; let submatch; let parts; let element; for (let i = 0; i < lines.length; ++i) { if ((parts = chrome.exec(lines[i]))) { const isNative = parts[2] && parts[2].indexOf('native') === 0; // start of line isEval = parts[2] && parts[2].indexOf('eval') === 0; // start of line if (isEval && (submatch = chromeEval.exec(parts[2]))) { // throw out eval line/column and use top-most line/column number parts[2] = submatch[1]; // url parts[3] = submatch[2]; // line parts[4] = submatch[3]; // column } element = { // working with the regexp above is super painful. it is quite a hack, but just stripping the `address at ` // prefix here seems like the quickest solution for now. url: parts[2] && parts[2].indexOf('address at ') === 0 ? parts[2].substr('address at '.length) : parts[2], func: parts[1] || UNKNOWN_FUNCTION, args: isNative ? [parts[2]] : [], line: parts[3] ? +parts[3] : null, column: parts[4] ? +parts[4] : null, }; } else if ((parts = winjs.exec(lines[i]))) { element = { url: parts[2], func: parts[1] || UNKNOWN_FUNCTION, args: [], line: +parts[3], column: parts[4] ? +parts[4] : null, }; } else if ((parts = gecko.exec(lines[i]))) { isEval = parts[3] && parts[3].indexOf(' > eval') > -1; if (isEval && (submatch = geckoEval.exec(parts[3]))) { // throw out eval line/column and use top-most line number parts[1] = parts[1] || `eval`; parts[3] = submatch[1]; parts[4] = submatch[2]; parts[5] = ''; // no column when eval } else if (i === 0 && !parts[5] && ex.columnNumber !== void 0) { // FireFox uses this awesome columnNumber property for its top frame // Also note, Firefox's column number is 0-based and everything else expects 1-based, // so adding 1 // NOTE: this hack doesn't work if top-most frame is eval stack[0].column = (ex.columnNumber as number) + 1; } element = { url: parts[3], func: parts[1] || UNKNOWN_FUNCTION, args: parts[2] ? parts[2].split(',') : [], line: parts[4] ? +parts[4] : null, column: parts[5] ? +parts[5] : null, }; } else { continue; } if (!element.func && element.line) { element.func = UNKNOWN_FUNCTION; } stack.push(element); } if (!stack.length) { return null; } return { message: extractMessage(ex), name: ex.name, stack, }; }
能夠看出,核心流程其實就是在對不一樣的瀏覽器作兼容處理,以及將數據組合成堆棧的形式promise
將異常數據進行捕獲以及處理以後,就是上報流程了。詳情能夠參看上一篇文檔 Sentry的異常數據上報機制瀏覽器
currentHub.captureEvent(event, { originalException: error, });
在大體瞭解到了整個異常數據處理流程後,發現重點是在對於不一樣瀏覽器的兼容性處理上,整個鏈路比較清晰,中間不少繁瑣的處理細節也都沒有太多的去關注,畢竟時間和精力相對有限,想的是在對Sentry的總體脈絡有了必定了解以後,對本身作監控能有不少啓發,固然這也是研究Sentry源碼的初衷。