ログ アラートを使用してアプリケーションのイベントに対するアラートを生成する
Azure Monitor を使用すると、ログ ファイルから重要な情報を取得できます。 アプリケーション、オペレーティング システム、その他のハードウェア、または Azure サービスによって、これらのログ ファイルが作成される可能性があります。
ソリューション設計者であるあなたは、顧客にとって問題になる前に、監視ログ データで問題を検出できる方法を調べる必要があります。 あなたは Azure Monitor がログ データの使用をサポートしていることを知っています。
このユニットでは、ログ データを使用してシステムの復元性を向上させる方法について理解します。
ログ アラートを使用する場合
ログ アラートでは、ログ データを使用してルール ロジックが評価され、必要に応じてアラートがトリガーされます。 このデータは、任意の Azure リソース (サーバー ログ、アプリケーション サーバー ログ、またはアプリケーション ログ) から取得することができます。
ログ データは性質上履歴であるため、分析と傾向が主な用途になります。
これらの種類のログを使用すると、過去 30 分間にサーバーの CPU 使用率が特定のしきい値を超えたかどうかを評価したり、過去 1 時間に Web アプリケーション サーバーで発行された応答コードを評価したりできます。
ログ アラートのしくみ
ログ アラートは、他のアラート メカニズムとは動作方法が少し違います。 ログ アラートの最初の部分によって、ログ検索ルールを定義します。 ルールでは、実行する頻度、評価の期間、実行するクエリを定義します。
ログ検索が正と評価されると、アラート レコードが作成され、関連するアクションがトリガーされます。
ログ検索ルールの構成
すべてのログ アラートには、検索ルールが関連付けられています。 これらのルールの構成は次のとおりです。
- ログ クエリ: 警告ルールが生成されるたびに実行されるクエリ
- 期間: クエリの時間範囲
- 頻度:クエリの実行頻度
- しきい値: 作成するアラートのトリガー ポイント
ログ検索の結果は、"レコード数" または "メトリック測定" という 2 種類のいずれかです。
レコード数
イベントまたはイベントドリブン データを使用する場合は、ログ検索のレコード数の種類を使用することを検討してください。 例として、syslog と Web アプリの応答があります。
この種類のログ検索では、検索結果のレコード数がレコード数の値 (しきい値) に達した場合、またはそれを超えた場合に 1 つのアラートが返されます。 たとえば、検索ルールのしきい値が 5 以上の場合、アラートがトリガーされる前に、クエリ結果で 5 行以上のデータが返される必要があります。
メトリック測定
メトリック測定ログでは、メトリック アラート ログと同じ基本的な機能が提供されます。
レコード数の検索ログとは異なり、メトリック測定ログでは、追加の条件を設定する必要があります。
- 集計関数:結果データに対して実行される計算。 たとえば、count や average などです。 関数の結果は AggregatedValue と呼ばれます。
- グループ フィールド:結果がグループ化されるフィールド。 この条件は、集計値に対して使用されます。 たとえば、平均をコンピューター別にグループ化するように指定できます。
- 間隔:データを集計する時間の間隔。 たとえば、10 分を指定した場合、10 分の集計されたブロックごとにアラート レコードが作成されます。
- しきい値:集計値と違反の合計数で定義されるポイント。
検出された結果に許容レベルを追加する必要がある場合は、この種類のアラートを使用することを検討してください。 この種のアラートの用途の 1 つは、特定の傾向またはパターンが検出された場合に応答することです。 たとえば、違反数が 5 であり、指定した期間内にグループ内の任意のサーバーで 85% の CPU 使用率を超えた回数が 5 回を超えた場合、アラートが生成されます。
このように、メトリック測定を使用すると、生成されるアラートの量が大幅に減少します。 ただし、重大なアラートを見過ごさないように、しきい値パラメーターを設定するときは慎重に検討する必要があります。
ログ アラートのステートレスな性質
ログ アラートの使用を評価する際の主な考慮事項の 1 つは、それらがステートレスであることです (ステートフル ログ アラートは現在プレビュー段階です)。 ステートレス ログ アラートでは、ルールの条件がトリガーされるたびに新しいアラートが生成されます。そのアラートが以前に記録されたかどうかは関係ありません。