可观测性与埋点

• 三类 ID 的粒度差异（请求/用户/会话）与生成时机
• 上下文注入与随事件携带的机制
• 发布标记对错误归属、版本对比与回滚决策的价值

三类 ID 粒度不同：TraceId 关联一次请求链路（每次 fetch/导航一个），SessionId 关联一次会话（打开到关闭浏览器，跨页面），UserId 关联登录用户；可观测性平台用它们把离散事件串成可检索的切片——按 UserId 看"这个用户的所有请求与报错"，按 SessionId 看"这一次访问的过程"，按 TraceId 看"一次请求的前后端调用链"。工程实现：SDK 在请求拦截时生成/透传 traceparent，SessionId 在会话开始时生成并随事件携带（页面 reload 保持），UserId 在登录后注入（登出清除），统一放进事件上下文 contexts。发布标记：上报事件绑定 release/版本（构建时注入），使错误、性能数据可按版本切片——新版本上线后问题量是否上升、某版本独有错误、CrUX/RUM 的版本对比，直接支撑灰度评估与回滚决策；版本与提交关联后还能从错误跳转到对应代码。

本题考察可观测性数据模型的基础。答题核心是"三级 ID 粒度"的语义差异与注入机制，以及 release 标记支撑版本化分析与回滚决策的运营价值。

• 脱敏的字段识别与掩码时机（上报前统一处理）
• 采样策略（全量/条件/分层）与统计影响
• 批量上报与失败重试（指数退避、去重、上限）

脱敏：在 SDK 上报出口统一执行，递归遍历事件对象按键名（token/password/phone）与值格式（手机号、身份证正则）掩码，保证业务代码无论怎么传，出口数据安全；敏感值在日志正文与 URL 参数中都要处理。采样：全量适合错误（量小价值高），性能与埋点事件量大需分层采样（核心事件全量、次要事件 5%~10%、条件采样如异常值全量），采样需带权重以便聚合还原。批量：同类事件在内存队列聚合（如 500ms 或 20 条一批）压缩后发送，减少请求数与带宽；重试策略：发送失败进入重试队列，指数退避（1s/2s/4s...）限次（如 3~5 次），对 4xx 不重试（客户端问题，重试无意义）、5xx 与网络错误重试；用去重键避免同一错误风暴式重复上报；页面卸载场景用 sendBeacon 兜底。边界：批量队列要防内存膨胀（设上限丢弃最旧）、重试要有总时间预算避免拖累页面、脱敏不能阻断主流程（脱敏失败降级为不发送而非抛错）。

本题考察上报管道的完整设计。答题核心是"出口统一脱敏、分级采样、批量压缩、分级重试（4xx 不重试）+ 队列上限与兜底"，体现对数据管道工程化的全面理解。

• Collector 的接收、处理、导出三段式架构
• 前端 trace 数据经 Collector 汇聚到后端的路径
• 采样、批处理与协议转换在 Collector 中的实现

OpenTelemetry Collector 是独立的代理/聚合服务，架构分三段：接收器（receivers）接受 OTLP 等多种协议数据，处理器（processors）做采样、批处理、属性改写、内存管理，导出器（exporters）把数据转发到 Jaeger/Tempo/Honeycomb 等后端。工程价值：前端 SDK 不必直连后端（后端地址变化、协议差异、鉴权都由 Collector 屏蔽），多端（浏览器、小程序、服务端）数据统一汇入后再分发；在 Collector 侧实现统一采样（tail sampling 按 trace 完整性决策）、脱敏（redaction 处理器）、故障隔离与缓冲重试，减少业务端复杂度。前端接入路径：@opentelemetry/instrumentation-document-load 等自动检测产生 span，经 OTLP HTTP/JSON 导出到 Collector 的 otlp receiver，Collector 处理后再导出到 Jaeger（存储/UI）、Tempo（Grafana 生态）、Honeycomb（高基数分析）。部署注意 Collector 的吞吐与稳定性（它是数据管道单点，需监控与高可用）。

