中秋連假的第二天，大家烤肉吃得如何，有抬頭看看很大的月亮嗎?
今天我們來一起看看 CloudFront Log 的設置。
CloudFront 的日誌分為兩種，標準日誌 (Standard Logs) 和 即時日誌(Real time logs)。
絕大多數的情況下，Standard Logs 都可以提供充分的信息，我們這篇以其為主。

標準日誌 (Standard Logs)

如何開啟

開啟 Standard Logs 的方式很簡單，在設定 Distribution 時就可以直接設定。
其中設定Prefix 也可以讓你的檔案存放在如資料夾的結構中，很建議使用。

但有些額外注意事項。

1. 部分 Region 的 S3 bucket 不能拿來存放 CloudFront Log (ex: ap-east-1|HKG, eu-south-1|Milan, af-south-1|Captown .. 等)。目前看來只要是 Opt-in Regions 的 S3 Bucket 就不能拿來放 CF Logs.
2. S3 bucket 必須啟用 ACL，透過 ACL 的設置，會允許 CloudFront 過來寫日誌。bucket 對應的 object ownership 也「不能」是 bucket owner 'enforced'，應為「bucket owner preferred」。
3. 如果你不小心關閉了 S3 Bucket 的 ACL，除了重新啟用外，也要確保特定的 canonicalid 可以有 list & write 的權限。 canonicalid: c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0
   4.
4. 設定好日誌功能之後，從發送請求到標準日誌產出之間可能會有幾分鐘的時間差，這是正常現像。

當設定完畢，就可以等請求進入 CloudFront 產出日誌囉。

日誌欄位

標準日誌中有一堆欄位，可以參考這裡(目前有33個欄位)。
(如果都貼出來有點太混，所以還是不貼好些)

日誌保留/定期清除

除非有特別需求，一般來說日誌通常僅會需要保留一段時間，之後就可以刪除。(ex: 13 個月、半年、或者更短)。而因為標準日誌是存放在 S3 之中，所以我們可以利用 S3 提供的 life cycle management rule 來達成自動清除的目標。設定路徑為 s3 console --> bucket --> management --> Lifecycle configuration。
比方說，可以設定日誌檔案在 13 個月後清除。這樣確保可以做最基本的 YoY 回顧。(除了刪除，也可以搬遷至其它的 StorageClass，如 Standard-IA、或者是 Glacier。)

日誌分析

至於分析日誌，我一般推薦以下四種方式。

1. (強烈推薦) Athena: AWS Athena 是基於 Presto 提供的 Managed Service，讓我們可以直接以 SQL Query指令來查詢日誌。作法步驟包含:
   a. 進入與存放 CloudFront 日誌的 S3 bucket 同一 region 的 Athena Console
   b. 在參考[這文件]中的 Query，調整對應的 Table 的名稱，S3 bucketname(含 prefix)，建立 Table

CREATE EXTERNAL TABLE IF NOT EXISTS default.cloudfront_logs (
  `date` DATE,
  time STRING,
  location STRING,
  bytes BIGINT,
  request_ip STRING,
  method STRING,
  host STRING,
  uri STRING,
  status INT,
  referrer STRING,
  user_agent STRING,
  query_string STRING,
  cookie STRING,
  result_type STRING,
  request_id STRING,
  host_header STRING,
  request_protocol STRING,
  request_bytes BIGINT,
  time_taken FLOAT,
  xforwarded_for STRING,
  ssl_protocol STRING,
  ssl_cipher STRING,
  response_result_type STRING,
  http_version STRING,
  fle_status STRING,
  fle_encrypted_fields INT,
  c_port INT,
  time_to_first_byte FLOAT,
  x_edge_detailed_result_type STRING,
  sc_content_type STRING,
  sc_content_len BIGINT,
  sc_range_start BIGINT,
  sc_range_end BIGINT
)
ROW FORMAT DELIMITED 
FIELDS TERMINATED BY '\t'
LOCATION 's3://CloudFront_bucket_name/'
TBLPROPERTIES ( 'skip.header.line.count'='2' )

c. 開始查詢
2. command line or 自己寫程式: 如果要查詢的資料量不多，或者你夠 Hardcore 喜歡寫程式自己來，這是一個推薦的方法。如果你熟悉文字處理，這方法通常可以很快就找到資料。
3. 透過 excel，比方 pivot table(樞紐分析): 相較於 Athena 時，分析的人可能比較明確知道想要看的是什麼，而 Excel 提供了一個方便的管道。比方說，可以很簡單的將請求區分抵達的「小時」「分鐘」甚至「秒鐘」。但不同於前兩者， Excel 的單一 sheet 有資料「行數」(number of rows)限制，最大數量為 1,048,576 (2^20)。
4. 透過 Cetralized Logging with Opensearch: 這邊有更完整的教學，可以直接參考。

推薦日誌分析小貼士

如果你想要分析 CloudFront 日誌，那麼以下是我建議可以考慮的查詢資訊。

1. 分 URL(cs-uri-stem) 統計 5xx 及 4xx 數量，看日誌中哪些 URL 最容易出現 4xx 和 5xx 錯誤。如果要改善，從錯誤較多的項目下手，總是比較能帶來明顯地進步。
2. 對 CloudFront 來說， TTFB (TimeToFirstByte) 是很重要的指標，但這個指標會因為有無 Hit Cache 而有很大的差異。所以如果要分析 TTFB，建議同時針對 cs-uri-stem(含 cs-uri-query) + x-edge-result-type 的組合分類。
3. 在 Athena 分析過的 Query會存下來，可以直接在 console 下載，不需要重新執行才能作。
4. 如果日誌的量實在太大(生意很大，每天都一堆請求)，請參考這文件將 CloudFront log 進行 partition，可以有效的加快 Athena 查詢的速度。
5. 因為 Athena 是基於 Presto 的服務，可以將 Presto 也作為關鍵字加入查詢。也推薦一個在分析時好用的 function: approximate，這可以用來計算百分比分為(ex: P95)，下面的範例 Query 可以找出 /index.html 的 TTFB 的 P50 & P95 值.

select approximate(time-to-first-byte, [0.5, 0.95])  from my_cf_logs
where date in date('2023-09-30') 
and uri like '/index.html'

Okay, 這就是今天的內容啦，一起透過分析日誌來瞭解你的客戶行為吧 :)