1.2. Sorry画面への切り替え実施

1.2.1. 今回のシナリオで自動化する作業について

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

• 作業B Sorry画面へ切り替える作業

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

稼働するインスタンス数が上限である3台のときに、リクエスト数が閾値を超過したとき

となります。

つまり、

3台稼働の閾値である150リクエスト/minを超えたとき

になります。

1.2.2. 具体的な設定の検討

では具体的に今回の運用保守の一連の流れをどのようにOASEで設定するか、作業計画を立てましょう。

作業Bを条件に合わせて実行するようにするためには、OASEで以下のような設定を行う必要があります。

• 設定a 外部サービスからイベントを収集する設定

• 設定b 収集したイベントの中から、リクエスト数超過に関するイベントを特定する設定

• 設定c リクエスト数超過に関するイベントの中から自動化する作業Bの条件に合うイベントを検知する条件の設定

• 設定d 自動化する作業Bの登録

• 設定e 設定cで設定した振り分け条件と設定dで登録した作業を紐づける設定

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

1. イベント収集設定

2. ラベルの設定

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

4. ルールの設定

1.2.3. イベント収集設定

警告

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

エージェントはイベント収集設定で設定された外部サービスに対して、イベントの収集を行います。

エージェントがどの外部サービスからリクエスト数超過というイベントを収集するか設定をしていきましょう。

Tip

設定するためには対象となる外部サービスの情報が必要です。お手元にご準備ください。

1.2.3.1. イベント収集設定

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

事前に用意したメールサーバの情報をもとに設定をしましょう。

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

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

表 1.35 イベント収集設定値

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

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

Tip

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

1.2.4. ラベルの設定

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

ラベル

ラベルは「キー」と「値」から成り、付与されたイベントの属性を表します。

イベントは、付与された「キー」と「値」によって認識されます。

今回必要なラベルは以下の通りです。

表 1.36 ラベル一覧

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

注釈

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

1.2.4.1. ラベルの作成

警告

前シナリオで設定したものが残っているようであれば、足りない分だけ追加してください。

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

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

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

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

表 1.37 ラベル作成の設定値

ラベルキー	カラーコード
subject	#FBFF00
requestcount	#7F76F9
page	#FF2600

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

注釈

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

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

警告

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

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

今回は、リクエスト数超過を知らせるものであるかどうか、また、基準となった閾値はいくらかを示すラベルを付与する必要があります。

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

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

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

表 1.38 ラベル付与の設定値

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

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

Tip

ラベリング設定名とイベント収集設定名は任意で設定可能です。わかりやすいものを設定しましょう。

メールの件名から通知内容を特定する、「subject」のラベルを付与する設定を行います。

メールの本文から通知の基準となった閾値を参照する、「requestcount」のラベルを付与する設定を行います。

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

警告

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

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

これにより、「イベント収集設定」で指定した外部サービスからイベントを収集し、「ラベルを付与する条件の設定」に合うイベントにはラベルが付与されます。

注釈

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

OASE Agent on Docker Compose - Online

1.2.5.1. .envの設定

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

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

表 1.39 .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.2.5.2. エージェントの実行

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

警告

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

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

docker compose up -d --wait

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

docker-compose up -d --wait

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

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

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

docker compose logs -f

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

docker-compose logs -f

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

1.2.6. ルールの設定

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

ルール では、イベントを特定する条件と、その条件に合致したイベントが発生した場合に実行したい作業を紐づけることができます。

イベントを特定する条件は フィルター 、実行したい作業は アクション 、でそれぞれ設定します。

ルール では、フィルター と アクション を紐づける形で設定します。

注釈

イベントフロー では、OASEエージェントが収集したイベント等、イベントが時系列に表示されます。

表示されたイベントには、ラベル付与での設定に沿ってラベルが付与されています。

この画面から フィルター 、アクション 、ルール の設定をそれぞれ行うこともできます。

今回は、3台稼働の時にリクエスト数超過のイベントを発生させて、設定を進めましょう。

表 1.40 通知メール一覧

通知内容	リクエスト数超過
件名	[alert] Requests: Threshold reached
本文	リクエスト数が、閾値を超えました。 RequestCount > 150

1.2.6.1. フィルターの設定

フィルター では、ラベルをもとにイベントを検知するための条件を設定します。

イベントの件名と本文からSorry画面への切り替え作業を実施する条件に合うイベントを特定できるように条件を設定してみましょう。

注釈

Sorry画面への切り替えを実施するのは、インスタンスが3台稼働している状態でも、リクエスト数が閾値を超過する場合です。

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

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

表 1.41 フィルターの設定値

有効	フィルター名	フィルター条件	検索方法
True	request_limit_max	[["subject", "==", "リクエスト数超過"], ["requestcount", "==", "150"]]	ユニーク

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

Tip

フィルター名は任意で設定可能です。わかりやすいものを設定しましょう。

ラベル「subject」の値から、リクエスト数が超過したことを通知するイベントであることを特定できるようにフィルター条件を設定します。

ラベル「requestcount」の値から、通知の基準となった閾値を特定できるようにフィルター条件を設定します。

今回は、閾値として150の場合のみを条件としてアクションを実行するので150と設定しました。

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

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

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

注釈

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

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

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

警告

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

1.2.6.2. アクションの設定

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

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

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

表 1.42 アクションの設定値

アクション名	Conductor名称	オペレーション名	ホスト
			イベント連携
sorry_switch	Sorry画面切り替え	Sorry画面切り替え	false

Tip

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

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

警告

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

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

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

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

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

1.2.6.3. ルールの設定

ルール では、フィルターとアクションを紐づけます。

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

注釈

Sorry画面への切り替えを実施するのは、インスタンスが3台稼働している状態でも、リクエスト数が閾値を超過する場合です。

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

表 1.43 ルールの設定値

有効	ルール名	ルールラベル名	優先順位	条件	アクション	結論イベント
				フィルターA	アクションID	元イベントのラベル継承		結論ラベル設定	TTL
						アクション	イベント
True	sorry画面切り替え	sorry画面切り替え	1	request-limit_max	sorry_switch	True	False	["page", "sorry"]	3600

Tip

ルール名・ルールラベル名は任意で設定可能です。わかりやすいものを設定しましょう。

条件では、フィルターの設定で設定したフィルター「request-limit_max」を選択します。

アクションでは、アクションの設定で設定したアクション「sorry_switch」を選択します。

これにより、フィルタ―「request-limit_max」でイベントを検知したら、アクション「sorry_switch」が実行されます。

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

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

TTLは、Sorry画面切り戻し実施 (演習問題) で必要となるため、3600秒と長めに設定します。

理由については、ルールに複数の条件を設定した場合のイベントのTTL問題について を参照してください。

警告

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

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

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

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

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

1.2.6.4. 結果の確認

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

Tip

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

表 1.44 通知メール一覧

通知内容	リクエスト数超過
件名	[alert] Requests: Threshold reached
本文	リクエスト数が、閾値を超えました。 RequestCount > 150

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

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