Azure 監視器中的記錄警示Log alerts in Azure Monitor

此文章提供記錄警示的詳細資料,記錄警示是 Azure 警示 內所支援的其中一種警示類型,可讓使用者使用 Azure 的分析平台來作為基礎警示。This article provides details of Log alerts are one of the types of alerts supported within the Azure Alerts and allow users to use Azure's analytics platform as basis for alerting.

記錄警示包含針對 Azure 監視器記錄Application Insights 所建立的記錄搜尋規則。Log Alert consists of Log Search rules created for Azure Monitor Logs or Application Insights. 若要深入了解其使用方式,請參閱在 Azure 中建立記錄警示To learn more about its usage, see creating log alerts in Azure

注意

Azure 監視器記錄中常用的記錄資料現在也會在 Azure 監視器的計量平台上提供。Popular log data from Azure Monitor Logs is now also available on the metric platform in Azure Monitor. 如需詳細資料檢視,請參閱記錄的計量警示For details view, Metric Alert for Logs

記錄搜尋警示規則 - 定義和類型Log search alert rule - definition and types

Azure 警示會建立記錄搜尋規則,以自動定期執行指定的記錄查詢。Log search rules are created by Azure Alerts to automatically run specified log queries at regular intervals. 如果記錄查詢的結果符合特定準則,則會建立警示的記錄。If the results of the log query match particular criteria, then an alert record is created. 規則接著可自動使用動作群組來執行一或多個動作。The rule can then automatically run one or more actions using Action Groups. 可能必須擁有可建立、修改和更新記錄警示的 Azure 監視參與者角色;再加上警示規則或警示查詢中分析目標的存取和查詢執行權限。Azure Monitoring Contributor role for creating, modifying, and updating log alerts may be required; along with access & query execution rights for the analytics target(s) in alert rule or alert query. 萬一建立的使用者無法存取警示規則或警示查詢中的所有分析目標-規則建立可能會失敗,或將以部分結果執行記錄警示規則。In case the user creating doesn't have access to all analytics target(s) in alert rule or alert query - the rule creation may fail or the log alert rule will be executed with partial results.

