OMS 警示正式發布

與 public review 有何不同? WebHook 支援:提供 WebHook URL 來接收警示。這使得與其他工具(如:Slack 或是 各種事件管理工具)結合變得很容易。   開啟/關閉和編輯警示:在 設定>Alerts 中,您可以開啟、關閉或是編輯單一的警示。您可以在此關閉惱人的警示或是在維修時關閉警示。   隱藏警示:在警示發佈後,停止警示一段時間。這能幫助減少警示的干擾。   新增警示畫面:在未來您還會看到這個使用者介面有些許的修改。 效能進步:最大搜尋時間間隔可達24小時。 在 OMS 工作區右上方的通知:現在當您進到 OMS 工作區,將會在通知告訴您當您離開的時間內有多少警示發佈。在通知中您也可以有連結查看所有發佈的警示。   警示嚴重性:總共有三種程度可以選擇:嚴重、警告、資訊。 OMS 警示還會繼續更新嗎? 當然會!警示是任何良好監視工具的基礎,因此微軟將會持續更新、改進 OMS 警示的功能。在未來您將會看到微軟積極採取行動來減少警界時間,並對警示管理進行修改來提供更有凝聚力的警示監控與管理。 開始使用 雖然您需要利用搜尋指令來產生警示,但其實您不需要知道任何搜尋語法就可以使用警示。最簡單的方式就是透過一個方案來做搜尋。 進到一個解決方案的儀表板後,點選任何您想建立警示的項目。接著 OMS 將會自動跳到記錄搜尋並之行該指令。 執行完後,您可以按下左上方的 [警示] 圖示。接著就會跳到先前提到的新增警示畫面,輸入各項資料後按下儲存即完成警示的新增。 有什麼好的警示可以作為開端嗎? 以下列出了一些有用的搜尋指令警示來幫助您開始,也列出了指令相對應所需的方案或是數據來源: Name Query Alert configuration Required solution/data source Computers missing required Critical or Security…


MS OMS 和 SCOM 之間的 Control management pack 更新

概要:學習如何從 OMS 到 SCOM 停用 automatic management pack 的更新並將更新限制在特定的時間間隔內。 當您將 SCOM 中的 management group 連結到 OMS 中的 Log Analytics,多個 management pack 將會自動安裝到您的  management group 中。除了有一套核心的 management packs 來支援連結和基本的數據收集,其他將會針對您添加到 OMS 工作區的方案進行安裝。您可以透過在 Administration workspace 中的 Management Packs 下搜尋 Advisor 來查看整個列表。   在初始安裝後,SCOM 會定期檢查 OMS 來獲得這些 management packs 的更新,並在可用時自動下載和導入。這在很多環境中都運作的很好,因為您在 OMS 和 SCOM 的結合會自動保持更新而您無須花費任何心力。儘管在低頻寬或是嚴格變更控制過程中,這可能會是一個問題。在這些情況下,您可能會想要關掉此自動更新,如此才能讓頻寬不會在高峰時斷消耗,並讓變更不會在您批准的時間間隔之外產生。 此更新過程被以下兩種規則所控制: Microsoft.SystemCenter.Advisor.MPUpdate 更新基本的 OMS management packs。預設每12小時執行。 Microsoft.SystemCenter.Advisor.Core.GetIntelligencePacksRule 更新您工作區中方案的 management packs。預設每5分鐘執行。 您可以輕易地利用 建立覆寫 來停用自動更新並停用上兩個規則。您可以撤銷覆寫來重新啟用並允許執行更新。您應該定期將其啟用來保持您的管理群組是最新的。 覆寫更新規則…


[OMS] Portal issues – HTTP Error 400

Hi, Sometimes the OMS portal seems to have various issues, so I will write about some that I encounter. For example “HTTP Error 400. The size of the request headers is too long” Usually this error happens if there is a corruption in the browser cache or cookies.   What to try which usually solves…

3

利用 OMS 幫遺失的安全性更新和其他更新建立警示

