More than 3 years have passed since last update.

Exastro OASE でマッチポンプした話(Web+Zabbix構築編)

Last updated at 2021-05-27Posted at 2021-05-18

前回のおさらい

前回は、Exastro OASE についての調査と1台のサーバ上にインストールをしました。

Exastro OASE について(再掲)

1. Exastro OASE って何よ？

「[Exastro OASE][公式ページ] はシステム運用の自立化・効率化・省力化を支援するためのOSSです。」
とのことで、平たくいえば、システムの運用を楽チンにしてくれるOSSってことみたいです。
OASE の読み方は「オアゼ」です。

2. Exastro OASE って誰得なの？

障害発生時には、以下のような対応フローが多いと思います。

監視システムによるアラート検知
インシデント・イベント起票
一次切り分け
暫定復旧作業
SEによる調査
恒久対応
クローズ

問題が起こったときに、いかに迅速かつ確実に復旧できるかがポイントとなります。
OASE でできるのは、この「3. 一次切り分け」と「4. 暫定復旧作業」といった初期対応の部分です。
「3. 一次切り分け」と「4. 暫定復旧作業」を OASE により自動化することで、サービス復旧までの時間を短縮できます。
また、未知のインシデントが発生した場合は1次切り分けルールと暫定復旧のアクションを増やしていくことで、次第に運用者の対応が減っていくので運用コストを抑える効果も期待できます。

3. Exastro OASE の機能をざっくり見てみよう

もう少し OASE の機能について見てみます。

外部連携機能

OASE は単体では機能しません。
監視機能を持ちませんし、障害発生時のアクションを実行する機能も持っていません。
代わりに、OASE は他のシステムと連携することで監視からアクションまでの一連の処理を実施します。

OASE の構成としては、主に

監視システムからのアラートを受け取る__監視アダプタ__
受け取ったアラートをルールに従って推論する__ディシジョンテーブル__
推論の結果を元にアクションをキックするための__ドライバ__

によって構成されています。

Ver. 1.2 までは監視ソフトウェアには ZABBIX、アクション部分の処理には Exastro IT Automation (ITA) と連携できたようですが、Ver. 1.3 からは Prometheus と連携できるようになったようです。今後この辺の連携機能も更に拡充されていくようです。

テスト実行

障害が発生する度にルールを追加すると記載しましたが、本番環境にテストもせずにアクションを導入することは通常ありえません。
必ず検証環境などで事前にテストを行ってから導入すると思います。
OASE では、検証環境を内部に持っており、アラート検知からアクション実行までのテストを本番に影響を与えることなく実施可能です。
これにより、安心して継続的なルールの管理を行うことが可能となります。

はじめに

本検証は、自らサーバに負荷を与える(着火する)ことでアラートを発生させ、OASE を使って暫定対応(消火)させるという、まさにマッチポンプ的検証なのである。笑

何をどう自動化するかを考える

シナリオ

花輪さんは、本業の片手間に会社の メディアサイトのシステム運用 を任されています。
運用範囲は、Web サーバ1台 における OS・ミドルウェアの障害発生時の対応です。
運用と言っても、何もなければ特にすることはなく、何か問題が有ったときだけ対応を求められる仕事です。

普段は何事もないのですが、投稿された記事が SNS サイトなどで話題になると、アクセスが急増し、Web アプリが高負荷な状態となり、最終的には OS がハングアップ してしまいます。
こうなってしまうと、SSH ログインすらまともにできないような状況になるため、社内の基盤担当に依頼 をして、OS の再起動 をしてもらう必要があります。
しかし、OS を再起動しても、アクセスが落ち着くまでは何度もハングアップが発生し、都度その対応が必要 な状況です。

根本原因は メモリ不足 であることはわかっており、スケールアウトや リソースの増強 も検討していますが、技術的にも予算的にも 基盤側の対応は厳しい状況 です。
また、運用メンバーは花輪さん一人 のため、本業ですぐに対応できない状況もしばしばあります。

方針を考える

まずは、状況を整理してみよう

上のシナリオをまとめてみます。

項目	内容
サービス内容	一般公開型のメディアサイト
問題点	高アクセスがあると OS がハングアップ
暫定対策	OSの再起動
根本原因	メモリ不足
恒久対策	リソース増強