記錄搜尋規則會由下列詳細資料定義:Log search rules are defined by the following details:

  • 記錄查詢Log Query. 每次引發警示規則都會執行的查詢。The query that runs every time the alert rule fires. 此查詢所傳回的記錄會用來判斷是否要觸發警示。The records returned by this query are used to determine whether an alert is to be triggered. 分析查詢可以用於特定的 Log Analytics 工作區或 Application Insights 應用程式,甚至是跨多個 Log Analytics 和 Application Insights 資源,只要使用者具備所有資源的存取和查詢權限即可。Analytics query can be for a specific Log Analytics workspace or Application Insights app and even span across multiple Log Analytics and Application Insights resources provided the user has access as well as query rights to all resources.

    重要

    使用 SCHEDULEDQUERYRULES API 設定的 Log Analytics Application Insights 和記錄警示的跨資源查詢支援記錄警示。cross-resource query support in log alerts for Application Insights and log alerts for Log Analytics configured using scheduledQueryRules API only.

    某些分析命令和組合與在記錄警示中的使用不相容;如需更多詳細資料,請檢視 Azure 監視器中的記錄警示查詢Some analytic commands and combinations are incompatible with use in log alerts; for more details view, Log alert queries in Azure Monitor.

  • 時間週期Time Period. 指定查詢的時間範圍。Specifies the time range for the query. 查詢只會傳回在此目前時間範圍內建立的記錄。The query returns only records that were created within this range of the current time. 時間週期會限制為了查詢記錄所能擷取的資料以防濫用,並可規避記錄查詢中所使用的任何時間命令 (例如 ago)。Time period restricts the data fetched for log query to prevent abuse and circumvents any time command (like ago) used in log query.
    例如,如果時間週期設定為 60 分鐘,且查詢會在下午 1:15 執行,則只會傳回在下午 12:15 與下午 1:15 之間所建立的記錄以執行記錄查詢。現在,如果記錄查詢使用 ago (7d) 之類的時間命令,則只會對下午 12:15 與下午 1:15 之間的資料執行記錄查詢 - 彷彿只有過去 60 分鐘有資料。而不是記錄查詢中所指定的七天資料。For example, If the time period is set to 60 minutes, and the query is run at 1:15 PM, only records created between 12:15 PM and 1:15 PM is returned to execute log query. Now if the log query uses time command like ago (7d), the log query would be run only for data between 12:15 PM and 1:15 PM - as if data exists for only the past 60 minutes. And not for seven days of data as specified in log query.

  • 頻率Frequency. 指定應執行查詢的頻率。Specifies how often the query should be run. 可以是介於 5 分鐘與 24 小時之間的任何值。Can be any value between 5 minutes and 24 hours. 應等於或小於此時間週期。Should be equal to or less than the time period. 如果值大於時間週期,則您可能有遺漏記錄的風險。If the value is greater than the time period, then you risk records being missed.
    例如,請考慮 30 分鐘的時間週期,以及 60 分鐘的頻率。如果在 1:00 執行查詢,它會傳回 12:30 到下午 1:00 之間的記錄。下一次執行查詢就是 2:00 時,它會傳回 1:30 至 2:00 之間的記錄。1:00 和 1:30 之間建立的任何記錄一律不會評估。For example, consider a time period of 30 minutes and a frequency of 60 minutes. If the query is run at 1:00, it returns records between 12:30 and 1:00 PM. The next time the query would run is 2:00 when it would return records between 1:30 and 2:00. Any records created between 1:00 and 1:30 would never be evaluated.

  • 閾值Threshold. 系統會評估記錄搜尋的結果,以判斷是否應該建立警示。The results of the log search are evaluated to determine whether an alert should be created. 不同類型的記錄搜尋警示規則會有不同的閾值。The threshold is different for the different types of log search alert rules.

不論是 Azure 監視器記錄還是 Application Insights 的記錄搜尋規則都可以屬於兩個類型。Log search rules be it for Azure Monitor Logs or Application Insights, can be of two types. 下列各節會詳細說明這兩個類型。Each of these types is described in detail in the sections that follow.

  • 結果數目Number of results. 當記錄搜尋所傳回的數目記錄超過指定數目時,系統會建立單一警示。Single alert created when the number records returned by the log search exceed a specified number.
  • 計量測量Metric measurement. 針對記錄搜尋結果中的每個物件,若其值超過指定的閾值,系統就會為其建立警示。Alert created for each object in the results of the log search with values that exceed specified threshold.

警示規則類型之間的差異如下所示。The differences between alert rule types are as follows.

  • 「結果數目」警示規則一律會建立單一警示,而「計量測量」警示規則會為每個超過閾值的物件建立警示。Number of results alert rules always creates a single alert, while Metric measurement alert rule creates an alert for each object that exceeds the threshold.
  • 結果數目警示規則會在閾值超過一次時建立警示。Number of results alert rules create an alert when the threshold is exceeded a single time. 計量測量警示規則會在閾值於特定時間間隔內超過一定次數時建立警示。Metric measurement alert rules can create an alert when the threshold is exceeded a certain number of times over a particular time interval.

結果數目警示規則Number of results alert rules

結果數目警示規則會在搜尋查詢所傳回的記錄數目超過指定閾值時建立單一警示。Number of results alert rules create a single alert when the number of records returned by the search query exceed the specified threshold. 這種類型的警示規則適用於處理例如 Windows 事件記錄、Syslog、WebApp 回應和自訂記錄的事件。This type of alert rule is ideal for working with events such as Windows event logs, Syslog, WebApp Response, and Custom logs. 您可能希望在建立特定的錯誤事件時,或是在特定時間週期內建立多個錯誤事件時建立警示。You may want to create an alert when a particular error event gets created, or when multiple error events are created within a particular time period.

