Power Automate で簡易に WordPress サイト監視してみる

# Power Automate で Web サイトの簡易監視
自前で24時間稼働している運用サーバーがあれば監視ツールでも稼働させるところですが、社外で稼働しているサーバーは Web サーバーだけ、社内には NAS 程度しか稼働していないため、簡易的ではあるけれども Power Automate を利用して 1 日 1 回のみ WordPress が動作しているかどうかを監視するフローを実行させてみる。
なお、 Power Automate は Microsoft 365 Business Standard で使用可能なものでプレミアムコネクタを利用しなくてもいいように構成してみた。
## 要件の確認
* Web サイトは仮にダウンしていたとしても1両日中程度で復旧すれば問題ない
* サイトの表示乱れ等も確認してから復旧すれば問題ないので、プラグイン等のエラー程度は検知しない
* サイトトップはお知らせが更新されるとコードも変わってしまうので、コードレベルでの比較はしない
* WordPress が完全に反応しない場合のみ、 Teams のチャットで自分に通知する
## フローの作成
本来は「スケジュール済みクラウドフロー」で開始したいところであるが、最初は手動テストするために「インスタント クラウドフロー」で作って、あとからスケジュール型に変更する。
以下が最終的に完成したフローになる。
![スクリーンショット 2022-08-30 172158.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/7e0710d1-c99b-5aba-c34c-f05e4de86daa.jpeg)
# フロー作成の手順と説明
最初に説明した通り、まずは「インスタント クラウドフロー」で作成を開始する。テストの際に手動実行できて楽だからだ。
## 準備
まず、フローに「URL からのファイルのアップロード」を配置し、監視したい WordPress の URL を「ソース URL」に記載する。この時 WordPress が動作しているドメインの情報に`/wp-json/wp/v2/users/1`と追記する。

これは WordPress に登録されているユーザー ID が 1 のユーザーの情報を取得する REST API のアドレスとなるが、REST API を停止している場合、およびユーザー情報を隠すような設定をしている場合は他の URL を参照されるように変更する。

ただし、のちに取得されたコードを比較することで正常動作を確認しているため、このアドレスから取得した JSON コードは比較が実施しやすかった。 html を取得して比較してもいいが、ページの更新等で変わってしまうページの情報では比較できないと思われるため、情報が取得・比較しやすいアドレスを指定することをお勧めする。
![スクリーンショット 2022-08-31 163511.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/ac3c467d-27f5-70d2-3e6d-9473ac3b401a.jpeg)
「対象ファイルのパス」に関しては、フローを実行する人の OneDrive 上に作られるファイルになるため、任意の場所、名前で構わない。「上書きする」は「はい」にしておかないと比較するファイルが更新されなくなるため、はいに設定しておく。

次に「パスによるファイル コンテンツの取得」フローを配置し、URL から取得したファイルをさらに読み込む。ファイルパスはもちろん先ほど設定したパスとファイル名を指定する。
![スクリーンショット 2022-08-31 164720.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/d764eb90-404d-476d-0462-c8a60731d3b9.jpeg)
最後に、「変数を初期化する」フローと「変数の設定」フローを配置して、適当な名前を設定、種類は「文字列」としておき、「パスによるファイル コンテンツの取得」フローから吐き出された「本文」を「値」として設定しておく。
![スクリーンショット 2022-08-31 164910.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/97ec62f9-293c-cc19-7010-5742622d974f.jpeg)
これで最初の準備は完了だ。
一度フローを手動実行し、実行結果から「変数の設定」にデータが取得できているかを確認する。
![スクリーンショット 2022-08-31 165050.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/04d7a19a-a14d-e0ef-44fb-56a694ebb428.jpeg)
ここで取得できた「値」を比較元のデータとして使用するので、コピーして取得しておく。
## 運用フローに改修
次に「URL からのファイルのアップロード」の前に判定元データとして「変数を初期化する」フローを追加して置く。
![スクリーンショット 2022-08-31 170015.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/ec0aaf02-551f-0540-cc2e-a4c03a0282c8.jpeg)
ここで先ほど取得した json データを「値」として設定してしまう。
これが「基準」となって実際にサイトから取得したデータと比較し、動作に問題がないことを確認しようという魂胆だ。WordPress が動作を停止してしまっている場合、REST API からの返答は期待できない。返答にユーザー ID 1 の json データが返ってこなければ問題が発生したと捉える。

次にサイトからのデータを取得したのち、「条件」フローを配置して検証を行う。
![スクリーンショット 2022-08-31 170203.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/d824c52c-b009-eda8-dd2c-94198498070c.jpeg)
作成した変数を比較して、等しかったら何もしないで問題ない。問題ないことを通知したければ「はい」側にも何らかの設定を行えばよいだろう。
![スクリーンショット 2022-08-31 170221.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/e95b9e14-d94c-e68a-4b1e-373667ea3970.jpeg)
いいえ側には「チャットまたはチャネルでメッセージを投稿する」フローを配置して、自分宛てにメッセージを飛ばすこととした。ここはメール等でも構わない。
![スクリーンショット 2022-08-31 170147.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/48596035-edd2-8de8-c0d1-7a0063c772d1.jpeg)
ここまでできれば一度手動実行してみて、メッセージが届くか試してみるとよい。はい側にメッセージ送信を設定して実験し、メッセージが届けばとりあえずは問題ないと思われる。
## 仕上げ
最後に一番上のフローを「繰り返し」フローに変更する。トリガーになっているフローを削除すると新しいトリガーを追加できるようになるので、「繰り返し」フローに変更した。
![スクリーンショット 2022-08-31 170252.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12937/7250ed3f-5c57-6d27-76fb-51e1634c34d3.jpeg)
勤務開始前の 8 時 30 分に 1 日 1 回チェックを行うようにしている。どの程度の頻度で実行できるか等はプランの契約内容にもよると思われるため、よく確認されてから実施されていただきたい。
なお、最初にもお伝えしたが、クリティカルなサイトにおける監視としては使えないと思った方がよい。私はあくまでも簡易監視として利用している。