【OCI_06】モニタリング機能でインスタンスを監視する
今回の作業は、管理者ユーザー（ocitestadm01）でフルアクセス権限のあるtest_compartmentコンパートメントに対して実施していきます。
OCIのチュートリアルを参照し、モニタリング機能でインスタンスの監視を検証してみます。
モニタリング機能でOCIのリソースを監視する
https://oracle-japan.github.io/ocitutorials/intermediates/monitoring-resources/
目次
事前準備：VCN関連のネットワーク、インスタンスの作成
VCN関連のネットワークやインスタンスは、以下の記事を参考に作成しています。
以下の「コンピュート・インスタンスのモニタリング」がチェックされているか念のために確認しておいてください。
基本的にはデフォルトで有効になっているようです。
確認方法は、インスタンス作成中と作成後の２とおりあります。
■インスタンス作成中
「イメージとシェイプ」項の「拡張オプション」を展開します。
Oracle Cloudエージェント > コンピュート・インスタンスのモニタリング のチェックボックスにチェックが入っていることを確認します。
■インスタンス作成後
該当インスタンスをクリックして「管理」タブを選択します。
Oracle Cloudエージェント > コンピュート・インスタンスのモニタリング の右側にあるトリコロンから有効化します。
コンピュート・インスタンスからメトリックを参照する（単体）
コンピュート・インスタンスの設定画面から個別にメトリックを参照してみます。
OCIコンソールの左上のハンバーガーメニューを展開し、「コンピュート」を選択、「コンピュート」の「インスタンス」を選択します。
該当のインスタンス名をクリックします。
「モニタリング」タブを選択、CPUやメモリの使用率、ディスクのI/O、ネットワークの送受信バイトなど確認できます。
サービス・メトリックからメトリックを参照する（複数台）
個別のリソースではなく複数のリソースにまたがってメトリックを一覧で参照したい場合は、サービス・メトリックのページから参照します。
OCIコンソールの左上のハンバーガーメニューを展開し、「監視および管理」を選択、「サービス・メトリック」を選択します。項目が多いので表示されてない場合は画面を下へスクロールします。
サービス・メトリック画面で表示させたい対象の コンパートメント と メトリック・ネームスペース を選択します。
今回メトリック・ネームスペースには「oci_computeagent」を選択します。
開始時間、終了時間を変更することで表示する範囲を変更できます。
画面下部へCPUやメモリの使用率、ディスクのI/O、ネットワークの送受信バイトなどが表示されます。
インスタンスが１台の場合、グラフは１つでした。
インスタンスをもう１台作成したら色違いでグラフが表示されました。グラフをポイントするとインスタンス名が表示されハイライトされているので見分けることができます。
アラームの通知先の作成
アラーム定義を作成し、何か起こった時に通知などを行うことができます。
今回は、インスタンスの死活監視目的でインスタンスのメトリックが取得できない場合に検知してメール通知を行う設定を実行します。
具体的には、CPUに負荷をかけ100%にさせて取得できない状況を作ります。
まずはメール通知先を作成していきます。
OCIコンソールの左上のハンバーガーメニューを展開し、「開発者サービス」を選択、「通知」を選択します。
「トピックの作成」をクリックします。
トピックの作成画面で任意の「名前」、「説明」を入力します。
「タグ」はデフォルトのままとし、右下の「作成」をクリックします。
作成したトピックの名前のリンクをクリックし、作成したトピックの画面を表示します。
「サブスクリプション」タブを選択し、「サブスクリプションの作成」をクリックします。
サブスクリプションの作成画面で以下のとおり、選択、入力して、右下の「作成」をクリックします。
プロトコル：電子メール
電子メール：受信可能なメールアドレス
サブスクリプションを作成すると、保留中 ステータスになっています。
先ほど登録したメールアドレスにメールが届いているので確認します。
以下のメールが届くので「Confirm subscription」をクリックします。
ステータスが「保留中」から「アクティブ」に変更されました。
これでメール通知の設定は完了です。
アラーム定義の作成
次は、インスタンスのメトリックが取得できない場合に検知してメール通知を行うアラームを定義していきます。
OCIコンソールの左上のハンバーガーメニューを展開し、「監視および管理」を選択、「アラーム定義」を選択します。
「アラームの作成」をクリックします。
アラームの定義は、以下を入力、選択します。
アラーム名：任意のアラーム名
メトリックの説明は、以下を入力、選択します。
コンパートメント：メトリックのあるコンパートメント
メトリック・ネームスペース：oci_computeagent
リソース・グループ：リソース・グループがありません（デフォルト）
メトリック名：CpuUtilization
間隔：1分 （デフォルト）
統計：Mean（デフォルト）
メトリック・ディメンションは、以下を入力、選択します。
ディメンション名：resourceDisplayName
ディメンション値：監視対象のインスタンス表示名
トリガー・ルール１は、以下を入力、選択します。
演算子：次より大きい を選択
値：40
トリガー遅延分数：5
アラームの重大度：クリティカル（デフォルト）
アラーム本体：任意の通知内容
アラーム通知の定義は、以下を入力、選択します。
宛先サービス：通知
コンパートメント：事前作成した通知トピックのあるコンパートメント
トピック：事前作成したトピック名
通知の件名：空白（デフォルト）
メッセージのグループ化は、デフォルトのままとします。
メッセージの書式は、以下を選択します。
「このアラームを有効化しますか。」にチェックが入っていることを確認し、「アラームの保存」をクリックします。
アラームが作成されました。アラームが有効になっていることを確認しておきます。
メール通知されることを確認
アラームやメール通知設定が完了したのでインスタンスへ負荷をかけ、CPUメトリックが取得できない状況を作り出します。
CPUメトリックが取得できない状況になればメールが通知されます。
公式チュートリアルに習いstressコマンドでCPU使用率を上げます。
インスタンスへSSHでログインします。
stressパッケージを含むEPELリポジトリが有効になっているか確認します。
おそらく「disabled」となっています。
sudo yum repolist all | grep -i epel
利用しているイメージのバージョンを確認し、有効化のためのyum-config-managerコマンドを実行します。
あらためて有効化されたことを確認します。
sudo yum-config-manager –enable ol9_developer_EPEL
sudo yum repolist all | grep -i epel
stressパッケージをインストールします。「Complete!」が表示されればインストール完了です。
sudo yum -y install stress
stressコマンドでCPUに負荷をかけます。該当インスタンスは「VM.Standard3.Flex」のシェイプを利用しています。
stress -c 2 &
topコマンドで確認してみます。
公式チュートリアルとシェイプは違いますが、下記コマンドでCPU負荷が100%になりました。（※画像はタイミングによって 99.5 になってます）
top
作成したアラームの「アラーム・データ」のグラフにCPU使用率が100になっているグラフが表示されています。
しばらくするとアラーム通知のメールが届きました。
メニューから「アラームのステータス」を選択します。
「クリティカル・アラーム」が「１」となり、今回のアラームが記録されていることがわかります。
しばらくすると「クリティカル・アラーム」が「０」になりました。現時点では、理由はわかっておりません・・・
アラーム通知のメールを確認したら、stressコマンドを停止させます。
バックグラウンドで動いているすべての stress プロセスを一括停止する場合、pkill stressを実行します。
pkill stress
topコマンドで確認してみます。
CPU使用率は、0 % になりました。
top
まとめ
今回は、メトリックの参照やアラームを定義し、メール通知の検証を行いました。
