ASP.NET Core 试题 48：可观测性
0941 在 日志、指标与追踪 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径
- B. 开启追踪后就不再需要任何日志和指标
- C. 三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求
- D. 观察到“延迟告警出现但无法定位具体依赖”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 日志、指标与追踪 的主规则：日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径。选项“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”是使用规则时要验证的边界，不是规则本身；“开启追踪后就不再需要任何日志和指标”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0942 延迟告警出现但无法定位具体依赖。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“开启追踪后就不再需要任何日志和指标”定性，不再检查配置、身份或运行时证据。
- B. 先验证“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”，再依据“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”。
- D. 以一次成功请求作为结论，不再确认“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”是否成立。
查看答案与解析
正确答案B
场景“延迟告警出现但无法定位具体依赖”指向 日志、指标与追踪，但症状本身不能证明根因。正确排查应先确认边界“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”，再用主规则“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”解释证据。直接采用误区“开启追踪后就不再需要任何日志和指标”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0943 关于 日志、指标与追踪，以下哪项说法不成立？
难度： 实战
- A. 日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径
- B. 三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求
- C. 开启追踪后就不再需要任何日志和指标
- D. 出现“延迟告警出现但无法定位具体依赖”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“开启追踪后就不再需要任何日志和指标”正是 日志、指标与追踪 的典型误区。其余三项分别给出了主规则“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”、适用边界“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0944 针对“延迟告警出现但无法定位具体依赖”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“开启追踪后就不再需要任何日志和指标”修改实现，并把一次请求成功作为验收结果。
- B. 按“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”修改代码后直接上线，不验证“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”。
- C. 只验证“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”，但实现仍继续依赖“开启追踪后就不再需要任何日志和指标”。
- D. 按“日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径”修正实现，并用测试或遥测验证“三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：日志记录离散事件，指标聚合数值趋势，追踪连接分布式调用路径；并确认 三者互补，不能只靠高基数日志替代告警指标或只看平均指标定位单请求。继续接受“开启追踪后就不再需要任何日志和指标”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“延迟告警出现但无法定位具体依赖”这一生产场景能否安全上线。
0945 在 Activity 与 TraceId 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. .NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId
- B. 任意线程上的 Activity.Current 都会自动跨消息队列永久保存
- C. 后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage
- D. 观察到“消费端追踪与生产端链路断开”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 Activity 与 TraceId 的主规则：.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId。选项“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”是使用规则时要验证的边界，不是规则本身；“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0946 消费端追踪与生产端链路断开。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”。
- C. 以一次成功请求作为结论，不再确认“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”是否成立。
- D. 先验证“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”，再依据“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“消费端追踪与生产端链路断开”指向 Activity 与 TraceId，但症状本身不能证明根因。正确排查应先确认边界“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”，再用主规则“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”解释证据。直接采用误区“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0947 关于 Activity 与 TraceId，以下哪项说法不成立？
难度： 实战
- A. .NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId
- B. 后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage
- C. 任意线程上的 Activity.Current 都会自动跨消息队列永久保存
- D. 出现“消费端追踪与生产端链路断开”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”正是 Activity 与 TraceId 的典型误区。其余三项分别给出了主规则“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”、适用边界“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0948 针对“消费端追踪与生产端链路断开”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”修改实现，并把一次请求成功作为验收结果。
- B. 按“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”修正实现，并用测试或遥测验证“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”。
- C. 按“.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId”修改代码后直接上线，不验证“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”。
- D. 只验证“后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage”，但实现仍继续依赖“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：.NET Activity 表示追踪操作，W3C Trace Context 可跨服务传播 TraceId 和 SpanId；并确认 后台消息和自定义协议需显式传播上下文，同时避免信任或记录不受控 Baggage。继续接受“任意线程上的 Activity.Current 都会自动跨消息队列永久保存”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“消费端追踪与生产端链路断开”这一生产场景能否安全上线。
0949 在 OpenTelemetry 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 引用 OpenTelemetry 包后遥测会自动上传到所有监控平台
- B. OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件
- C. SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端
- D. 观察到“生产看不到任何 Trace”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 OpenTelemetry 的主规则：OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件。选项“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”是使用规则时要验证的边界，不是规则本身；“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0950 生产看不到任何 Trace。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”。
- C. 以一次成功请求作为结论，不再确认“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”是否成立。
- D. 先验证“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”，再依据“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“生产看不到任何 Trace”指向 OpenTelemetry，但症状本身不能证明根因。正确排查应先确认边界“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”，再用主规则“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”解释证据。直接采用误区“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0951 关于 OpenTelemetry，以下哪项说法不成立？
难度： 实战
- A. 引用 OpenTelemetry 包后遥测会自动上传到所有监控平台
- B. OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件
- C. SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端
- D. 出现“生产看不到任何 Trace”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”正是 OpenTelemetry 的典型误区。其余三项分别给出了主规则“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”、适用边界“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0952 针对“生产看不到任何 Trace”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”修改实现，并把一次请求成功作为验收结果。
- B. 按“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”修改代码后直接上线，不验证“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”。
- C. 按“OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件”修正实现，并用测试或遥测验证“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”。
- D. 只验证“SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端”，但实现仍继续依赖“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：OpenTelemetry 提供采集和导出日志、指标、追踪的标准化组件；并确认 SDK 配置、采样、资源属性和 Exporter 决定数据去向，框架不会自动选择后端。继续接受“引用 OpenTelemetry 包后遥测会自动上传到所有监控平台”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“生产看不到任何 Trace”这一生产场景能否安全上线。
0953 在 指标基数 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 指标系统会自动合并所有不同用户 ID 而不增加序列
- B. 标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪
- C. 把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸
- D. 观察到“监控存储成本和内存突然增长”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 指标基数 的主规则：把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸。选项“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”是使用规则时要验证的边界，不是规则本身；“指标系统会自动合并所有不同用户 ID 而不增加序列”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0954 监控存储成本和内存突然增长。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“指标系统会自动合并所有不同用户 ID 而不增加序列”定性，不再检查配置、身份或运行时证据。
- B. 先验证“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”，再依据“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”。
- D. 以一次成功请求作为结论，不再确认“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”是否成立。
查看答案与解析
正确答案B
场景“监控存储成本和内存突然增长”指向 指标基数，但症状本身不能证明根因。正确排查应先确认边界“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”，再用主规则“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”解释证据。直接采用误区“指标系统会自动合并所有不同用户 ID 而不增加序列”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0955 关于 指标基数，以下哪项说法不成立？
难度： 实战
- A. 把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸
- B. 标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪
- C. 出现“监控存储成本和内存突然增长”时，应收集证据并同时核对主规则与适用边界。
- D. 指标系统会自动合并所有不同用户 ID 而不增加序列
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“指标系统会自动合并所有不同用户 ID 而不增加序列”正是 指标基数 的典型误区。其余三项分别给出了主规则“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”、适用边界“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0956 针对“监控存储成本和内存突然增长”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”修正实现，并用测试或遥测验证“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”。
- B. 按“指标系统会自动合并所有不同用户 ID 而不增加序列”修改实现，并把一次请求成功作为验收结果。
- C. 按“把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸”修改代码后直接上线，不验证“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”。
- D. 只验证“标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪”，但实现仍继续依赖“指标系统会自动合并所有不同用户 ID 而不增加序列”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：把用户 ID、原始 URL、异常消息等无界值作为指标标签会造成基数爆炸；并确认 标签值应限定在路由模板、状态类别等有限集合，单用户细节放日志或追踪。继续接受“指标系统会自动合并所有不同用户 ID 而不增加序列”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“监控存储成本和内存突然增长”这一生产场景能否安全上线。
0957 在 采样 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 采样 10% 表示每条 Trace 只保留 10% 的 Span
- B. 低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持
- C. 观察到“链路出现大量断裂的孤立 Span”即可把一次现象当成完整框架契约。
- D. 追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致
查看答案与解析
正确答案D
正确答案直接描述 采样 的主规则：追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致。选项“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”是使用规则时要验证的边界，不是规则本身；“采样 10% 表示每条 Trace 只保留 10% 的 Span”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0958 链路出现大量断裂的孤立 Span。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“采样 10% 表示每条 Trace 只保留 10% 的 Span”定性，不再检查配置、身份或运行时证据。
- B. 先验证“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”，再依据“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”。
- D. 以一次成功请求作为结论，不再确认“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”是否成立。
查看答案与解析
正确答案B
场景“链路出现大量断裂的孤立 Span”指向 采样，但症状本身不能证明根因。正确排查应先确认边界“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”，再用主规则“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”解释证据。直接采用误区“采样 10% 表示每条 Trace 只保留 10% 的 Span”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0959 关于 采样，以下哪项说法不成立？
难度： 实战
- A. 采样 10% 表示每条 Trace 只保留 10% 的 Span
- B. 追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致
- C. 低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持
- D. 出现“链路出现大量断裂的孤立 Span”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“采样 10% 表示每条 Trace 只保留 10% 的 Span”正是 采样 的典型误区。其余三项分别给出了主规则“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”、适用边界“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0960 针对“链路出现大量断裂的孤立 Span”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“采样 10% 表示每条 Trace 只保留 10% 的 Span”修改实现，并把一次请求成功作为验收结果。
- B. 按“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”修改代码后直接上线，不验证“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”。
- C. 按“追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致”修正实现，并用测试或遥测验证“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”。
- D. 只验证“低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持”，但实现仍继续依赖“采样 10% 表示每条 Trace 只保留 10% 的 Span”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：追踪采样控制记录比例和成本，父子采样决策应尽量保持链路一致；并确认 低比例可能漏掉稀有错误，可采用基于错误或尾部采样并评估后端支持。继续接受“采样 10% 表示每条 Trace 只保留 10% 的 Span”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“链路出现大量断裂的孤立 Span”这一生产场景能否安全上线。