用 AI 做运维排障，结论却总跑偏？问题常常不在模型，而在底下的数据。小编先给结论：LogicMonitor 为其 Enterprise Data Foundation 加入了 OpenTelemetry 指标接入和内嵌的基础设施成本追踪，目标是让复杂混合环境里的遥测数据更完整、更可治理、更好用。据称在该厂商的企业客户中，系统每天处理超过两万亿条指标。
LogicMonitor 首席技术官 Prabhu Nakkeeran 说：“IT 运维的 AI，只能和它底下的遥测数据一样可信。”他建议在评估任何 IT 运维 AI（包括他们自己的）之前，先用三个问题审视您的数据基础：它完整吗？它受治理吗？它可被消费吗？三个都答“是”，上面每一层才可信。
遥测数据常见的几个失灵点
遥测数据的质量决定自动排查工具是否准确。Nakkeeran 认为，AI 在运维上出问题，源于有缺陷的数据，而不是模型本身：“AI 并没有胡编，它只是用不完整的数据在推理。”
- 可见性不全：一个场景里，自动诊断软件把应用延迟归咎于数据库，实际是没被监控的网络设备拖慢了，那组防火墙集群因为不支持标准 SNMP 监控协议而没被发现。分支机构的 SD-WAN 设备和未被监控的存储阵列也会造成类似盲区，云账户凭证悄悄过期则会切断遥测数据流，却不通知管理员。
- 治理缺失：采集指标却没有保留规则，各业务单元的合规风险会增加；需要用分区控制来隔离运行环境；不同监控工具不共享统一的主机身份时，割裂的数据结构会让问题更严重。
用 OpenTelemetry 管道统一采集
为补上覆盖缺口，平台可通过上游开源的 OpenTelemetry 采集器或 LogicMonitor 采集器，接入“推送式”指标。这种推送设计避开了传统轮询，绕过了隔离网段里老旧 SNMP 的限制，也支持无需专有代理的流式指标。
应用性能监控在架构中仍是独立的：trace 仍由 LogicMonitor APM 管理，OpenTelemetry 日志的原生接入路径则计划在以后推出。对于老环境，厂商用 OpenTelemetry 的 Windows 采集器抓取应用层的请求指标，监控 IIS 服务器，跟踪 HTTP 状态码、出错端点和响应时长。这些指标为以前难以插桩的 Windows 层带来了可见性，LogicMonitor 还在准备预配置的查询包，用来分析这些 Web 服务器遥测数据。
把费用数据接给 Edwin AI
企业的遥测策略往往把财务数据排除在外。Nakkeeran 说：“成本也是遥测，只是今天它通常放在另一个团队负责的另一个工具里。”平台把基础设施支出数字直接嵌在技术性能指标旁边，由 Edwin AI 在事件调查时使用：系统会同时查看运维遥测和支出数据，在建议干预措施前权衡商业上的取舍。Edwin AI 评估完技术和财务背景后，还能直接执行受治理的运维动作。Nakkeeran 总结道：“为行动而设计的数据，才能让一次调查以决策收尾，而不是以报告收尾。”
此外，LogicMonitor 是今年阿姆斯特丹 Digital Transformation Expo Europe 的重要赞助商，展位号 #256。
常见问题（FAQ）
这次更新支持 OpenTelemetry 日志吗？
目前接入的是指标，trace 仍由 LogicMonitor APM 管理，日志的原生接入路径计划在以后推出。
推送式接入比传统轮询好在哪？
它避开了轮询，能绕过隔离网段里老旧 SNMP 的限制，并支持无需专有代理的流式指标。
为什么要把成本也当作遥测数据？
这样 Edwin AI 排查事件时能同时权衡技术与费用，让调查更容易落到具体决策上。
Windows 老系统能监控吗？
可以用 OpenTelemetry Windows 采集器监控 IIS 服务器的请求指标。