簡介

本篇將實際建立 CloudWatch Metric、Alarm、以及 CloudTrail 操作紀錄。

在上一篇 「Day28 維運之章 - CloudWatch、CloudTrail」 中，我們了解了這兩個服務的定位與差異：

• CloudWatch：系統監控與告警
• CloudTrail：行為審計與操作追蹤

本篇將帶你實際操作：

1. 建立 CloudWatch Metric Alarm
2. 整合 SNS 通知
3. 開啟 CloudTrail Data Event 並查詢操作紀錄

調整 IAM Role Policy

Step1：透過使用者 Joe 為 Full_Glue_Role Role 添加 CloudWatchFullAccess Policy

Step2：確保 Glue Job sliver_animes 有開啟相關的功能

• Enable the creation of CloudWatch metrics when this job runs.
• Enable the creation of additional observability CloudWatch metrics when this job runs.
• Enable logs in CloudWatch.

Step3：重跑 Glue Job sliver_animes

Step4：再次進入 CloudWatch 查看 Log groups，可以發現多出了兩個 Glue 相關的 Group

• /aws-glue/jobs/logs-v2：包含 INFO、WARN、ERROR 等全部輸出
• /aws-glue/jobs/error：包含 INFO、WARN、ERROR 等全部輸出
  • 包含 INFO 與 ERROR，偏向 Spark Driver 輸出
  • 錯誤通道的標準輸出，但並非只含錯誤訊息

Step5：查看 /aws-glue/jobs/logs-v2 內容

• logs-v2 Group 內還可以再看到多個 Log stream 以及 Last event time
  

• 進入 Log stream：jr_9de1b5ec8c5d54d06c41643c2a744d7d08eea145a3c55fa53821447d12b4740a-1

  • 可以看到一些基本的 event 事件紀錄

透過新增 Policy 給 Role 之後，我們可以正常的蒐集到 Glue 的相關執行 log，其他 AWS 服務也可以透過將 服務執行狀況的 log 紀錄載入到 CloudWatch 來做查驗。

確認 Metrics

Step1：進入 CloudWatch Metrics 頁面確認所有的 Metrics 內容，並點選 Glue 的 Metrics

Step2：確認 Glue 取得的相關 Metrics

• Observability Metrics Per Source（每個資料來源的觀測性指標）
• Observability Metrics（Glue 作業整體觀測性）
• Job Metrics（每個 Job 的執行指標）

Step3：透過勾選 Metrics 提供上方簡易的指標可視化線圖呈現資料，並且可以在下方看到相關的欄位

• JobName
• JobRunId
• Source

Step4： 點選「圖表化指標」頁籤，可以更清楚的看到相關欄位資訊

• ID
• 標籤
• 詳細資訊
• 統計資料
• 期間
• Y 軸

Step5：接著我們隨便調整 Glue Job sliver_animes 使其失敗

Step6：找到 Glue Job 失敗的 Metrics

以上即完成了產生 Glue Job 失敗 Metrics 的步驟，接下來我們再解釋一下相關 Metrics 的內容。

Metrics 解釋

在新版 AWS Glue (v4 / v5) 中，官方已經將原本的 JobRunsFailed、JobRunsSucceeded 指標改為以「Error Category（錯誤類別）」 為核心的觀測性指標 (Observability Metrics)。

這些指標會自動上傳到 CloudWatch → Metrics → Glue → Observability Metrics，
幫助我們即時監控 Glue Job 的成功、錯誤與資源使用狀況。

Glue Metrics 架構說明

Glue 會針對每個 Job 建立多種錯誤與成功指標，常見如下：

指標層級解釋

建立 Glue Job 失敗 Alarm

Step1：先至 Graphed metrics 頁籤，找到該 Metric，接著點選該筆 Metric 右邊的小鈴鐺

• Metric name：glue.error.SYNTAX_ERROR
• JobName：silver_animes
• JobRunId：ALL

Step2：點選鈴鐺後，會跳轉至 Create Alarm 的頁面

Step3：接著我們要設定 Alarm 的條件

• Threshold type：Static
• Condition：Greater than 0
• Period：5 minutes

Step4：再來要選擇傳輸的 SNS Topic，我們可以先選擇之前建立的 anime-etl-alert 即可點選下一步

若有需要調整，可再自行建立別的 SNS Topic。

Step5：接下來要為這個 Alarm 命名，我們先命名為 glue_fail_alarm，接著按下一步

Step6：最後要來確認剛剛選擇的內容是否正確，若確認後沒問題，即可點選 Create Alarm 完成建置作業

Step7：跳轉頁面後，確認是否有正常建立 Alarm 和啟用

Step8：驗證 Email 信箱是否有正常收到 Alarm 通知

