技能解封中間章程-城池間敢死報信者(Azure Alert)

前言

https://ithelp.ithome.com.tw/articles/10214085

 

成本評估

Azure Alert 依下列定價面向計費:

警示規則的費用會根據其監視的訊號類型與數目而定。訊號可為資源計數、記錄或活動記錄。監視多個訊號的警示規則成本,是監視每個訊號和所有已啟用功能的成本總計。

警示訊號 包含免費單位 價格
計量 每月 10 監視的計量時間序列 每月每個監視的計量時間序列 NT$3.006
記錄 15 分鐘 (含) 以上的間隔:每月每個監視的記錄 NT$15.028
10 分鐘的間隔:每月每個監視的記錄 NT$30.055
5 分鐘的間隔:每月每個監視的記錄 NT$45.082
活動記錄 無限制 免費
動態閾值 NT$3.006 /每月/每個動態閾值
  • 每個訂用帳戶的設定限制為 100 個計量時間序列警示、100 個活動記錄警示,以及 10 個動作群組。若要提高限制,請連絡 Azure 支援服務。
  • 活動記錄免費供應 90 天。如需於 90 天後保留活動記錄資料,可將活動記錄資料路由至儲存體帳戶或事件中樞。將分別對儲存體及事件中樞收取對應的費用。提取活動記錄資料的 API 呼叫不會產生費用。
  • Azure 資訊安全中心 (ASC) 附帶提供的警示目前並不收費。
  • 為健全準則建立的警示並不收費。

動態警示會就動態閾值功能與基礎計量警示收費。

範例如下:

  1. 為 10 部 VM 監視 CPU 使用率與 RAM 使用量 (即 2 計量時間序列),且啟用動態閾值的警示規則價格,以下列公式計算:
    • 警示規則價格 + 動態閾值價格。
    • (10 部 VM * 每部 VM 2 個計量時間序列 – 10 個免費單位) * 每月每個計量時間序列警示規則 NT$3.006 + [(10 部 VM * 每部 VM 2 個計量時間序列) * 每月每個動態閾值 NT$3.006] = 每月 NT$90.163
  2. 每 15 分鐘查詢 1 個 Log Analytics 工作區是否有 404 錯誤的警示規則價格,以下列公式計算:
    • 1 個工作區 * 每個記錄警示查詢 1 * 每月每個記錄警示規則 NT$15.028 = 每月 NT$15.028

通知觸發

功能 包含免費單位 價格
ITSM 連接器建立或更新事件12 每月 1,000個事件 NT$150.271/1,000 事件
電子郵件 每月 1,000 封電子郵件 NT$60.109/100,000 封電子郵件
推播通知 (對 Azure 行動應用程式) 每月 1,000 則通知 NT$60.109/100,000 則通知
安全的 Webhook 1 個安全的 Webhook NT$180.326/1,000,000 個安全的 Webhook
Webhook 每月 100,000 個 Webhook NT$18.033/1,000,000 個 Webhook

Azure Alert Q&A

上述定價是否適用活動記錄、服務健康狀態與資源健康狀態警示規則?

  • 可繼續免費使用活動記錄、服務健康狀態與資源健康狀態警示規則。

警示通知 (透過 Azure 動作群組) 的費用是否包含在警示規則的費用內?

  • 警示通知會根據使用的通知類型個別收費。

如果還是傳統警示平台上的既有客戶,是否適用上述的警示規則定價?

  • 上列定價適用新的警示平台。若你將現有警示規則從傳統警示平台移轉到新平台,則上述定價一律適用。

 

服務架構

警示規則需要備觸發而有進一步您設置所採取的動作。規則可以是啟用或停用狀態。而警示只有在啟用狀態才會觸發。

以下說明警示規則的關鍵屬性
1.目標資源 – 定義可用於警示任何 Azure 範圍資源。標的如:VM、Storage、VMSS(自動擴展)、WebApps、SQL等資源。均可指定多個資源作為警示規則的目標。
2.信號 – 由目標資源做觸發,可以是以下類型如:計量、活動記錄、Application Insights。
3.準則 – 用於目標資源信號邏輯間的組合。

  • CPU >= 70%
  • MEM >= 75%
  • 主機回應時間 >= 1sec

4.嚴重性 – 符合警示規則中指定準則之後的警示嚴重性。 嚴重性的範圍可從 0 到 4。

  • Sev 0 = Critical(重大)
  • Sev 1 = Error(錯誤)
  • Sev 2 = Warning(警告)
  • Sev 3 = Informational(資訊)
  • Sev 4 = Verbose(詳細資訊)