他にも、花輪さん個人の悩みとしては、本業があるのに、バズり対応のために ちょくちょく手が止まってしまう といった問題があります。
また、基盤担当も何度も OS を再起動する必要がありますね。

そこで Exastro OASE さんの出番ですよ！

OASE を使ってどう解決していくかを考えていきましょう。

OASE は、ルールエンジンを内包していおり、ディシジョンテーブルにより管理されたルールを元に運用を自動化します。
ディシジョンテーブルとは、条件(入力) とそれに対する アクション(出力) からなる ルール を網羅的にまとめたテーブルです。

今回の例における運用ルールは、

OS がハングアップした場合(条件)、OS を再起動する(アクション)

のようになると思います。

ディシジョンテーブルを作成すると、下記のようになります。

	条件	アクション
Rules	OS がハングアップした場合
Rule1	Y	再起動を実行する
Rule1	N	何もしない

あー、これアカンわ...

OS がハングアップした状態では、SSH でログイン出来ないので、OS コマンドを使った「OSの再起動」は不可ですね。
(OS の外からの再起動であればできますが、花輪さんにはそういった OS 外の作業権限がありません)
ということで、ハングアップする前になんとかしちゃおうという方針に切り替えます。

修正後の運用ルールは、

アクセス数が多い場合(条件1)、Sorry ページに切り替える(アクション)
アクセス数が少ない場合(条件2)、元のページに切り替える(アクション)

といったところでしょうか。
処理の重い動的なページを、Sorry ページ のような軽量な静的ページに切り替えることで、サーバのハングアップを回避しようというねらいです。
そして、修正版のディシジョンテーブルはコレ！

	条件1	条件2	アクション
Rules	アクセス数が多い場合	アクセス数が低い場合
Rule1	N	N	何もしない
Rule2	Y	N	Sorry ページに切り替える
Rule3	N	Y	元のページに切り替える
Rule4	Y	Y	Sorry ページに切り替える

悩ましいのは、Rule4 の条件に対する処理です。
矛盾した条件ですが、Zabbix の監視上タイミングによってはどちらの状態も取り得る可能性があります。
この場合は、フェイルセーフの考えに基づき、「Sorry ページ に切り替える」ようにしました。

環境構築

システム構成

方針も決まったところで、今回のシステム構成を見ていきましょう。

登場人物の紹介

サーバ	ホスト名	説明
Webサーバ	target-web	メディアサイトを公開するサーバ
監視サーバ	zabbix	Web サーバの監視を行う
OASEサーバ	exastro-oase	今回の主役。運用を自動化
ITAサーバ	exastro-ita	OASE からの API コールをトリガーにオペレーションを実行

作業の流れ

周辺環境構築
1. 監視対象の Web サーバ構築
2. Zabbix 環境構築
3. Exastro IT Automation (ITA) 環境を構築
ディシジョンテーブルの作成
Zabbix 監視アダプタの設定
Exastro IT Automation (ITA) ドライバの設定
ディシジョンテーブルのルール登録
動作確認

本稿では、1. 周辺環境構築 を取り扱います。
2. Zabbix 監視アダプタの設定 以降については、次回扱います。

本編スタート

前置きが長くなりましたが、ここから本検証の周辺環境を整えていきます。

1. 周辺環境構築

OASE サーバについては前回やったので、省略します。
OASE サーバ以外の Web サーバ、監視サーバ、ITA サーバの構築を行っていきましょう。
Exastro Suite は、IT Automation (ITA) も OASE も RHEL 系の OS がシステム要件なので、今回は、全台 CentOS 8 で構築していきます。

項目	Webサーバ	Zabbixサーバ	ITAサーバ
ホスト名	target-web	zabbix	exastro-ita
CPU(Cores)	1	1	1
メモリ	2GB	2GB	2GB
ディスク	20GB	40GB	40GB
OS	CentOS 8	CentOS 8	CentOS 8
アプリケーション	Apache, php-fpm	Zabbix 5.2	Exastro IT Automation 1.7.1

1.1. 監視対象の Web サーバ構築

監視対象となる Web サーバを構築していきます。
コンテンツの内容自体はどーでもいいですが、ページの表示に関して制御をしたいので、Apache + PHP で動的ページを作ります。

