1.6. Sorry画面からの切り戻し実施 (解答)¶

1.6.1. 問題 (再掲)¶

以下のようなリクエスト数が閾値内に回復したイベントが発生したときに、Sorry画面切り戻しのアクションが実行されるようにOASEの設定を行ってください。

表 1.60 通知メール一覧¶
通知内容	Sorry画面切り替え中にリクエスト数が閾値内に回復した場合
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `150`

1.6.2. 自動化する作業の具体的な検討¶

まずは作業計画を立てましょう。

今回のシナリオでは、以下の保守作業を自動的に実行します。

作業D Sorry画面から切り戻す作業

今回想定している構成から作業Dが実行されるのは、

すでに3台稼働し、Sorry画面に切り替わっている状況において、リクエスト数が3台稼働時の閾値150リクエスト/min内に回復したとき。

となります。

ここまで整理できたら、具体的に以下のOASEの設定を行っていきましょう。

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

1.6.3. イベント収集設定¶

1.6.3.1. イベント収集設定¶

警告

前シナリオで設定したものが残っているようであれば、こちらの設定は不要です。

イベント収集設定では、エージェントがどの外部サービスからイベントを収集するかを設定します。

OASE管理 ▶ エージェントから、外部サービスの情報を登録します。

登録ボタンを押し、以下のエージェントの登録をしていきます。

表 1.61 イベント収集設定値¶
イベント収集設定名	接続方式	リクエストメソッド	接続先	認証情報		TTL
				ユーザー名	パスワード
`リクエスト監視`	`IMAP` `パスワード認証`	`IMAP:` `Plaintext`	`...**`	`***@.***`	`**`	`60`

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

Tip

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

1.6.4. ラベルの設定¶

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

表 1.62 ラベル一覧¶
ラベルキー	利用目的
subject	イベントの内容を特定できるようにするラベル
requestcount	基準となった閾値を把握するためのラベル
page	作業Dの作業結果を示すためのラベル

注釈

イベントに含まれる全ての情報をラベルとして管理する必要はありません。今後必要になったタイミングで適宜追加や見直しをしましょう。

1.6.4.1. ラベルの作成¶

警告

前シナリオで設定したものが残っているようであれば、こちらの設定は不要です。

ラベル作成では、イベントを特定する時に利用するキー(ラベル)を作成します。

OASE ▶ ラベル ▶ ラベル作成から、ラベルを作成します。

登録ボタンを押し、以下のラベルの設定を追加していきます。

必要に応じて、追加ボタンを押して行数を追加しましょう。

表 1.63 ラベル作成の設定値¶
ラベルキー	カラーコード
`subject`	`#FBFF00`
`requestcount`	`#7F76F9`
`page`	`#FF2600`

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

注釈

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

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

ラベル付与では、イベントにラベルを付与する条件と、条件に合った際に付与するラベルの内容を設定します。

今回は、リクエスト数閾値内回復を知らせるものであるかどうかを示すラベルを付与する必要があります。

警告

前シナリオで設定したものが残っているようであれば、こちらの設定は不要です。

OASE ▶ ラベル ▶ ラベル付与から、ラベルを付与するための設定を行います。

登録ボタンを押し、以下のラベル付与の設定を追加していきます。

必要に応じて、追加ボタンを押して行数を追加しましょう。

表 1.64 ラベル付与の設定値¶
ラベリング設定名	イベント収集設定名	検索条件				ラベル
		キー	値のデータ型	比較方法	比較する値	キー	値
`通知名`	`リクエスト監視`	`subject`	`文字列`	`==`	`[info]` `Requests:` `Threshold` `recovery`	`subject`	`リクエスト数回復`
`リクエスト数監視`	`リクエスト監視`	`body.plain`	`その他`	`RegExp`	`RequestCount` `.` `(\d{2,3})`	`requestcount`	`\1`

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

Tip

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

1.6.5. OASEエージェントの設定¶

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

警告

前シナリオで設定したものが残っているようであれば、こちらの設定は不要です。

注釈

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

OASE Agent on Docker Compose - Online

1.6.5.1. .envの設定¶

.envの項目にこれまでの工程で設定した値を設定します。

exastro-docker-compose/ita_ag_oase/.env に下記の内容を入力します。

表 1.65 .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

* の部分は、各自の情報を入力してください。
「EXASTRO_USERNAME」と「EXASTRO_PASSWORD」は、ワークスペースのものになります。
各項目の詳細は、下記のページ 2.8.1. OASE Agentの処理フローと.envの設定値 を参照ください。
OASE 管理