本题考察可观测性基础设施架构。答题核心是 Collector 的接收-处理-导出三段模型及其"屏蔽后端差异、统一采样脱敏"的价值，体现对现代可观测性部署形态的理解。

• 自动检测（auto-instrumentation）的 patch 机制
• document-load 生成的 span 结构（navigation、resource）
• 与 Web Vitals、错误监控的衔接

@opentelemetry/instrumentation-document-load 在 SDK 初始化后自动 patch 浏览器关键接口：监听 performance timeline（navigation、resource entry）与页面生命周期事件，生成结构化的 span——navigation span（页面导航全过程，含 TTFB、DOMContentLoaded、load 时间戳）与每个资源的 resource span（下载时长、大小、initiatorType），并带上页面 URL、浏览器信息等属性。自动检测机制基于 OpenTelemetry JS 的 Instrumentation 抽象：SDK init 时加载该包，注册 span 处理器（如 OTLP exporter），无需业务代码打点。工程价值：零侵入获得页面级与资源级性能 span，与后端 trace 无缝关联（同一 traceparent 传递），支持在 Jaeger/Tempo 中查看"一次页面加载"的完整瀑布；可配置忽略特定资源、限制资源 span 数量；与 Web Vitals（自行另采集）和错误事件（错误携带 trace 上下文）配合，形成页面体验的完整可观测视图。

本题考察前端自动检测的具体实现。答题核心是 document-load 包的 span 模型（navigation/resource）、零侵入的 patch 机制，以及 trace 上下文与后端贯通的工程价值。

• 声明式埋点（v-track 指令、data-track 属性）的解析与自动上报
• 命令式埋点（track('event', params)）的灵活性与侵入性
• 两种模式的混合治理（SDK 架构、统一事件协议）

声明式埋点：在模板/HTML 上声明 data-track 属性或框架指令（Vue 自定义指令 v-track、React 属性扫描），SDK 统一解析并自动绑定事件（点击、曝光），好处是埋点与视图结构绑定、增删埋点不动业务逻辑、可批量治理与灰度校验；局限是复杂事件（动态参数、跨组件联动、条件上报）难以表达，需配合"动态属性值解析"（读取 data-track-params 中的表达式）。命令式埋点：业务代码调用 track(eventName, params)，灵活可控、可携带任意运行时上下文，适合复杂业务事件（下单参数、AB 分组、错误上下文）；缺点是侵入性强、易漏埋与重复埋。工程实践：按事件复杂度分层——通用交互（按钮点击、模块曝光）用声明式收敛，核心转化与带参数事件用命令式，SDK 统一事件协议（事件名、参数 schema、公共字段注入），并在 CI 中校验埋点声明合法性。两类模式可共存：声明式解析器内部最终也调用统一的 track 内核。

本题考察埋点架构设计。答题核心是"声明式收敛通用交互、命令式覆盖复杂事件、内核统一"，并指出声明式的解析机制与局限，体现对埋点治理体系的完整思考。

• 卸载场景中异步请求被中断的原因
• sendBeacon 的语义（可靠投递、post-only、64KB 限制）
• fetch keepalive 的能力（2 分钟、64KB 总额）与响应不可读的边界

页面卸载（unload/pagehide/bfcache 冻结）时浏览器会中断未完成的普通 fetch/XHR，导致卸载前埋点丢失；sendBeacon 与 fetch keepalive 专为此设计：请求由浏览器接管调度，不依赖页面事件循环继续存活，保证发起后尽力送达。sendBeacon：POST-only、请求体与响应均不处理（无响应可读），单次 payload 约 64KB 限制，浏览器排队发送；fetch keepalive：同样 POST 在卸载期存活（最多 2 分钟），单个请求体 64KB、且所有未完成 keepalive 请求总字节数有上限，响应同样不可被读取（跨页面上下文），但请求头可控（可带鉴权头，sendBeacon 无法自定义 header）。工程取舍：简单埋点（事件串、小 JSON）用 sendBeacon 最轻量；需要自定义 Header（认证、traceparent）或更细控制用 fetch keepalive；数据量大时需分片或降级（本地存储延迟上报）；兼容兜底：老浏览器无 keepalive 时降级为同步 XHR 或 image beacon（1x1 GIF GET）。

