Log Analytics のアラートについてUnderstanding alerts in Log Analytics

注意

Log Analytics の警告は、Azure も対象としていますAlerts in Log Analytics are being extended into Azure. この記事の情報は、Azure Portal で Log Analytics 検索を使用するアラートの詳細を定義するときにも使用できます。Information in this article can still be used for defining the details of alerts in the Azure portal that use Log Analytics searches.

Log Analytics のアラートは、Log Analytics リポジトリ内の重要な情報を特定します。Alerts in Log Analytics identify important information in your Log Analytics repository. この記事では、クエリ対象のデータの収集頻度に基づいて行う必要があるいくつかの設計上の決定、ネットワーク待ち時間や処理能力が原因として考えられるデータ インジェストを伴うランダムな遅延、および Log Analytics ワークスペースへのデータのコミットについて説明します。This article discusses some of the design decisions that must be made based on the collection frequency of the data being queried, random delays with data ingestion possibly caused by network latency or processing capacity, and committing the data into the Log Analytics workspace. また、Log Analytics のアラート ルールのしくみを詳しく紹介するほか、アラート ルールの種類ごとの違いについても説明します。It also provides details of how alert rules in Log Analytics work and describes the differences between different types of alert rules.

警告ルール作成のプロセスについては、以下の記事を参照してください。For the process of creating alert rules, see the following articles:

考慮事項Considerations

さまざまなソリューションおよびデータ型のデータ収集の頻度に関する詳細は、ソリューションの概要に関する記事の「データ収集の詳細」で確認できます。Details about the data collection frequency for various solutions and data type are available in the Data collection details of the Solutions overview article. この記事で説明したように、収集の頻度は 7 日に 1 回のように少なくすることも、"通知時" に収集するように指定することもできます。As noted in this article, collection frequency can be as infrequent as once every seven days to on notification. 重要なのは、アラートを設定する前に、データ収集の頻度について理解し、検討することです。It is important to understand and consider the data collection frequency before setting up an alert.

  • 収集の頻度によって、OMS エージェントが Log Analytics にデータを送信する頻度が決まります。The collection frequency determines how often the OMS agent sends data to Log Analytics. たとえば、収集の頻度が 10 分で、システムに他の遅延がない場合は、送信されたデータのタイム スタンプは、リポジトリに追加される前の 0 ~ 10 分になり、Log Analytics で検索できます。For instance, if the collection frequency is 10 minutes and there are no other delays in the system, then time stamps of the transmitted data may be anywhere between zero and 10 minutes old before being added to the repository and is searchable in Log Analytics.

  • アラートをトリガーするには、データをリポジトリに書き込み、クエリの実行時に使用可能にしておく必要があります。Before an alert can be triggered, the data must be written to the repository so that it is available when queried. 上記で説明した待ち時間のため、収集の頻度と、クエリでデータを使用できる時間は同じではありません。Because of the latency described above, the collection frequency is not the same as the time the data is available to queries. たとえば、データが正確に 10 分ごとに収集されていても、データ リポジトリでデータが使用可能になる間隔は不規則です。For instance, while the data may be collected precisely every 10 min, the data is available in the data repository at irregular intervals. 0、10、および 20 分間隔で収集されたデータが、それぞれ 25、28、および 35 分の検索に対して、またはインジェスト待ち時間の影響による他の不規則な間隔で使用可能になる可能性があります。Hypothetically, data collected at zero, 10, and 20-minute intervals might be available for search at 25, 28, and 35 minutes respectively, or at some other irregular interval influenced by ingestion latency. こうした遅延の最悪のケースは、「Log Analytics の SLA」で文書化されていますが、これには、収集の頻度や、コンピューターと Log Analytics サービスの間のネットワーク待ち時間による遅延は含まれていません。The worst case for these delays is documented in the SLA for Log Analytics, which does not include a delay introduced by the collection frequency or network latency between the computer and Log Analytics service.

アラート ルールAlert rules