1.6.5.2. エージェントの実行¶

次のコマンドを使い、コンテナを起動してみましょう。

警告

UIDが1000以外のユーザで実行する場合は、「chown -R 1000:1000 保存先のボリュームのパス」を実行してください。

リスト 1.20 docker コマンドを利用する場合(Docker環境)¶

docker compose up -d --wait

リスト 1.21 docker-compose コマンドを利用する場合(Podman環境)¶

docker-compose up -d --wait

状態が Healthy になっていることを確認します。

正常に接続できているか、以下のコマンドでLogの確認をします。

リスト 1.22 docker コマンドを利用する場合(Docker環境)¶

docker compose logs -f

リスト 1.23 docker-compose コマンドを利用する場合(Podman環境)¶

docker-compose logs -f

エラーが出ている場合は、.envファイルの各設定値が正しいか確認してください。

1.6.6. ルールの設定¶

では、今度はイベントの発生に合わせてSorry画面からの切り戻し作業を自動的に実行する設定を行っていきましょう。

今回は応用として、リクエスト数に関するイベントだけでなく、現在Sorry画面に切り替わっているかどうかも条件に設定していきます。

下記のSorry画面に切り替わっているときのリクエスト数回復のイベントを発生させて、設定を進めましょう。

表 1.66 通知メール一覧¶
通知内容	リクエスト数回復
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `150`

1.6.6.1. フィルターの設定¶

OASE ▶ ルール ▶ フィルターから、フィルターを設定します。

登録ボタンを押し、以下のフィルターの設定を追加していきます。

表 1.67 フィルターの設定値¶
有効	フィルター名	フィルター条件	検索方法
`True`	`request_range_max`	`[["subject",` `"==",` `"リクエスト数回復"],` `["requestcount",` `"==",` `"150"]]`	`ユニーク`

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

Tip

フィルター名は任意で設定可能です。わかりやすいものを設定しましょう。
ラベル「subject」の値から、リクエスト数が閾値内に回復したことを通知するイベントであることを特定できるようにフィルター条件を設定します。
ラベル「requestcount」の値から、通知の基準となった閾値を特定できるようにフィルター条件を設定します。
今回は、閾値として150の場合のみを条件としてアクションを実行するので150と設定しました。

ラベル「requestcount」だけでは超過したイベントなのか回復したイベントなのか判別できないため、ラベル「subject」をフィルター条件に設定し、イベントを一意に特定できるようにします。

このように、イベントごとに特定のラベルを付与しなくても、必要に応じてフィルター条件を複数設定することで、イベントを一意に特定することできます。

フィルターは OASE ▶ イベント ▶ イベントフローからも設定することが可能です。

注釈

未知のイベントが発生した場合は、OASE ▶ イベント ▶ イベントフローからの設定がおすすめです。

イベントを参照しながら直感的に設定できます。

OASE ▶ イベント ▶ イベントフローからは以下のように設定します。

警告

フィルターでイベントを検出するには、そのイベント発生前に設定しておく必要があります。

合わせて、Sorry画面に切り替えが行われているのかどうかを把握するためのフィルターも設定しましょう。

Tip

Sorry画面に切り替えが行われているのかどうかは、Sorry画面に切り替えたアクションの結論イベントに付与したラベルから特定することができます。
Sorry画面に切り替えたときの結論イベントのTTLが切れている場合は、改めて、Sorry画面への切り替え実施 に沿って、Sorry画面に切り替えたアクションの結論イベントを発生させましょう。
結論イベントについては、ルールに複数の条件を設定した場合のイベントのTTL問題について や 不要になったイベントについて も参考にしてください。

OASE ▶ ルール ▶ フィルターから、フィルターを設定します。

登録ボタンを押し、以下のフィルターの設定を追加していきます。

表 1.68 フィルターの設定値¶
有効	フィルター名	フィルター条件	検索方法
`True`	`sorry_switch`	`[["page",` `"==",` `"sorry"],` `["_exastro_type",` `"==",` `"conclusion"]]`	`ユニーク`

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

Tip

フィルター名は任意で設定可能です。わかりやすいものを設定しましょう。
ラベル「page」の値から、現在、Sorry画面に切り替わっている状況を特定できるようにフィルター条件を設定します。
ラベル「_exastro_type」の値から、結論イベントであることを特定できるようにフィルター条件を設定します。