構築手順

PHP 関連パッケージインストール

PHP の Web アプリケーションを実行するためにパッケージのインストールを行います。

# PHP 関連のパッケージのインストール
dnf install -y php php-mbstring php-xml php-xmlrpc php-gd php-pdo php-mysqlnd php-json

テストページを配置

表示までに非常に時間が掛かるページ を想定したテストページを配置します。
GET パラメータに time で指定した秒数分だけ表示を遅らせるプログラムとなります。
このプログラムにアクセスした分だけ処理を滞留させようというのがねらいです。

# テストページの配置
cat << '_EOF_' > /var/www/html/wait.php
<html>
 <head>
  <title>PHP Test</title>
 </head>
 <body>
 <?php
   $WAIT_TIME = $_GET["time"];
   sleep($WAIT_TIME);
   echo "<p>Hello World</p>";
 ?> 
 </body>
</html>
_EOF_

# テストページのパーミッションを変更
chown apache: /var/www/html/wait.php

Zabbix モニタリング用の設定

ステータス画面が表示できるように設定を入れます。
これは、Zabbix がリアルタイムに接続数を取得するためのものです。

# Apache の統計情報を表示させるアクセス数監視用の設定を投入
cat << _EOF_ > /etc/httpd/conf.d/status.conf 
ExtendedStatus On
<Location /server-status>
  SetHandler server-status
  # ↓必要に応じてアクセス制御を入れる
  # Require ip 127.0.0.1
</Location>
_EOF_

Zabbix エージェントの導入

# Zabbix リポジトリのインストール
rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/8/x86_64/zabbix-release-5.2-1.el8.noarch.rpm

# リポジトリのキャッシュを初期化
dnf clean all

# Zabbix エージェントのインストール
dnf -y install zabbix-agent

# Zabbix エージェント上のホスト名の変更
sed -i.org -e "s/^Hostname=.*$/Hostname=target-web/" /etc/zabbix/zabbix_agentd.conf

# Zabbix サーバのIPアドレスを設定
ZABBIX_IP=[ZabbixサーバのIPアドレス]
sed -i -e "s/^Server=.*$/Server=${ZABBIX_IP}/" /etc/zabbix/zabbix_agentd.conf
sed -i -e "s/^ServerActive=.*$/ServerActive=${ZABBIX_IP}/" /etc/zabbix/zabbix_agentd.conf

タイムアウト値のチューニング

デフォルトの設定では、1分程度でセッションが切断されるので、タイムアウト値を600秒(10分)まで伸ばします。

# Apache のタイムアウト値の変更
cp -pi /etc/httpd/conf/httpd.conf{,.org}
echo "Timeout 600" >> /etc/httpd/conf/httpd.conf

# PHP のタイムアウト値の変更
sed -i.org -e "s/^max_execution_time.*$/max_execution_time = 600/" /etc/php.ini

サービスの(再)起動

サービスの自動起動設定と起動を行います。

# 各サービスの自動起動設定
systemctl enable httpd php-fpm zabbix-agent

# 各サービスの(再)起動
systemctl restart httpd php-fpm zabbix-agent

動作確認

以下の確認は全てブラウザで行います。

Apache ステータス画面

Apache のステータス画面を確認してみましょう。

http://[target-webのIPアドレス]/server-status

1 requests currently being processed, 99 idle workers

と表示されています。
これは、このステータス画面にアクセスした分のリクエストが表示されているということです。

テストページ

テストページにパラメータ指定せずにアクセスしてみましょう。

http://[target-webのIPアドレス]/wait.php

すぐに「Hello World」が表示されたはずです。
次に、パラメータに time=30 を設定してもう一度テストページにアクセスします。

http://[target-webのIPアドレス]/wait.php?time=30

今度は、30秒後に「Hello World」が表示されたと思います。

リクエストの滞留確認

パラメータに time=30 でアクセスした後に F5 キーを9回連打します。

http://[target-webのIPアドレス]/wait.php?time=30

このときに急いで Apache のステータス画面を見てみましょう。

http://[target-webのIPアドレス]/server-status

すると、下記のようにリクエスト数が 11件 と表示されたと思います。

11 requests currently being processed, 89 idle workers

