読者です 読者をやめる 読者になる 読者になる

s_tajima:TechBlog

渋谷で働くインフラエンジニアのTechブログです。

fluentdの設定管理サーバーを構築

概要

fluentdによるログの回収の構成を広げていくと、
多くのインスタンスにfluentdがインストールされることになるため、
全体に影響するような設定変更が面倒になりそうである。

そこで、fluentdの設定ファイルの中で

include http://config-server/path/

このようにinclude対象にhttp(s)でのリソース取得ができることに注目し、
この仕組を利用した構成を組むことで設定変更時の手間を減らす工夫をした。

構成

f:id:s_tajima:20140303224155j:plain

  • CONTROLLERと呼ばれるサーバーにfluentdの設定を配布するためのWebサーバー(config-server)を立てる。
    • config-serverは、GETパラメータによって返す内容(設定)を変更するようなものとする。
    • 大した処理をしないので、今回はsinatraで実装。
    • 今回実装した例で言えばGETパラメータにはホスト名を指定。config-serverにはホスト毎に必要な設定を定義した。
  • CLIENT(ログの取得元)側では、cronによって定期的にSIGHUPをかける。
    • config-serverで設定を変更した際、その設定が定期的に反映される。
    • 事前に--dry-runを実施し、httpによる設定の取得のエラーや、設定ファイルのエラーがあればSIGHUPは中止する。
    • fluentdのプロセスが停止している場合には、SIGHUPではなく再起動(service td-agent restart)する。
    • 設定には以下のようにGETパラメータにhostnameを付与したものを指定
include https://config-server/?hostname=CLIENT
  • STREAM(ログの収集サーバー)は、台数が少ないのと設定の不備があった場合に広い範囲に影響が出る可能性があるため定期SIGHUPはなし。

まとめ

  • fluentdの死活監視/buffer監視等については別途環境整備済みなので、この構成で運用を開始してみて副作用を検証。
  • 毎回SIGHUPをかけるのではなく、予めcurlなどで設定ファイルを取得してmd5を計算してどこかにおいておき、前回のものと差分があったらSIGHUPでもいいかも。
  • 設定変更時、最初に少数のtd-agentで別のinclude先を指定(同サーバーの別virtualhost等)して、設定をテストする。みたいなことも可能。