【AEM 每日一贴】Audit Log
在我们日常使用AEM Sites 和 AEM DAM的时候，经常会遇到类似以下这样的问题：
- Publish实例上的一个Active的页面，不知道什么时候被哪个用户Deactive了
- Author上的一个还在编辑中，还没发布的页面，不知道什么时候被那个用户Delete了
- Author上的某个资产或资产文件夹不知道什么时候被哪个用户给删除了
这个时候，相关的业务人员就会着急的找到IT人员求助，大概也就是这样一系列让人脑阔疼的场景：
- “我这个页面怎么突然就不见了，快帮我恢复！！！”
- “帮我查出这是谁干的，我要他负责！！！”
- “是不是你们IT把我们的页面弄坏了！一定是你们！"
这个时候，作为一个IT人员，你就可以通过 Audit Log 来找出真凶
Audit Log 通俗易懂，Audit 审计审查，Log 日志
但其实Audit Log并不是一个真正意义上的Log，它其实是一个节点 audit 节点
只是结合这个节点存在的意义来说，我愿称之为 Log
这个节点 存在于 根目录下的 var 节点下，如下图所示：
如上图所示，audit节点下面有三个节点，分别是
com.day.cq.wcm.core.page 记录页面相关操作
com.day.cq.replication 记录发布相关操作
com.day.cq.dam 记录资产相关操作
以其中一个为例子，假设我现在在AEM6.4的DAM目录下,上传一个资产
可见我上图中，上传这个资产的路径为 /content/dam/projects/we-retail
然后 再让我们在CRXDE打开 /var/audit/com.day.cq.dam 如下
你会发现 com.day.cq.dam 节点下，也有一个content节点
再打开content节点你会发现，这个content节点的结构，和根目录下的content节点一模一样
所以我们直接打开 audit节点下 我们刚刚上传图片资产的路径 也就是这个路径 /var/audit/com.day.cq.dam/content/dam/projects/we-retail
你会发现，刚刚上传的图片资产节点就在这，打开这个节点，你会发现有一条 jcr:primaryType属性为 ca:auditEvent 的记录节点
再详细看这个节点的其他属性 我们能看到分别有 记录时间，操作类型还有操作的用户
接下来 我发布了这个资产
让我们刷新一下 dog.jpg这个节点，你会发现，节点下并没有新增记录
那是因为发布这类操作，会记录在 com.day.cq.replication 节点下 （上文也提到过）
所以让我们打开 /var/audit/com.day.cq.replication/content/dam/projects/we-retail/dog.jpg 节点，就能看到相应的记录
cq:type是 Active 也就是发布操作，和我们的操作记录完全一致
再接下来，我们进行重头戏，我把这个图片资产进行删除
当一个资产被删除后，我们从前台界面，已经看不到这个资产了
我们再进入后台的content节点下查找，也发现这个节点已经不在了
这个时候再打开audit节点下的相应路径，会发现dog.jpg节点还在
我们在这里就可以看到 我们的删除操作 被记录了下来
通过这个节点，我们就能查到 是哪个用户 在什么时间 删除了这个操作，进行相关的追溯或者追责
以上，是以一个asset为例子，讲述了如何通过audit节点，查看操作记录
同理，page也是一样的可以这样查看，就不多阐述
【Tips】
有一种操作，导致的节点被删除，是不会被audit log记录的，我也不知道是AEM OOTB就没有打算记录这个操作还是一个产品的bug
就是这个
当你通过CRX Package Manger 进行装包操作对content下的节点进行修改时，是不会记录进audit log的
所以当需要追溯一个资产或者页面被删除的记录时，正确的Trouble Shooting的思路应该如下：
- 查找audit节点下，相应资产或页面对应路径的操作记录，如果能找到删除的记录即可定位追溯
- 如果找不到删除的记录，但资产或页面确实又被删除了，这个时候就要打开Package Manager，从资产或页面相应的记录里，找到最后一条操作记录的时间，在Package Manger里找这个时间之后安装的包，是否有包含这个资产或页面对应的路径，将相应的资产或页面覆盖了，导致被删除的
通过以上两点，大概率已经可以将问题解决
【写在最后】
其实通过我定位这类 资产或页面 误删除操作的经验来看
大概率这些页面和资产，都是业务人员，不小心给删除了
所以这样的记录也同时可以排除IT侧的责任，在追责的时候起到一个证明