3、Azure活动日志详解：活动日志内容结构、类别（管理、服务健康、安全等）、查看与筛选
活动日志是什么？先说说我的理解
Azure 活动日志就是平台的审计日志，记录着所有控制平面操作。说白了，你在 Azure 上做的每一次创建、修改、删除资源，都会在这里留下痕迹。我习惯把它比作 Azure 的“操作黑匣子”——出了问题翻一翻，谁在什么时候动了什么，一目了然。
但它不记录数据平面操作，比如从存储账户里下载文件、查询数据库。这个区别很多人刚开始容易搞混。嗯，这里要注意：活动日志只管 管理操作，不碰数据面。
活动日志内容结构：一条记录长什么样？
每条活动日志都是一个 JSON 对象，里面有几十个字段。不过日常排查，你重点关注的就那几个。我整理成了一张表格，方便对照：
| 字段名 | 说明 | 示例值 |
|---|---|---|
caller |
操作发起者（用户/服务主体/系统） | admin@contoso.com |
operationName |
操作名称，通常含资源类型和动作 | Microsoft.Compute/virtualMachines/write |
status |
操作结果：Succeeded / Failed / Started | Failed |
eventTimestamp |
事件发生时间（UTC） | 2025-02-18T09:23:45.123Z |
category |
日志类别（见下文） | Administrative |
resourceId |
操作目标的 Azure 资源 ID | /subscriptions/.../resourceGroups/.../providers/... |
correlationId |
相关事件关联 ID（调试利器） | a1b2c3d4-... |
level |
严重级别：Critical / Error / Warning / Informational | Error |
我在项目中遇到过好几次，光看 operationName 不够，必须配合 correlationId 才能串联起同一操作的多条日志。比如创建虚拟机失败，往往先是 Started，然后才是 Failed，中间可能还有子操作。用 correlationId 一搜，全连起来了。
活动日志类别：三大主线 + 其他
类别字段把日志分成了几类。最常用的三个：
- Administrative（管理）：所有资源创建、修改、删除、分配权限等。占日志量的 90% 以上。
- Service Health（服务健康）：Azure 服务自身的问题，比如区域故障、计划维护。这个不是你的操作，是微软的。
- Security（安全）：安全相关事件，比如 Azure AD 条件访问评估、安全策略违规。注意它不包含登录失败等细节，那些得看 Sign-in logs。
除此之外还有 Alert（警报触发）、Autoscale（自动缩放）、Recommendation（建议）等类别，但很少用到。
为什么要有分类？因为筛选的时候直接按 category 过滤，效率极高。我曾经排查一起“资源无故被删”的事故，先按 Administrative 和 Delete 操作过滤，只用了 30 秒就定位到人了。
查看与筛选：三种姿势，各有利弊
查看活动日志，我个人常用三种方式：门户、Azure CLI、PowerShell。你按场景选就行。
1. Azure 门户
最直观。在左侧菜单点“Monitor”→ 活动日志，或者直接在资源页点“活动日志”。
支持快速筛选：时间范围、类别、操作、状态、发起者。还可以添加自定义筛选条件。
适合临时看一眼，或者给非技术同事展示。
2. Azure CLI
我习惯用 CLI 做快速排查。命令简单，响应快。
# 列出最近1小时的管理类失败操作
az monitor activity-log list \
--filter "category eq 'Administrative' and status eq 'Failed'" \
--start-time "$(date -u -d '1 hour ago' '+%Y-%m-%dT%H:%M:%SZ')"
配合 --query 参数可以只取你关心的字段，适合脚本化。
3. PowerShell
更接近 .NET 体系，适合需要复杂逻辑的场景。
Get-AzLog -StartTime (Get-Date).AddHours(-1) `
-Status Failed `
-Category Administrative |
Select-Object OperationName, Caller, EventTimestamp, Status
说到底，这三种方法查出来的数据是一样的，区别在于交互方式。你想想看，日常告警响应时间就几分钟，哪还有时间慢慢点门户？我都是 CLI 上来直接 grep。
另外，活动日志默认保留 90 天，超过的数据会自动消失。如果需要长期审计，必须把日志导出到存储账户或 Log Analytics 工作区。
一张图看懂活动日志体系
下面我用 SVG 画了一张结构图，把上面讲的内容串起来。你可以把它当作速查地图。
从图里能看出来，所有控制平面操作统一汇聚到活动日志，按类别分流，最后通过三种方式查询。你可以在门户上点鼠标，也可以用 CLI 写一行命令——结果一样，后者适合自动化。
总结几个实用经验
- 筛选关键词：用
operationName的Microsoft.Compute/virtualMachines/delete这种格式，避免把创建误判为删除。 - 定时导出：审计要求高的场景，建议用诊断设置把活动日志流到 Log Analytics，再建警报。比如“30分钟内同一用户连续删除3个资源”就发通知。
- 了解默认保留期：90天。如果你需要查半年前的操作，必须提前导出到存储账户。我有个客户因为在第91天发现违规操作，结果日志已经被清理，后悔莫及。
correlationId 和 status 筛选，五分钟内通常能找到根因。
好了，这一章的内容就这么多。活动日志结构和筛选本身不难，难的是养成“出事先看活动日志”的习惯。我记得刚接触 Azure 时，遇到问题总先去找 VM 内的系统日志，折腾半天才发现是 Azure 平台拒绝了操作。从那以后，活动日志成了我解决问题时的第一站。