Bài này nói về monitoring frontend ở góc nhìn senior: bạn biết gì về production sau khi đã ship. Người phỏng vấn không hỏi bạn dán Sentry.init. Họ muốn sampling, PII, release, Vue bắt được gì, LCP/INP/CLS (không phải FID), và bạn có page một người hay không.

Đọc 19.1–19.2 trước (Sentry như một sản phẩm, rồi tầng lỗi Vue). 19.3 là RUM so với lab. 19.4–19.5 là log và pager. 19.6 là playbook spike flag. Vue 3 / Nuxt trước; ý telemetry không phụ thuộc framework. Khác Q&A observability (chuyện nói thành lời): ở đây bạn nêu rõ cơ chế.

Tóm tắt: Sentry là một sản phẩm: release bằng git SHA, source map hidden upload trên CI, PII được scrub trong beforeSend, sampling để inbox là regression, không phải firehose #frontend và không phải dán Sentry.init từ docs.

Vì sao quan trọng: “Dùng Sentry trên production thế nào?” Một issue 50k event chẳng ai quan tâm; stack hiện chunk-7a2.js:1:20483. Họ muốn sampling, PII, release, và ownership. Stack không đọc được là map/release lệch, không phải “Vue minify quá mạnh”. Khác Q&A observability: ở đây là cơ chế.

1. Cách hoạt động: Upload map hidden đúng SHA đó (build-tools 12.1). Gán release, environment, dist. Tag feature flags. Bỏ 401 đã handle trong beforeSend. Sample volume lặp; giữ uniqueness cho issue mới. Trace 0.1–

   • 0.2. Session Replay thấp trên session khỏe; che text/media.
2. Route issue tới codeowner (checkout → checkout). Inbox là regression trên release này, issue mới, spike, không phải ResizeObserver ba năm từ extension. Đừng captureException mọi console.error hoặc $fetch 404 bị reject.
3. Gắn issue với PR: release → git SHA → digest GitOps → PR. Tăng tracesSampleRate chỉ khi đang săn incident đã biết, rồi hạ lại.

Sentry.init({
  app,
  dsn: dsnFromRuntimeConfig, // không phải secret VITE_ trong JS
  release: import.meta.env.VITE_COMMIT_SHA, // phải khớp digest GitOps
  environment: "production",
  tracesSampleRate: 0.15,
  replaysOnErrorSampleRate: 1,
  beforeSend(event) {
    if (event.tags?.http_status === "401") return null
    return scrubPii(event) // bỏ email, token, payload đơn hàng
  },
})

Điều gì xảy ra: 401 không bao giờ mở issue. Email không vào Sentry. Stack đọc được chỉ khi CI đã upload map hidden đúng SHA này. Replay lúc lỗi bật; replay session khỏe giữ thấp.

Lỗi hay gặp

• Không release. Triệu chứng: stack folklore. Nguyên nhân: Sentry.init thiếu SHA. Sửa: CI inject digest.
• Map sai commit. Triệu chứng: số dòng trỏ vào comment. Nguyên nhân: upload sau lần rebuild. Sửa: cùng SHA với image.
• Capture mọi 404. Triệu chứng: 50k event, không bug checkout. Nguyên nhân: $fetch throw. Sửa: beforeSend / ignore list.
• Email trong extra. Triệu chứng: incident PII. Nguyên nhân: JSON.stringify(user) trong breadcrumb. Sửa: scrub; log id.

Tóm tắt: Vue không có boundary bọc hết kiểu React. onErrorCaptured bắt render và lifecycle đồng bộ. Hầu hết bug production là async (click, $fetch, watch). Bạn cần ba tầng: app.config.errorHandler / Nuxt vue:error, unhandledrejection + window.error, và try/catch tại chỗ. Cô lập widget bằng <NuxtErrorBoundary> hoặc handler captured local.

Vì sao quan trọng: “Có error boundary không?” Nếu bạn dừng ở onErrorCaptured, họ hỏi nó miss gì: submitOrder(), click handler, và chart làm trắng shell. Khác Q&A React error-boundary-limits: ở đây là API Vue/Nuxt.

