Tech Sketch Bucket of Technical Chips by TIS Inc.

fluentdで始めるログ管理【フォワード設定まとめ】

Pocket

この記事はeXcale Developer's Blogから移転されたものです。

eXcale開発チームの泉谷(@syguer)です。

今回は前回の続きとして、fluentdでログを他のサーバーに転送する方法について紹介します。

>>eXcaleは期間限定でサインアップキャンペーン実施中!気になる内容はこちら<<


ログの転送について

fluentdではアウトプットの手段として他のサーバーへの転送を選択することでログの集約を簡単に実現できます。


基本的な構成

設定と動作のイメージができるように、シンプルにあるサーバーからあるサーバーへ送信する例を見てみます。

以下がデータを送る側と送られる側の設定例です。

※本記事ではバッファリングに対する設定はデフォルト値を使うため、以下のすべての例で設定はありません(設定しなければデフォルト値が使われます)
バッファリングの設定については前回の記事を参照してください。

・ 送信側

送信側ではどのログを転送するかをsourceディレクティブで指定し、アウトプットを指定するmatchディレクティブのtypeをforwardとします。
matchディレクトリの中にserverディレクティブを追加し、データの送り先を指定します。
オプションの内容は以下の通りです。

* send_timeout
データを転送する際に相手が反応しなかった場合、どのくらいの時間でタイムアウトするかを設定します。
デフォルトは60秒です。

* recover_wait
送信に失敗した際に、復旧までどれくらい待つかを設定します。
デフォルトは10秒です

* heartbeat_interval
fluentdはデータの送信先が生きているかをチェックします。
このオプションではその死活監視の間隔を指定します。
デフォルトは1秒です。
死活監視はUDPで行われます。FW設定等の理由でTCPを使いたい場合は「heartbeat_type tcp」という行を追加してください。

* phi_threshold
送信が失敗したと判断するしきい値です。
内部で死活を判断する計算で使われるphiという値のしきい値であり、特にいじる必要はありません。
デフォルトは8です。

* hard_timeout
リモートのサーバー接続に失敗したと判断する時間です。
デフォルトはsend_timeoutと同じ値になります。

* serverディレクィブのオプション
- name
宛先の名前を指定します。ログで使われるので必ずしもホスト名である必要はありません。
- host
宛先を記載します。IPアドレスではなくホスト名を指定することもできます。ホスト名を指定する際は名前解決が必要です。
- port
送信で使うポートを指定します。デフォルトは24224です。

* 受信側

受信側ではsourceディレクティブのtypeをforwardに指定し、アウトプットをmatchディレクティブで指定します。
matchディレクティブ内で指定しているタグ(この例で言う"messages")は送信側で指定しているものになります。
オプションの内容は以下の通りです。

* port
ポートを指定します。ここで指定した値を送る側で指定する必要があります。
デフォルトは24224です。

*bind
送信を受け付けるネットワークを指定します。
デフォルトは0.0.0.0(全ネットワーク)です。

以上でデータ転送の設定は完了です。
データの転送がうまく行かない場合は以下の点を確認してみてください。

・送信側と受信側でポートの指定が合っているか
・通信経路のTCPとUDPの両ポートが空いているか(送信側のheartbeat_intervalオプションの説明を参照)
・送信側で指定しているタグと受信側で指定しているタグが合っているか

これがうまく行けば、同じ送信側の設定のfluentdを複数のサーバーで動かすことでデータの集約が実現できます。


冗長化構成

fluentdではデータの受信側を冗長化し、データ送信先を複数指定することもできます。
送信先を複数指定することでサーバーのダウン等によって発生した送信失敗によるデータ消失リスクを下げることができます。
複数指定は、送信側のmatchディレクティブの中で指定しているserverディレクティブを複数書くことで実現できます。

・アクティブ-アクティブ構成

この設定ではweightというオプションを追加しています。
weightはサーバーを複数指定した際にどの割合で転送するかの重みを指定するオプションです。
重みであって%ではないので、合計を100にする必要はありません。
weightを指定していないserverのweightは60として扱われます。

・アクティブ-スタンバイ構成

複数台のサーバーそれぞれに送信するのではなく、あるサーバーが使えなくなったときのみ他のサーバーに送信したい場合は、serverディレクティブの中にstandbyオプションを付加します。


余談 最後の砦を作る

1台しか送信先を設定しない際にサーバーがダウンした場合や、複数台サーバーを指定していてもネットワークの問題等ですべて繋がらなくなった場合どうなるでしょうか?
バッファの設定である程度はリトライをしてくれますが、最終的にはデータが破棄されてしまいます。(ただしバッファのtypeをfileにしている場合は残ります)

こういった場合の応急処置用にsecondaryディレクティブを指定することができます。
fluentdは全てのサーバーがダウンしたと判断した時に、secondaryで指定されたものをアウトプット先とします。

このようにsecondaryディレクティブを用意しておくことで送信し損ねたデータの喪失を防ぐことができます。


最後に

前回の基本編と今回を通してfluentdの基本的な使い方からログの転送までを見てきました。
ここまでのことと各種プラグインを駆使することで、あらゆる要件に対応できることと思います。
最近ではログをリアルタイムに解析してフィードバックを得ることの重大さが謳われるようになり、先日の記事で紹介させて頂いたelasticsearchのようなログ解析用のツールも多数存在しています。
fluentdはそういったツールとの連携でも役立ちます。
ぜひこの機会に、fluentdを使ったログの運用にトライしてみてください!

エンジニア採用中!私たちと一緒に働いてみませんか?