什麼是跟蹤(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.對日誌存儲的服務設置較為嚴格的權限策略，避免數據被篡改或洩露；
如有任何疑問，歡迎加入操作審計官方技術支持群，我們會及時解答您的疑問。