フィルターは OASE ▶ イベント ▶ イベントフローからも設定することが可能です。

注釈

未知のイベントが発生した場合は、OASE ▶ イベント ▶ イベントフローからの設定がおすすめです。

イベントを参照しながら直感的に設定できます。

OASE ▶ イベント ▶ イベントフローからは以下のように設定します。

警告

フィルターでイベントを検出するには、そのイベント発生前に設定しておく必要があります。

1.6.6.2. アクションの設定¶

アクションでは、ITAで作成したConductorとオペレーションを指定できます。

Sorry画面からの切り戻しを実施するアクションを指定してみましょう。

OASE ▶ イベント ▶ イベントフローから、アクションを設定します。

表 1.69 アクションの設定値¶
アクション名	Conductor名称	オペレーション名	ホスト
			イベント連携
`sorry_switch`-`back`	`sorry画面切り戻し`	`sorry画面切り戻し`	`false`

Tip

アクション名は任意で設定可能です。わかりやすいものを設定しましょう。

Conductor名称とオペレーション名は、事前に設定してあるものから選択します。今回はSorry画面切り戻し用に準備したものを選択しましょう。

警告

設定する際に参照したイベントに適用したい場合は、そのイベントのTTL内に設定する必要があります。

TTL内に設定が難しいようであれば、事前に OASE ▶ ルール ▶ アクションから設定しておきましょう。

OASE ▶ ルール ▶ アクションからは以下のように設定します。

登録ボタンを押し、以下のアクションの設定を追加していきます。

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

1.6.6.3. ルールの設定¶

そのフィルターでイベントを検知した場合に実行したいアクションを紐づけましょう。

注釈

Sorry画面からの切り戻しを実施するのは、Sorry画面への切り替えが行われている状況で、リクエスト数が閾値内に回復したイベントが発生した場合です。

フィルター演算子を用いることで、二つのフィルターを条件にできます。

OASE ▶ イベント ▶ イベントフローから、ルールを設定します。

表 1.70 ルールの設定値¶
有効	ルール名	ルールラベル名	優先順位	条件			アクション	結論イベント
				フィルターA	フィルター演算子	フィルターB	アクションID	元イベントのラベル継承		結論ラベル設定	TTL
								アクション	イベント
`True`	`sorry画面切り戻し`	`sorry画面切り戻し`	`1`	`sorry_switch`	`A` -`>` `B`	`request_range_max`	`sorry_switch`-`back`	`True`	`False`	`[["page",` `"normal"]]`	`60`

Tip

ルール名・ルールラベル名は任意で設定可能です。わかりやすいものを設定しましょう。
条件では、フィルターの設定で設定したフィルター「sorry_switch」と「request_range_max」を選択します。
アクションでは、アクションの設定で設定したアクション「sorry_switch-back」を選択します。
これにより、フィルタ―「sorry_switch」でイベントを検知したあとに、「request_range_max」でイベントを検知したら、アクション「sorry_switch-back」が実行されます。

条件が成立するためには、フィルタ―「sorry_switch」で検知したイベントのTTL内に「request_range_max」でイベントが検知される必要があります。

そのため、Sorry画面への切り替え実施のルール設定の際にTTLを長めに設定しました。

結論ラベル設定には、アクションが実行されたことを示す結論イベントに付与するラベルを設定します。

結論イベントが判別しやすいようなラベルを設定するとよいでしょう。

警告

設定する際に参照したイベントに適用したい場合は、そのイベントのTTL内に設定する必要があります。

TTL内に設定が難しいようであれば、事前に OASE ▶ ルール ▶ ルールから設定しておきましょう。

OASE ▶ ルール ▶ ルールからは以下のように設定します。

登録ボタンを押し、以下のルールの設定を追加していきます。

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

1.6.6.4. 結果の確認¶

以上の設定が完了すると、発生したイベントをもとにアクションが実行される様子を、イベントフロー画面から確認してみましょう。

Tip

ルールの設定の間に発生させたイベントのTTLが切れてしまったら、改めて同じイベントを発生させてください。

表 1.71 通知メール一覧¶
通知内容	リクエスト数回復
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `150`

OASE ▶ イベント ▶ イベントフローの画面に、時系列にイベントが発生しているのが確認できます。

アクションが実行されたことを示す結論イベントには、スケールインの時とは違う、ルールで設定したラベルが付与されているのも確認しましょう。

↑ Page Top