5.動作 – 觸發警示時採取執行的動作群組。

1.png

 

簡易實測環境

圖1. 找到警示服務

1.png

圖2. 先建立新的警示規則

2.png

圖3. 選擇你要警示的資源類型

3.png

圖4. 選擇WebApp 重新開機為觸發條件

4.png

圖5. 可以選擇圖表最近的時段區間,包含警示的邏輯

5.png

圖6. 已確定規則條件完成

6.png

圖7. 條件規則為啟用中

7.png

圖8. 選擇動作群組

8.png

圖9. 接下來常用的寄送郵件通知,不過這是改成對ARM的角色成員發送

9.png

圖10. 選擇Owner

10.png

圖11. 設置郵件通知完成

11.png

圖12. 動作群組此規則已啟用

12.png

圖13. 此為新功能我們進去看看

13.png

圖14. 決定在哪個資源群組下選取的資源服務

14.png

圖15. 選擇觸發後的執行動作

15.png

圖16. 完成後回到規則檢視其中嚴重層級被歸類為4

19.png

圖17. 所以如果此層級不需要觸發可以在此勾選

16.png

圖18. 設置動作規則確認欄位是否正確,如果無誤就確定

20.png

圖19. 透過檢視傳統警示

21.png

圖20. 開啟活動紀錄警示

22.png

圖21. 這裡才有剛剛設置的規則

23.png

 

 

 

 

 

技能解封中間章程-城池間的隱形之眼(Azure Metrics)

前言

https://ithelp.ithome.com.tw/articles/10214083

 

成本評估

Azure Metrics 依下列定價面向計費:

計量代表一組時間序列。會依監視的時間序列數以及進行的 API 呼叫數計費。目前,計量查詢和自訂查詢不會產生任何費用。計量查詢與自訂計量的收費標準將自 2019 年 12 月 1 日起生效。

功能 包含免費單位 價格
標準計量 無限制 免費
自訂計量 每月 150 MB NT$7.754/MB:150-100,000 MB

NT$4.539/MB:100,000-250,000 MB

NT$1.834/MB:高於 250,000 MB

計量查詢 每月 1,000,000 個標準 API 呼叫 NT$0.301/1,000個標準 API 呼叫

標準計量類型如下:

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported

計量查詢費用以標準 API 呼叫數目為依據。標準 API 呼叫是會分析 1,440 個資料點的呼叫 (1,440 也是每個計量每天可儲存的總資料點數)。

如 API 呼叫分析 1,440 個以上的資料點,即計為多個標準 API 呼叫。如 API 呼叫分析 1,440 個以下的資料點,則計為不到一個 API 呼叫。標準 API 呼叫的數目會每天計算,計算方式為每日分析的資料點總數除以 1,440。

計量免費供應 90 天。若要在 90 天後保留計量資料,可將計量資料路由至儲存體帳戶、Azure Log Analytics 工作區或事件中樞。將分別對儲存體、Log Analytics 及事件中樞收取對應的費用。此外,計量查詢將會為路由資料所需的對應 API 呼叫計費

範例如下:

  • 分析 2,000 個資料點的 API 呼叫會計為 2,000/1,440 = 1.4 個標準 API 呼叫。
  • 分析 200 個資料點的 API 呼叫會計為 200/1,440 = 0.1 個標準 API 呼叫。
  • 以一分鐘資料粒度從 100 部 VM 追蹤五個計量一天的情況下,會產生 720,000 個資料點,進而轉譯成每天 (720,000/1,440) 500 個標準 API 呼叫。

 

Azure Metrics Q&A

支援 Azure 監視計量的參考有哪些?

https://docs.microsoft.com/zh-tw/azure/azure-monitor/platform/metrics-supported

 

服務架構

Azure Monitor 所收集的資料均符合以下兩種類型:

  • 計量則是描述系統在當前時間區間的某個行為表現。此屬輕量服務能支援近乎即時的實例。
  • 記錄則包含各種不同類型資料,並針對每個類型組織成不同的屬性。除效能資料外,還會將事件和追蹤的遙測資料儲存為記錄,並整合一起來進行分析。

