2.3. ルール設定について¶

Tip

新規のワークスペースを作成し、以下シナリオを実施してください。

これまでの検討を踏まえて、具体的に以下の順にOASEの設定を行っていきましょう。

イベント収集設定
ラベルの設定
OASEエージェントの設定
ルールの設定

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 に下記の内容を入力します。

表 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未満に回復したというリクエスト数回復通知が来た場合のものになります。

↑ Page Top