2.3. ルール設定について

Tip

新規のワークスペースを作成し、以下シナリオを実施してください。
これまでの検討を踏まえて、具体的に以下の順にOASEの設定を行っていきましょう。

  1. イベント収集設定

  2. ラベルの設定

  3. OASEエージェントの設定

  4. ルールの設定

2.3.1. イベント収集設定

2.3.1.1. イベント収集設定

イベント収集設定では、エージェントがどの外部サービスからイベントを収集するかを設定します。
OASE管理 ▶ イベント収集 から、外部サービスの情報を登録します。
登録 ボタンを押し、以下のエージェントの登録をしていきます。
イベント収集登録画面
表 2.26 イベント収集設定値

イベント収集設定名

接続方式

リクエストメソッド

接続先

認証情報

TTL

ユーザー名

パスワード

リクエスト監視

IMAP パスワード認証

IMAP: Plaintext

**.***.**.***

*****@**.***

**

60
入力が終わったら、編集確認 ボタンを押して登録します。

Tip

* の部分は、各自の外部サービスの情報を入力してください。

2.3.2. ラベルの設定

収集するイベントに付与するラベルの作成と付与する条件を設定します。
表 2.27 ラベル一覧

ラベルキー

利用目的

subject

イベントの内容を特定できるようにするラベル

requestcount

基準となった閾値を把握するためのラベル

instance

現在のインスタンス数を示すラベル

page

Sorry画面への切り替え状況を示すラベル

2.3.2.1. ラベルの作成

ラベル作成 では、イベントを特定する時に利用するキー(ラベル)を作成します。
OASE ▶ ラベル ▶ ラベル作成 から、ラベルを作成します。
登録 ボタンを押し、以下のラベルの設定を追加していきます。
ラベル作成画面
表 2.28 ラベル作成の設定値

ラベルキー

カラーコード

subject

#FBFF00

requestcount

#7F76F9

instance

#00FF33

page

#FF2600

pattern

#A1DEB8
入力が終わったら、編集確認 ボタンを押して登録します。

注釈

ラベルそれぞれにカラーコードを設定することで、付与されたときに見分けやすくなります。

2.3.2.2. ラベルを付与する条件の設定

OASE ▶ ラベル ▶ ラベル付与 から、ラベルを付与するための設定を行います。
登録 ボタンを押し、以下のラベル付与の設定を追加していきます。
必要に応じて、追加 ボタンを押して行数を追加しましょう。
表 2.29 ラベル付与の設定値

ラベリング設定名

イベント収集設定名

検索条件

ラベル

キー

値のデータ型

比較方法

比較する値

キー

値

通知名

リクエスト監視

subject

文字列

==

[alert] Requests: Threshold reached

subject

リクエスト数超過

通知名

リクエスト監視

subject

文字列

==

[info] Requests: Threshold recovery

subject

リクエスト数回復

リクエスト数監視

リクエスト監視

body.plain

その他

RegExp

RequestCount . (\d{2,3})

requestcount

\1
入力が終わったら、編集確認 ボタンを押して登録します。

Tip

ラベリング設定名とイベント収集設定名は任意で設定可能です。わかりやすいものを設定しましょう。
メールの件名から通知内容を特定する、「subject」のラベルを付与する設定を行います。
メールの本文から通知の基準となった閾値を参照する、「requestcount」のラベルを付与する設定を行います。

2.3.3. OASEエージェントの設定

OASEエージェントの設定を行い、エージェントを実行します。

注釈

OASEエージェントの詳細は、下記のページにてご確認ください。
OASE Agent on Docker Compose - Online

2.3.3.1. .envの設定

.envの項目にこれまでの工程で設定した値を設定します。
exastro-docker-compose/ita_ag_oase/.env に下記の内容を入力します。
.env
表 2.30 .envの設定値

項目名

設定値

AGENT_NAME

ita-oase-agent-01

EXASTRO_URL

http://********

EXASTRO_ORGANIZATION_ID

********

EXASTRO_WORKSPACE_ID

********

EXASTRO_USERNAME

********

EXASTRO_PASSWORD

********

EVENT_COLLECTION_SETTINGS_NAMES

リクエスト監視

EXECUTE_INTERVAL

5

LOG_LEVEL

INFO

Tip

* の部分は、各自の情報を入力してください。
各項目の詳細は、下記のページ 2.8.1. OASE Agentの処理フローと.envの設定値 を参照ください。
OASE 管理

2.3.3.2. エージェントの実行

次のコマンドを使い、コンテナを起動してみましょう。
リスト 2.43 docker コマンドを利用する場合(Docker環境)
docker compose up -d --wait
リスト 2.44 docker-compose コマンドを利用する場合(Podman環境)
docker-compose up -d --wait
状態が Healthy になっていることを確認します。
正常に接続できているか、以下のコマンドでLogの確認をします。
リスト 2.45 docker コマンドを利用する場合(Docker環境)
docker compose logs -f
リスト 2.46 docker-compose コマンドを利用する場合(Podman環境)
docker-compose logs -f
エラーが出ている場合は、.envファイルの各設定値が正しいか確認してください。

2.3.4. ルールの設定

