iT邦幫忙

2025 iThome 鐵人賽

DAY 24
0
Security

導入CDN防護大作戰系列 第 24

【Day24】上線前的救命仙丹~~監控告警設定

  • 分享至 

  • xImage
  •  

隨著準備工作到了一個階段,顧問開始要跟Jerry講關於告警設定的事。

顧問問了Jerry一個問題,你覺得監控要做哪些事情?目的為何?

Jerry回答,不就是PING一下服務有沒有正常,然後主機CPU、Memory有沒有正常,還有別的嗎?

顧問聽完後搖搖頭,HTTP的服務可不能像網路設備這樣監控阿!!

既然你提到網管的監控,我用一個網路管理模型來跟你講監控的重要性,那就是FCAPS!!

FCAPS

FCAPS(故障、組態、資源、效能和安全)是由國際標準化組織(ISO)創建的網路管理框架和模型。這種網路管理模型的主要目標是更好地了解網路管理系統的主要功能。
文章參考-什麼是 FCAPS 故障、組態、資源、效能和安全性

https://ithelp.ithome.com.tw/upload/images/20251007/200427798R65XzRCMk.png

  • 障礙管理 :透過即時的品質的監控以及告警,並使用趨勢分析預測錯誤的發生,以辨別可能的故障,原因並避免日後同樣問題重複發生。

  • 組態管理 :妥善組態異動設定,並完善版本控管以及備分,確保任何的異動都在掌握之中。

  • 資源管理 :提供所有網路節點上,設備即時的使用率變化以及歷史資料的查詢與分析,以利未來容量規劃的管理與計劃。

  • 效能管理 :藉由收集和分析效能資料建立量測與品質效能等基準值,並利用相關防護機制避免干擾,發揮服務應有效能。

  • 安全管理 :透過日誌與流量分析以及告警管理,避免惡意或非正當使用者接近並消耗網路及主機資源。

現在來帶你看一下該如何完成這個機制,或是逐步完成。

障礙管理

針對HTTP服務以及CDN架構特性,先理解要監控什麼,再針對監控的內容設定告警。

首先HTTP的請求及回應都會以Http狀態碼的呈現結果,狀態碼分為5類:

  • 1xx :資訊回應。
  • 2xx:成功回應。
  • 3xx:重新導向。
  • 4xx:用戶端錯誤回應。
  • 5xx:伺服器錯誤回應。

Akamai 因應一些無法在既有Http狀態碼可明確定義的情況,額外增加了0xx。

  • 0xx :源站無回應。

透過監控不同Http狀態碼於一定時間內產生的頻率次數,就可以透過告警,提醒網站管理員注意網站的情況。

舉個例子 : 500 Internal Server Error (伺服器遇到一個它不知道如何處理的情況,或是執行發生錯誤)

如果在短時間內,你收到過多的500請求而觸發告警!! 那有可能是以下兩種情況

  1. 主機可能因為效能的原因,無法正常處理請求一直發生錯誤。
  2. 外部請求找不到對應的資源,因此不知道如何處理。

https://ithelp.ithome.com.tw/upload/images/20251007/20042779PIAUawQvsf.png

從資安的角度來看,極有可能是外部的攻擊請求穿越所有防護,而且已經送到源站的AP主機。

透過這個告警不僅讓管理者發現服務現況,還可能發現資安的問題。

Jerry問,那Akamai服務發生故障時會通知嗎? 怎麼知道?

顧問回答,你可以看以下網站 Akamai Status ,或是透過平台上的Notifications機制接收最新的故障通知。

組態管理

Jerry搶答這個我知道,就是你先前講過的 測試環境與版本控制

影響服務當然也包含,錯誤的設定以及不完整的測試,因此組態管理就顯得非常重要。

Akamai平台上的異動紀錄包含異動時間、異動人員帳號、異動原因以及版號,對每一代啟用的歷史紀錄,可以清清楚楚的交待所有異動的軌跡,是組態管理的模範生。

資源管理

基本上你不用擔心Akamai的資源不足夠,他敢跟你強調100% SLA,就代表他承諾要做到。

但從整體請求路徑來看,CDN回到源站的入口請求服務時,包含網路頻寬、主機資源等等,只要有異常就會影響服務。

有時你會聽到CDN業者跟你說,有了CDN,ISP的線路就不用租這麼大條水管了。

如果你是純靜態網站,的確會因為快取的關係降低對網路頻寬的需求。但現今網站動靜態都混在一起,也多了很多一定要回源請求的功能。

此時會發生一個情況,以往你家的頻寬大門是限制,塞滿了就無法再提供。但有了CDN後,CDN的大門比起以前你家大很多,那這些要回源的請求只要沒被阻擋,反而會會狂塞猛送的回你家!!

所以地端的監控也必須要能針對資源提供即時的告警,讓管理員介入處理。

效能管理

如果是在地端的網路效能管理,通常都會搭配ICMP以及封包分析的方式,來確認整體網路架構回應品質。

但在CDN,雖然你無法再介入這個過程,但有些機制或方式供你參考:

  1. 導入應用程式效能監控APM之類的產品,例如Dynatrace

  2. 透過網站效能監控的產品,例如Akamai自家的 mPulse 產品或是其他免費服務,可以針對頁面載入時間、前後端回應時間等,進行分析並提供建議。

安全管理

應該不用再特別說明分析防護日誌的重要性,這邊要提醒的反而是防護設備本身的安全性。

考量若防護機制出了漏洞被利用,勢必也會影響服務或是防護資源,因此防護機制或是設備本身的弱點或是漏洞問題,也都應該時刻去關心及了解。

例如很有名的HTTP/2 快速重置漏洞(CVE-2023-44487),可導致大規模第7層DDoS攻擊,漏洞發佈時,就應該了解CDN服務商有沒有針對此問題修補了。How Akamai Protects Customers from HTTP/2 Rapid Reset DDoS Attacks

常用Alerts設定

我已經先幫你把所有上線的服務設定了一些告警,來看看有哪些?

  • Origin Connection Failure :源站連線失敗,通常是源站無法接受CDN主機的TCP交握導致,請檢查對外ISP的線路狀態,或是內部網路及主機服務異常。

  • Origin Read Error : 源站請求讀取失敗,CDN與主機已經建立好TCP連線,但轉送的請求都沒有收到回應,通常都是地端地端防護機制阻擋了請求。

  • Origin DNS failures :CDN主機無法解析源站的DNS位置,請立即檢查對外DNS服務或是網路服務是否異常。

  • Origin Server Failure (HTTP 5xx errors) :源站在一定的時間內,回應HTTP 500的次數超過閥值設定,請先確認源站服務是否異常,若否則可能為外部攻擊。

  • Origin Object Not Found (HTTP 404 errors) :源站在一定的時間內,回應HTTP 404的次數超過閥值設定,請透過即時日誌分析機制,確認是網站掃描攻擊還是網站程式更新的問題。

  • Origin SSL Transaction Failure :CDN主機與源站的TLS交握出現問題,有可能是憑證到期或損毀等問題。


上一篇
【Day23】上線前防護機制的調整
下一篇
【Day25】上線慘況實錄1 - 一出場就陣亡
系列文
導入CDN防護大作戰25
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言