続けて、インプット/バッファ/アウトプットの各層のプラグインがどのように実現され、どのような役割を果たすのか、もう少し具体的に紹介しましょう。なお本記事では、各プラグインの内部的な仕組みの概要のみを紹介します。より具体的な実装方法はマニュアルを参照してください。
インプットプラグインは、管理すべきデータを集める機能に特化したプラグインになります。データの入力元として、ログファイルやデータベース、クラウドAPIなどさまざまなソースを対象とすることができます。代表的なプラグインについては、第2回にて紹介します。
インプットプラグインには、主に以下の3つの処理が内部実装されています。
1のデータを収集する部分では、取得したいデータソースごとにRubyのライブラリなどを活用しながら取得するよう実装しています。
2の処理では、1で取得したデータを処理し、以下のような、キーとバリューをセットにしたRubyのハッシュ形式に変換します。
{"key1" => "value1, "key2" => "value2", ・・・}
3の処理では、このデータに対して、タグ情報と時刻情報を付与してfluentdの内部的なイベント発行を行います。
バッファプラグインは、インプットプラグインから入力された情報をアウトプットプラグインでターゲットに対して出力するまでの間の、データ管理処理を実装したプラグインです。
バッファプラグインはfluentdの標準組み込みプラグインで、以下の3種類が用意されています。
バッファプラグインは単独で利用するものではなく、アウトプットプラグインに組み込んで利用されます。アウトプットプラグインごとにどの種類のバッファを利用するのか(もしくはバッファを利用しないか)が指定されています。
例えば、アウトプットプラグインがBufferedOutputを継承して作られている場合にはデフォルトでMemoryBufferプラグインが、TimeSlicedOutputを継承して作られている場合にはデフォルトでFileBufferプラグインが内部で利用されています。
デフォルトのバッファプラグイン以外を利用したい場合は、fluentdのアウトプットプラグインの設定にてbuffer_typeを指定(file/memory/zfileのうちいずれかを指定)することで、どの形式でバッファ管理するかを指定可能です。
fluentdのバッファは、Queue(キュー)とChunk(チャンク)という形で管理されています。fluentdのコア部分ではこのQueueとChunkを管理し、何らかの要因により、指定したアウトプット先に対する出力が失敗した時でも、データが紛失しないような仕組みが実装されています。
QueueとChunkを含むバッファ管理の詳細な仕組みについては、以下のURLを参照してください。
Buffer Plugin Overview
http://docs.fluentd.org/articles/buffer-plugin-overview
Fluentdの仕組み -バッファ機能でログ収集漏れを防ぐ-(Tech-Sketch)
http://tech-sketch.jp/2013/05/fluentd-buffer.html
アウトプットプラグインは、fluentdで収集されたデータを用途に応じて出力する機能を実装したプラグインです。アウトプットプラグインには、前述したバッファプラグインを組み込んだものと、バッファを利用しないものがあります。
また、バッファを利用するものの中にも、「BufferedOutput」と呼ばれるタイプ(QueueやChunkのサイズベースでバッファ管理を行うタイプ)や、「TimeSlicedOutput」と呼ばれるタイプ(BufferedOutputタイプのバッファ管理仕様に加え、時間ベースでChunkを管理するタイプ)など、複数の種類があります。
バッファを利用するアウトプットプラグインには、主に以下の2つの処理が内部実装されています。
1では、入力されたfluentdのイベントデータに対して、時刻表記フォーマットの変換などを行い、最終的に出力したい形式に変換します。変換後、バッファプラグインに送られ、バッファへの登録処理が行われます。
2では、バッファから送られてくるデータを実際にアウトプット先に出力するための処理が行われます。何らかの原因で出力に失敗した場合でも、バッファで一時的にデータを蓄積できる機構になっているため、ログの紛失を防ぐことが可能です。
バッファを利用しない場合は以下のような処理のみが実装されています。
このようにインプットプラグインやアウトプットプラグインは、実装範囲が非常に少なくて済む作りとなっています。タグ情報に基づいてデータを該当のプラグインに振り分けたり、バッファの管理(送信に失敗した時の再送処理など)を行うなど、その他複雑な処理はfluentdのコアが実施しています。
連載の第1回では、fluentdとはどういったものか、またどのような仕組みでログの管理が実現されているのか、大まかに概要を紹介しました。ここまで説明したように、入力や出力の処理を書くだけで、自身のシステム要件に応じたプラグインを容易に作ることができ、幅広い環境に適用できるようなアーキテクチャが取られていることが特徴です。
第2回では、fluentdを使うには具体的にどうすればいいのか、インストール手順から設定までを紹介します。
池田大輔
Twitter : @ike_dai
TIS株式会社戦略技術センター所属。社内向けシステムの保守運用業務を経験後、クラウド時代の効率的な統合運用管理をテーマに活動中。特に、OSSを駆使した運用のエコシステム実現を目指し、fluentdなどの導入や検証に取り組む。TIS戦略技術センターでは、技術検証成果などを技術ブログ『Tech-Sketch』にて発信中。著書:『Zabbix統合監視徹底活用 - 複雑化・大規模化するインフラの一元管理』
Copyright © ITmedia, Inc. All Rights Reserved.