アラートは、ログ検索を一定の間隔で自動的に実行するアラート ルールによって作成されます。Alerts are created by alert rules that automatically run log searches at regular intervals. ログ検索の結果が特定の条件に一致すると、アラート レコードが作成されます。If the results of the log search match particular criteria then an alert record is created. さらに、アラートを事前に通知したり、別のプロセスを呼び出したりするために、1 つ以上のアクションを自動的に実行できます。The rule can then automatically run one or more actions to proactively notify you of the alert or invoke another process. この分析では、アラート ルールの種類に応じてさまざまなロジックが使用されます。Different types of alert rules use different logic to perform this analysis.

Log Analytics alerts

ログ データのインジェストにより待ち時間が発生することが予想されるため、データのインデックスが作成されてから、そのデータを検索で使用できるようになるまでの絶対時間は予測できません。Because there is an anticipated latency with the ingestion of log data, the absolute time between indexing data and when it is available to search can be unpredictable. アラート ルールを定義しながら、収集したデータのほぼリアルタイムの可用性を考慮する必要があります。The near-real-time availability of data collected should be taken into consideration while defining alert rules.

アラートの信頼性とアラートの応答性の間にはトレードオフがあります。There is a trade-off between reliability of alerts and the responsiveness of alerts. アラートが誤っている、アラートが発生しない、などの状況は、アラート パラメーターの構成によって最小限に抑えることができます。また、監視対象の状況に迅速に対応するアラート パラメーターを選択することもできます。しかし、誤ったアラートが生成されたり、アラートが発生しなかったりすることはあります。You can choose to configure alert parameters to minimize false alerts and missing alerts, or you can choose alert parameters to respond quickly to the conditions that are being monitored, but occasionally generates false or missed alerts.

警告ルールは次の内容で定義されます。Alert Rules are defined by the following details:

  • ログ検索: Log search. 警告ルールが実行されるたびに実行されるクエリ。The query that runs every time the alert rule fires. このクエリから返されるレコードは、アラートを作成するかどうかの決定に使用されます。The records returned by this query are used to determine whether an alert is created.
  • 時間枠: Time window. クエリの時間範囲を指定します。Specifies the time range for the query. クエリでは、現在の時刻に先立つ指定の時間範囲の間に作成されたレコードだけを返します。The query returns only records that were created within this range of the current time. 5 分から 24 時間までの値を指定できます。This can be any value between five minutes and 24 hours. この範囲には、インジェストによる妥当な遅延に対応できるだけの長さを確保してください。The range needs to be wide enough to accommodate reasonable delays in ingestion. 処理できるようにしたい遅延の 2 倍の長さを時間枠として確保する必要があります。The time window needs to be two times the length of the longest delay you want to be able to handle.
    たとえば、30 分の遅延について信頼できるアラートが必要な場合、範囲は 1 時間にする必要があります。For instance, if you want alerts to be reliable for 30 minute delays, then the range needs to be one hour.

    時間の範囲が短すぎるときに発生する可能性がある症状は 2 つあります。There are two symptoms you could experience if the time range is too small.

    • アラートが発生しないMissing alerts. たとえば、インジェストの遅延がたまに 60 分になるとします。しかし、ほとんどの場合、この遅延は 15 分です。Assume the ingestion delay is 60 minutes sometimes, but most of the time it is fifteen minutes. 時間枠が 30 分に設定されていると、遅延が 60 分のときにアラートが発生しません。これは、アラート クエリの実行時、検索でデータを使用できないためです。If the time window is set to 30 minutes, then it misses an alert when the delay is 60 minutes because the data isn't available for search when the alert query is executed.

      注意

      アラートが発生しなかった理由を診断することはできません。Trying to diagnose why the alert is missed is impossible. たとえば、上記の例では、アラート クエリが実行されてから 60 分後に、データがリポジトリに書き込まれます。For example, in the case above, the data is written to the repository 60 minutes after the alert query was executed. 翌日にアラートが実行されなかったことに気が付き、その翌日のクエリを正しい時間範囲で実行した場合、ログ検索条件は結果と一致します。If it is noticed the next day that an alert was missed, and the next day the query is executed over the correct time interval, the log search criteria would match the result. アラートは確かにトリガーされていたように見えるでしょう。It would appear that the alert should have been triggered. 実際は、アラート クエリが実行されたとき、データは使用可能な状態でなかったため、アラートはトリガーされていません。In fact, the alert was not triggered because the data was not yet available when the alert query was executed.

    • 誤ったアラートFalse Alerts. イベントがないことを特定するようにアラート クエリが設計されていることがあります。Sometimes alert queries are designed to identify the absence of events. たとえば、ハートビートが存在しないことを検索して、仮想マシンがオフラインであることを検出するのは、その一例です。One example of this is detecting when a virtual machine is off-line by searching for missed heartbeats. 上記のように、アラート時間枠で検索にハートビートを使用できないと、アラートが生成されます。ハートビート データがまだ検索できず、存在しないと判断されたためです。As above, if the heartbeat is not available for search within the Alert time window, then an alert is generated because the heartbeat data was not yet searchable, and therefore absent. これは、VM が本当にオフラインで、ハートビート データが生成されなかった場合と同じ結果です。This is the same result as if the VM was legitimately off-line and there was no heartbeat data generated by it. 正しい時間枠で次の日にクエリを実行すると、ハートビートが存在すること、そしてアラートが失敗したことが示されます。Executing the query the next day over the correct time window shows that there were heartbeats and alerting failed. 実際は、アラート時間枠が短すぎたため、ハートビートを検索に使用できなかった、ということです。In fact, the heartbeats were not yet available for search because the Alert time window was set too small.

  • [頻度]: Frequency. クエリの実行頻度を指定します。また、通常の場合のアラートの応答性を高めるためにも使用できます。Specifies how often the query should be run and can be used to make alerts more responsive for the normal case. 5 分から 24 時間までの値を指定でき、アラートの時間枠以下にする必要があります。The value can be between five minutes and 24 hours and should be equal to or less than the Alert time window. この値が時間枠の値よりも大きい場合、レコードを見落とすおそれがあります。If the value is greater than the time window, then you risk records being missed.
    最大遅延 30 分、通常の遅延 10 分に対して信頼性を確保することが目的の場合、時間枠は 1 時間、頻度の値は 10 分にします。If the goal is to be reliable for delays up to 30 minutes and the normal delay is 10 minutes, the time window should be one hour and the frequency value should be 10 minutes. これにより、アラート データが生成されたときの 10 分から 20 分の間に、インジェストの遅延が 10 分のデータに対してアラートが生成されます。This would trigger an alert with data that has a 10 minute ingestion delay between 10 and 20-minutes of when the alert data was generated.
    時間枠が大きすぎることが原因で、同じデータに対して複数のアラートが作成されるのを回避するには、[アラートを表示しない] オプションを使用します。これにより、少なくとも時間枠の間はアラートが表示されないようにできます。To avoid creating multiple alerts for the same data because the time window is too wide, the Suppress Alerts option can be used to suppress alerts for at least as long as the time window.

  • しきい値: 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 alert rules.