閾值:「結果數目」警示規則的閾值會大於或小於特定值。Threshold: The threshold for a Number of results alert rules is greater than or less than a particular value. 如果記錄搜尋所傳回的記錄數目符合此準則,則會建立警示。If the number of records returned by the log search match this criteria, then an alert is created.

若要針對單一事件警示,請將結果數目設定為大於 0,並檢查在上次執行查詢後是否發生所建立的單一事件。To alert on a single event, set the number of results to greater than 0 and check for the occurrence of a single event that was created since the last time the query was run. 有些應用程式可能會記錄不一定會產生警示的偶發錯誤。Some applications may log an occasional error that shouldn't necessarily raise an alert. 例如,應用程式可能會重試造成錯誤事件的處理序,而下一次就會成功。For example, the application may retry the process that created the error event and then succeed the next time. 在此情況下,除非在特定時間週期內建立多個事件,否則您不會想建立警示。In this case, you may not want to create the alert unless multiple events are created within a particular time period.

在某些情況下,您可能想在某個事件不存在時建立警示。In some cases, you may want to create an alert in the absence of an event. 例如,處理序可能會記錄一般事件,表示運作正常。For example, a process may log regular events to indicate that it's working properly. 如果它不在特定的時間週期內記錄一個事件,則應建立警示。If it doesn't log one of these events within a particular time period, then an alert should be created. 在此情況下,您會將閾值設定為小於 1In this case, you would set the threshold to less than 1.

記錄數目類型記錄警示的範例Example of Number of Records type log alert

請考慮一個情境,您想要知道您的 Web 架構應用程式何時向使用者回應程式碼 500 (亦即) 內部伺服器錯誤。Consider a scenario where you want to know when your web-based App gives a response to users with code 500 (that is) Internal Server Error. 您可以建立詳細資料如下的警示規則:You would create an alert rule with the following details:

  • 查詢: 要求 | 其中 resultCode =="500"Query: requests | where resultCode == "500"
  • 時間週期: 30 分鐘Time period: 30 minutes
  • 警示頻率: 5 分鐘Alert frequency: five minutes
  • 閾值: 大於 0Threshold value: Greater than 0

然後警示會以 30 分鐘的資料,每隔 5 分鐘執行一次查詢,以尋找結果碼為 500 的任何記錄。Then alert would run the query every 5 minutes, with 30 minutes of data - to look for any record where result code was 500. 如果找到一筆這樣的記錄,它就會引發警示並觸發設定的動作。If even one such record is found, it fires the alert and triggers the action configured.

公制度量單位的警示規則Metric measurement alert rules

