この記事は、Microsoft Azure Advento Calendar 2018の13日目の記事です。
https://qiita.com/advent-calendar/2018/azure
はじめに
Azureのサービスを実運用で使用する場合、メトリック監視、ログ分析、アラートといったことを行うかと思います。
その中で今回は、アラート機能についてピックアップしてみようと思います。
以前から存在するApp Serviceに存在するアラート機能(クラシックアラート)は、Azure Monitorと統合され、2019年6月に廃止されることがアナウンスされています。
そのためクラシックアラートを使用している場合は、2019年6月までにAzure Monitorに移行する必要があります。(クラシックアラートからAzure Monitorへの移行ツールの提供作業が進行中とのこと)
Azure Monitorは、Azureのリソースをまとめてモニタリングできる機能になっているので、色々なサービスでアラート設定が分散するといったことがなくなります。
そこで今回は、Azure Monitorを使用してApp Serviceのメトリック監視・アラート処理にする方法について触れてみようと思います。
アラートを構築する前に
今回は、Function Appで例外を出し、アラート受取用のFunction Appでアラートの受け取りを行う構成を作ってみます。
なのでFunction Appを一つ作成し、その中に例外を吐き出す用の関数とアラートを受け取る用の関数を作成します。
アラートを受け取る用の関数は、Httpトリガーである必要があるので、アラート受取用は、必ずHttpトリガーを作成してください。
自分の環境は、2つともHttpトリガーを作成しました。
アラート受取用
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
log.LogInformation(requestBody);
return (ActionResult)new OkObjectResult(requestBody);
}
例外発生用
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
throw new Exception();
}
またFunction Appのアプリケーション設定に下記の設定を追加してください。
Key |
Value |
AzureWebJobsSecretStorageType |
Files |
アラートを構成する
早速簡単なアラートを構成してみます。
Azure Monitorは、ポータルでモニターの項目からアクセス出来ます。
モニター内の、アラート > 新しいアラートルールを選択するとアラート作成に移動します。
アラート作成画面では、
* アラート対象のリソース
* アラート条件
* アクショングループ(後述)
* アラート内容の詳細
を設定します。
まず最初にリソースを設定します。
この画面では、サブスクリプションを一番上に、その下にぶら下がるリソースが一覧で表示されます。
最初は、サブスクリプションしか表示されないので「リソースの種類でフィルター」の部分でリソースをフィルターします。
それによりターゲットのリソースが表示されるようになるので監視対象にしたいリソースを選択します。
ここで設定できるリソースは、1アラートに対して1リソースになります。
次にアラートの条件を設定します。
アラートのトリガーにできる条件を指定します。
メトリック、アクティビティログなどから条件を指定してトリガーに設定できます。
今回は、簡単に実行出来るように
Http Server Errorを使用します。
アラートの条件は、エラー回数が1回以上になったら実行の設定にします。
次にアクショングループを設定します。
アクショングループでは、複数のアクションを設定します。
アクションタイプを選択するとそれぞれのアクションタイプに対応した設定画面が表示されます。
今回は、Function Appにアラートを送るように設定するのでAzure Functionを選択します。
Azure Functionの設定項目では、リソースグループ、Function App、Function Appの中の関数を選択します。
作成が完了したら、「既存の選択」で先ほど作成したアクショングループを選択します。
最後にアラートの詳細を記入してアラートルールの作成を選択します。
アクショングループについての補足
アクショングループは、通知を送る対象をまとめたものになります。
現在は、下記のサービスと連携することができます。
- 電子メール
- SMS
- Azureアプリのプッシュ通知
- 音声通話
- Azure Functions
- Azure Logic App
- Webhook
- ITSM
- Automation Runbook
ITSMは、Service Now、Provance、Cherwell、System Center Service Managerに接続可能です。
クラシックアラートでは、メールの送信対象に複数のメールアドレスを区切り文字で指定できましたが、Azure Monitorでは、
現状複数メールアドレスを区切り文字で指定できないので、アクションを各メールアドレス分作成するか、通知用のメーリングリストを使用しましょう。
アラートを受け取る
先ほど作成した例外発生用の関数を実行して数分待つとアラート受取用関数が実行されます。
アラート受取用関数が実行されるとRequest Bodyの中に下記のjsonが送られてきます。
最終的に何か処理をする場合は、送られてきたjsonを基に処理を分岐させる形になります。
{
"schemaId": "AzureMonitorMetricAlert",
"data": {
"version": "2.0",
"properties": null,
"status": "Deactivated",
"context": {
"timestamp": "2018-12-11T15:36:42.4343490Z",
"id": "/subscriptions/30bc1c24-7c50-471e-97c4-b86a3d9cedb1/resourceGroups/Qiita/providers/microsoft.insights/metricAlerts/%E3%83%86%E3%82%B9%E3%83%88",
"name": "テスト",
"description": "",
"conditionType": "SingleResourceMultipleMetricCriteria",
"severity": "3",
"condition": {
"windowSize": "PT5M",
"allOf": [
{
"metricName": "FunctionExecutionCount",
"metricNamespace": "Microsoft.Web/sites",
"operator": "GreaterThanOrEqual",
"threshold": "1",
"timeAggregation": "Total",
"metricValue": null,
"dimensions": [
{
"name": "ResourceId",
"value": "qiitamonitoreception.azurewebsites.net"
}
]
},
{
"metricName": "Http5xx",
"metricNamespace": "Microsoft.Web/sites",
"operator": "GreaterThan",
"threshold": "1",
"timeAggregation": "Total",
"metricValue": null,
"dimensions": [
{
"name": "ResourceId",
"value": "qiitamonitoreception.azurewebsites.net"
}
]
}
]
},
"subscriptionId": "30bc1c24-7c50-471e-97c4-b86a3d9cedb1",
"resourceGroupName": "Qiita",
"resourceName": "QiitaMonitorEception",
"resourceType": "Microsoft.Web/sites",
"resourceId": "/subscriptions/30bc1c24-7c50-471e-97c4-b86a3d9cedb1/resourceGroups/Qiita/providers/Microsoft.Web/sites/QiitaMonitorEception",
"portalLink": "https://portal.azure.com/#resource/subscriptions/30bc1c24-7c50-471e-97c4-b86a3d9cedb1/resourceGroups/Qiita/providers/Microsoft.Web/sites/QiitaMonitorEception"
}
}
}
送信済みアラートの管理
Azure Monitorでは、送信したアラートの一覧、内容などを管理する機能が提供されています。
アラートが発生した場合は、この画面でアラートの確認、ステータス変更を行えます。
ステータスは、
* 新規
* 確認済み
* クローズ済み
の3種類のステータスがあります。
ステータスを適切に管理すれば、アラートの取りこぼしといったことを減らせるなどのメリットがあります。
まとめ
Azure Monitorのモニタリング機能でクラシックアラートよりも柔軟にアラートの作成や管理ができるようになりました。
クラシックアラートの廃止もすぐにやってくるので、今からアラート設定を行う場合は、必ずこちらを使いましょう。
App Service 以外でも実運用をしようとすると必ずと言っていいほど使うサービスになると思うので是非使いこなしてみてください。