【AEM Daily】Audit Log

【关于AEM】

Adobe Experience Manager （AEM）

一个将 Content Management System （CMS）与 Digital Asset Management （DAM）的强大功能相结合的企业级应用

【正文】

在我们日常使用AEM Sites 和 AEM DAM的时候，经常会遇到类似以下这样的问题：

• Publish实例上的一个Active的页面，不知道什么时候被哪个用户Deactive了
• Author上的一个还在编辑中，还没发布的页面，不知道什么时候被那个用户Delete了
• Author上的某个资产或资产文件夹不知道什么时候被哪个用户给删除了

这个时候，相关的业务人员就会着急的找到IT人员求助，大概也就是这样一系列让人脑阔疼的场景：

1. “我这个页面怎么突然就不见了，快帮我恢复！！！”
2. “帮我查出这是谁干的，我要他负责！！！”
3. “是不是你们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的思路应该如下：

1. 查找audit节点下，相应资产或页面对应路径的操作记录，如果能找到删除的记录即可定位追溯
2. 如果找不到删除的记录，但资产或页面确实又被删除了，这个时候就要打开Package Manager，从资产或页面相应的记录里，找到最后一条操作记录的时间，在Package Manger里找这个时间之后安装的包，是否有包含这个资产或页面对应的路径，将相应的资产或页面覆盖了，导致被删除的

通过以上两点，大概率已经可以将问题解决

【写在最后】

其实通过我定位这类 资产或页面 误删除操作的经验来看

大概率这些页面和资产，都是业务人员，不小心给删除了

所以这样的记录也同时可以排除IT侧的责任，在追责的时候起到一个证明