Log Analytics の警告ルールはいずれも、2 種類のどちらかに該当します。Each alert rule in Log Analytics is one of two types. どちらについても、後のセクションで詳しく説明します。Each of these types is described in detail in the sections that follow.

  • 結果の数Number of results. ログ検索によって返されるレコードの数が指定された数を超えた場合に、アラートが 1 回生成されます。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.

この 2 種類のアラート ルールの違いは次のとおりです。The differences between alert rule types are as follows.

  • 結果の数アラート ルールは常に 1 つのアラートを作成するのに対し、メトリック測定アラート ルールはしきい値を超えたオブジェクトごとにアラートを作成します。Number of results alert rule always create a single alert while Metric measurement alert rule creates an alert for each object that exceeds the threshold.
  • 結果の数の警告ルールでは、1 回しきい値を超えた時点で警告が生成されます。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

結果の数のアラート ルールでは、検索クエリによって返されるレコード数が指定されたしきい値を超えた場合に、1 回だけアラートが生成されます。Number of results alert rules create a single alert when the number of records returned by the search query exceed the specified threshold.

しきい値Threshold

結果の数アラート ルールのしきい値は特定の値より大きいか、または小さいかのどちらかです。The threshold for a Number of results alert rule 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.

シナリオScenarios

イベントEvents

この種類の警告ルールは、Windows イベント ログ、Syslog、カスタム ログのようなイベントでの使用に最適です。This type of alert rule is ideal for working with events such as Windows event logs, Syslog, 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 window.