計量測量警示規則會為查詢中的每個物件建立警示,其值超過指定的閾值和指定的觸發條件。Metric measurement alert rules create an alert for each object in a query with a value that exceeds a specified threshold and specified trigger condition. 不同于結果數目的警示規則,當分析結果提供時間序列時,計量測量警示規則會正常執行。Unlike Number of results alert rules, Metric measurement alert rules work when analytics result provides a time series. 這些警示規則與結果數目警示規則具有下列明顯差異。They have the following distinct differences from Number of results alert rules.

  • 彙總函式:決定要執行的計算,並可能決定要彙總的數值欄位。Aggregate function: Determines the calculation that is performed and potentially a numeric field to aggregate. 例如,count() 會在查詢中傳回記錄數目,avg(CounterValue) 則會傳回 CounterValue 欄位在一段間隔內的平均值。For example, count() returns the number of records in the query, avg(CounterValue) returns the average of the CounterValue field over the interval. 查詢中的彙總函式必須是命名為/稱為:AggregatedValue,並提供一個數值。Aggregate function in query must be named/called: AggregatedValue and provide a numeric value.

  • 群組欄位:系統會為這個欄位中的每個執行個體建立帶有彙總值的記錄,而且每個執行個體都可產生警示。Group Field: A record with an aggregated value is created for each instance of this field, and an alert can be generated for each. 例如,如果您想要為每部電腦產生警示,您可以使用依電腦For example, if you wanted to generate an alert for each computer, you would use by Computer. 如果警示查詢中指定了多個群組欄位,則使用者可以使用 [彙總項目] (metricColumn) 參數來指定要使用哪個欄位來排序結果。In case, there are multiple group fields specified in alert query, user can specify which field to be used to sort results by using the Aggregate On (metricColumn) parameter

    注意

    [彙總項目] (metricColumn) 選項僅適用於 Application Insights 的「公制度量單位」類型記錄警示,以及使用 scheduledQueryRules API 來設定的 Log Analytics 的記錄警示。Aggregate On (metricColumn) option is available for Metric Measurement type log alerts for Application Insights and log alerts for Log Analytics configured using scheduledQueryRules API only.

  • 間隔:定義用來彙總資料的時間間隔。Interval: Defines the time interval over which the data is aggregated. 例如,如果您指定 5 分鐘,則系統會為群組欄位的每個執行個體建立記錄,而這些執行個體是在針對警示所指定的時間週期內以每 5 分鐘為間隔進行彙總的。For example, if you specified five minutes, a record would be created for each instance of the group field aggregated at 5-minute intervals over the time period specified for the alert.

    注意

    查詢中必須使用 Bin 函式來指定間隔。Bin function must be used in query to specify interval. 由於 bin() 可能會導致時間間隔不相等,警示會在執行階段自動使用適當時間將 bin 命令轉換為 bin_at 命令,以確保結果有固定時間點。As bin() can result in unequal time intervals - Alert will automatically convert bin command to bin_at command with appropriate time at runtime, to ensure results with a fixed point. 公制度量單位類型的警示記錄是專為與最多具有三個 bin() 命令執行個體搭配的查詢搭配運作而設計的Metric measurement type of log alert is designed to work with queries having up to three instances of bin() command

  • 閾值:計量測量警示規則的閾值是由彙總值與若干違規所定義。Threshold: The threshold for Metric measurement alert rules is defined by an aggregate value and a number of breaches. 如果記錄搜尋中的任何資料點超過此值,系統就會將其視為違規。If any data point in the log search exceeds this value, it's considered a breach. 如果結果中任何物件的違規數目超過指定值,系統舊會為該物件建立警示。If the number of breaches in for any object in the results exceeds the specified value, then an alert is created for that object.

[彙總項目] 或 metricColumn 選項設定錯誤可能會造成警示規則錯誤地觸發。Misconfiguration of the Aggregate On or metricColumn option can cause alert rules to misfire. 如需詳細資訊,請參閱在公制度量單位警示規則不正確時進行疑難排解For more information, see troubleshooting when metric measurement alert rule is incorrect.

計量測量類型記錄警示的範例Example of Metric Measurement type log alert

假設您想要在任何電腦於過去 30 分鐘內發生三次處理器使用率超過 90% 時收到警示。Consider a scenario where you wanted an alert if any computer exceeded processor utilization of 90% three times over 30 minutes. 您可以建立詳細資料如下的警示規則:You would create an alert rule with the following details:

  • 查詢: Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), ComputerQuery: Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer
  • 時間週期: 30 分鐘Time period: 30 minutes
  • 警示頻率: 5 分鐘Alert frequency: five minutes
  • 警示邏輯 - 條件和閾值: 大於 90Alert Logic - Condition & Threshold: Greater than 90
  • 群組欄位 (開啟彙總): ComputerGroup Field (Aggregate-on): Computer
  • 觸發警示的依據: 違規數總計大於 2Trigger alert based on: Total breaches Greater than 2

