什么是跟踪(Trail)？
操作审计仅保留记录您在云上90天窗口期的操作日志，超过该时间段的日志将会被自动丢弃，并且仅支持简单的日志过滤分析。基于这些限制及大量客户的实际需要，操作审计提供了投递服务：跟踪。
跟踪(Trail): 持续且实时地把您的云账号在云上的操作日志投递到您配置的存储服务，如日志服务(SLS) 或对象存储(OSS)。
什么时候需要使用跟踪？
您需要考虑您所在企业是否存在以下诉求：
• 需要记录超过90天的云上操作日志；（公司IT部门要求或安全合规部门要求）
• 需要对操作日志进行归档或下载；
• 需要对操作日志做精细的分析、统计及解读；
• 在未来，如果发生异常操作，需要追溯事件原因及定责；
• 在未来，需要应对合规部门要求提供几年的云上操作日志；
• 在未来，不确定性很多，以备不时之需；
如果以上所列的场景已经匹配的您的诉求，我们建议您使用操作审计的跟踪服务，将您在云上产生的操作日志持续投递到您设置的存储服务中。
创建跟踪
步骤 0: 进入创建跟踪页面
知识点1: 操作审计分地域部署，按照合规要求，用户在云上的操作日志会在当前发生的地域存储。但是在跟踪配置中，您仍可选择将日志投递到其他地域的存储服务进行存储（这属于用户行为）。
比如您在杭州(cn-hangzhou)创建了一个投递所有读写事件的跟踪，并配置存储位置为上海(cn-shanghai)的日志服务，那么跟踪所属地域为杭州(cn-hangzhou)，但日志仍然会按照跟踪设置投递到上海(cn-shanghai)的存储服务中。
为了方便您查看和后续的管理，我们还是建议您将跟踪地域和日志存储的位置设置在同一个地域。
图解：当前您所在的地域为“华东1(杭州)”。
步骤1: 跟踪基本属性
• 设置跟踪名称：操作审计会根据您设置的跟踪名称，对日志进行归档，起一个好记且有意义的名称也非常必要；
• 跟踪的地域： 您可选择将全部地域或部分地域的日志进行存储；
• 事件类型：云产品对事件做了读写分类，简单可理解为：读事件表示“CRUD”中的“R”，写事件表示“CUD”；（CRUD: Create, Retrieve, Update, Delete)
• 企业账号可选 应用到所有成员账号: 针对企业账号，操作审计建议您对组织中所有成员账号的日志进行中心化存储；
知识点2: 根据大量的客户案例总结的最佳实践来看，建议您的第一个跟踪将“跟踪的地域”设置为“全部地域”，事件类型设置为“所有事件”；
步骤2: 审计事件投递
操作审计目前支持日志服务(SLS)，对象存储(OSS)，若暂未开通相关服务，可以前往开通。
关于如何选择存储服务，需要结合您实际的业务需要。
以下是两个产品的简单对比：
| 产品对比 | 日志服务SLS | 对象存储OSS |
|---|---|---|
| 支持长期保存操作日志? | Yes | Yes |
| 支持归档 | No | Yes |
| 支持下载 | Yes | Yes |
| 支持实时分析 | Yes | No |
| 价格 | 相对较高 SLS成本计算器 | 相对较低 OSS计费方式 |
对象存储OSS 结合 DLA 也能实现类似 SLS 提供的在线搜索分析功能，具体可参考文档: 使用DLA分析OSS中的操作日志。配置对象存储(OSS)的投递，强烈建议开启防篡改(WORM)，尤其是归档存储时，成本非常低，适合平时查询分析需要比较少的场景。
SLS 适合平时查询分析比较多的场景， 同时操作审计提供基于日志服务(SLS)的高级搜索功能，您也可直接前往日志服务控制台对操作日志进行实时分析，快速分析及定位问题。
知识点3: 我们建议您在日志服务(SLS)中保留近期数据（如90天、180天），这些数据经常需要分析；对象存储(OSS)对日志长期保存，用于归档和满足合规需要，并开启防篡改设置(WORM)。
操作审计会根据您填写的跟踪名称创建一个名称为 actiontrail_${trailName} 日志库(Logstore)。
步骤3: 预览并创建
创建跟踪时，操作审计将会自动创建一个服务关联角色，以完成相应功能。若角色已存在，则不会重复创建。
跟踪创建成功后，同步任务会开启投递服务，但是可能会存在5-10分钟的延迟，请耐心等待。
自助验证
如果在对应的存储中依旧没有找到任何日志，可进行如下自助排查：
1.确认跟踪是开启状态；
2.确认跟踪配置的存储位置正确；
3.确认在跟踪的地域发生过指定事件类型的操作(如控制台查看，操作等都会记录操作事件)
4.确认对应服务选择的时间区间是否正确；
跟踪分析
进入跟踪详情，即可查看到跟踪的信息及投递到日志服务(SLS)的实时日志。
场景1： 谁修改了我的Ecs实例名称
背景：某创业公司Leader 鲍勃周一上班时始终无法找到一个名为 launch-advisor-20201208 的Ecs实例，花了半个小时发现，实例名称被人修改，为了把这个“恶意篡改者”找出来，他决定来操作审计控制台进行日志分析；
问题1: 有很多跟踪，到底该用哪一个呢？
1.检查跟踪的开启状态
2.检查跟踪的region和跟踪的事件读写类型
知识点4: 前面建议您创建一个记录所有地域，所有事件类型的跟踪，并持续保持开启状态，就能立马派上用场。
最终发现一个名为 actiontrail-events-of-ziji 的日志库是符合要求的。进入到跟踪详情页，即可进行实时的数据分析。
通过查找 Ecs 的文档发现，修改实例名称使用了一个名为 modifyInstanceAttribute 的API。
问题2: 如何写SLS的查询分析语句
分析SQL如下：
* and event.eventName: modifyInstanceAttribute设定搜索时间为昨天晚上6点到当前时间，立刻发现了这条操作记录，锁定了“篡改者”，这是一个名为 ziji 的ram子账号在昨晚8:06分做的修改。
场景2: 谁停用了我的配置审计规则？
背景：公司小高是公司的运维同学，现在公司发展壮大，已经有超过200台ECS实例，小高想要看下，目前哪些机器的核数小于2的，如果在ECS的控制台查看，非常麻烦，需要切换不同的地域。于是使用了阿里云的另一款审计产品：配置审计。
新建了一条检查机器核数的规则。 但是突然有一天，他发现，规则不知道何时被人停用了，一定要把这个恶意删除规则的人找出来，当面批评一番。
虽然规则停用对应的API不记得了，我们可以根据资源名称 + 读写类型来缩小搜索范围。
很快就根据资源名称锁定到目标操作日志: 主账号root在12/23号 下午2点调用 stopConfigRules 停用了 我的规则。
推荐阅读
操作审计提供了更多典型的分析案例，可供您参考：
• 使用DLA分析OSS中的操作日志
• 在 SLS 中分析ActionTrail跟踪投递日志
• 通过操作审计监控AccessKey的使用
• 通过操作审计监控阿里云账号的使用
附录：创建跟踪最佳实践
操作审计结合大量客户案例给出如下最佳实践:
1.为每一个账号设置一个记录所有地域，全部读写类型日志的跟踪；
2.如果有需要分析日志的场景，建议重新建一个跟踪；
3.如果是企业账号且开启了资源目录，且多个账号在一个资源目录内，建议在创建跟踪时勾选“将跟踪应用到所有成员账号”，这样就可以避免成员账号错误的操作导致跟踪日志丢失或者暂停记录的情况；
4.对日志存储的服务设置较为严格的权限策略，避免数据被篡改或泄露；
如有任何疑问，欢迎加入操作审计官方技术支持群，我们会及时解答您的疑问。