本题考察卸载期上报的底层机制。答题核心是两个 API 的"浏览器接管"原理、64KB/2 分钟/响应不可读的具体限制，以及按场景选型与降级方案。

• 内存队列与批量合并发送的模型
• 采样在 SDK 中的层级与实现
• 失败重试策略与离线缓存（localStorage/IndexedDB）的边界

事件队列：SDK 收到事件先入内存队列（数组/环形缓冲），按时间窗口或条数（如 500ms 或 20 条）批量合并为一次上报，减少请求数；队列设上限（如 1000 条），满时按策略丢弃最旧或最不重要的事件，防止内存膨胀。采样：在入口按配置分层（全量事件、采样率、条件采样），采样发生在入队前，带采样权重标识；错误等关键事件默认全量。失败重试：批量发送失败后整批回退队列，按指数退避（1s/2s/4s，上限 30s）重试，重试次数上限（如 3 次），对 4xx 直接丢弃（客户端错误不可恢复），5xx/网络错误重试；批次带批次 ID 与去重键，服务端幂等去重。离线缓存：页面关闭或网络不可用时，队列落盘到 localStorage（小数据）或 IndexedDB（大数据），下次会话启动恢复队列补报；缓存需要版本化与容量上限（防止无限增长），并配合 TTL 丢弃过期事件。协同关系：入队→采样→批量→发送→失败回退/离线持久化，构成完整管道，卸载时用 sendBeacon 兜底。

本题考察埋点 SDK 的完整工程实现。答题核心是"队列批量 + 入口采样 + 退避重试 + 持久化恢复"四段管线及其边界（容量、TTL、4xx 不重试），体现 SDK 级数据管道的设计能力。

• 合成监控的可控性（固定环境、固定场景、定期执行）
• RUM 的真实性（真实用户、真实网络、覆盖长尾）
• 两者结合的使用模式（发布回归、CDN 探测、告警 vs 体验分析）

合成监控用脚本在受控环境（无头浏览器/云端节点）定期模拟关键路径（首页打开、登录、下单），特点是一切可控可复现：固定网络、固定设备、固定缓存状态，适合做可用性探测（页面挂没挂、接口通不通）、发布回归对比（新版本 vs 旧版本同环境测速）、CDN/地域质量探测（多节点对比），问题在于样本不能代表真实用户（缓存命中、网络、设备分布都不同）。RUM 采集真实用户数据，反映真实分布与长尾环境，能发现合成监控永远碰不到的问题（某地区弱网卡顿、低端机白屏、特定浏览器报错），但不可复现、样本受流量影响。互补模式：合成监控负责"主动发现与回归验证"（发布前跑合成基线、定时拨测告警），RUM 负责"被动反映真实体验"（分级阈值告警、分桶分析）；合成发现的问题用 RUM 验证影响面，RUM 的劣化用合成脚本复现定位。

本题考察监控双模式的方法论。答题核心是"合成=可控可复现的主动探测、RUM=真实分布的被动采集"，以及发布回归与体验分析的分工配合，避免二选一。

• 告警分级的维度（影响面、业务损失、时效）
• SLO 的指标选择（错误率、可用性、Web Vitals 分位）与目标设定
• 告警与 SLO 预算消耗的联动机制