これは、wait.php の応答待ちのリクエスト 10 件 + server-status へのアクセス 1 件分です。

これで Web サーバ側の下準備は完了しました。

1.2. Zabbix 環境構築

監視サーバとして Zabbix を構築していきます。
公式のマニュアルを参考にインストールします。

構築手順

SELinux の無効化

石川サンゴメンナサイ

# 一時的に Permissive モードに変更
setenforce 0

# 恒久的に無効化
sed -i.org 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

Zabbix リポジトリの登録とパッケージのインストール

Zabbix 公式リポジトリのインストールと Zabbix 関連パッケージをインストールします。

# Zabbix リポジトリのインストール
rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/8/x86_64/zabbix-release-5.2-1.el8.noarch.rpm

# リポジトリのキャッシュを初期化
dnf clean all

# Zabbix 関連パッケージのインストール
dnf -y install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-agent

MySQL(MariaDB) のセットアップ

MySQL(MariaDB) 関連のパッケージのインストールとサービス起動をします。

# MySQL サーバのインストール
dnf -y install mariadb-server

# MySQL の自動起動を有効にしつつ即座に起動
systemctl enable --now mariadb

MySQL の初期設定をします。

mysql_secure_installation

基本はデフォルト値ですが、MySQL の root パスワードのみ password に設定します。

Enter current password for root (enter for none): (入力なしでエンター)
Set root password? [Y/n]: (入力なしでエンター)
New password: password
Re-enter new password: password
Remove anonymous users? [Y/n]: (入力なしでエンター)
Disallow root login remotely? [Y/n]: (入力なしでエンター)
Remove test database and access to it? [Y/n]: (入力なしでエンター)
Reload privilege tables now? [Y/n]: (入力なしでエンター)

Zabbix 用のデータベースとユーザを作成します。

項目	値
DB名	zabbix
ユーザ名	zabbix
パスワード	zabbix

# データベースの作成
mysql -uroot -p'password' -e "create database zabbix character set utf8 collate utf8_bin;"

# Zabbix ユーザのパスワードを設定
mysql -uroot -p'password' -e "grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbix';"

データベーススキーマのインポートをします。

# データベーススキーマのインポート
zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p'zabbix' zabbix

Zabbix サーバの設定

Zabbix サーバの設定ファイルに DB のパスワードを設定します。

# Zabbix サーバの設定ファイルに DB のパスワードを設定
echo 'DBPassword=zabbix' >> /etc/zabbix/zabbix_server.conf

Zabbix サーバとエージェントの起動

Zabbix サーバとエージェントを(再)起動し、自動起動を有効にします。

# 各サービスの再起動
systemctl restart zabbix-server zabbix-agent httpd php-fpm

# 各サービスの自動起動を有効化
systemctl enable zabbix-server zabbix-agent httpd php-fpm

Zabbix の基本セットアップ

まずは、下記の URL から Zabbix にログインします。

http://[ZabbixサーバのIPアドレス]/zabbix

ようこそ

言語設定は、英語 English (en_GB) を選択します。
日本語に設定したい場合は、フォントをインストールする必要があります。
(フォントがない場合は入力内容が豆腐□になってしまいます。)

前提条件のチェック

オール OK であることを確認します。

データベース接続設定

データベース構築時に設定した値で設定します。

項目	設定値
データベースタイプ	MySQL
データベースホスト	localhost
データベースポート	0
データベース名	zabbix
資格情報保存先	Plane text(プレーンテキスト)
ユーザ	zabbix
パスワード	zabbix

Zabbix サーバの詳細

デフォルトでいいです。

項目	設定値
ホスト	localhost
ポート	10051
Name	zabbix server

GUI設定

タイムゾーンはもちろん日本なので、Asia/Tokyo に、デフォルトのテーマは、今の気分に合わせて Blue にしました。笑

インストール事前準備概要

内容を確認して問題なければ次に進みます。

インストール

これでインストール完了です。
Finish ボタンを押して終了します。

ユーザ名	パスワード
Admin	zabbix

ホストの追加

監視対象の Web サーバを追加します。
左メニューから Configuration > Hosts をクリックします。
画面右上の Create host ボタンを押下します。

ホスト情報の入力

下記の項目を設定します。それ以外はデフォルトです。