Azure Monitor 可從各種來源收集資料。包含各層級中的應用程式監視資料,範圍從您的應用程式、它所倚賴的任何作業系統和服務再到平台本身。所收集的資料來源類型如下:

  • 應用程式監視資訊 – 程式碼效能或相關功能資訊。
  • Guest OS 監視資訊 – 關於應用程式執行所在作業系統的資料。可以是 Azure 以外包含其他雲端或企業內部監視。
  • Azure 資源監視資訊 – Azure 資源操作行為資訊。
  • Azure 訂閱帳戶監視資訊 – 關於訂閱帳戶作業管理及 Azure 本身健康監視情況的資訊。
  • Azure 租用戶(tenant)監視資訊 – 租用戶層級作業相關如:Azure Active Directory。

1.png

簡易實測環境

圖1. 其實每個服務下的刀鋒視窗只要有計量服務都可以直接運用,結果都一樣但前著是針對明確的目標標的,所以從訂閱到資源群組到服務都已經歸納好比較方便,這次示範標準作法

01.png

圖2. 貼心的可以從最近的資源來選擇(需要的話)

02.png

圖3. 選擇指定訂閱

03.png

圖4. 選擇指定想監視計量的資源群組範圍

04.png

圖5. 選擇指定的服務,列出全部也無法,如果服務不多,方便找即可

07.png

圖6. 指定虛擬機器的網卡

08.png

圖8. 選擇接收的度量

09.png

圖9. 多維度(也可以是不同VM的網卡但同個傳送度量一起比較)同一張網卡選擇傳送的度量

10.png

圖10. 自訂好辨識管理的名稱(不然會把你所有的計量一長串往上加不好管理)

11.png

圖11. 為了想要把不同類型的度量分開,透過新增圖表呈現(可透過不同圖形分開表示)

12.png

圖12. 可以把目前設計好的透過共用功能複製其連結打算給另個管理帳戶來做後續調整設置

13.png

圖13. 把連結複製到無痕瀏覽避免Cookies問題

14.png

圖14. 會跳出登入畫面,改用其他管理帳戶來登

15.png

圖15. 開啟後呈現畫面就跟剛剛設計的一樣,都一樣可以在做邊修

16.png

圖16. 調整完成後就可以釘選至儀表板上

17.png

圖17. 可以再做細部微調包含呈現磚塊大小

18.png

圖18. 開啟自訂磚資料

19.png

圖19. 可以從這邊來決定更新的範圍時間區間

20.png

圖20. 設置完成

22.png

技能解封中間章程-城內防禦機關重啟(Azure Policy)

前言

https://ithelp.ithome.com.tw/articles/10214082

成本評估

Azure 原則為免費

 

Azure Policy Q&A

哪些區域可使用 Azure 原則?

  • Azure 原則已在所有提供 Azure 的區域正式推出,包括國家雲端。

可以自建原則嗎?

  • 可以。Azure 原則隨附一組內建原則,但您也可以建立自訂原則

Azure 原則支援哪些 Azure 資源?

  • 所有 Azure 資源。

可排除資源或訂用帳戶嗎?

  • 可從原則指派中排除資源、資源群組、帳戶訂閱或管理群組。

服務架構

上一篇章RBAC多屬於人為本身的權力委派控制這段,而最終目的還是資源,故回歸保護監視限制在訂閱->資源群組->資源本身的政策執行的保護就是此服務的優勢。

ARM-Policies.jpg

 

簡易實測環境

僅 Allowed storage account SKUs 來做為示範

以下是透過已提供的 JSON 檔作為範例:

https://docs.microsoft.com/en-us/azure/governance/policy/samples/allowed-storage-account-skus

圖1. 透過此範本來做佈署,最下面有個 Azure Portal 佈署按鈕

6.png

圖2. 選擇範圍(通常是整個訂閱為主,並建立新項目名稱這樣日後自訂的都可以放此比較好辨識)

8.png

圖3. 確認剛剛設置的原則在自訂類型確實已建立

9.png

10.png

圖4. 套用剛剛建立的原則

11.png

圖5. 除了指派套用剛剛的原則外重要的是下面允許的SKU (我只允許標準LRS層級其餘皆不允許)

12.png

圖6. 最後範圍地區我選擇了美國東部(也就是整個訂閱下只要是美國東部地區建立儲存體都不允許標準層LRS以外的建立)

13.png

圖7. 指派建立完成

14.png

圖8. 在美國東部示範建立儲存體選用標準層LRS以外的等級(此時還沒經過原則偵測顧驗證是正常)

15.png

圖9. 有了,很明顯寫到原則限制讓此次建立失敗,可以套用各公司企業避免無預警誤建或亂建導致成本上升的情事

16.png

圖10. 進一步看就會檢視到JSON檔裡僅允許的層級,此層及以外的都擋掉

17.png