1 つのイベントに対してアラートを作成するには、結果の数を 0 より大きな値に設定し、頻度と時間枠の両方を 5 分に設定します。To alert on a single event, set the number of results to greater than 0 and both the frequency and time window to 5 minutes. それにより、クエリが 5 分ごとに実行され、前回のクエリ実行後に作成された 1 つのイベントの発生を確認します。That runs the query every 5 minutes and check for the occurrence of a single event that was created since the last time the query was run. 頻度の値を大きくすると、イベントが収集されてアラートが作成される間隔が長くなります。A longer frequency may delay the time between the event being collected and the alert being created.

一部のアプリケーションでは、必ずしもアラートを発生させない偶発的なエラーが記録される場合もあります。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 window.

また、イベントが発生しないときにアラートを作成する場合もあります。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 window, then an alert should be created. この場合は、しきい値を Less than 1 に設定します。In this case you would set the threshold to less than 1.

パフォーマンスのアラートPerformance alerts

パフォーマンス データ は、イベントと同様に OMS リポジトリ内のレコードとして格納されます。Performance data is stored as records in the OMS repository similar to events. パフォーマンス カウンターが特定のしきい値を超えたときにアラートを生成する場合は、クエリにそのしきい値を含める必要があります。If you want to alert when a performance counter exceeds a particular threshold, then that threshold should be included in the query.

たとえば、プロセッサが 90% を超える割合で実行されたときにアラートを生成させるには、次のようにクエリにアラート ルールのしきい値 greater than 0 を含めます。For example, if you wanted to alert when the processor runs over 90%, you would use a query like the following with the threshold for the alert rule greater than 0.

Perf | where ObjectName=="Processor" and CounterName=="% Processor Time" and CounterValue>90

プロセッサが一定の時間内に平均 90% を超える割合で実行されたときにアラートを生成させるには、次のようにクエリで measure コマンドを使用し、アラート ルールのしきい値 greater than 0 を含めます。If you wanted to alert when the processor averaged over 90% for a particular time window, you would use a query using the measure command like the following with the threshold for the alert rule greater than 0.

Perf | where ObjectName=="Processor" and CounterName=="% Processor Time" | summarize avg(CounterValue) by Computer | where CounterValue>90

メトリック測定のアラート ルールMetric measurement alert rules

注意

メトリック測定のアラート ルールは、現在パブリック プレビューの段階です。Metric measurement alert rules are currently in public preview.

メトリック測定のアラート ルールでは、クエリの対象となったオブジェクトが分析され、特定の値が指定されたしきい値を上回っているオブジェクトについて、それぞれ別個にアラートが生成されます。Metric measurement alert rules create an alert for each object in a query with a value that exceeds a specified threshold. 結果の数のアラート ルールとは、以下の点が明確に異なります。They have the following distinct differences from Number of results alert rules.

結果の数のアラート ルールではどのようなクエリでも使用できるのに対し、メトリック測定のアラート ルールの場合にはクエリに一定の要件が存在します。While you can use any query for a Number of results alert rule, there are specific requirements the query for a metric measurement alert rule. 具体的には、特定のフィールドに関する結果をグループ化するために measure コマンドが 1 つ必要になります。It must include a measure command to group the results on a particular field. このコマンドに必要な要素は以下のとおりです。This command must include the following elements.

  • 集計関数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.
  • グループ フィールドGroup Field. このフィールドのインスタンスごとに値を集計したレコードが作成されます。警告は、それぞれのインスタンスについて生成されます。A record with an aggregated value is created for each instance of this field, and an alert can be generated for each. たとえば、コンピューターごとにアラートを生成する場合には、by Computer を使用します。For example, if you wanted to generate an alert for each computer, you would use by Computer.
  • [間隔]: Interval. データを集計する間隔を定義する要素です。Defines the time interval over which the data is aggregated. たとえば、5 分を指定した場合には、アラートに対して指定した期間にわたり、グループ フィールドの各インスタンスについて、5 分間隔でレコードが作成されます。For example, if you specified 5 minutes, a record would be created for each instance of the group field aggregated at 5 minute intervals over the time window specified for the alert.

しきい値Threshold