查詢會以 5 分鐘為間隔為每部電腦建立平均值。The query would create an average value for each computer at 5-minute intervals. 此查詢會每隔 5 分鐘針對在先前 30 分鐘內所收集的資料來執行。This query would be run every 5 minutes for data collected over the previous 30 minutes. 由於所選的「群組欄位 (開啟彙總)」是單欄式的「電腦」,AggregatedValue 會分割為「電腦」的各種值,而每部電腦的平均處理器使用率是以 5 分鐘的時間間隔判斷。Since the Group Field (Aggregate-on) chosen is columnar 'Computer' - the AggregatedValue is split for various values of 'Computer' and average processor utilization for each computer is determined for a time bin of 5 minutes. 3 部電腦 (假設) 的範例查詢結果會如下所示。Sample query result for (say) three computers, would be as below.

TimeGenerated [UTC]TimeGenerated [UTC] ComputerComputer AggregatedValueAggregatedValue
20xx-xx-xxT01:00:00Z20xx-xx-xxT01:00:00Z srv01.contoso.comsrv01.contoso.com 7272
20xx-xx-xxT01:00:00Z20xx-xx-xxT01:00:00Z srv02.contoso.comsrv02.contoso.com 9191
20xx-xx-xxT01:00:00Z20xx-xx-xxT01:00:00Z srv03.contoso.comsrv03.contoso.com 8383
...... ...... ......
20xx-xx-xxT01:30:00Z20xx-xx-xxT01:30:00Z srv01.contoso.comsrv01.contoso.com 8888
20xx-xx-xxT01:30:00Z20xx-xx-xxT01:30:00Z srv02.contoso.comsrv02.contoso.com 8484
20xx-xx-xxT01:30:00Z20xx-xx-xxT01:30:00Z srv03.contoso.comsrv03.contoso.com 9292

如果會繪製查詢結果,則會顯示如下。If query result was to be plotted, it would appear as.

查詢結果範例

在此範例中,我們看到 3 部電腦每一部的 5 分鐘間隔,平均處理器使用率是以 5 分鐘來計算。In this example, we see in bins of 5 mins for each of the three computers - average processor utilization as computed for 5 mins. srv01 只有在 1:25 間隔違反 90 閾值一次。Threshold of 90 being breached by srv01 only once at 1:25 bin. 相較之下,srv02 在 1:10、1:15 和 1:25 間隔超過 90 閾值;而 srv03 在 1:10、1:15、1:20 和 1:30 超過 90 閾值。In comparison, srv02 exceeds 90 threshold at 1:10, 1:15 and 1:25 bins; while srv03 exceeds 90 threshold at 1:10, 1:15, 1:20 and 1:30. 由於警示設定為違規超過兩次才觸發,我們看到 srv02 和 srv03 符合準則。Since alert is configured to trigger based on total breaches are more than two, we see that srv02 and srv03 only meet the criteria. 因此系統會為 srv02 和 srv03 建立個別警示,因為它們在多個時間間隔內違反 90% 閾值 2 次。如果「觸發警示依據:」參數改為設定 [連續違規] 選項,則「只有」srv03 會觸發警示,因為它在 1:10 到 1:20 的時間間隔連續違反閾值 3 次。Hence separate alerts would be created for srv02 and srv03 since they breached the 90% threshold twice across multiple time bins. If the Trigger alert based on: parameter was instead configured for Continuous breaches option, then an alert would be fired only for srv03 since it breached the threshold for three consecutive time bins from 1:10 to 1:20. 而 srv02 則「不會」觸發,因為它在 1:10 到 1:15 連續違反閾值 2 次。And not for srv02, as it breached the threshold for two consecutive time bins from 1:10 to 1:15.

記錄搜尋警示規則 - 引發與狀態Log search alert rule - firing and state

