はじめに

Fluentd は、応答が遅い場合やハートビートを返さない場合に、転送先サーバを自動で切り離す機能があります。

切り離す事自体はいいのですが、こちらの知らない内に切り離されてそのままになっていては困るので、Fluentd プロセスが転送先サーバを切り離し／接続復旧を通知します。

Zabbix でログを監視する

Zabbix には、ログファイルの監視機能があるのでこれを利用することで、アプリケーションやシステムの状態を監視、通知することができます。

今回の場合は、以下のように Zabbix のアイテムを設定することで Fluentd の切り離し／接続復旧を監視することができます。具体的には、以下の設定でアイテムを作成すると、Zabbix は、/path/to/fluentd.log ファイルの中から(detached|recovered|adding) forwarding server 'hoge' を含む行をヒストリーとして保存します。hoge はサーバの名前です。

タイプ: Zabbix エージェント (アクティブ)
キー: log[/path/to/fluentd.log,(detached|recovered|adding) forwarding server 'hoge']
データ型: ログ
ログの時間形式: yyyy-MM-dd hhss +0900

上記のアイテムを作成した上で、当該アイテムにひも付けたトリガーを作成します。トリガーの条件式は、以下の通りです。この条件式は、detached forwarding server が出た時に異常、(recovered|adding) forwarding server が出た時に正常になります。phi_threshold による detached の場合、recovered が出るまでは異常扱いになり、hard_timeout による detached の場合、Fluentd プロセスを再起動し adding されるまで異常扱いになるということです。

切り離しと接続復旧を監視する条件式

{Fuga:log[/path/to/fluentd.log,(detached|recovered|adding) forwarding server 'hoge'].regexp(detached forwarding server)}<>0

phi_threshold による detached は、転送先サーバの Fluentd プロセスが忙しい状態だと逐一通知されてしまう面倒はありますが、そもそも phi_threshold が常に高い状態で対策もしていないということは問題であることに間違いないので、そこは許容しています。

まとめ

Fluentd を運用している人からすれば、もっといい方法を知っていたり、当たり前の事なのかもしれませんが、Fluentd の運用について書いた記事は余りないと感じたので、基本的なことでも紹介してみました。

この記事が、Fluentd に興味を持ったけど、運用が面倒だという人に少しでも役立てば幸いです。