では、イベントの発生とイベントが発生した時に稼働しているインスタンスの台数によってアクションが実行されるルールを作成していきましょう。
リクエスト数に関するイベントだけでなく、現在Sorry画面に切り替わっているかどうかも条件に設定していきます。

2.3.4.1. フィルターの設定

OASE ▶ ルール ▶ フィルター から、フィルター を設定します。
フィルターは、OASEを設定する際の事前設計について で検討したように、
インスタンスが何台稼働しているか
どのような通知が来たか
さらに、
sorry画面に切り替わっているか
という三種類のものが必要です。
登録 ボタンを押し、以下のフィルターの設定を追加していきます。
フィルター
表 2.31 フィルターの設定値

有効

フィルター名

フィルター条件

検索方法

True

パターン2

[["instance", "==", "2"], ["pattern", "≠", "2"]]

ユニーク

True

パターン3

[["instance", "==", "3"], ["pattern", "≠", "3"]]

ユニーク

True

パターン4

[["page", "==", "sorry"], ["pattern", "≠", "4"]]

ユニーク

True

パターン5

[["instance", "==", "3"], ["pattern", "≠", "5"]]

ユニーク

True

パターン6

[["instance", "==", "2"], ["pattern", "≠", "6"]]

ユニーク

True

超過_通知

[["subject", "==", "リクエスト数超過"], ["_exastro_type", "≠", "conclusion"]]

ユニーク

True

超過_閾値50以外

[["requestcount", "≠", "50"], ["subject", "==", "リクエスト数超過"]]

ユニーク

True

超過_閾値150

[["requestcount", "==", "150"], ["subject", "==", "リクエスト数超過"]]

ユニーク

True

回復_通知

[["subject", "==", "リクエスト数回復"], ["_exastro_type", "≠", "conclusion"]]

ユニーク

True

回復_閾値150以外

[["requestcount", "≠", "150"], ["subject", "==", "リクエスト数回復"]]

ユニーク

True

回復_閾値50

[["requestcount", "==", "50"], ["subject", "==", "リクエスト数回復"]]

ユニーク
入力が終わったら、編集確認 ボタンを押して登録します。

2.3.4.2. フィルターの設定ポイント

フィルター名について
任意で設定可能です。わかりやすいものを設定しましょう。
それぞれのフィルターの性格について
「パターン＊」は、それぞれ、パターンごとの状況把握のためのフィルターになります。
それ以外のものは、通知内容を確認するものになります。
「超過_通知」「回復_通知」について
こちらのフィルターは以下のパターンで用います。

  • パターン1 インスタンス1台のとき、リクエスト数超過通知:50/100/150

  • パターン4 sorry画面に切り替わっているとき、リクエスト数回復通知:50/100/150

イベントが発生したら、閾値に関わらず、アクションが実行されるものです。
["_exastro_type", "≠", "conclusion"]が設定されているのは、「subject」だけだと、ほかの「元イベントのラベル継承」をした結論イベントでも該当するからです。
意図せず、条件にあってしまうことを避けるために設定します。
「超過_通知」「回復_通知」以外の通知内容を把握するフィルターについて
これらのフィルターでは、
通知内容が届いたときのイベントから通知内容をフィルタリングする場合
通知内容と状況に基づいてアクションが実行された後の結論イベントから通知内容をフィルタリングする場合
があるため、["_exastro_type", "≠", "conclusion"]は条件に入っていません。
また、それぞれ閾値の指定があるのは、

  • パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150

  • パターン3 インスタンス3台のとき、リクエスト数超過通知:150

  • パターン5 インスタンス3台のとき、リクエスト数回復通知:50/100

  • パターン6 インスタンス2台のとき、リクエスト数回復通知:50

の閾値によって条件付けされているパターンに対応するためです。

2.3.4.3. アクションの設定

OASE ▶ ルール ▶ アクション から、アクション を設定します。
登録 ボタンを押し、以下のアクションの設定を追加していきます。
表 2.32 アクションの設定値

アクション名

Conductor名称

オペレーション名

ホスト

イベント連携

scale-out

インスタンススケールアウト

インスタンススケールアウト

false

scale-in

インスタンススケールイン

インスタンススケールイン

false

sorry_switch

Sorry画面切り替え

Sorry画面切り替え

false

sorry_switch-back

sorry画面切り戻し

sorry画面切り戻し

false
入力が終わったら、編集確認 ボタンを押して登録します。

Tip

アクション名は任意で設定可能です。わかりやすいものを設定しましょう。
Conductor名称とオペレーション名は、事前に設定してあるものから選択します。

2.3.4.4. ルールの設定

それでは、フィルターとアクションを以下の6パターンに合わせて紐づけていきましょう。
scale-outが実行される状況

  • パターン1 インスタンス1台のとき、リクエスト数超過通知:50/100/150

  • パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150

sorry画面への切り替えが実行される状況

  • パターン3 インスタンス3台のとき、リクエスト数超過通知:150

sorry画面からの切り戻しが実行される状況

  • パターン4 sorry画面に切り替わっているとき、リクエスト数回復通知:50/100/150