告警分级按"影响面 × 业务损失 × 恢复时效"划分：P0 为全站性故障（主流程不可用、错误率飙升超过预算），要求立即响应（10 分钟级），电话/短信值班升级；P1 为重要功能受损或大范围错误（核心页面报错率超标），小时级处理；P2 为局部/低频问题，工作时间处理；P3 为低危问题（样式异常、告警噪声），记录待办。SLO（服务水平目标）设计：选取可量化指标——页面错误率（如 99.9% 无错误请求）、可用性（核心页面可访问率 99.95%）、Web Vitals（p75 LCP < 2.5s 达成率 90%）等，定义错误预算（如每月允许 0.1% 的失败额度），SLA 则是对外承诺。联动机制：SLO 错误预算消耗速率驱动告警优先级——预算剩余充足时低危告警延迟处理，预算快速消耗触发 P0 升级；告警疲劳时用"预算视角"判断真实严重性，避免每条错误都拉响最高级警报。

本题考察监控运营的体系化设计。答题核心是分级维度与响应时效、SLO 指标与错误预算的数学表达，以及"预算消耗驱动告警升级"的联动逻辑。

• navigation entry 的一次性语义与 buffered 读取
• longtask 的持续流式语义与聚合上报
• 两类数据结合的主线程/加载归因

navigation entry 每页只产生一条（记录导航全过程：TTFB、DOMContentLoaded、load、重定向等），属一次性数据，采集要点是尽早注册 observer 并在 load 后读取完整字段，可用 buffered: true 兜底晚注册场景。longtask 是持续事件流：应用运行期间每个超过 50ms 的主线程任务都会产生 entry，采集需在启动时注册、长期存活，并做聚合——按会话统计长任务数量、总阻塞时间（TBT 近似）、Top 耗时任务与其发生时段，避免逐条上报造成数据爆炸。两者结合：navigation 数据回答"页面加载慢在哪一段"（网络/解析/脚本），longtask 数据回答"运行期主线程为何卡"（交互响应慢的根源），配合形成"加载阶段 + 运行阶段"的完整性能归因；长任务可与 INP/event entry 的 interactionId 关联，定位具体交互的阻塞来源。

本题考察两类性能数据的采集模式差异。答题核心是"一次性 vs 持续流"的采集范式（buffered vs 常驻 observer + 聚合），以及加载归因与主线程归因的分工。

• GDPR/个保法对数据最小化、告知同意、删除权的核心要求
• 前端采集的合规设计（URL 脱敏、不采集生物信息、同意弹窗）
• 技术落地（consent 管理 SDK、数据删除通道、留存策略）

合规三大原则：最小化——只采集业务必要字段（如性能数据不采集 URL 查询参数、不做设备指纹跨站追踪），能匿名则不采集身份信息；同意——采集前告知（隐私政策）并在敏感场景（定位、广告追踪）取得明确同意，用户可撤回；删除——用户可请求删除个人数据，前端 SDK 需支持清空本地缓存并触发服务端删除。工程落地：接入 CMP/consent 管理（如 OneTrust 或自建 consent SDK），把同意状态写入 cookie/IndexedDB，SDK 按 consent 门控采集（未同意只采集匿名聚合数据）；上报 URL 统一脱敏（只留路径）、事件字段白名单化、对 userId 做哈希/假名化；数据留存设 TTL（如会话数据 30 天、聚合数据 1 年），提供数据导出与删除接口；发布前做隐私影响评估（PIA），对新增采集字段走审批。注意 Cookie 墙与影子采集（绕过同意采集）在法规上风险极高，应避免。

本题考察数据合规的工程落地。答题核心是"最小化-同意-删除"三原则在前端采集、SDK 门控、数据生命周期上的具体实现，体现合规不是法务文档而是工程机制。

• OTel JS 浏览器端组件（tracer provider、instrumentation、exporter）
• 上下文传播（traceparent）与 span 生命周期
• 与商业监控 SDK 的共存策略（避免重复打点、共享 trace）

