Zabbixでsyslogのログ監視
１．はじめに
Zabbixでsyslogのログ監視を行う場合、OS既定値のままだとログの日時やプライオリティを認識できない。そのため、認識できるようにする設定方法を説明する。
【環境】
CentOS 8
Zabbix 5.0
２．rsyslog.confの設定
(1) rsyslog.confの編集
/etc/rsyslog.confに、以下の2行を追加する。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
# テンプレートの定義
$template SyslogMonitor,"%timegenerated:::date-rfc3339% %hostname% [%syslogfacil
ity-text%.%syslogseverity-text%] %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-l
ast-lf%\n"
# warn以上をログ出力
*.warn /var/log/syslog-monitor;SyslogMonitor
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
(2) rsyslogの再起動
systemctl restart rsyslog
(3) テストメッセージの通知
logger -p local1.crit "test crit message."
(4) テストメッセージが、監視用のsyslogファイル（syslog-monitor）に出力されたことを確認する。
tail /var/log/syslog-monitor
(5) Zabbixでログ監視できるように、読み取り権限を追加
chmod +r /var/log/syslog-monitor
３．監視用のsyslogファイル（syslog-monitor）のローテーション設定
(1) logroateに、syslog-monitorをローテーションする設定を追加する。
４．Zabbixの監視アイテムの設定
(1) 設定ーホストーZabbix-serverのアイテムを開く
(2) アイテムの作成を開く
(3) 名前は任意の名前を入力する
(4) タイプは、「Zabbixエージェント（アクティブ）」を選択する
(5) キーは、logrt[/var/log/syslog-monitor,,,,,,,]と入力する
(6) データは、「ログ」を選択する
(7) ログの時間の形式に、「yyyy-MM-ddThh:mm:ss」と入力する
(8) 追加ボタンをクリックする。
５．Zabbixの監視トリガーの設定
(1) 監視トリガーの設定
①設定ーホストーZabbix-serverのトリガーを開く
②トリガーの作成を開く
③任意の名前をつける。(名前の後ろに{ITEM.VALUE}と入力する）
④深刻度を「警告」にする。
⑤条件式で、以下のように定義する
(({Zabbix server:logrt[/var/log/syslog-monitor,,,,,,,].iregexp(.warning])})<>0)
⑥追加ボタンをクリックする。
(2) 他の深刻度の設定
警告以外の深刻度も、上記(1)①～⑥を参考に設定する。
設定例
(3) loggerコマンドを使い、テストメッセージを通知してみる。
（警告の場合）
logger -p local1.warn "test warn message."
Zabbixのトリガー設定ができていれば、SYSLOGのプライオリティ（優先度）に応じたZabbixの深刻度が表示させる。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【解説】
今回紹介したsyslogのログ監視は、下図の通り。
①OSのsyslogデーモンが、syslog-monitorファイルにメッセージを出力する。
②Zabbix-agentが、syslog-monitorのファイルを読み込む。
③トリガーの条件式に基づき、syslogのメッセージを障害判定する。
rsyslog.confの設定
syslog（/var/log/messages）の既定では、日付が「Sep 26」というような形式になっているため、Zabbixのログ監視では日付を認識できない。そのためrsyslog.confにテンプレートを定義して、日付をrfc3339形式で出力するようにしている。また、プライオリティ（優先度）も出力するように定義している。
Zabbixの監視アイテム
今回はlogrtを使用しているが、syslogログのローテーションの設定で、copytruncateを指定した場合は、logrtのオプションでcopytruncateを指定する必要がある。
Zabbixの監視トリガー
syslogのプライオリティ（優先度）とZabbixの深刻度の種類は、一致しないため環境に合わせてカスタマイズが必要になる。また、監視トリガーの名前に{ITEM.VALUE}をつけておくと、Zabbixのダッシュボードに、syslogのメッセージも表示されるので見やすくなる。
以上
ZabbixでDNSフェールオーバーを作ってみた（その３）
３．権威DNSを書き換えるスクリプトをZabbixで実行する
(1) 事前準備
（例：DNS_Change.sh）
(2) スクリプトファイルをZabbixサーバーに配置する。
①Zabbixサーバーに、SSH接続する
②以下のフォルダにスクリプトファイルを配置する
/usr/lib/zabbix/externalscripts/
③配置したスクリプトファイルにZabbixアカウントで実行できるように、ファイルに実行権限を付与する。
cd /usr/lib/zabbix/externalscripts
chmod 755 DNS_Change.sh
(3) Zabbix エージェントでスクリプトを実行できるようにする。
①Zabbix エージェントのコンフィグに、EnableRemoteCommands=1を追加する。
vi /etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1
②Zabbixエージェントを再起動する
systemctl restart zabbix-agent
(4) アクションを設定する
①「設定」ー「アクション」を開く
②右上の「アクションの作成」を開く
③アクションタブで、任意の名前を入力する
④実行条件で、データセンタの障害を検知するトリガー名を指定する
⑤実行内容タブを開く
⑥実行内容欄の「追加」をクリックする
⑦下図のように、上記(2)で配置したスクリプトを実行するように設定する
⑧Addをクリックする
⑨「追加」ボタンをクリックする。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【解説】
スクリプトの実行方法で「Zabbixサーバー」を指定した場合、5分以内にスクリプトの実行が終了しないと強制終了してしまう。スクリプトの実行が5分以内であれば、「Zabbixサーバー」でも構わない。
実際に使ってみた権威DNSだと、API経由でDNSレコードを書き換えようとすると、1レコードあたり1秒くらいかかったので、5分間では300レコードしか書き換えできず、物足りなかった。そのため、Zabbixエージェントでスクリプトを実行するようにした。
Zabbixエージェントを利用する注意点としては、スクリプトの実行が非同期実行になるため、スクリプトの実行が途中で停止すると、永遠にプロセスが残ってしまう可能性がある。別途、スクリプトの実行を監視する仕組みが必要になってくるが、これは別の機会に説明したい。
次回は、複数拠点のZabbixのWeb監視を連携する方法を説明する。
ZabbixでDNSフェールオーバーを作ってみた（その２）
２．自社データセンターの障害監視
(1) Web監視の設定
①「設定」ー「ホスト」ー「Zabbix server」ー「web」を開く。
②右上の「Webシナリオの作成」を開く。
③シナリオタブで、任意の名前を入力する。
④ステップタブを開き、「追加」をクリックする。
⑤Webシナリオのステップで任意の名前を入力し、URL欄に自社データセンターのWebサーバーのURLを入力する。
⑥追加ボタンをクリックする。
⑦追加ボタンをクリックする。
(2) トリガー条件の設定
①「設定」ー「ホスト」ー「Zabbix server」ー「トリガー」を開く。
②右上の「トリガーの作成」を開く。
③任意の名前を入力する。
④条件式の追加ボタンをクリックする
⑤アイテムは、上記(1)で追加したWeb監視の「Failed step of scenario・・・」を選択する
⑥関数は、sum()※を選択する。
※障害判定の例として、直近10回中5回接続に失敗した場合を障害とする。sum()ではなく、count()を利用する方法もある。
⑦「挿入」をクリックする
⑧「追加」ボタンをクリックする。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【解説】
AWS Route53やAzure Traffic Managerを使わずに、Zabbixを利用するメリットは、上記2(2)の通り、細かく監視条件を指定できる点にある。特に〇回中〇回失敗した場合という条件式は、Route53やTraffic Managerではできない。（指定できるのは〇回連続で失敗した場合という条件になる）
私見だが、データセンターの障害は、まったく接続できなくなるというより、接続できたりできなかったりするケースのほうが多いと思っている。そのため、障害判定の条件は、連続〇回接続に失敗した場合ではなく、〇回中〇回接続に失敗した場合のほうが妥当だと思う。
なお、データセンターの障害監視としては、本来複数のURLを監視すべきだが、今回は説明の都合上、1URLとしている。
次回は、アクションの設定を説明する。
ZabbixでDNSフェールオーバーを作ってみた（その１）
０．はじめに
Zabbixを使ったDNSフェールオーバーを紹介してみようと思う。
DNSフェールオーバーといえば、AWS Route53やAzure Traffic Managerがメジャーどころだと思うが、ZabbixのWeb監視を使って同じような仕組みが実現できる。
ZabbixのWeb監視を利用するメリットは以下の通り。
(1) DNSフェールオーバーの発動条件を詳細に定義できる。
(2) DNSフェールオーバー発動時に、メールやSNSといった通知と連動できる。
(3) DNSクエリ数によっては、Route 53やTraffic Managerより安い。
反面、デメリットとするとRoute 53やTraffic Mangerは、設定だけで複数の拠点（プロープ）からWebサーバーを監視してくれるが、ZabbixのWeb監視の場合、複数の拠点から監視するには、Zabbix APIを使う必要があり、ちょっと手間がかかる。
１．システム概要
(1) Zabbixを使ったDNSフェールオーバーは、下図の通り。
①通常時は、権威DNSが自社データセンターのWebサーバーのIPアドレスを返す。これにより、利用者は自社データセンターのWebサーバーにアクセスする。
②Zabbixが自社データセンターの障害を監視し、障害を検知したら、権威DNSのレコードを書き換える。
③レコード書き換え後、権威DNSは外部データセンターのSorryサーバのIPアドレスを返す。これにより、利用者は外部データセンターのSorryサーバにアクセスする。
(2) 使用したZabbixのバージョン
Zabbix 5.0（OSはCentOS）
次回以降で、具体的な設定手順を説明する。
