测验：可观测性

安装服务网格后，分布式追踪却只显示单跳。最可能的原因是什么？

• 采集器地址有误，导致下游服务生成的 span 无法发送
• Sidecar 只在第一跳生成 span，后续跳数不再生成
• 应用没有把入站请求的追踪标头复制到出站请求中
• 采样率为 1%，导致后续跳数大多被过滤

如果查询 istio_requests_total 时没有按 reporter 标签过滤，会有什么问题？

• 同一个请求在发送方和接收方都被记录，请求数看起来翻倍
• 未指定 reporter 的指标完全不会被采集
• 发送方与接收方的桶边界不同，导致延迟直方图不一致
• 无法区分请求使用的是 mTLS 还是明文

如果用指标定义切换至 STRICT mTLS 的完成标准，以下哪项最合适？

• 访问日志中的 response_flags 在一段时间内全部为 -
• istio_requests_total 的总量在切换前后保持不变
• 切换前后 p99 延迟没有统计显著差异
• connection_security_policy 为 none 的请求在一段时间内为零

移除 Mixer 并改用 Telemetry API v2 后，最大的收益是什么？

• 无需 Prometheus 等采集系统也能查看仪表板
• 访问日志在代理内部自动压缩，减少存储用量
• 不再为每个请求调用独立服务，消除了额外延迟和故障点
• 指标名称与标签体系统一为行业标准

排查访问日志中响应标记为 UF 的 503 时，首先应检查什么？

• 是否用尽配置的重试次数仍未成功
• 连接池允许等待的最大请求数是否太小
• VirtualService 是否缺少匹配的路由
• 两侧 mTLS 的 STRICT 配置是否不一致，或端口、协议是否不匹配

仅凭服务网格指标无法知道什么？

• 哪个服务调用了哪个服务
• 订单是否真的保存成功等业务领域结果
• 请求延迟在 p50 和 p99 的分布情况
• 各服务的请求成功率和 5xx 响应比例

如果用自定义标签把完整请求路径或用户 ID 放进指标标签，会怎样？

• 标签值种类增多时，采样率会自动降低
• 可以区分每个请求，仪表板会更准确
• 代理会自动对高基数标签做哈希归并
• 时间序列会随着标签值的种类增加，导致基数爆炸