OpenTelemetry 浏览器端 SDK 由三部分组成：tracer provider（配置资源、采样器、span 处理器与 exporter）、instrumentation 插件（自动 patch fetch/XHR、document-load、用户交互等生成 span）、exporter（OTLP HTTP 或自定义导出到 Collector）。工作方式：页面初始化时通过 WebTracerProvider.with(browser) 构建，加载 instrumentations 后业务代码可用 API（getTracer().startSpan）手动补充 span，span 树通过 context 传播（traceparent 注入请求头）与后端链路合并。与 Sentry 协同：两者可共存——Sentry 负责错误与体验聚合（自带 tracing 集成），OTel 负责统一导出到企业可观测性平台（Jaeger/Tempo）；避免冲突的关键是 trace 上下文只生成一份（让 OTel 生成 traceparent，Sentry 的 BrowserTracing 读同一上下文或关闭其一的重叠采集），span 命名与采样策略统一，防止同一请求出现两套 traceId 导致关联断裂。工程上可配置 OTel 作为唯一 trace 源，Sentry 消费其 trace 上下文挂载到错误事件。

本题考察标准追踪在前端的落地与共存。答题核心是 OTel 浏览器 SDK 的组件模型与上下文传播，以及与商业 SDK"单一 trace 源"的协同原则。

• 自动检测的 patch 机制（hook 浏览器 API 生成 span）
• 覆盖场景（fetch/XHR、document-load、用户交互）
• 自动检测的边界（无法覆盖的业务语义、配置项与采样）

自动检测通过在 SDK 初始化时"包装"（monkey-patch）浏览器 API 实现：fetch/XMLHttpRequest 发送前创建 span、响应后结束并记录状态码与耗时；document-load 读取 performance entry 生成导航与资源 span；部分实现可监听用户交互（click）生成交互 span。边界与风险：patch 的是原生 API，第三方库内部若绕过这些 API（如用自己的传输层）则无法覆盖；业务语义（订单、支付等业务动作）无法自动推断，需要手动 startSpan 补充；patch 本身有性能与兼容风险（需按版本维护、避免影响被测性能）；自动检测产生的 span 量大，需配置 ignore 规则（忽略埋点/日志接口）、按路径采样与 span 属性裁剪。工程实践：自动检测做"基础覆盖"，业务打点做"语义补充"，两者结合并统一采样与传播头，才能形成完整但不过载的 trace 数据。

本题考察自动检测的能力边界。答题核心是 patch 机制的原理与覆盖范围（网络、加载、交互），以及"自动兜底 + 手动补语义"的组合模式与降量治理。

• IntersectionObserver 回调时机与 threshold 语义
• 曝光判定（可见比例、时长）与一次曝光去重
• 兼容性（无 IO 时降级）与性能（rootMargin、批量观察）

曝光埋点用 IntersectionObserver 监听元素进入视口：threshold 决定"可见比例达到多少触发回调"（如 0.5 表示元素一半可见），可传数组（[0, 0.5, 1]）感知渐进可见；工程要点：判定标准要业务化——"可见比例 ≥ threshold 且持续 X 毫秒"才算有效曝光（防快速滚动误报），用进入回调时打时间戳、离开/稳定后校验；去重：同一元素一次会话只上报一次（进入视口后立即 unobserve 或标记已上报），防止上下滚动反复触发；可见性判定：还需配合 document.visibilityState（页面隐藏时不算曝光）与元素尺寸（display:none/零尺寸过滤）；性能：用 rootMargin 预扩大视口、一个 observer 观察多个元素（批量）、离开视口即销毁；兼容降级：无 IntersectionObserver 的旧浏览器回退到 getBoundingClientRect + 滚动监听节流。

本题考察曝光埋点的完整工程细节。答题核心是 threshold 语义与业务化判定（比例+时长）、一次曝光去重、页面可见性过滤，以及批量观察与降级策略。

• 事件 schema（字段定义、类型、必填）的集中管理
• 事件命名规范（层级、时态、动作）与字典化
• 版本化演进（新增字段、破坏性变更）与灰度校验流程

