2026 年 1 月 26 日（今天），微软正式对 Azure Monitor 中仍在使用 旧版 Log Analytics 代理（Legacy Log Analytics Agent，即 MMA/OMS Agent）的用户执行一次 12 小时的强制数据上传中断测试。此次操作并非故障，而是一次有计划的验证演练，旨在为 2026 年 3 月 2 日 的最终服务关闭做最后预警。
在此期间，所有依赖旧版代理的监控数据将无法上传，且本地缓存的数据会被永久丢弃——即使服务恢复后也无法补传。这意味着，未完成迁移的系统将出现不可逆的日志断档，直接影响安全分析、合规审计与故障排查能力。
测试时间与影响范围
- 测试窗口（太平洋时间 PT）：2026 年 1 月 26 日 00:00 – 12:00
- 对应北京时间：2026 年 1 月 26 日 16:00 至 1 月 27 日 04:00
- 影响对象：所有尚未迁移到 Azure Monitor Agent（AMA） 的 Azure 虚拟机、订阅及工作区
- 数据后果：测试期间产生的所有遥测数据永久丢失，无重试、无回溯机制
此次中断是微软在正式停服前的“实战模拟”。其目的不是造成混乱，而是迫使组织正视迁移的紧迫性。
背景：为何必须迁移？
微软早在 2024 年 8 月 31 日 就已宣布旧版 Log Analytics 代理正式停用，但当时仅停止功能更新，后端服务仍保持运行。而 2026 年 3 月 2 日 才是真正的“硬截止日”——届时，旧代理的后端接收管道将被彻底关闭，所有数据流将永久中断。
新方案 Azure Monitor Agent（AMA） 并非简单替代品，而是微软监控体系现代化的核心组件：
- 统一整合多个旧监控代理（如 Dependency Agent、Security Agent 等）
- 通过 Data Collection Rules（DCR） 精细控制数据采集策略
- 消除重复计费风险（旧架构中多代理可能上报相同数据）
- 深度集成 Microsoft Defender for Cloud、Sentinel 等安全服务
如何判断是否受影响？
管理员可通过 Azure 门户使用官方提供的 “AMA 迁移辅助工作簿”（AMA Migration Helper Workbook）快速识别：
- 哪些虚拟机仍在运行旧版代理
- 当前使用的数据收集配置
- 迁移所需的 DCR 模板建议
该工具能自动扫描资源组、订阅和工作区，生成清晰的迁移路线图。
迁移步骤简明指南
- 创建 Data Collection Rule（DCR）
在 Azure Monitor 中定义需要采集的数据类型（如性能指标、事件日志、自定义日志等）及目标 Log Analytics 工作区。 - 部署 Azure Monitor Agent（AMA）
通过 Azure 门户、ARM 模板或脚本将 AMA 安装到目标虚拟机。 - 关联 DCR 与资源
将 DCR 绑定到具体 VM 或虚拟机规模集，激活数据流。 - 验证数据流入
在 Log Analytics 工作区中查询Heartbeat或自定义表，确认 AMA 正常上报。 - 卸载旧版代理
务必手动移除旧版 Log Analytics 代理，避免资源冗余、配置冲突或意外计费。
微软不会自动迁移旧配置。AMA 是全新架构，必须主动部署和验证。
为什么不能拖延？
- 今日测试已造成真实数据丢失：若你的系统仍在用旧代理，过去几小时的日志很可能已经消失。
- 3 月 2 日后无任何补救措施：服务一旦关闭，旧代理将彻底失效，且无延期或例外通道。
- 安全与合规风险上升：日志断档可能导致无法满足 SOC2、ISO 27001 或内部审计要求。
- 故障排查能力受限：缺少连续监控数据，将大幅延长 MTTR（平均修复时间）。
建议行动清单
✅ 立即登录 Azure 门户，运行 AMA 迁移辅助工作簿
✅ 对关键生产系统优先执行 测试迁移，验证 DCR 与 AMA 功能
✅ 制定分阶段迁移计划，确保在 2026 年 3 月 2 日前完成全部切换
✅ 迁移完成后，彻底卸载旧版代理，清理残留配置
这不是一次普通的功能迭代，而是基础设施的代际更替。微软通过今天的 12 小时中断发出明确信号：旧时代已结束，现代化监控架构不容拖延。
评论