这件事在什么时候变成问题
当企业部署的系统从单体架构演进为分布式架构，或新增MCP工具集成、Agent模式应用等功能时，零散的监控配置会逐渐暴露出局限性。当出现跨团队协作时责任边界模糊、问题定位耗时过长、告警响应滞后、合规审计无法满足要求等情况时，可观测基线的建立会从潜在需求转变为必须决策的问题。例如，当系统引入基于上下文工程的Agent模式与LLM请求追踪功能后，若未明确日志采集与查看的责任划分，会导致调试时无法快速定位LLM调用异常；当重构日志系统移除Mongo存储并切换为OTEL收集后，若未配置正确的日志变量与采集规则，会出现日志丢失或无法聚合的情况。此外，当内网MCP工具调用需求出现时，若未明确MCP服务的监控指标与告警阈值，会导致工具调用失败时无法快速定位是服务端还是客户端的问题。当系统出现多节点部署、多服务依赖的情况时，缺乏统一的可观测基线会让不同团队之间互相推诿责任，影响系统的稳定性与运维效率。
需要先定下来的判据
| 判据 | 取什么值 | 依据 |
|---|---|---|
| LLM请求追踪日志保留时长 | 默认保留6小时，可通过LLM_REQUEST_TRACKING_RETENTION_HOURS变量调整 | v4.14.7新增临时LLM请求追踪功能，用于调试 |
| 对话日志过滤功能 | 开启错误日志过滤选项与使用者精准过滤选项 | v4.14.7新增对话日志列表过滤功能 |
| 系统依赖预检查 | 启动项目时进行infra/子服务有效性检测 | v4.14.7新增依赖预检查功能，便于定位不可用服务 |
| 模型监控指标采集 | 开启缓存命中率采集 | v4.14.7新增模型监控缓存命中率指标 |
| MCP服务监控指标 | 采集schema解析状态、调用成功率、响应时长 | 公开文档提及MCP服务解析$ref语法优化与MCP调用问题 |
| 告警阈值分级 | 按P0、P1、P2级划分，对应不同响应时效 | 需按实际业务场景确认具体阈值 |
这些判据之间存在明确的优先级与取舍关系。首先，核心链路的日志与指标优先级高于非核心功能，例如LLM请求追踪与MCP服务监控属于核心业务链路，需优先配置与采集。其次，日志保留时长需平衡调试需求与存储资源占用，默认6小时的保留时长可满足常规调试需求，若需更长周期的审计，可通过环境变量调整，但需按实际环境确认存储资源是否充足。再者，不同判据对应不同的责任主体，例如系统依赖预检查由运维团队负责验证，模型监控指标由AI应用开发团队负责分析，需明确划分责任边界以避免重叠或遗漏。最后，告警阈值的分级需结合业务影响程度，P0级告警对应系统核心功能不可用，需优先处理，P2级告警对应非核心功能异常，可在工作时段内处理，需避免过度配置告警导致告警疲劳。
具体怎么做
首先完成日志系统的配置与对齐。移除旧版环境变量LOG_LEVEL、STORE_LOG_LEVEL、SIGNOZ_BASE_URL、SIGNOZ_SERVICE_NAME、SIGNOZ_STORE_LEVEL，配置新版日志控制变量：开启控制台打印与OTEL收集，设置对应的最低日志等级，指定传递给OTLP收集器的服务名称与收集地址。配置LLM请求追踪的保留时长，通过LLM_REQUEST_TRACKING_RETENTION_HOURS变量调整默认保留周期，满足不同场景的调试需求。开启对话日志的错误日志过滤与使用者精准过滤选项，便于快速筛选与定位异常日志。
其次完成核心指标的采集配置。开启模型监控的缓存命中率采集，将该指标纳入AI应用的性能监控体系。配置MCP服务的监控指标，包括schema解析状态、调用成功率与响应时长，在服务启动时通过依赖预检查功能验证MCP服务的有效性，未通过检查的服务需禁止启动并触发告警。针对知识库上传、文件解析等场景的异常，采集对应的错误率指标，便于快速定位功能异常。针对内网MCP工具调用的场景，需额外配置长连接相关的监控指标，确保本地Agent节点注册与指令下发的链路正常。
然后完成告警阈值与责任划分的对齐。明确不同指标与日志的责任主体：运维团队负责基础设施指标与依赖服务可用性的监控与告警，AI应用开发团队负责LLM请求、模型性能与MCP服务的监控与告警，客服与运维团队负责对话日志的查看与用户问题排查。按业务影响程度划分告警级别，P0级告警对应系统核心功能不可用，如LLM请求成功率异常、依赖服务宕机，需在15分钟内响应；P1级告警对应核心功能性能下降，如模型缓存命中率降低，需在1小时内响应；P2级告警对应非核心功能异常，如分享链接的事件传输异常，需在工作时段内处理。配置告警的接收对象，确保不同级别的告警发送至对应的责任团队或个人。
最后完成基线的落地与迭代。将可观测基线的配置纳入上线前的检查清单，确保每一项判据都已正确配置与验证。定期review告警记录与监控数据，调整告警阈值与采集规则，避免告警疲劳或遗漏关键异常。针对新增的功能或组件，及时更新可观测基线的内容，确保覆盖所有核心业务链路。例如，当新增本地Agent节点注册功能时，需同步配置长连接状态、节点注册状态等相关指标与告警规则。
怎么验收
- 日志配置验证：登录服务后台查看环境变量配置，确认旧版日志相关变量已移除，新版6个日志控制变量已正确配置。触发LLM请求，查看是否生成对应的追踪日志，且保留时长符合配置要求，通过标准为变量配置正确，日志生成与保留正常。
- 指标采集验证：查看监控面板，确认模型缓存命中率、MCP服务调用指标、系统依赖预检查结果已正常采集且无数据缺失，通过标准为指标数据按时更新，无异常报错。
- 告警阈值验证：模拟触发不同级别的告警场景，如关闭依赖服务触发P0级告警，调整模型缓存命中率触发P1级告警，查看告警是否按时触发且发送至预设的接收对象，通过标准为告警响应及时，接收对象符合责任划分。
- 过滤功能验证：进入对话日志列表，测试错误日志过滤与使用者精准过滤功能，查看是否能正确筛选出对应的日志内容，通过标准为过滤功能正常生效，无筛选异常。
- MCP功能验证：配置MCP服务，测试getTools与runTool功能，查看是否能正常解析schema与调用工具，无协议错误，通过标准为MCP功能正常运行。
- 责任划分验证：查看告警分配规则，确认不同指标对应的责任主体正确，无责任重叠或遗漏，通过标准为告警分配符合预设的责任边界。
- 合规性验证：确认日志保留时长符合企业合规要求，若未明确合规标准则需按实际环境确认，通过标准为日志保留周期满足业务与合规需求。
边界：什么情况下这套做法不成立
当企业使用的监控组件不支持OTEL协议时，本次配置的日志采集规则将无法生效，因为v4.14.7版本已重构日志系统并移除Mongo存储，仅支持OTEL收集方式。当MCP服务仅支持特定请求方式、不支持标准 JSON-RPC 协议时，例如只接受 GET 请求、不接受 POST 请求，会出现getTools调用失败的情况，无法正常采集MCP服务的监控指标。当企业内网存在严格的防火墙限制，不允许建立长连接时，本地Agent节点注册的功能将无法实现，无法安全调用内网MCP工具。当系统引入未在基线中定义的新组件，例如新增向量数据库或模型服务时，现有指标与日志将无法覆盖新组件的监控需求，需重新调整基线内容。当企业团队的职责划分不清晰，运维与开发团队的责任边界模糊时，告警的接收与处理将出现滞后或遗漏，无法发挥基线的作用。当合规要求超出当前日志保留时长的配置范围，例如某些行业要求保留日志超过6个月，而默认的LLM请求追踪仅保留6小时时，需调整保留时长，但需按实际环境确认存储资源是否充足，否则无法满足合规要求。
继续阅读
参考资料
需要进一步确认时
上述判据与验收项可依据公开文档逐条核对。若需要结合具体部署环境与运维条件落地这套流程，可通过商务咨询获取支持；云服务形态可直接开始使用。