事件 schema 管理：在数据字典（如 JSON Schema / 代码仓库或埋点平台）中集中定义每个事件的名称、字段、类型、必填性与枚举，前端 SDK 与后端消费方共享 schema 校验，防止字段漂移。命名规范：统一格式如 {页面}.{模块}.{动作}（home.cart.click），动作用过去时（clicked/viewed），禁用口语化名称，全量事件名建立字典并在 CI 中强制 lint 新埋点。版本化：事件字段演进遵循"只加不减"——新增字段为可选、默认值兼容，破坏性变更（改名、改类型）必须升事件版本（如 evt.v2）并双写过渡，老版本按 TTL 下线；schema 变更走评审流程并自动生成前后端类型。灰度校验：新埋点先在小流量环境开启 debug 模式（本地控制台输出、sdk 校验回调）验证字段完整性，再到测试环境用录制/回放比对事件内容，最后灰度环境用 schema 校验统计"非法事件率"达标后全量，配合埋点自动化测试（CI 中跑页面用例断言事件发出）。

本题考察埋点数据质量的体系化治理。答题核心是"schema 集中 + 命名规范 + 版本兼容演进 + 灰度校验"四位一体，体现数据工程而非简单埋点。

• 全埋点的实现原理（全局事件代理、DOM 属性注入）
• 自动获取交互数据的覆盖度与上下文丰富度
• 数据噪声问题（无关事件、元素身份漂移）与治理边界

全埋点通过全局事件代理（document 级捕获监听 click/input 等）或编译期注入，自动记录所有用户交互（点击位置、目标元素、页面路径），无需逐个业务打点，价值在于：零接入成本快速上线、覆盖业务没埋到的事件、为回溯分析提供"全量行为底稿"；典型实现（如 Heatmap、GA4 的自动事件）配合元素路径（CSS selector）与页面信息还原上下文。噪声边界：自动采集无法区分"业务价值"——菜单项、日志按钮、无意义空白点击全被记录，信噪比低；元素身份随 DOM 结构与框架渲染变化漂移（React 复用导致选择器错位）；自动事件缺乏业务参数（订单号、商品 id 需要从 DOM data 属性提取），复杂分析仍需手动埋点；隐私风险大（可能记录敏感输入）。治理：只对核心页面开启、按事件类型过滤、结合 DOM 标注（data-track 属性）提升元素身份稳定性、自动+手动混合，且全埋点数据只做行为洞察不进核心业务漏斗。

本题考察全埋点的双面性。答题核心是"零接入全量采集的价值"与"语义缺失、身份漂移、噪声、隐私"四类边界，给出自动+手动混合的治理结论。

• 实验标识（experimentId/group）随事件携带的机制
• 曝光时机（看到才归组）与点击/转化归因的先后一致性
• 分流变化、刷新与多实验嵌套下的归因稳定

数据一致性核心是"归因口径一致"：实验标识必须在事件产生的时刻就绑定并随事件上报，而非分析时反查（避免分流配置变化导致历史事件错配）。实现要点：SDK 在页面加载时读取实验分配（cookie/localStorage 存 experimentId+group 与分配版本），把标识注入事件公共字段；曝光类实验要记录"曝光时机"（元素首次可见）而非页面加载时刻——用户滚动到实验区域才产生曝光，点击/转化归因到"曝光所属的组"；多实验嵌套时携带实验列表而非单一标识。边界处理：刷新与跨页保持一致（持久化分配）、分流比例调整后旧用户按"分配版本"归组（带 allocationId）、存在未曝光点击（绕过实验区域）的排除逻辑。分析侧用"曝光为分母、转化为分子"的同源口径，避免拿全量点击对比局部曝光组。

本题考察实验数据链路的严谨性。答题核心是"标识随事件出生即携带"与"曝光时机驱动归因"两个一致性要点，以及分配版本、嵌套实验的边界处理。

• 埋点数据污染源（爬虫、脚本刷量、重复上报）
• 设备指纹与异常行为识别（频次、时间模式）
• 数据质量分层（可用性校验、去重、异常标记）与业务影响

