インフラエンジニアの隙間時間 Infrastructure Engineer's Spare Time
はじめに
Azure Monitorのアラート機能について紹介します。
無料でできること、で紹介した内容とかぶる部分もありますが、
なるべくイメージしやすいように現場で使っているアラート設定例や設計ポイントを紹介できればと思います。
Azure Monitor アラート概要
Azure Monitorで収集されるログを監視してアラートを上げる機能です。
しきい値を超えたなどの条件を満たした場合に、自動で通知や各種アクションをトリガーすることができます。
以下にアラート動作の流れを示します。
①ログ収集
②アラートルール設定
③アラート発報
④アクショングループ実行
①ログ収集
一部のログを除いて、事前に監視したいログの収集設定が必要です。
リソースの診断設定やAzure Monitorエージェントを利用して、必要なログをLogAnalyticsワークスペースに連携しておきます。
【補足】
ここではLogAnalyticsワークスペースの詳細は割愛しますが、ログ収集のポイントとしては必要なログのみ転送設定する、ということです。
転送されるログ量に応じた従量課金のため、「何かあったときに使えるかもしれないし、とりあえず全部のログを取っておくか」とすると利用料金にはねます。
じゃあ必要なログって何？と考えるとき、Azure Monitorでアラート設定に利用したいログは最低限必要なログです（たぶん使い道が思い浮かばないのに取っておいても使われないかと）。
②アラートルール設定
①で収集したログの監視設定がアラートルール（というリソース）です。
監視設定は大きく3つの要素で構成されます。
- スコープ
監視の範囲、最小単位はリソース - シグナル
監視するログの種類 - 条件
アラートのしきい値
ログの種類ごとに利用例を紹介してみます。
アクティビティ ログ アラート
Azureリソースに対する特定の管理操作が検出されたときにアラートを上げます。
で具体的にどんなログが出るか、ですが対象のリソースを選択して「すべてのシグナルを表示」で、
そのリソースに関連したアクティビティ ログを一覧で確認できました（画像は仮想マシンの例）。
（いまの現場では全然アクティビティ ログ アラートは使われていないのですが、
唯一Azureポリシーに違反するリソースを検知した時にアラートを上げるために利用されていました。）
アクティビティ ログ アラートは無料ですが、サブスクリプションあたり100ルールまでが上限です。
また次のサービス正常性&リソース正常性アラートもアクティビティログアラートの一種です。
サービス正常性アラート
Azure サービス自体の正常性を監視して、サービス正常性イベントあった場合にアラートを上げます。
計画メンテナンスやリージョン障害などによりAzureサービスへの影響があることを知らせてくれます。
サービス正常性アラートを設定するときはサービス、リージョンおよびイベントを全選択して
通知設定することが推奨されています（リソース毎に設定する必要なし）。
スコープが全選択されている場合でも、サブスクリプションで利用しているリソースに影響があるイベントだけをフィルターして通知する仕様になっているため、関係ないアラートが上がることはありません。
なので1ルールで全範囲がカバーでき、リソースが増えても後から設定を見直す必要もありません。
リソース正常性アラート
対象リソースの正常性イベントが発生した場合にアラートを上げます。
通常はリソースが利用可能な状態から、それ以外（利用不可、低下中、不明）の状態に変化したことを知るために利用されます。
※ただし、リソース正常性アラートは 発報までに20 分～ 30 分程度かかる場合もあり、リソースによっては別の死活監視方法も検討したほうがよさそうです。
（アクティビティ ログにリソース正常性イベントが書き込まれてからアラートが上がるため、検知に時間がかる）
リソース正常性アラートもスコープを全選択して「今後すべてのリソースを含める」とすることで、1ルールでサブスクリプション内の全リソースの正常性監視が可能です。
これで後から追加されたリソースも勝手にスコープに入ります。
メトリックログアラート
Azureリソースのパフォーマンス情報を監視して条件を満たした場合にアラートを上げます。
仮想マシンなど一部のリソースでは、推奨されるアラートルールとして項目が表示されるので簡単にメトリック ログ アラートを設定できるようになっています。
【補足】
いまの現場では、例えば仮想マシンで以下のような監視を設定しています。
・CPU使用率75%を超えたら重大度「警告」
・CPU使用率90%を超えたら重大度「エラー」
・メモリ使用率75%を超えたら重大度「警告」
・メモリ使用率90%を超えたら重大度「エラー」
こんな感じで各リソース毎に複数のアラートルールを作成しているのですが、だんだんリソース数が増えてきてしまって管理が大変です。。
公式ドキュメントを見てみると、同じ条件であれば複数のリソースをまとめて1つのアラートルールで監視する方法が推奨されていました。
サブスクリプションやリソースグループ単位で、リソースの種類とリージョンを指定することで複数のリソースをまとめて監視することができるとのこと。
サブスクリプション内の全ての仮想マシン（東日本リージョン）をスコープとする例
これなら管理するアラートルールの数を減らすことができる上、新しいリソースも自動で監視対象に追加されそうで楽ですね（１ルールでも監視対象が増えるとその分ちゃんと課金されるようで、コスト節約にはつながらなさそうでした）。
また１ルールであってもリソースごとに別個に評価され、アラートもリソースごとに別個に発生するのだそうです。
https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-metric-multiple-time-series-single-rule#multiple-resources-multi-resource
ログ検索アラート
LogAnalyticsワークスペースのログ検索結果を利用したしアラートを作成できます。
まずログを検索するためには、①で収集設定したログがLogAnalyticsワークスペースのどのテーブルに保管されるか把握しておく必要があります。
こちらにリソースのカテゴリ別で出力先となるログテーブル名がまとまっています。
https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/logs-index
例えばAzure Monitorエージェントで仮想マシンのログを取得している場合、「Heartbeat」というテーブルにエージェントの死活監視ログが保管されます。
１分に１度の間隔でログが出力されていることがわかります。
このログを利用して、直近５分以内で出力されるHeartbeatのログが２以下だった時にアラートを上げる、というようなルールで仮想マシンの死活監視が可能です。
【補足】
ログ検索アラート設計時のポイント
-
コスト最適化
ログ検索の頻度が多いほどアラートルールのコストが上がることに注意が必要です。
例えば日次バックアップの失敗を検知するためのアラートルールで５分おきにログ検索を繰り返しても無駄にコストがかかります（すぐに検知したい場合は別ですが）。 -
ステートフル／ステートレス
アラートは以下の２種類から選択可能です。
①ステートフルアラート：一度アラートが上がると解決されるまで同じアラートは上がらない
②ステートレスアラート：条件を満たすたびにアラートが上がる
例えば１分おきにログ検索を実行するアラートルールをステートレスで設定すると、週明け気づいた時には同じ内容のアラートで埋め尽くされていた、ということになりかねません。
1度アラートが発生したら都度アラート通知はいらない（解決されるまで不要）という場合はステートフルアラートを使用します。
逆に１日１回のログ検索頻度であればステートレスでいいと思います。
長くなってきたので続きは次回
以上