項目	設定値
Host name	target-web
Groups	Linux servers
Interface - Type	Agent
Interface - IP address	Web サーバの IP アドレス
Interface - DNS name	target-web
Interface - Connect to	IP
Interface - Port	10050

テンプレートの設定

上メニューから Templates をクリックします。
下記のテンプレートをリンクします。

ホストグループ	テンプレート名
Templates/Applications	Apache by HTTP
Templates/Operating systems	Linux by Zabbix agent

画面を見る

ホストの追加を実行

画面下の Add ボタンを押下します。

コネクション数更新間隔の変更(1m => 5s)

ページの切り替わりを早くするために、監視の間隔を変更します。

初期値	変更後
1m	5s

左メニューから Configuration > Hosts をクリックします。
ホスト一覧から target-web を選択します。
上メニューの Items を選択します。
最後に Subfilter の一覧から Apache を選択します。

Apahce: Get status をクリックします。

Update interval の値を 5s に設定し、5秒ごとに値を取得するように変更します。
その後、ページ下部の Update ボタンを押下します。

閾値(トリガー)の設定

次に、監視対象の Web サーバに対する監視ルールを入れていきます。

メトリックス	閾値
コネクション数	20を超えた場合
コネクション数	11を下回った場合

コネクション数閾値超え設定

上メニューの Triggers を選択します。
画面右上の Create trigger ボタンを押下します。

下記の項目を設定します。それ以外はデフォルトです。

項目	設定値
Name	More than 20 connections
Severity	Warning
Expression	{target-web:apache.workers_total.busy.last(#1)}>20

コネクション数閾値下回り設定

画面右上の Create trigger ボタンを押下します。
下記の項目を設定します。それ以外はデフォルトです。

項目	設定値
Name	Less than 11 connections
Severity	Information
Expression	{target-web:apache.workers_total.busy.last(#1)}<11

ダッシュボードの設定(オプション)

ダッシュボードの追加手順の詳細は記載しませんが、ダッシュボードにグラフを表示しています。
HTTP Connection count のグラフでは、前述の wait.php ページに対して 20 回を超えるアクセスで More than 20 connections トリガーが引かれ、11回を下回る箇所で Less than 11 connections のトリガーが引かれていることが確認できます。

設定画面を見る

設定前のダッシュボード

データセット

Problems

設定後のダッシュボード

1.3. Exastro IT Automation (ITA) 環境を構築

本項では、高負荷が発生した場合に動的ページを静的な Sorry ページ に切り替えるアクションを構築していきます。

インストール

Exastro IT Automation (ITA) のインストール手順については、この辺を参考にしてください。

ユーザ名	パスワード
administrator	password

作業対象ホストの登録

メインメニュー を開き、メニューグループ 画面から 基本コンソール を選択します。
左メニューの 機器一覧 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)

項目	設定値
HW機器種別	SV
ホスト名	target-web
IPアドレス	(WebサーバのIPアドレス)
ログインユーザID	root
ログインパスワード - 管理	●
ログインパスワード - ログインパスワード	(rootユーザのパスワード)
Ansible利用情報 - Legacy/Role利用情報 - 認証方式	パスワード認証

※本検証では、Webサーバに対して、パスワード認証で root ログイン可能な状況を想定しておりますが、鍵認証を使った操作も可能です。

入力が完了したら、登録ボタンを押下します。

オペレーションの登録

左メニューの オペレーション一覧 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)

#	オペレーション名	実施予定日
1	Sorryページ切り替え	適当な日付
2	Sorryページ戻し	適当な日付

入力が完了したら、登録ボタンを押下します。

コンテンツファイルのアップロード

コンテンツファイルの作成

事前に、下記のファイルを作成しておきます。

▼通常ページ

wait.php.normal

<html>
 <head>
  <title>PHP Test</title>
 </head>
 <body>
 <?php
   $WAIT_TIME = $_GET["time"];
   sleep($WAIT_TIME);
   echo "<p>Hello World</p>";
 ?>
 </body>
</html>

▼Sorryページ

wait.php.sorry

<html>
 <head>
  <title>PHP Test</title>
 </head>
 <body>
 Sorry. Please try again later.
 </body>
</html>

ファイル素材の登録

メインメニュー を開き、メニューグループ 画面から Ansible共通 を選択します。
左メニューの ファイル管理 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)
ファイルは上記で作成したものをアップロードします。

#	ファイル埋込変数名	ファイル素材
1	CPF_wait_php_normal	wait.php.normal
2	CPF_wait_php_sorry	wait.php.sorry

入力が完了したら、登録ボタンを押下します。

Movement の登録

メインメニュー を開き、メニューグループ 画面から Ansible-Legacy を選択します。
左メニューの Movement一覧 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

#	Movement名	Ansible利用情報 - ホスト指定形式
1	Sorryページ切り替え	IP
2	Sorryページ戻し	IP

入力が完了したら、登録ボタンを押下します。

Playbook 素材のアップロード

Playbook の作成

事前に、下記のファイルを作成しておきます。

▼通常ページに差し替え

replace_content_to_normal.yml

- name: Replace NORMAL wait.php
  copy:
    src: "{{ CPF_wait_php_normal }}"
    dest: /var/www/html/wait.php
    owner: apache
    group: apache
    mode: 0644
    backup: yes

▼Sorryページに差し替え

replace_content_to_sorry.yml

- name: Replace SORRY wait.php
  copy:
    src: "{{ CPF_wait_php_sorry }}"
    dest: /var/www/html/wait.php
    owner: apache
    group: apache
    mode: 0644
    backup: yes

Playbook 素材の登録

左メニューの Playbook素材集 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)
ファイルは上記で作成したものをアップロードします。