埋点质量风险：爬虫与无头浏览器流量、脚本刷量（自动点击）、SDK 重复上报（重放、多开）会造成指标失真，直接影响投放与决策。设备指纹：组合浏览器特征（UA、canvas、字体、屏幕、时区等）生成稳定标识，用于识别同一设备多次上报与刷量设备，但需注意指纹本身的隐私合规（跨站追踪限制）与失效漂移。异常流量识别：按频率与模式检测——同 IP/指纹的超高频事件、固定时间间隔的机械行为、无曝光直接转化的"跳跃事件链"、非人类时间分布（凌晨集中）；会话重放（回放分析）可人工抽查疑似流量，验证交互是否符合真实用户路径。质量治理：上报端做事件幂等键（clientEventId）去重，分析端分层——正常/可疑/无效流量分层存储，核心指标用"仅正常层"计算，并定期用规则+抽样复核校准；异常率本身作为质量看板指标监控。

本题考察埋点数据可信度治理。答题核心是"污染源识别（指纹/模式/重放）+ 幂等去重 + 分层计算"的体系，以及反作弊与隐私合规的平衡。

• 三类数据（日志、指标、错误事件）的告警适用性差异
• 指标告警（阈值、SLO）与错误告警（事件、聚合）的互补
• 多平台数据汇聚后的统一告警路由设计

三类数据的告警特性不同：Metrics（计数器、直方图）适合阈值与趋势告警——错误率超 1%、p95 延迟超标的持续性问题，告警稳定且可做 SLO 预算；Logs 适合详情检索与特定模式匹配（关键字、错误码）告警，量大需聚合与采样；Errors（Sentry/Bugsnag 的 issue）以事件为单元，自带堆栈与分组，适合"新增问题"与"问题量突增"告警。分工取舍：持续性的服务劣化用 Metrics 阈值（可设定基线、避免逐条告警疲劳）；一次性的新缺陷用 Errors 事件告警（带堆栈直接定位）；排查细节靠 Logs 关联。工程实践：OpenTelemetry 作为统一采集底座输出 Metrics/Logs 到监控后端（Prometheus/Loki），Sentry/Bugsnag 专注 Errors 并携带 OTel trace 上下文，告警路由在统一平台（如 Alertmanager/PagerDuty）按严重级聚合——同一 trace 的错误与指标劣化合并为一条告警，避免多渠道轰炸；避免"同一问题既报错误告警又报指标告警"的重复，用 dedup 键与静默窗口治理。

本题考察可观测性三类数据的告警分工。答题核心是"Metrics 管趋势阈值、Errors 管新缺陷事件、Logs 管详情"，以及统一告警路由与去重的整合设计。

• traceparent 的字段结构（version、trace-id、parent-id、flags）
• 传播链路（前端生成、请求头注入、后端延续、响应返回）
• 采样标志（sampled）与 trace 完整性的关系

W3C traceparent 是分布式追踪的标准化传播头，格式为 version-trace-id-parent-id-flags：version（当前 00）、trace-id（32 位十六进制，全局唯一，串联整条链路）、parent-id（16 位十六进制，当前 span id）、flags（低 1 位 sampled 表示是否采样）。传播机制：前端 SDK 发起请求时把当前 trace 上下文序列化为 traceparent 注入请求头（fetch/XHR 拦截自动完成），后端收到后读取并延续同一 trace 创建服务端 span，必要时通过 tracestate 携带厂商私有信息；响应可选带 traceparent 实现双向关联。sampled 标志决定该 trace 是否被采样保留（0 不采 1 采），前端在生成 trace-id 时按采样率决策；若前端标记 sampled=0 而服务端强制采样，会导致部分 span 缺失，前后端采样策略需协调（如由 Collector 做 tail sampling 统一决策）。工程上建议前后端统一采用 traceparent，兼容 zipkin B3 时可做双头转换。

本题考察追踪标准头的基础机制。答题核心是四段字段的语义、前端到后端的注入延续链路，以及 sampled 标志对 trace 完整性的影响，体现对分布式追踪协议的准确掌握。

