Azure Virtual MachineのCPU負荷を監視し通知を受け取る

船井総研デジタルのよもぎたです。

この記事ではAzure Virtual MachineのCPU負荷を監視し、高負荷時に通知を受け取るところまでをまとめます。

# 負荷試験用のツールを試す

今回は負荷をかけるのに``stress-ng``ツールを使用します。
```bash
$ apt show stress-ng
Package: stress-ng
Version: 0.13.12-2
Priority: optional
Section: universe/devel
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Colin Ian King <colin.i.king@gmail.com>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 6,193 kB
Depends: libapparmor1 (>= 2.10), libbsd0 (>= 0.6.0), libc6 (>= 2.34), libcrypt1 (>= 1:4.1.0), libipsec-mb1 (>= 1.2), libjudydebian1, libkmod2 (>= 5~), libsctp1 (>= 1.0.10+dfsg), libxxhash0 (>= 0.6.5), zlib1g (>= 1:1.1.4)
Homepage: https://github.com/ColinIanKing/stress-ng
Download-Size: 2,107 kB
APT-Manual-Installed: yes
APT-Sources: http://jp.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
Description: tool to load and stress a computer
 stress-ng can stress various subsystems of a computer.  It can stress load
 CPU, cache, disk, memory, socket and pipe I/O, scheduling and much more.
 stress-ng is a re-write of the original stress tool by Amos Waterland but
 has many additional features such as specifying the number of bogo operations
 to run, execution metrics, a stress verification on memory and compute
 operations and considerably more stress mechanisms.
```

``stress-ng``でCPUに負荷をかけると、本当にほとんど何もできなくなるので、負荷をかける時間を適宜調節する必要があります。
手元の検証環境でこのように負荷をかけたところ…
```bash
$ sudo stress-ng -t 60 -a 0
```
load averageが4ケタに突入しました。
```bash
$ top -n 1 | head -5
top - 00:00:00 up 3 min,  2 users,  load average: 5286.47, 2315.27, 873.05
Tasks: 807 total,  19 running, 197 sleeping,   0 stopped, 591 zombie
%Cpu(s):  4.4 us, 41.2 sy, 50.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  4.4 si,  0.0 st
MiB Mem :   3924.0 total,   2763.1 free,    736.1 used,    424.8 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   2690.7 avail Mem
```

``-t n``が負荷をかける時間の指定で、``n``秒間負荷をかけ続けます。上の例だと、60秒負荷をかけることになります。``-a 0``は``stress-ng``のインスタンス数の指定で、``0``を指定することで全てのCPUを使い切ります。

自分の管理下にないサーバーで実行すると確実に怒られます。テスト用のサーバーを用意するか、きちんと管理者の方の許可を得たうえで、十分理解してもらったうえで実行してください。私はこの記事を読んで何かやらかしちゃっても、責任は負えません。

幸い、クラウド環境ならテスト用サーバーを用意するのはカンタンですね。早速Azureにテスト用サーバーをデプロイして試してみたいと思います。