scale-inが実行される状況

  • パターン5 インスタンス3台のとき、リクエスト数回復通知:50/100

  • パターン6 インスタンス2台のとき、リクエスト数回復通知:50

OASE ▶ ルール ▶ ルール から、ルール を設定します。
登録 ボタンを押し、以下のルールの設定を追加していきます。
ルール
表 2.33 ルールの設定値

有効

ルール名

ルールラベル名

優先順位

条件

アクション

結論イベント

フィルターA

フィルター演算子

フィルターB

アクションID

元イベントのラベル継承

結論ラベル設定

TTL

アクション

イベント

True

パターン1

インスタンス数2台へscale-out

2

超過_通知

scale-out

True

True

[["instance", "2"], ["pattern", "1"]]

3600

True

パターン2

インスタンス数3台へscale-out

1

超過_閾値50以外

A and B

パターン2

scale-out

True

True

[["instance", "3"], ["pattern", "2"]]

3600

True

パターン3

Sorryへ切り替え

1

超過_閾値150

A and B

パターン3

sorry_switch

True

false

[["page", "sorry"], ["pattern", "3"]]

3600

True

パターン4

Sorry切り戻し

1

回復_通知

A and B

パターン4

sorry_switch-back

True

True

[["page", "normal"], ["pattern", "4"], ["instance", "3"]]

3600

True

パターン5

インスタンス数2台へscale-in

1

回復_閾値150以外

A and B

パターン5

scale-in

True

True

[["instance", "2"], ["pattern", "5"]]

3600

True

パターン6

インスタンス数1台へscale-in

1

回復_閾値50

A and B

パターン6

scale-in

True

false

[["instance", "1"], ["pattern", "6"]]

10
入力が終わったら、編集確認 ボタンを押して登録します。

2.3.4.5. ルールの設定ポイント

ルール名・ルールラベル名について
任意で設定可能です。わかりやすいものを設定しましょう。
条件について
パターンの条件に合うフィルターを選択します。
パターン1では、平常時のインスタンス数1台である状態をOASEのイベントとしては管理していないので、条件は「超過_通知」のみとなります。
リクエスト数超過通知のイベントが発生したときに、前提となる状況を示す結論イベントがなければ、こちらのルールが適用されるように、優先順位を「2」とします。
パターン1以外のパターンでは、前提となる状況を示す結論イベントが条件の一つになりますので、そちらを選択します。
複数の条件がある場合は、それぞれの項目を以下のように設定します。
フィルターA : 通知内容をフィルタリングするためのフィルター
フィルター演算子 :「A and B」
フィルターB : 前提となる状況をフィルタリングするためのフィルター
同じキーがフィルターAとフィルターBそれぞれにフィルタリングされるイベントの両方に付与されていた場合、
フィルターAでフィルタリングされたイベントのラベルの値が継承される仕様のためです。
通知内容を示すラベルが次のアクションのために必要なので、通知内容を示すイベントのラベルをフィルタリングするフィルターをフィルターAに設定します。
結論ラベルについて
アクションが実行された結果がわかるように、ラベルを付与するよう設定を行います。
元イベントから継承するラベルの中に結論ラベル設定で設定するキーがある場合は、結論ラベル設定で設定した値が付与される仕様です。
こちらの仕様を活用して、アクションが実行される前の状況を示す値となっているラベルの値を、アクションが実行された後の状況を示す値に更新するように設定を行います。
これにより、結論イベントがその結論イベントを発生させたルールに再適用されるループの発生を回避することもできます。
TTLについて
前提となる状況を示す結論イベントが各ルールの条件となるため、ルールに複数の条件を設定した場合のイベントのTTL問題について でも説明したように、
TTLを通知内容を示すイベントが発生するまで伸ばす必要があります。
今回は ルールに複数の条件を設定した場合のイベントのTTL問題について で提示したTTL切れを防ぐ方法のうち、TTLを長めに設定する方法を採用しました。
もし結論イベントをループさせたい場合は、各ルールで発生する結論イベントにループ用の["event_status", "progress"]などを付与し、
こちらのラベルが付与されたイベントをフィルタリングするフィルターを条件としたルールを追加してください。
その際に、ループが発生するように「元イベントのラベル継承」をTrueにし、優先順位は「3」としましょう。
これにより、ほかのルールが適用されなかった場合、このルールが適用されるようになります。
パターン6について
平常時に戻った状態となり、次のイベントの条件になることはありません。
そのため、意図しない形でほかの条件となってしまわないように、TTLを最小値にし、念のため、「元イベントのラベル継承」を「false」に設定しておくとよいでしょう。

2.3.4.6. 結果の確認

では、イベントフロー 画面から、ルールに従ってイベントが発生していく様子を確認してみましょう。
OASE ▶ イベント ▶ イベントフロー の画面に、時系列にイベントが発生しているのが確認できます。
複数のアクションが連続して発生している様子を確認してみましょう。
以下は、インスタンス1台のときに閾値150リクエスト/minを超過したというリクエスト数超過通知が来た場合と、
その後、閾値150リクエスト/min未満に回復したというリクエスト数回復通知が来た場合のものになります。
イベントフロー_結論イベント