記錄搜尋警示規則僅適用于您在查詢中建立的邏輯。Log search alert rules work only on the logic you build into the query. 警示系統沒有任何其他系統狀態、您的意圖或查詢所隱含的根本原因的任何內容。The alert system doesn't have any other context of the state of the system, your intent, or the root cause implied by the query. 因此,記錄警示稱為「不是狀態」。As such, log alerts are referred to as state-less. 每次執行時,都會將條件評估為 "TRUE" 或 "FALSE"。The conditions are evaluated as "TRUE" or "FALSE" each time they are run. 每次警示條件評估為 "TRUE" 時,不論先前是否引發,都會引發警示。An alert will fire each time the evaluation of the alert condition is "TRUE", regardless of it is fired previously.

讓我們使用實用的範例來瞭解這種行為。Let's see this behavior in action with a practical example. 假設我們有一個名為 [ Contoso-記錄-警示] 的記錄警示規則,其設定方式如針對結果類型記錄警示所提供的範例中所示。Assume we have a log alert rule called Contoso-Log-Alert, which is configured as shown in the example provided for Number of Results type log alert. 條件是自訂警示查詢,其設計目的是在記錄檔中尋找500結果程式碼。The condition is a custom alert query designed to look for 500 result code in logs. 如果在記錄檔中找到一個以上的500結果碼,警示的條件就是 true。If one more more 500 result codes are found in logs, the condition of the alert is true.

在以下的每個間隔中,Azure 警示系統會評估Contoso-記錄警示的條件。At each interval below, the Azure alerts system evaluates the condition for the Contoso-Log-Alert.

TimeTime 記錄搜尋查詢所傳回的記錄數目Num of records returned by log search query 記錄條件 evalutionLog condition evalution 結果Result
下午1:051:05 PM 0筆記錄0 records 0不 > 0,因此為 FALSE0 is not > 0 so FALSE 警示不會引發。Alert does not fire. 沒有任何動作呼叫。No actions called.
下午1:101:10 PM 2筆記錄2 records 2 > 0 為 TRUE2 > 0 so TRUE 會引發警示,並呼叫名為的動作群組。Alert fires and action groups called. 警示狀態為作用中。Alert state ACTIVE.
下午1:151:15 PM 5筆記錄5 records 5 > 0 為 TRUE5 > 0 so TRUE 會引發警示,並呼叫名為的動作群組。Alert fires and action groups called. 警示狀態為作用中。Alert state ACTIVE.
下午1:201:20 PM 0筆記錄0 records 0不 > 0,因此為 FALSE0 is not > 0 so FALSE 警示不會引發。Alert does not fire. 沒有任何動作呼叫。No actions called. 警示狀態保持作用中。Alert state left ACTIVE.

使用先前的案例做為範例:Using the previous case as an example:

在下午1:15,Azure 警示無法判斷在1:10 看到的基礎問題是否持續存在,以及記錄是否為新的失敗,或在1:10PM-12AM 重複出現較舊的失敗。At 1:15 PM Azure alerts can't determine if the underlying issues seen at 1:10 persist and if the records are net new failures or repeats of older failures at 1:10PM. 使用者所提供的查詢不一定會考慮先前的記錄,系統也不知道。The query provided by user may or may not be taking into account earlier records and the system doesn't know. Azure 警示系統的建立是錯誤的警告,並于下午1:15 引發警示和相關聯的動作。The Azure alerts system is built to err on the side of caution, and fires the alert and associated actions again at 1:15 PM.

在下午1:20 時,如果看到500結果碼的零筆記錄,Azure 警示就無法確定在 1:10 PM 和 1:15 PM 看到的500結果程式碼的原因現在已解決。At 1:20 PM when zero records are seen with 500 result code, Azure alerts can't be certain that the cause of 500 result code seen at 1:10 PM and 1:15 PM is now solved. 這並不知道500錯誤問題是否會因為同樣的原因而發生。It doesn't know if the 500 error issues will happen for the same reasons again. 因此, Contoso-記錄警示不會在 Azure 警示儀表板中變更為已解決,而且/或通知不會送出,指出警示已解決。Hence Contoso-Log-Alert does not change to Resolved in Azure Alert dashboard and/or notifications are not sent out stating the alert is resolved. 只有瞭解內嵌于分析查詢之邏輯的確切條件或原因時,才可以視需要將警示標示為已關閉Only you, who understands the exact condition or reason for the logic embedded in the analytics query, can mark the alert as closed as needed.

