yum install zabbix-agent を実行してみて下さい。

おそらくKUSANAGI-7.8.x 以前からKUSANAGI-8.0.xにインストールしたことがあるのだと思いますが、
ここで、zabbix22-agent から zabbix-agent-3.0.x に変更しています。このアップデート後すぐにリブートした場合、
zabbix-agent がインストールされない事象が発生します。

この場合は、手動でzabbix-agent をインストールして下さい。

それで大丈夫です。
ConoHaでKUSANAGIのインスタンスをデプロイする場合、以下のドキュメントを参照して下さい。

KUSANAGI for ConoHa

また以下の記事で、KUSANAGIでLaravelを動かしているので、こちらも参考にして下さい。

http://qiita.com/tajima_taso/items/f139eb71423041120247

wp search-replace で、DBの内容を置き換える部分で問題があるようです。
kusanagi ssl –email, kusanagi ssl –cert/–key, kusanagi setting は
DocumentRoot/wp にWordPressを移動しているとうまく動作しません。

なお、上記の状態でもDB上のhttp://FQDN/ が https://FQDN/ に変わらないだけで
Let’s EncryptのSSL証明書が取得でき、NGINXも再起動している状態です。

もし手動で修正したい場合は、root アカウントで以下のようにコマンド実行して下さい。
# FQDNは、provision 時に指定したホスト名を指定して下さい

wp search-replace http://FQDN https://FQDN –path=/home/kusanagi/プロファイル/DocumentRoot/wp/ –all-tables

kusanagi では、wp-config.php が、DocumentRoot直下もしくはDocumentRootと同じディレクトリにあることを想定していて、それ以外の場所にある場合はコマンド実行に失敗します。

ですので、DocumentRoot/wp/wp-config.php を DocumentRootに移動するか、
以下のようにhard link を貼っていただければと思います。

# cd DocumentRoot
# ln wp/wp-config.php .

monit が正常に動作していないかもしれません。
以下のコマンドを実行して、monitを再起動してみて下さい。

systemctl restart monit

横から失礼します。
以下のコマンドの結果を教えてください。

grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php

初期状態では以下のようになるのが正常です。

> grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
#define('WP_CACHE', true);

bcacheの使用時には以下のようになるはずです。

kusanagi bcache onの例）

> kusanagi bcache on
onにします。
完了しました。
> kusanagi bcache 
bcache は有効です
完了しました。
> grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
define('WP_CACHE', true);

kusanagi bcache off の例)

> kusanagi bcache off
offにします。
完了しました。
> kusanagi bcache 
bcache は無効です
完了しました。
> grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
#define('WP_CACHE', true);