• 合规要求下的采集授权模型（opt-in/opt-out、consent 分级）
• 敏感字段识别与最小化（不采集、脱敏、假名化三档）
• consent 状态驱动的 SDK 运行时门控

协作模型：GDPR/个保法要求数据处理有合法依据，埋点需区分"必要数据"（功能与安全，可默认采集）与"非必要数据"（分析、广告，需同意）；落地用 consent 管理平台（CMP）统一管理授权，按用途分级（严格必要、分析、营销）存储同意状态。敏感字段最小化：先做字段清单与敏感识别（个人身份、位置、生物特征、支付信息），按"不采集 > 脱敏（掩码/哈希假名化）> 仅会话内使用"三档处置——业务不需要的字段直接不采，需要的敏感字段脱敏后采，可用哈希（加盐防彩虹表）假名化保留关联能力；埋点平台配置字段白名单与自动脱敏规则。SDK 运行时门控：初始化时读取 consent 状态，未同意则禁用分析采集（仅保留必要事件）、清空本地缓存中未授权数据、同意变更时同步生效并上报状态变更；合规审计上提供数据导出、删除接口与采集日志，配合 PIA 评审新增字段。

本题考察隐私合规与埋点工程的深度融合。答题核心是"授权分级 + 三档最小化处置 + SDK 运行时门控 + 数据主体权利支持"的完整机制，体现合规即工程。

• 实时管道的组成（接入网关、Kafka、实时计算）与典型应用
• 离线链路（数仓、批处理）与实时链路的延迟差异
• 前端上报的分流设计（同一事件多路消费、重放）

实时链路：埋点经上报网关（校验、鉴权、脱敏）进入 Kafka 等消息队列，流计算（Flink）实时消费，典型应用是实时大盘、异常检测、在线推荐归因，端到端秒级~分钟级；离线链路：Kafka 数据定期落数仓（Hive/Doris/ClickHouse）做批处理，支撑周报、漏斗深挖、机器学习样本，延迟以小时/天计，可承载更重计算与全量历史。分工原则：实时保证"快决策"（告警、风控、运营大屏），离线保证"深分析"（复杂关联、长周期回溯），同一原始事件双写两路避免口径分裂。前端适配要点：上报服务端同时写 Kafka 即可天然分流，前端只需保证事件结构化（schema 稳定、字段完整）与幂等（eventId 去重）；离线重放依赖时间戳与会话键，上报必须带准确的客户端时间与偏移校正（时钟漂移处理）；实时与离线口径不一致时以"原始事件"为基准统一转换逻辑，避免两套清洗。

本题考察数据管道的架构分工。答题核心是"实时快决策、离线深分析"的定位差异、同源事件双路消费的架构，以及前端上报对结构化与幂等的支撑。

• debug 模式（控制台实时输出、白名单）的验证流程
• 日志回放（录制/重放用户会话）验证事件时序与参数
• CI 中 schema 校验与页面用例断言的自动化

埋点质量保障分三层：开发验证——SDK 提供 debug 模式（控制台输出事件名、参数、公共字段，可按事件名过滤，仅本地/测试环境开启），开发者操作页面即时核对埋点是否触发、字段是否符合约定；回归测试——用录制/回放（如 Playwright 录制会话后回放比对事件流）验证"功能改版后埋点没丢、参数没变"，或用 E2E 用例在关键路径断言事件发出与载荷；CI 自动化——埋点定义（schema）入库后，CI 中执行页面用例并校验每个断言事件的字段完整性与类型（用 JSON Schema 校验器），发现新埋点未在字典注册或类型漂移即失败阻断。实践要点：事件字典与代码同源（自动生成 TS 类型）、上报与校验共用 schema、测试环境隔离真实上报（mock 网关）、对历史事件做定期抽样比对（离线回放校验线上数据质量），形成"开发可查、测试可比、CI 可断"的闭环。

本题考察埋点质量工程化。答题核心是"debug 即时验证 → 回放/断言回归 → CI schema 校验"三层防线与"字典同源、测试隔离"的配套机制。