# 1. Elastic Common Schema（ECS）的字段标准化中@timestamp、log.level、message、service.name 等核心字段如何统一业务日志字段集？ A ECS 统一了字段命名与语义，使跨服务日志能被一致的查询与告警规则消费 ✓ 正确答案 B ECS 仅适用于 Elasticsearch，其他日志平台无法使用 C @timestamp 应使用服务本地时区的时间，便于开发阅读 D 业务自定义字段可以直接使用任意命名，无需遵循 ECS 约定
# 2. OpenTelemetry Logs Data Model 与 ECS 的协同 A OTel 与 ECS 互相排斥，只能二选一 B OTel Logs 不支持 traceId/spanId 字段 C ECS 已替代 OTel 成为日志传输标准 D OTel 提供日志传输结构与 traceId/spanId 关联能力，ECS 提供字段语义统一，二者可协同使用 ✓ 正确答案
# 3. 日志关联（correlation）中 traceId、spanId、requestId 的注入规范（MDC、NDC），异步与消息场景如何传递？ A MDC 基于 ThreadLocal，线程池中的线程会自动继承调用方上下文 B MDC 基于 ThreadLocal，线程池中不会自动继承，需包装任务复制上下文并在事后清理 ✓ 正确答案 C NDC 与 MDC 是完全相同的机制 D 消息场景无需传递 traceId，上下文会自动跨进程同步
# 4. 日志字段的 Schema 演进中新增或重命名字段时如何保持向后兼容（版本化字段、兼容别名、废弃流程），避免查询与告警在升级后失效？ A 重命名时直接删除旧字段，最快的迁移方式 B 字段重命名无需通知消费者，查询会自动适配 C 通过兼容别名或短期双写让旧字段继续可查，再逐步废弃旧字段 ✓ 正确答案 D 版本化字段后缀是唯一推荐的兼容方案
# 5. 运行时动态调整日志级别中生产排障时如何按服务或请求临时开启 DEBUG，权限、审计与成本如何控制？ A 生产环境应直接全量开启 DEBUG，方便排障 B 应通过请求定向调试或采样限制 DEBUG 量，并配合权限、审计与自动回退控制 ✓ 正确答案 C 任何工程师都可以在生产环境随意调级，无需审计 D 动态调整日志级别必须重启服务才能生效
# 6. 日志库（SLF4J、log4j2、logback、zap、winston、logrus）的封装与切换 A 通过门面（如 SLF4J）封装，业务代码只依赖门面，切换实现时无需改业务代码 ✓ 正确答案 B 业务代码应直接依赖具体日志实现，便于充分利用其特性 C 日志库无法在不重启的情况下切换 D 封装日志库时越深越好，封装越多越安全
# 7. 日志级别（DEBUG、INFO、WARN、ERROR、FATAL）的语义边界（SLF4J、log4j2） A ERROR 表示实际失败且影响功能，应触发告警；WARN 表示值得注意但未导致失败 ✓ 正确答案 B DEBUG 应默认在生产环境开启，方便排查 C WARN 表示功能已失败，必须立即告警 D FATAL 与 INFO 语义相同，仅是名称不同
# 8. 日志采样（log sampling）的策略中 rate-based、tail-based、head-based A tail-based 采样在请求结束后根据结果决定是否保留，能保证错误请求的保真度 ✓ 正确答案 B rate-based 采样能保证重要错误样本不被丢弃 C 三种采样策略适用场景完全相同，可随意互换 D tail-based 采样在请求入口就决定是否采样，实现最简单
# 9. 结构化日志（structured logging）的 JSON 格式（ECS、logfmt）vs 非结构化（plain text） A 非结构化日志比结构化日志更便于机器检索与聚合 B JSON 格式日志无需字段约定，随意嵌套即可 C 结构化日志把日志组织成可解析的键值对，提升检索、告警与自动化的能力 ✓ 正确答案 D 结构化日志只适合 Java，不适合其他语言
# 10. SLF4J 的门面（facade）与实现（logback、log4j2）的解耦 A 业务代码应直接依赖 logback，才能使用全部特性 B SLF4J 只定义 API，通过绑定器桥接到具体实现，业务代码只依赖门面即可切换实现 ✓ 正确答案 C 换了实现后必须重写所有业务日志代码 D SLF4J 本身就是一个日志实现，不需要 logback
# 11. 业务日志 vs 系统日志的字段差异中请求 ID、用户 ID、业务单据号等上下文字段的注入规范与脱敏边界如何统一制定？ A 系统日志应包含用户手机号等敏感信息，便于排障 B 业务日志与系统日志字段完全一致，无需区分 C 脱敏规则由各开发自行决定，无需统一 D 业务日志需注入 requestId、userId、单据号等业务标识，并统一脱敏边界，敏感字段不进日志 ✓ 正确答案
# 12. 日志字段的类型与大小规范中字符串/数字/对象字段的 JSON 类型约定、字段值长度上限与大对象（如整条请求体）入日志的约束？ A 单条日志应完整记录整条请求体，便于排查 B 应统一字段 JSON 类型（如 ID 用字符串）、限制字段长度，并禁止把整条请求体等大对象入日志 ✓ 正确答案 C 日志字段长度没有限制，越大越好 D 数字字段和字符串字段可以随意混用，查询不受影响
# 13. 异常堆栈的日志规范中记录异常时如何保留 cause 链、完整堆栈与上下文，避免截断或吞掉原始异常？ A 记录异常时只需 e.getMessage()，避免堆栈太长 B 应把异常对象传入日志并保留 cause 链与完整堆栈，且避免重复打印或吞掉异常 ✓ 正确答案 C 捕获异常后直接吞掉，日志越少越好 D 异常由上层打印，下层捕获后无需记录
# 14. 日志字段的单位与格式约定中时长、字节与百分比字段命名（duration_ms、size_bytes）如何避免跨团队歧义？ A 单位不需要写进字段名，开发自行理解即可 B 时长的单位各团队可以不同，只要数值正确 C 时间戳使用本地时区即可，无需统一 D 统一把单位编进字段名（如 duration_ms、size_bytes），避免跨团队数值歧义 ✓ 正确答案
# 15. log4j2 的 disruptor 异步日志（LMAX）的吞吐量 A 基于 Disruptor 无锁环形缓冲把日志入队与后台写盘解耦，减少锁竞争从而提升吞吐 ✓ 正确答案 B 异步日志与同步日志吞吐完全相同 C 异步日志在业务线程内直接写盘，吞吐更高 D Disruptor 使用锁保护的有界队列实现
# 16. zap（Go）的结构化日志与性能（zero allocation） A zap 通过字段预分配与编码器复用避免堆分配，减少 GC 压力从而提升性能 ✓ 正确答案 B zap 的 JSON 编码器每次都会分配新对象 C zap 只支持非结构化日志 D zap 通过字符串拼接输出日志，性能较低
# 17. 日志脱敏中敏感字段的遮蔽？ A 对手机号、身份证等敏感字段统一遮蔽（如保留位打码），并把脱敏规则落地到日志库/序列化/采集端 ✓ 正确答案 B 脱敏只影响诊断，最好不做 C 敏感字段应完整记录，便于审计 D 脱敏规则不需要统一，各服务自行处理
# 18. 日志字段命名与跨服务一致性中统一字段命名（如 user_id、trace_id）如何避免查询与告警在跨服务时失配？ A 各服务字段名可自由命名，查询时自动适配 B 统一字段命名（如 user_id、trace_id）并维护字段字典，保证同义同名字，跨服务查询告警不失配 ✓ 正确答案 C 跨服务告警无需统一字段名 D 字段名区分大小写无关紧要，不会影响查询
# 19. 日志时间戳规范中统一 UTC 与时间精度（毫秒或纳秒），避免跨时区排障歧义？ A 各服务使用本地时区日志，排障时简单 B 时间戳精度统一为毫秒或纳秒不重要 C 时间戳无需带时区标识 D 统一使用 UTC 存储、ISO 8601 格式并约定精度，避免跨时区与精度歧义 ✓ 正确答案