記錄警示的價格和計費Pricing and Billing of Log Alerts

Azure 監視器價格頁面有說明適用於記錄警示的價格。Pricing applicable for Log Alerts is stated at the Azure Monitor Pricing page. 在 Azure 帳單中,記錄警示是以類型 microsoft.insights/scheduledqueryrules 搭配下列項目來表示:In Azure bills, Log Alerts are represented as type microsoft.insights/scheduledqueryrules with:

  • 隨著警示名稱與資源群組警示內容顯示的 Application Insights 上的記錄警示Log Alerts on Application Insights shown with exact alert name along with resource group and alert properties
  • 所顯示 Log Analytics 上的「記錄警示」會有確切的警示名稱,以及資源群組和屬性 (當建立方式是使用 scheduledQueryRules API 時)Log Alerts on Log Analytics shown with exact alert name along with resource group and alert properties; when created using scheduledQueryRules API

舊版 Log Analytics API 具有屬於 Log Analytics 儲存搜尋的警示動作和排程,且並非為適當的 Azure 資源The legacy Log Analytics API has alert actions and schedules as part of Log Analytics Saved Search and not proper Azure Resources. 因此,若要啟用這類針對使用 Azure 入口網站的 Log Analytics 所建立的舊版記錄警示,而「沒有」切換至新 API 或透過舊版 Log Analytics API,則會在 microsoft.insights/scheduledqueryrules 上建立 Azure 隱藏虛擬警示規則以啟用計費。Hence to enable billing for such legacy log alerts created for Log Analytics using of Azure portal without switching to new API or via legacy Log Analytics API - hidden pseudo alert rules are created on microsoft.insights/scheduledqueryrules for billing on Azure. microsoft.insights/scheduledqueryrules上為計費建立的隱藏虛擬警示規則,會有如<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>所示的資源群組和警示屬性。The hidden pseudo alert rules created for billing on microsoft.insights/scheduledqueryrules as shown as <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId> along with resource group and alert properties.

注意

如果出現 <, >, %, &, \, ?, / 等無效字元,則會在隱藏虛擬警示規則名稱以及 Azure 帳單中以 _ 取代這類字元。If invalid characters such as <, >, %, &, \, ?, / are present, they will be replaced with _ in the hidden pseudo alert rule name and hence also in the Azure bill.

若要使用舊版 Log Analytics API 來移除為警示規則計費建立的隱藏 scheduleQueryRules 資源,使用者可以執行下列任一項:To remove the hidden scheduleQueryRules resources created for billing of alert rules using legacy Log Analytics API, user can do any of the following:

此外,針對使用舊版 Log ANALYTICS API來計費警示規則而建立的隱藏 scheduleQueryRules 資源,任何修改作業(例如 PUT)都會失敗。Additionally for the hidden scheduleQueryRules resources created for billing of alert rules using legacy Log Analytics API, any modification operation like PUT will fail. 由於 @no__t 0 類型的虛擬規則是為了計費使用舊版 Log ANALYTICS API建立的警示規則。As the microsoft.insights/scheduledqueryrules type pseudo rules are for purpose of billing the alert rules created using legacy Log Analytics API. 您應該使用舊版 Log ANALYTICS API (或)來修改任何警示規則,使用者也可以將警示規則的 API 喜好設定切換為改用scheduledQueryRules APIAny alert rule modification should be done using legacy Log Analytics API (or) user can switch API preference for the alert rules to use scheduledQueryRules API instead.

後續步驟Next steps