# 1. OpenTelemetry Collector 以 agent mode 部署时的架构与适用场景是什么？ A agent mode 是集中式部署，所有数据发送到单一实例 B agent mode 以 DaemonSet 形态就近采集并本地预处理后转发，适合大规模就近降噪场景 ✓ 正确答案 C agent mode 不支持任何本地处理 D agent mode 与 gateway mode 完全等价
# 2. OpenTelemetry Collector 如何通过 OTLP receiver 接收并处理遥测数据？ A OTLP receiver 不解析数据格式 B OTLP receiver 同时负责解析与导出 C OTLP receiver 只支持 gRPC 一种传输 D OTLP receiver 负责接收、解析 OTLP 数据并转入 pipeline，处理逻辑在 processors ✓ 正确答案
# 3. OpenTelemetry Collector 的 pipeline（receivers、processors、exporters）如何配置与串联？ A pipeline 由 receivers、processors、exporters 组成，在 service.pipelines 中按数据流串联 ✓ 正确答案 B receivers 负责导出数据，processors 负责接收 C 一个 receiver 只能用于一个 pipeline D processors 执行顺序与配置顺序无关
# 4. OpenTelemetry 中 span link 与 parent-child 关系的区别及适用场景是什么？ A 一个 span 只能有一个 parent，也只有一个 link B span link 与 parent-child 完全等价 C parent-child 表达严格调用层级，span link 表达非父子但有业务关联的 span ✓ 正确答案 D link 用于表达同步 HTTP 调用链
# 5. OpenTelemetry 的 semantic conventions（语义约定）如何统一指标、日志与 Trace 的属性命名？ A semantic conventions 只用于 trace，不用于日志 B 每个团队可随意命名属性，无需约定 C semantic conventions 让各语言、各信号用统一属性命名，便于互通与关联 ✓ 正确答案 D 属性命名统一会破坏可观测性
# 6. OpenTelemetry 的 tail-based sampling（尾部采样）如何工作，即如何保留完整调用链并控制成本？ A tail-based sampling 在 span 开始前就采样 B tail-based sampling 随机丢弃单个 span C tail-based sampling 在 trace 结束后按完整信息决定是否保留整条 trace，能保留完整链路并控制成本 ✓ 正确答案 D tail-based sampling 无法保留异常链路
# 7. Prometheus Histogram 与 Summary 的差异中客户端聚合与服务端聚合、分位数误差与存储开销如何取舍 A Histogram 在服务端聚合分位数（可跨实例），Summary 在客户端算好（不可跨实例聚合） ✓ 正确答案 B Histogram 分位数精确无误差 C Summary 分位数可在服务端跨实例聚合 D 两者存储开销完全相同
# 8. node-exporter 与 kube-state-metrics 在 K8s 监控中的分工，即 node_cpu_seconds_total、node_filesystem_avail_bytes 与 kube_deployment_status_replicas_available、kube_pod_container_resource_requests 的典型用途以及标签基数过高如何规避？ A 标签基数越高越好，便于粒度分析 B 两者采集相同指标 C kube-state-metrics 用于采集节点 CPU D node-exporter 采集节点资源指标，kube-state-metrics 采集 K8s 对象状态指标，并需控制标签基数 ✓ 正确答案
# 9. OpenTelemetry Collector 的 transform processor 如何对遥测数据做字段级转换与过滤？ A transform processor 只能做批量处理，不能改字段 B transform processor 用 OTTL 对遥测数据做字段级转换、过滤与脱敏 ✓ 正确答案 C transform processor 用于导出数据到后端 D transform processor 无法过滤数据
# 10. OpenTelemetry Exemplar（示例）如何把指标样本与 Trace 关联，在告警触发时快速跳到对应调用链 A Exemplar 是独立的 trace 数据 B Exemplar 把指标数据点与 trace/span 关联，告警时可借 trace_id 跳到对应调用链 ✓ 正确答案 C Exemplar 与指标无关 D Exemplar 无法关联 trace
# 11. Thanos/Cortex/Mimir/VictoriaMetrics 长期存储与全局查询选型 A 只有 Thanos 支持全局查询 B 四者都提供长期存储与全局查询，但架构复杂度、多租户与运维成本不同 ✓ 正确答案 C VictoriaMetrics 无法长期存储 D Mimir 不支持多租户
# 12. eBPF 可观测性（Pixie/Cilium Hubble）的落地中无侵入采集 HTTP/gRPC/DNS/内核指标与 Kubernetes 服务拓扑自动生成 A eBPF 通过内核无侵入采集 HTTP/gRPC/DNS 与内核指标，并自动生成服务拓扑 ✓ 正确答案 B eBPF 观测必须在应用代码中埋点 C eBPF 只能采集指标，无法生成拓扑 D eBPF 采集开销极高
# 13. rate/irate/increase 在计数器指标中的正确用法，以及进程重启导致的计数归零与突刺如何规避 A 计数器应直接读取原始累计值 B 计数器应用 rate/irate/increase 读取，rate 平滑、irate 敏感，重启归零需结合窗口与生命周期标记规避 ✓ 正确答案 C rate 对瞬时突刺最敏感 D 进程重启对计数器查询无任何影响
# 14. 事件（events）数据在可观测性体系中的定位与工程价值是什么？ A 事件数据无需时间戳 B 事件与指标完全等价 C 事件只能用于审计，不能用于排障 D 事件是"发生了什么"的结构化记录，与指标/日志/追踪配合可解释系统变化 ✓ 正确答案
# 15. 如何利用 OpenTelemetry Collector 的 pprof extension 排查 collector 自身的性能问题？ A pprof extension 暴露 pprof 端点，用于剖析 collector 自身的 CPU、内存与 goroutine 热点 ✓ 正确答案 B pprof extension 用于采集应用数据 C pprof extension 只能看 CPU，不能看内存 D pprof extension 与性能排查无关
# 16. 持续剖析 continuous profiling（Pyroscope/Parca）在资源优化中的作用中 CPU 剖析、内存剖析、goroutine 剖析与告警联动 A 持续剖析只能看 CPU，不能看内存 B 持续剖析只能在测试环境运行 C 持续剖析持续采集 CPU/内存/goroutine 函数级占用，可与告警联动定位资源问题 ✓ 正确答案 D 持续剖析与告警无关
# 17. 持续剖析（profiling）数据与指标、日志、追踪三大支柱如何互补？ A profiling 只用于离线分析，无法与在线告警配合 B profiling 与三支柱完全重复 C profiling 在函数粒度补充三支柱，指标/追踪定位范围与链路，profiling 定位具体函数 ✓ 正确答案 D 三支柱已包含函数级信息
# 18. 遥测数据成本控制与基数治理中高基数 label 识别、指标降采样、日志采样策略与存储分层 A 高基数标签越多越好，便于分析 B 应识别并治理高基数 label、降采样、日志采样并做热冷存储分层 ✓ 正确答案 C 所有数据应全量保存高精度 D 日志无需采样，保留全部即可
# 19. PromQL 常用函数与 recording rules 中如何用 rate/irate、histogram_quantile 与预计算降低查询开销 A 每次查询都应实时计算，无需预计算 B 用 recording rules 预计算高频复杂查询（如分位数、速率）为指标，可降低查询开销 ✓ 正确答案 C histogram_quantile 只能用于上报的分位数 D recording rules 会增加每次查询的延迟
# 20. Prometheus TSDB 的存储结构中 block、chunk 压缩与查询性能调优要点 A TSDB 将所有数据存为一个文件 B TSDB 以 block 存储、chunk 压缩，查询调优重点是预计算、降基数与限范围 ✓ 正确答案 C chunk 压缩不影响存储 D 标签基数不影响查询性能
# 21. Prometheus remote_write 与联邦的取舍中长期存储、多集群聚合与数据丢失风险如何权衡 A 联邦用于长期存储，remote_write 用于多集群聚合 B remote_write 用于长期存储与全局查询，联邦用于多集群聚合，两者都需权衡数据丢失风险 ✓ 正确答案 C remote_write 不会丢失数据 D 联邦能聚合任意高基数指标
# 22. Prometheus 服务发现（kubernetes_sd/consul_sd/file_sd）与 relabel 的配合，target 丢失的排查思路 A 服务发现返回带元数据标签的目标，relabel 筛选并设置最终标签，target 丢失需排查 relabel 与选择器 ✓ 正确答案 B relabel 用于服务发现，服务发现用于打标签 C 服务发现与 relabel 无关 D target 丢失都是网络问题，与 relabel 无关
# 23. Prometheus 的 relabel_configs 在服务发现中的高级用法 A relabel 发生在抓取后 B relabel 只能加标签，不能筛选 C relabel 用 keep/drop 筛选、replace/labelmap 重写、labeldrop 删减标签，把元数据标签转化为可用标签 ✓ 正确答案 D relabel 无法删除标签
# 24. Prometheus 高可用、分片与采集成本控制 A 高可用用双实例去重，分片把 target 分给多实例降负载，并控制标签与保留降成本 ✓ 正确答案 B 高可用只需单实例 C 分片会增加单实例负载 D 采集频率与标签系数不影响成本
# 25. 自定义 Prometheus exporter 的开发要点中指标命名、标签基数控制与 textfile collector 的适用场景 A 标签基数越高越便于分析 B 指标命名遵循规范、控制标签基数，textfile collector 适合脚本/批处理产生的低频指标 ✓ 正确答案 C textfile collector 用于高频请求指标 D 指标命名无需规范