メトリック測定のアラート ルールのしきい値は、集計値と "抵触" の発生回数の 2 つの要素によって決まります。The threshold for Metric measurement alert rules is defined by an aggregate value and a number of breaches. ログ検索でいずれかのデータ ポイントが一定の値を超えると、抵触が 1 回発生したと判定されます。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.

Example

いずれかのコンピューターでプロセッサの使用率が 90% を超える状態が 30 分間に 3 回発生した場合にアラートを生成するシナリオを考えてみましょう。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.

[クエリ]: Type=Perf ObjectName=Processor CounterName="% Processor Time" | measure avg(CounterValue) by Computer Interval 5minuteQuery: Type=Perf ObjectName=Processor CounterName="% Processor Time" | measure avg(CounterValue) by Computer Interval 5minute
時間枠: 30 分Time window: 30 minutes
アラートの頻度: 5 分Alert frequency: 5 minutes
集計値: 90 よりも大きいAggregate value: Greater than 90
アラートをトリガーする基準: 違反総数が 5 より大Trigger alert based on: Total breaches Greater than 5

上のクエリは、5 分間隔で各コンピューターの平均値を計算するものです。The query would create an average value for each computer at 5 minute intervals. このクエリは過去 30 分間に収集されたデータを対象に、5 分ごとに実行されます。This query would be run every 5 minutes for data collected over the previous 30 minutes. コンピューターが 3 台の場合、サンプル データは以下のようになります。Sample data is shown below for three computers.

サンプル クエリの結果

この例では、指定された期間内に srv02 と srv03 の 2 台がしきい値 (90 %) に合計 3 回抵触しています。このため、この 2 台について個別にアラートが生成されます。In this example, separate alerts would be created for srv02 and srv03 since they breached the 90% threshold 3 times over the time window. [アラートをトリガーする基準][Consecutive (連続)] に変更した場合には、3 回連続でしきい値に抵触した srv03 についてのみアラートが生成されます。If the Trigger alert based on: were changed to Consecutive then an alert would be created only for srv03 since it breached the threshold for 3 consecutive samples.

アラート レコードAlert records

Log Analytics のアラート ルールで作成されるアラート レコードは、[Type][Alert][SourceSystem][OMS] に設定されています。Alert records created by alert rules in Log Analytics have a Type of Alert and a SourceSystem of OMS. これらのレコードには、次の表に示したプロパティがあります。They have the properties in the following table.

プロパティProperty [説明]Description
typeType アラート:Alert
SourceSystemSourceSystem OMSOMS
ObjectObject メトリック測定のアラートには、グループ フィールドのプロパティがあります。Metric measurement alerts has a property for the group field. たとえば、ログ検索のグループ分けがコンピューターごとの場合には、アラートのレコードに Computer フィールドが存在します。また、そのフィールドの値はコンピューター名となります。For example, if the log search groups on Computer, the alert record with have a Computer field with the name of the computer as the value.
AlertNameAlertName アラートの名前。Name of the alert.
AlertSeverityAlertSeverity アラートの重大度。Severity level of the alert.
LinkToSearchResultsLinkToSearchResults アラートを作成したクエリに基づいてレコードを返す Log Analytics ログ検索へのリンク。Link to Log Analytics log search that returns the records from the query that created the alert.
クエリQuery 実行されたクエリのテキスト。Text of the query that was run.
QueryExecutionEndTimeQueryExecutionEndTime クエリの時間範囲の終了時刻。End of the time range for the query.
QueryExecutionStartTimeQueryExecutionStartTime クエリの時間範囲の開始時刻。Start of the time range for the query.
ThresholdOperatorThresholdOperator アラート ルールで使用された演算子。Operator that was used by the alert rule.
ThresholdValueThresholdValue アラート ルールで使用された値。Value that was used by the alert rule.
TimeGeneratedTimeGenerated アラートが作成された日付と時刻。Date and time the alert was created.

Alert Management ソリューションおよび Power BI エクスポートでは、他の種類のアラート レコードも作成されます。There are other kinds of alert records created by the Alert Management solution and by Power BI exports. これらはすべて、[Type][Alert] ですが、それぞれ [SourceSystem] によって区別されます。These all have a Type of Alert but are distinguished by their SourceSystem.

次の手順Next steps