1. Cách hoạt động: onErrorCaptured ở parent chạy với throw đồng bộ ở descendant lúc render/lifecycle. return false dừng lan truyền. Luôn báo Sentry trước. return false không báo là fail im lặng.
2. app.config.errorHandler (hook Nuxt vue:error) là lưới cả process. Ghép unhandledrejection và window.error cho promise và throw ngoài Vue. Lỗi async setup / Suspense thường vào đây, không phải onErrorCaptured.
3. Cô lập widget: boundary cho chart kèm fallback. Dialog Teleport có thể thoát cây bạn tưởng đã bọc. Đặt boundary ở host, không chỉ opener. Chrome checkout phải sống sót khi một tile throw.

app.config.errorHandler = (err, _instance, info) => {
  Sentry.captureException(err, { extra: { info } })
}
window.addEventListener("unhandledrejection", (e) => {
  Sentry.captureException(e.reason)
})
window.addEventListener("error", (e) => {
  Sentry.captureException(e.error ?? e.message)
})
// widget: onErrorCaptured + return false sau Sentry; Nuxt: <NuxtErrorBoundary>

Điều gì xảy ra: Throw lúc render trong chart có thể được bắt local. Click mà await $fetch reject thì không bao giờ đụng onErrorCaptured. unhandledrejection hoặc try/catch của bạn mới bắt. Shell còn nếu chart return false sau khi báo.

Lỗi hay gặp

• return false mà không Sentry. Triệu chứng: widget trắng im lặng. Nguyên nhân: “mình đã handle”. Sửa: báo rồi mới dừng.
• Chỉ một boundary cấp app. Triệu chứng: checkout chết cùng chart. Nguyên nhân: không cô lập widget. Sửa: <NuxtErrorBoundary> quanh tile.
• Nhận Vue chạy như React. Triệu chứng: trượt follow-up. Nguyên nhân: folklore API. Sửa: nêu rõ ba tầng.
• Teleport ngoài cây captured. Triệu chứng: dialog throw giết shell. Sửa: boundary trên host đích.

Tóm tắt: Theo dõi LCP (Largest Contentful Paint ≤ 2.5 s), INP (Interaction to Next Paint ≤ 200 ms; đã thay FID), và CLS (Cumulative Layout Shift ≤ 0.1). RUM (Real User Monitoring) là nguồn sự thật. Lab (Lighthouse CI) là ngân sách và cổng regression. Chúng sẽ lệch; bạn cần cả hai.

Vì sao quan trọng: “Theo dõi Core Web Vitals thế nào?” Nếu mở bằng FID bạn đã lỗi thời. Họ muốn ngân sách theo template, p75 theo route kể cả soft navigation, và bạn làm gì khi INP tệ, không phải Lighthouse 100 hão. Khác performance 9.2.5 (topic vitals): ở đây là cách bạn báo chúng.

1. Cách hoạt động: web-vitals onLCP / onINP / onCLS kèm tên route và release. Báo p75 cắt theo template (/ vs /app), thiết bị, và flag. Trung bình homepage sẽ giấu checkout.
2. Lab: Lighthouse CI như ngân sách byte và TBT, không phải điểm 100. TBT mang tính lab; INP là metric field. Soft navigation trong SPA vẫn cần dimension route, không thì bạn chỉ thấy lần load đầu.
3. INP tệ → long task > 50 ms, handler input, filter 50k hàng không virtualize. CLS → media chưa size, nhét banner, skeleton không giữ chỗ. LCP → ảnh hero, TTFB, font. Tag third-party load idle hoặc bị kill (Q&A third-party).

import { onINP, onLCP, onCLS } from "web-vitals"
function report(m: { name: string; value: number; id: string }) {
  sendToRum({ ...m, route: route.name, release: SHA, flag: flags.checkout_v2 })
}
onINP(report) // field, không phải FID
onLCP(report)
onCLS(report)
// alert p75 so tuần trước trên /checkout, không phải trung bình cả site

Điều gì xảy ra: Mỗi vital mang route, SHA, và flag để bạn cắt. INP là metric tương tác bạn alert. Trung bình cả site sẽ giấu checkout 400 ms.

Lỗi hay gặp