Virtual Machineのデプロイは[こちらの記事](https://qiita.com/t_ymgt/items/0c473f73cfe4794a8036)でご紹介しています。今回はWebサーバとして利用するわけではないので、ネットワークセキュリティグループはTCP22番ポートを自分のグローバルIPアドレスだけ許可すれば十分です。

さっそくVirtual Machineをデプロイして、負荷をかけてみます。デプロイするVirtual Machineのサイズは``Standard B1ls (1 vcpu、0.5 GiB メモリ)``にしました。``top``コマンドで様子を見ながら``stress-ng``で負荷をかけると、あっという間にload averageが300を超えました。

```bash
top - 00:00:00 up 15 min,  2 users,  load average: 364.91, 164.34, 63.53
Tasks: 436 total,   5 running, 376 sleeping,   0 stopped,  55 zombie
%Cpu(s):  3.9 us, 90.6 sy,  5.0 ni,  0.0 id,  0.1 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :    402.8 total,      4.0 free,    283.6 used,    115.2 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.     11.9 avail Mem
```

Azure Portalの監視⇒メトリックの``CPU Credits Consumed``のカウントのグラフもほぼ垂直という勢いで急上昇しています。``stress-ng``ツールはこの高負荷の状態を指定した時間だけ維持できるので、高負荷をトリガーに通知を受け取ることができそうです。

# Azure Virtual MachineのCPU高負荷時に通知を受け取る設定
では、Virtual Machineはデプロイできたものとして、高付加をトリガーに通知を受け取る設定をしていきたいと思います。通知はe-mailとスマホのAzure Portalアプリで受信します。

スマホアプリはiPhone/Androidとも、AppStore/Playストアで``Microsoft Azure``で検索すればヒットします。

## 通知アクションの作成
Azure PortalでVirtual Machineのリソースに移動し、左のメニューの「監視」⇒「警告」を選択します。
![01-warn..png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/b1c39f2c-2f35-cd63-d040-5a421a994cbd.png)

まずは、通知アクションを定義します。右上のメニューの中から「アクショングループ」を選択し「作成」を選択ます。ここからはウィザードに従っていけばアクションを作成できると思います。

今回は「通知」タブの、「通知タイプ」プルダウンメニューで「電子メール/SMSメッセージ/プッシュ/音声」を選択し、右に出てくるメニューで「電子メール」と「Azure mobile appの通知」に自分のアドレスを指定して、通知を受け取れるように設定します。「アクション」タブは今回は設定しません。

![04-create-action-group-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/d92af256-6aca-3b24-aeb3-b7018d338c6f.png)

スマホにAzure Portalアプリをインストールして、設定するメールアドレスでログインしておく必要があります。

アクショングループが作成出来たら、通知のテストをしてみます。なお、新規作成したアクショングループが一覧に表示されるまで、何度か「最新情報に更新」する必要がありました・

下の赤枠で囲った「テストアクショングループ（プレビュー）」をクリックして、表示されるメニューで「サンプルの種類を選択」プルダウンメニューから適当な選択肢を選び「Test」をクリックします。今回はサンプルの種類は「メトリックアラート - 静的しきい値」を選択しました。
![06-test-actiongroup.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/ad856bba-ab2a-43da-f425-2fce89d55341.png)

少し待つと、無事メールとスマホアプリでテストアラートを受信できました。

テストメール
![07-test-alert-email.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/d825e212-4269-da33-312c-8bf2bc15ad72.png)

テストモバイルアプリ通知
![07-test-alert-mobile-app.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/f50ba7aa-3d31-f103-2600-47b5c7a6a516.png)

## アラートルールの設定
続いてアラートを発生させるルールを設定していきます。先程の「アクショングループ」の左隣にある「アラートグループ」をクリックし、ルールを作成していきます。

今回はCPU高負荷時にアラートを受け取りたいと考えています。そこで、次の2つの場合にアラートが発生するようにします。

1. ``CPU Credits Consumed``の値がしきい値を越えたとき
1. ``CPU Credits Remaining``の値がしきい値を下回ったとき

前者はわかりやすいかと思います。後者はやや分かりにくいかと思いますが、``CPU Credits``が無くなったとき、～Consumedの値も上がらず、しかしVirtual Machineの処理も進まない（CPUパワーを回してもらえない）状態を検知したく、通知を設定します。

今回は、``CPU Credits Consumed``のアラートルールは次のような条件で設定しました。実際に使うときは、パラメータは適宜チューニングしてください。
![08-alertrule-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/395de073-1024-b2b9-9702-47d728c5dc70.png)

「アクション」タブで先ほど作成した「アクショングループ」を選択し、メールとスマホアプリに通知されるように設定します。このタブの他に「詳細」タブでアラートルール名を設定する必要があります。同じ「詳細」タブでアラートの重大度も``0 - 重大`` ～ ``4 - 詳細`` までの5段階から選べます。

もう一つ、``CPU Credis Remaining``のアラートルールは、``CPU Credits Remaining``の平均が5を下回ったときに警告が発せられるように設定しました。

## いざ、負荷試験

事前に、試験前の``CPU Credits Consumed``のグラフを見ておきたいと思います。Virtual Machineのリソースの「監視」⇒「メトリック」から参照でき表示する項目や時間のレンジを指定できます。

グラフはいたって平坦で、右端にちょっとした山がありました。``stress-ng``パッケージをインストールしたタイミングでした。こんなところまで感知するんですね。

では、いよいよ負荷をかけて通知を受け取れることを確認したいと思います。load averageもあがりますが、テンションも上がりますね！

```bash
tymgt@tymgt-qiita-loadtest:~$ stress-ng -a 0 -t 1200
stress-ng: info:  [1611] apparmor stressor will be skipped, need to be running with CAP_SYS_ADMIN rights for this stressor
stress-ng: info:  [1611] binderfs stressor will be skipped, need to be running with CAP_SYS_ADMIN rights for this stressor
```
グラフは一気に跳ね上がります。（テンションも上がります！）
![10-loadtest-graph-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/39fc7158-a4bc-8514-bdb2-4ed1e237b551.png)

なお、SSHで2つログインして、片方で``top``を実行しながらもう一方で``stress-ng``を実行したのですが、``stress-ng``を実行した瞬間から、``top``の更新が大幅に遅延、ほぼ止まったような状態になりました。

さて、負荷はかけられたので、アラートが来るのを待ちます。しばらくすると、メールとスマホアプリに通知が来ました。また、Portalの警告画面にもアラートが表示されます。

アラートメール
![11-alertmail.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/d242a83f-7fcf-e19e-d868-f727a0ad71ab.png)

スマホアプリの通知
![12-mobileapp-alert.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/dd5325ed-d633-cb39-7573-0176eabfecc7.png)

Portalの警告画面
![13-portal-alert2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2822136/0a413ab5-a84f-2118-7ee9-76060fc7102c.png)

無事、Virtual Machineの高負荷でアラートを受信できましたので、本記事の目標達成としたいと思います。

最後までお読みいただきありがとうございました。
今後もAzureの記事を投稿していきたいと思いますので、よろしくお願いします。