技能解封中間章程-城池間的隱形之眼(Azure Metrics)
上篇回顧迪亞波羅的手下地獄火門神,捧來的一個大禮讓天使城受到了一個天然的屏障,隱形結界,但只有魔眼監視還不足以完美的抗衡迪亞波羅。所謂知己知彼才能百戰百勝,順道把魔眼監視注入的隱鬼的靈魂,只要讓魔眼發現到可能到結界攻擊的傾向舉動,就會發動隱鬼向駐守邊疆城外的天使將士們保持警覺隨時能夠回防,回到人類聽得懂的代名詞"警示通知"小弟先簡述一下此服務究竟為何?
每當你所監視的服務中有偵測到所設定的警示條件時,會觸發主動通知的動作。讓你可以在IT管理人員發現問題之前能有所幫助並解決問題。在上篇整合了 Azure Monitor 包含先前由 Log Analytics 和 Application Insights 所管理的警示服務。在之前的警示類型都稱為傳統警示。現在都是直接由"警示"來取代掉從前的傳統警示類型。
警示規則需要備觸發而有進一步您設置所採取的動作。規則可以是啟用或停用狀態。而警示只有在啟用狀態才會觸發。
以下說明警示規則的關鍵屬性
1.目標資源 - 定義可用於警示任何 Azure 範圍資源。標的如:VM、Storage、VMSS(自動擴展)、WebApps、SQL等資源。均可指定多個資源作為警示規則的目標。
2.信號 - 由目標資源做觸發,可以是以下類型如:計量、活動記錄、Application Insights。
3.準則 - 用於目標資源信號邏輯間的組合。
4.嚴重性 - 符合警示規則中指定準則之後的警示嚴重性。 嚴重性的範圍可從 0 到 4。
5.動作 - 觸發警示時採取執行的動作群組。
警示對象監視來源為何?
最終就是兩項記錄和計量以下式列出較細的監視範疇
何謂智慧群組?
聽到智慧應該大家都很聰明直接聯想到就是AI,沒錯,是AI的起手式用ML機器學習搭配演算法自動建立問題的相關警示。每當警示建立時演算法就會根據歷史紀錄分析相似屬性結構等資訊,並自動將警示加至智慧群組中。舉例如果Azure 中有多個 VM 的 CPU 百分比同時出現突然激增導致每組個別都單獨觸發警示,而此類警示在過去分析到某一時段曾經一同發生則這些警示就會被分到一個獨立的新的智慧群中,來判斷未來的可能的"root cause"。
最後補充預覽的新功能篩選準則
我們可以在更精準的定義條件來縮小觸發的警示動作。而目前我個人認為比較常機會應用的篩選如下:
而光說不練怎麼行,實驗環境中會把持續關注的你/妳帶到小弟我的 wordpress.com Blog連結內容如下:
如果有興趣對您有幫助也請多多支持,歡迎給小弟建議或互相交流!