• Mở đầu bằng FID. Triệu chứng: bạn lỗi thời. Nguyên nhân: thói quen 2020. Cách xử lý: INP.
• Chỉ lấy trung bình homepage. Triệu chứng: checkout cháy. Nguyên nhân: không có dimension route. Cách xử lý: cắt theo route.
• Skeleton không giữ chỗ. Triệu chứng: bạn mua CLS để giấu loading. Cách xử lý: layout khớp.
• Chặn merge bằng Lighthouse 100. Triệu chứng: CI flaky. Nguyên nhân: nhiễu lab. Cách xử lý: ngân sách byte + TBT.

Tóm tắt: Không console.log trên prod. Client gửi event có cấu trúc: level, name, x-request-id từ BFF, một code lỗi ổn định, flag, release. Không bao giờ access token hay payload đơn hàng. DEBUG tắt mặc định.

Vì sao quan trọng: “Bạn log gì trên client?” Họ muốn rule PII và correlation id để FE + API + trace khâu được với nhau, không phải log sót trong store Pinia. Một 500 mà thành ba ticket là fail correlation. Khác 19.1 (issue Sentry): ở đây là shape của event.

1. Cách hoạt động: DEBUG là local hoặc ?debug= và tắt trên prod. INFO rất hiếm (vào checkout, id lần thanh toán, không phải số thẻ). WARN là retry đã hồi phục. ERROR được capture một lần kèm context, không trong vòng lặp.
2. Log id, không phải payload. Session id ≠ user id. Lấy x-request-id từ response BFF rồi gắn vào event tiếp theo và Sentry. SSR in hồ sơ user ra stdout của pod là incident PII.
3. Replay và log dùng chung một redaction. Đừng log object Axios thô, hãy log code. Context sát secret (token, cookie) không bao giờ nằm trong breadcrumb.

logger.error("checkout.pay_failed", {
  requestId: lastRequestId, // từ x-request-id của BFF
  code: err.code,           // QUOTE_EXPIRED, không phải object Axios
  flag: flags.checkoutV2,
  release: SHA,
  // không bao giờ: token, email, payload đơn hàng, JSON.stringify(user)
})
// DEBUG tắt trên prod; INFO chỉ là nav + id lần thử

Điều gì xảy ra: Một event, một code, một request id. Grep req_9f trong log BFF khớp Sentry. Số thẻ không rời browser. DEBUG không spam prod.

Lỗi hay gặp

• console.log sót trong store Pinia. Triệu chứng: token trên console máy dùng chung. Cách xử lý: logger để DEBUG thành no-op trên prod.
• JSON.stringify(user) trong breadcrumb. Triệu chứng: PII trên Sentry. Cách xử lý: chỉ log id.
• Không request id. Triệu chứng: ba ticket cho một 500. Cách xử lý: header BFF, propagate.
• Log mọi retry trong vòng lặp. Triệu chứng: spike chi phí, không tín hiệu. Cách xử lý: đếm + một ERROR.

Tóm tắt: Chỉ gọi người khi chỗ đau user thấy, đang xảy ra, xử lý được trên path critical, kèm runbook. Một TypeError, CLS 0.12 trên blog lúc 3 giờ sáng, và vách error-rate checkout sau deploy không giống nhau. Chỉ cái vách (và chunk-404 / Nitro crash) mới nên đánh thức ai.

Vì sao quan trọng: “Bạn có gọi người vì cái này không?” Tín hiệu là bạn gọi theo triệu chứng (checkout gãy) chứ không theo nguyên nhân (đếm TypeError), với baseline ngày thường, không phải “> 50 event”. Pager FE ngoài giờ phải hiếm; nếu không, ngưỡng đang sai.

1. Cách hoạt động: FE gọi pager khi: lỗi JS checkout/pay/login so với baseline trên release này, chunk 404 / RUM màn trắng trên / sau deploy, error rate × checkout_v2, SSR 5xx / vòng crash Nitro, bão refresh auth.
2. Dùng rate + baseline ngày thường, không phải đếm thô. Gắn release, route, và flag, không thì không cắt được. Pager tới owner dịch vụ kèm link runbook. Crawler window is not defined là ticket.
3. Bắt đầu im và chỉ thêm pager khi đã có runbook. Blip lúc deploy khác spike kéo dài: chờ một cửa sổ deploy, rồi gọi nếu vẫn còn. Khác 18.7 (bạn làm gì khi đã bị gọi): ở đây bạn quyết có gọi hay không.

