MCP 面试高频考点：如何给 MCP Server 落地日志、指标、追踪与最小权限审计
面试场景
面试官：我们先从一个很常见的工程问题聊起。假设你负责维护一个对外提供 Tools、Resources、Prompts 的 MCP Server，既有本机通过 stdio 启动的场景，也有远程通过 Streamable HTTP 部署的场景。现在线上排障困难：调用失败时不知道是参数问题、权限问题还是下游超时；运维也看不到调用量、错误率和耗时分布；出现越权或误操作后，没法快速定位是谁在什么时间调用了哪个 Tool、影响了哪些资源。你会怎么设计这套可观测与安全审计方案？
候选人：我的结论是：不能把“打点日志、接监控、接链路追踪、做权限校验”当成四件孤立的事来做，而要围绕 MCP 的 JSON-RPC 请求生命周期，在统一的请求上下文中串联认证、授权、业务执行、审计与观测。stdio 和 Streamable HTTP 的传输差异只影响上下文如何接入，不改变核心分层：传输层负责接入和会话，协议层负责解析 JSON-RPC 与能力分发，能力层负责 Tool/Resource/Prompt 业务逻辑，横切层负责日志、指标、追踪、鉴权和审计。MCP 本身采用客户端—服务端架构，通信消息使用 JSON-RPC，Server 暴露 Tools、Resources、Prompts 三类能力 [资料1]，所以可观测埋点应该先围绕这三类能力设计，而不是只围绕 HTTP 接口。
基础问题：先把日志做对
面试官：如果先从日志开始，你觉得最容易做错的地方是什么？
候选人：最容易错的是把调试日志写到标准输出。stdio 传输下，Host 通常把 MCP Server 作为子进程启动，标准输出用于协议消息，调试日志必须写到标准错误，否则会破坏协议通信 [资料1]。这是一个非常具体但很容易踩坑的点。
第二，日志不能只打“成功/失败”。至少要区分几类事件：连接建立与断开、会话初始化、JSON-RPC 方法分发、Tool 调用开始/结束、Resource 读取、Prompt 获取、参数校验失败、授权失败、下游依赖调用、异常堆栈。但凭据不能出现在日志、Tool 返回值或模型上下文中 [资料1]。像访问令牌、密钥、用户隐私字段、文件路径中的敏感目录、SQL 参数中的个人信息，都要在进入日志前脱敏。
第三，日志需要稳定的关联字段。例如请求 ID、会话 ID、能力类型（tool/resource/prompt）、能力名称、调用方主体、资源范围、结果状态。如果 SDK 已经通过异步上下文传递 correlation ID 和 tracing state，就应复用这套机制，不要自己再造线程局部变量导致跨异步边界丢失。以 Java SDK 为例，公开 API 只通过 SLF4J 输出日志，SDK 本身不内置 metrics 或 tracing 实现，但会把 observability metadata 沿着 Reactor 流水线传递，方便接入 Micrometer、OpenTelemetry 等框架 [资料2]。也就是说，日志框架选型要轻，后端实现解耦，不要把某个具体监控厂商硬编码进业务代码。
面试官点评：这里的考察点有两个：一是是否理解 MCP 不同传输方式对日志输出的约束；二是是否知道日志既要服务排障，也要受安全边界约束。合格回答会明确指出 stdio 下 stderr 与 stdout 的区别，并提到敏感字段脱敏；加分项是能结合 SDK 的异步上下文说明关联 ID 如何跨线程、跨异步边界传递。
追问一：指标和分布式追踪怎么和日志协同
面试官：日志有了，指标和追踪呢？如果只是每个函数前后打耗时，是不是就够了？
候选人：不够。指标、追踪、日志解决的是不同问题。指标看趋势和告警，追踪看调用链和瓶颈，日志看细节和异常现场。三者必须共用同一套上下文标识，否则排查时对不上。
我会在 MCP Server 的请求入口建立统一 span，名称可以按能力类型区分，例如mcp.tool.invoke、mcp.resource.read、mcp.prompt.get。span 上记录稳定属性：传输方式（stdio/streamable_http）、方法名、能力名、协议错误码、鉴权结果。如果 Tool 内部还要访问数据库、对象存储、检索服务或其他 HTTP 下游，就继续创建子 span，把 MCP 层的 trace context 传下去。这样线上看到一个慢 Tool，才能判断是 MCP 协议解析慢、权限检查慢，还是下游依赖慢。
指标方面，建议至少有四类黄金指标，但标签设计要克制，避免高基数爆炸：调用次数、错误率、执行耗时、在途请求数。标签可包含 transport、capability_type、capability_name、status、auth_result。不要把用户输入、完整资源 URI、原始错误文本直接作为指标标签，否则成本高且可能泄露数据。具体的桶边界、超时阈值、采样率，应该结合业务 SLA、风险评估和压测结果确定，而不是拍脑袋写死。
这里还有一个取舍：stdio 场景通常是本地子进程，没有传统意义上的入站 HTTP trace header，所以 trace context 可能需要由 Server 自己创建，并在 stderr 日志中输出 trace ID；远程 Streamable HTTP 场景则可以从请求头接收或续接 trace context。两种场景的接入层不同，但能力层埋点应保持一致，避免业务逻辑里写一堆if transport == ...。
面试官：如果出现异常呢？比如 Tool 执行到一半抛错，或者下游超时，追踪和日志怎么避免“断链”？
候选人：异常要在边界处记录，不要在每个底层方法里重复打错误日志造成噪音。我的做法是：协议分发层捕获业务异常、参数异常、授权异常、下游超时异常，统一映射为明确的结果状态；在当前 span 上记录异常事件和状态；审计日志记录失败原因类别，但不打印敏感堆栈或原始用户输入全文；指标按错误类别计数。
还要区分“用户可恢复错误”和“系统错误”。例如参数 schema 校验不通过，属于调用方输入问题，不应打成 500；真正的下游超时、依赖不可用才是系统错误。MCP 虽然用 JSON-RPC 通信，但 Tool 的参数 schema 只是结构约束，不能代替服务端校验和授权，服务端必须把模型传入的文本视为不可信输入 [资料1]。因此参数非法、路径越权、URL 命中 SSRF 黑名单等，都应该在进入业务逻辑前拦截，并在追踪和审计中留下明确原因。
面试官点评：这一轮考察是否理解可观测三支柱的分工，以及是否能在异常路径上保持上下文完整。合格回答会说明统一 span、指标标签治理、异常分类；加分项是能把“schema 校验不等于安全校验”讲清楚，避免把模型传入参数默认可信。
追问二：最小权限和审计日志不是“多打一条日志”
面试官：你前面提到审计日志，它和普通错误日志有什么区别？如果让你把最小权限原则落到 MCP Server，你会怎么做？
候选人：审计日志不是普通 debug 日志，它的目标是安全追责和合规分析，所以字段要稳定、不可随意开关、不能含敏感明文。根据安全实践，审计日志应记录谁在什么时间调用了哪个 Tool、关键资源范围与结果状态，同时对敏感字段脱敏 [资料1]。我会把审计事件限定在“有安全意义的动作”上，例如 Tool 调用、高风险 Resource 读取、权限拒绝、管理员配置变更；不是每个 debug 信息都进审计。
最小权限方面，核心不是“用户登录了就能调所有 Tool”，而是每次请求都做授权检查。远程 MCP Server 必须对每次请求执行授权检查，不能只判断用户是否已登录 [资料1]。更进一步，MCP Server 不能接受不是明确发给自己的令牌；如果把上游令牌原样转发给下游，而不校验 claims、角色、权限或 audience，就可能被攻击者当成数据外透代理，扩大信任边界 [资料3]。所以授权至少要回答四个问题：是谁调用、调用哪个能力、访问什么资源范围、是否满足本次操作所需权限。
例如一个文件读取 Tool，不能因为传入了路径字符串就直接读。需要校验路径是否在允许目录内、调用主体是否有该资源的读权限、是否命中高危扩展名或敏感目录；高风险或不可逆操作还应显示具体影响，并在执行前要求用户确认 [资料1]。Resource 也是一样，不要把只读资料强行设计成有副作用的 Tool [资料1]，否则权限模型会混乱：本来只是读上下文，却被设计成可执行操作，审计时很难解释。
伪代码层面，我会把横切逻辑做成统一中间层，而不是散落在每个 Tool 里：
on_request(req): start_span(req) inject_context(req) principal = authenticate(req) if principal is None: audit("auth_failed", req, status="denied") record_metric(status="unauthenticated") return error capability = resolve_capability(req) resource_scope = extract_resource_scope(req, capability) if not authorize(principal, capability, resource_scope): audit("authz_failed", principal, capability, resource_scope, status="denied") record_metric(status="permission_denied") return error sanitized_input = validate_and_sanitize(req.params, capability.schema) log("invoke_start", principal, capability, resource_scope) try: result = execute_capability(capability, sanitized_input) audit("invoke_success", principal, capability, resource_scope, status="success") record_metric(status="success") return result except DomainError as e: audit("invoke_failed", principal, capability, resource_scope, status="domain_error") record_metric(status="domain_error") span.record_exception(e) return mapped_error(e) except TimeoutError as e: audit("invoke_failed", principal, capability, resource_scope, status="timeout") record_metric(status="timeout") span.record_exception(e) return mapped_error(e) finally: end_span()这里的关键取舍是：校验、授权、审计放在统一入口，能保证一致性；但资源范围解析有时依赖业务语义，所以extract_resource_scope需要能力层提供元数据，不能完全靠通用框架猜。另一个容易踩坑的点是审计日志里记录“资源范围”时，不能把用户原始输入原样落盘，否则既可能泄露敏感信息，也会让攻击者通过构造输入污染审计字段。应该记录经过规范化后的资源标识，例如真实文件路径脱敏后的结果、文档 ID、租户 ID，而不是原始 prompt 文本。
面试官：这套方案的适用边界是什么？
候选人：它适合需要多租户、远程接入、有审计要求或会访问内部资源的 MCP Server。如果只是本地个人使用的极简工具型 Server，比如本机 stdio 启动的计算器 Demo，可以只保留基础 stderr 日志和异常处理，不必一开始就上完整的 OpenTelemetry、审计存储和复杂权限系统。Python SDK 可以快速写出一个 15 行左右的 MCP Server，支持 stdio、Streamable HTTP、SSE 等传输 [资料4]，这说明 MCP Server 的门槛很低，但一旦进入远程服务或企业场景，认证、授权、会话管理、限流、超时和观测就必须补上 [资料1]。也就是说，工程化程度要和部署形态、风险等级匹配，不能为了“看起来专业”把本地开发体验搞得很重。
面试官总结
面试官：你今天的回答整体有几个关键点是对的。第一，没有把 MCP Server 的可观测理解成普通 Web 服务打点，而是回到 MCP 的协议与能力模型，围绕 Tool、Resource、Prompt 和 JSON-RPC 生命周期设计。第二，能区分 stdio 与 Streamable HTTP 在日志输出和上下文传递上的差异，尤其是 stdout/stderr 这个高频坑点。第三，没有把安全与审计当成附加项，而是明确了“每次请求授权”“不接受非本 Server 令牌”“schema 不能替代服务端校验”“审计字段要脱敏且规范化”这些边界。第四，也谈到了取舍：轻量场景不必过度工程化，远程高风险场景必须补齐鉴权、限流、超时和审计。
如果想再往上走一步，建议继续准备三个方向：一是多租户下的资源隔离和审计留存策略；二是 Tool 调用前的用户确认机制如何和 Host 交互，避免高风险操作被自动执行；三是采样、日志成本、指标基数和 trace 数据量之间的平衡，这些都是把 MCP Server 从“能跑”带到“能上生产”的关键。
参考资料
- MCP 基础知识
- MCP Java SDK：https://github.com/modelcontextprotocol/java-sdk
- Security Best Practices：https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
- MCP Python SDK：https://github.com/modelcontextprotocol/python-sdk