概要:學習如何利用 OMS 警示功能來產生基於遺失安全性或其他更新的警示。 找一個好的搜尋指令 要找一個能夠回報遺失的安全性更新和其他從您系統中遺失的更新的指令,最簡單的方式就是利用 系統更新評定方案。 Note:若系統更新評定方案沒有在您的 OMS 概觀中,您可以到方案庫增加此方案。 進到系統更新評定方案的儀表板後,您可以很直接地看到遺失重大或安全性更新的數量和遺失重大或安全性更新超過30天的電腦。此外,還可以看到遺失更新的總數量。下圖是在概觀中 系統更新評定方案 的概述方塊: 選擇要配置的安全性和更新警示 您需要做的就是決定您需要的是哪種警示。這將會決定您執行的指令的種類。此範例中想要對所有遺失重大更新或遺失安全性更新的來源做警示 – 不考慮遺失的時間和遺失的數量。因此選擇了 Critical or Security Updates 方塊進行搜尋。如下圖: 在此搜尋背後的指令: Type:Update (Classification:”Security Updates” OR Classification:”Critical Updates”) AND UpdateState=Needed AND Optional=false AND Approved!=false | measure count() by Computer 在記錄搜尋頁面選擇左上較的 警示,便會跳出以下新增警示的畫面: 您可以看到搜尋指令已經自動打好了,因此可以避免您複製貼上時所造成的錯誤。 現在需要輸入警示名稱、設定時間間隔、設定閾值、並指定傳送警示的 email。此範例中時間間隔設定為15分鐘,並將閾值設定為0,接著將隱藏警示時間設為120分鐘。如下圖: 都設定完成後,按下 [Save]。如此一來就新增了遺失重大或安全性更新的警示。


Monitoring temperature sensors in remote locations with Twilio, Azure Automation and Log Analytics – Part 3

This is part three of my little three part series on how to monitor temperature sensors in  remote locations with Twilio, Azure Automation and OMS. It describes my current OMS solution and the costs associated with the solution, in case that you want to build something similar. For the background of this post, please read…


Monitoring temperature sensors in remote locations with Twilio, Azure Automation and Log Analytics – Part 2

This is part two of my little three part series on how to monitor sensors in remote locations with Twilio, Azure Automation and OMS. It describes the overall solution architecture, some technical challenges I faced, solutions I found and lessons I learned. For the background of this blog series, please read part one. If you…


Monitoring temperature sensors in remote locations with Twilio, Azure Automation and Log Analytics – Part 1

This blog series is based on a private project and not customer related. But it might show you how easy it is to solve real world problems with Azure services. As a short teaser, this is my current custom OMS solution dashboard that I will explain throughout this blog series: Part 1 describes the initial…


透過您需注意的問題來延伸 OMS 安全性

概要:學習如何建立您自己需注意的問題來配合您的商業需求。 OMS 安全性與稽核方案會強調需注意的安全性問題。管理員需要注意並測試這些問題。有些問題是很常見的,像是正常商業節奏的一部份可能發生標準配置的改變。其他稀少的事件可能代表惡意的活動,像是偵測一個安全性記錄被刪除。 OMS 安全性與稽核方案有很多內建的需注意的問題。雖然這些是一個很好的開始,但很多組織仍會想延伸和加入一些具有特殊邏輯或是特定優先順序的需注意的問題。 您可以將任何 OMS 搜尋指令轉換為一個安全性與稽核的需注意的問題,只需將其儲存到以下三種搜尋類別的的其中一類中: Security Critical Notable Issues Security Warning Notable Issues Security Info Notable Issues 在您將搜尋指令儲存到一個類別後,它便會顯示在安全性與稽核方案中的需注意的問題區塊。 以下是步驟: 1. 開啟 OMS 記錄搜尋頁面,按下左上方的 我的最愛。在此頁面,您也可以測試預先配置好的一些指令。   2. 在您定義好搜尋後,將其儲存到需注意的問題的一個種類中。   3. 從現在起,新的指令便會出現在 OMS 安全性與稽核方案儀表板的需注意的問題中。   4. 若您想要將此指令刪除,只需到記錄搜尋的我的最愛,找到要刪除的指令,再按下其右方的 [X] 即可。 Note:您無法刪除預先配置的指令。


Azure Application Insights 企業方案添加至 OMS 訂閱中了!!

OMS 更新:購買微軟 OMS E1 和 E2 的客戶,可以取得 Application Insights 企業方案作為額外的元件,無需再付其他費用。 具體來說,OMS  E1 和 E2 的每個單元包含一個 Application Insights 企業方案節點權利。每個 Application Insights 節點每日最多有 200 MB 的內嵌資料(獨立 Log Analytics 資料擷取),且資料可免費保存 90 天。 欲了解更多 Azure Application Insights 的資訊,請點此篇文章。


容器管理解決方案正式發布

我們在8/23公布了 Log Analytics 中容器監控解決方案的正式發布版,這次新增了一些新的功能,讓您可以更深入了解您的 Kubernetes 叢集。您可以從 OMS 方案庫裡,或 Azure 首頁上的 Azure Marketplace 獲得此容器監控解決方案。欲知詳情,請閱讀 Azure blog 中的公告。