PAGE nếu đủ:
  - route trong {/login, /checkout, /pay}
  - error_rate > 3× baseline ngày thường trên release này
  - duration > 5 phút (không phải blip deploy)
  - đã có runbook
TICKET: một TypeError, CLS 0.12 trên /blog lúc 03:00, crawler SSR window is not defined
payload: release, route, flag, link Sentry, p75 RUM
# gọi owner dịch vụ, không phải #frontend

Điều gì xảy ra: CLS blog lúc 3 giờ sáng không bao giờ reo. Vách checkout năm phút sau một digest, gấp ba baseline, có runbook, thì reo. Payload đã có SHA và flag để 19.6 gạt được flag.

Lỗi hay gặp

• Gọi #frontend khi không có owner. Triệu chứng: không ai tới. Sửa: service owner + runbook.
• > 50 events. Triệu chứng: Black Friday gọi bạn dậy. Nguyên nhân: không baseline. Sửa: rate × ngày thường.
• Gọi pager vì CLS hero chiến dịch lúc 3 giờ sáng. Triệu chứng: mệt vì alert. Nguyên nhân: không lọc critical path. Sửa: ticket.
• Không payload. Triệu chứng: 19.6 không gạt được flag. Sửa: release + route + flag trên alert.

Tóm tắt: Bạn rollout flag lên 10% và Sentry nổ. Nếu spike bám theo flag trên critical path, đưa về 0% trước. Giữ evidence. Rồi RCA và rollout lại theo bước. Đừng debug ở 30% và đừng tăng 50% “cho tín hiệu”.

Vì sao quan trọng: Họ muốn gạt trước, telemetry cắt lát, và rollout lại, không phải hai mươi phút debug khi 10% checkout đang cháy. Khác 14.4 (loại flag) và Q&A rollout (chuyện cleanup): ở đây là mốc giờ incident.

1. Cách hoạt động: Vẽ errors / INP / conversion cắt theo flag key. Treatment át control trên pay/login → mitigate về 0% hoặc bản trước rồi announce (17.7 / 18.7).
2. Ổn định: để ý HTML cache vẫn hiện UI mới (16.2 / 14.1). Giữ link Sentry, SHA, payload flag, một Replay không PII. Đừng xóa evidence lúc đang mitigate.
3. RCA, thêm test và alert (19.5), rollout lại 1 → 5 → 25. Ghim bucket SSR để hydrate khớp (14.4). Flag chỉ evaluate trong GTM thì không cắt lát được trên Sentry. Đó là bug thiết kế.
4. CLS trên hero chiến dịch vẫn phải gạt flag nếu user thấy. Flag off mà user vẫn crash: HTML cache sót, flag thứ hai, hoặc digest bạn cũng vừa ship.

1. Cắt Sentry/RUM theo flag key + route + release
2. Nếu treatment >> control trên /pay|/login → flag = 0%  (đừng debug ở 30%)
3. Announce: bọn mình đã gạt checkout_v2, theo dõi p75 15 phút
4. Giữ: link Sentry, SHA, payload flag, một Replay (PII đã che)
5. Purge HTML nếu CDN vẫn trả UI mới
6. RCA + test + alert; rollout lại 1% → 5% → 25%
7. Nếu flag off mà user vẫn crash: cache, flag thứ hai, hoặc digest
# không bao giờ: tăng 50% cho tín hiệu khi checkout đang cháy

Điều gì xảy ra: Bước 2 cầm máu trước khi bước 6 kịp học gì. Replay bạn giữ là cách chứng minh giá null, không phải đoán. Rollout lại theo bước để spike sau nhỏ hơn.

Lỗi hay gặp

• Tăng 50% để lấy tín hiệu. Triệu chứng: thiệt hại gấp đôi. Nguyên nhân: tò mò. Sửa: 0%, rồi RCA.
• Xóa issue Sentry lúc đang mitigate. Triệu chứng: không RCA được. Sửa: giữ link và payload.
• Quên cache HTML. Triệu chứng: flag off, UI vẫn còn. Sửa: purge (14.1).
• Flag chỉ trong GTM. Triệu chứng: không cắt lát được. Sửa: evaluate ở BFF, tag Sentry.