#	Playbook素材名	Playbook素材
1	replace_content_to_normal	replace_content_to_normal.yml
2	replace_content_to_sorry	replace_content_to_sorry.yml

入力が完了したら、登録ボタンを押下します。

Movement と Playbook の紐付け

左メニューの Movement-Playbook紐付 をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)

#	Movement	Playbook素材	インクルード順序
1	Sorryページ切り替え	replace_content_to_sorry	1
2	Sorryページ戻し	replace_content_to_normal	1

入力が完了したら、登録ボタンを押下します。

作業対象ホストの設定

左メニューの 作業対象ホスト をクリックします。
登録アコーディオンメニューを開き、 登録開始 ボタンを押下します。

下記のように項目を設定します。(設定する項目のみ記載)

#	オペレーション	Movement	ホスト
1	Sorryページ切り替え	Sorryページ切り替え	target-web
2	Sorryページ戻し	Sorryページ戻し	target-web

入力が完了したら、登録ボタンを押下します。

Conductor の登録

メインメニュー を開き、メニューグループ 画面から Conductor を選択します。
左メニューの Conductorクラス編集 をクリックします。
下記の画像のように、Conductor クラスを作成します。

▼ Webサーバ高負荷対応

▼ Webサーバ高負荷戻し対応

作成が完了したら、登録ボタンを押下します。

作業実行

事前確認

事前に wait.php にアクセスし、変更前の状態を確認しておきます。
この時、ページには「Hello World」と表示されているはずです。

Sorry ページヘの切り替え実行

Conductor に、「Webサーバ高負荷対応」を選択し、オペレーションに「Sorryページ切り替え」を選択します。

ITA のページに戻り、ページ下部の実行ボタンを押下します。

画像のように、実行が正常に完了すると DONE と表示されているはずです。

ページ切り替えの確認

再度 wait.php にアクセスします。
この時、ページの内容が「Sorry. Please try again later.」に切り替わっていれば成功です。

元のページに切り戻し実行

同様にして、ページの戻し作業を実施してみましょう。
実行が正常に完了し、wait.php の内容が「Hello World」に戻っていれば成功です。

まとめ

Exastro OASE を使うための想定シナリオを考えた。
また、そのシナリオに沿った検証を行うための下準備として、監視対象の Web サーバと Zabbix サーバの構築を行った。
さらに、コンテンツを切り替える仕組みとして Exastro IT Automation (ITA) に Conductor を設定し、コンテンツの切り替えができることを確認した。

周辺環境整えるだけでしたが一苦労でした。。。

次回はついに OASE 開封の儀じゃよ！！
じゃぁの！ヽ(*・ω・)ノ

次回、Exastro OASE でマッチポンプした話(活用編)に続く！

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up