以上即完成 Metrics Alarm 的建置，可以再透過不同的指標，搭配設定不同的 alarm，來滿足使用場景的警示通知機制。

實際操作 CloudTrail

CloudTrail 的三大事件類型

本次實作我們要來建置 S3 Bucket 的 Trail。

Step1：首先我們先透過使用者 Joe 進入 CloudTrail Dashboard 頁面

• 可以看到已經有一些預設的操作監控
• 接著我們要來實際建立我們所需的操作追蹤
• 點選 Creata Trail

Step2：設定相關內容

• 命名為 s3-anime-lake-trail
• 選擇 Use existing S3 bucket
• 選擇已存在的 anime-lake Bucket
• KMS alias 命名 s3-anime-lake-kms
• Role Name 命名 CloudTrail_s3_anime_lake
• 其餘選擇預設即可點選下一步

Step3：Event 設定

簡易介紹：

• 這邊我們可以直接全部選取

Step4：Management events 設定，選擇 read、write 權限

Step5：Data events 設定

• Resource type：S3
• Log selector template：Log All events

Step6：選擇 Insights 類型

⚠️ 注意：要啟用 Insights events，至少需勾選其中一項。
若兩者都未選，系統會顯示紅字：「Select at least one Insights type to enable Insights events」。

• 我們這邊一樣兩個都做選擇

Step7：Network activity events 設定

• Network activity event source：選擇 S3
• Log selector template：選擇 Log all events

Step8：確認設定的內容有無錯誤，若無誤就直接點選 Create trail

Step9：待頁面跳轉後，即可看到剛剛建立好的 s3-anime-lake-trail

Step10：接著回到 Dashboard 我們可以看到剛剛建置的 s3-anime-lake-trail，以及下方有一些預覽的 Event 狀況

Step11：再來我們至 S3 Bucket 確認有正常建置儲存 CloudTrail 的 Folder

• 若出現上述 .json.gz 檔案，即代表 CloudTrail 已成功開始寫入 Log。

Step12：然後我們在 Event history 驗證事件紀錄

• CloudTrail 主控台 → Event history

這些紀錄代表 Trail 的設定、啟動、串接 Log Stream 全部正常。

Step13：接著我們實際上傳一個 CSV 檔案到監控的 S3 Bucket 上，來看看會有什麼紀錄追蹤

• 使用篩選條件：Event Source 選擇 s3.amazonaws.com 後跳出以下 Events
  • GetBucketVersioning
  • GetBucketEncryption
  • GetBucketObjectLockConfiguration
  • GetBucketVersioning
  • GetBucketEncryption
  • GetBucketAcl
• 且有詳細的紀錄到是使用者 Andy 做的操作

Step14：接我們打開 GetBucketAcl 來看看裡面的內容

• 上方可以看到 GetBucketAcl 相關的 Detail 資訊

• 下方 Event record 則是一個 json 檔案，裡面會記載本次事件的詳細內容

以上即為 CloudTrail 相關的設定流程，可以根據所需的場景，來選擇適當的 Event 做追蹤，同時也有費用的問題，也請納入考量。

結論與建議

透過本篇的實作，我們已經完成了 Data Lakehouse 的監控基礎建設。

• CloudWatch 負責「即時監控」
• CloudTrail 負責「行為稽核與追蹤」
• 兩者搭配可以讓整個資料流程從 運作效能 到 安全操作 都有完整的可視化管理

🔹 建議做法：
✅ 啟用 CloudWatch Log Group，集中 Glue、Lambda 的運作紀錄。
✅ 為 Glue Job 設定 CloudWatch Alarm（失敗次數 > 0 時發送 SNS 通知）。
✅ 在 CloudTrail 中啟用 S3 Data Events，確保物件層級行為可追蹤。
✅ 搭配 Athena 或 QuickSight 對 CloudTrail Log 進行可視化分析。
✅ 為重要 Trail 設定 S3 Log 儲存桶加密與存取控管。

最終，我們的 Data Lakehouse 不僅能自動化運行，也能自我監控與稽核，成功建置 穩定、透明、可追溯 的雲端數據平台運作環境。

下篇預告

經過前面 29 天的修行，我們從零搭建出符合我們所需的 Data Lakehouse 架構。

在 最後一篇，我們將進行總結：

• 回顧整體架構設計與關鍵服務
• 分享這 30 天的技術心得與學習收穫

明天讓我們一起完成這趟「動漫宅的 30 天 AWS Lakehouse 修行日誌」的最後章節！

來源資料

[1] Amazon CloudWatch Documentation
[2] AWS CloudTrail Documentation
[3] Monitoring AWS Glue
[4] Logging data events for Amazon S3 with AWS CloudTrail