Ubuntu 16.04でFluentdとElasticSearchを使用してDockerログを集中化する方法

Fluentdの記事

前書き

Dockerコンテナーを実稼働環境にロールすると、コンテナーよりも一時的ではない場所にログを保持する必要性が高まります。 DockerにはFluentd用のネイティブログドライバーが付属しているため、これらのログを簡単に収集し、https://www.elastic.co/ [Elasticsearch]などの別の場所にルーティングできるため、データを分析できます。

Fluentdは、ロギングインフラストラクチャを統合するために設計されたオープンソースのデータコレクターです。 ログの収集と保存を簡単かつスケーラブルにすることで、運用エンジニア、アプリケーションエンジニア、データエンジニアを結び付けます。

Fluentdには、クリーンで信頼性の高いログパイプラインの構築に適した4つの重要な機能があります。

  • * JSONを使用した統合ロギング:* Fluentdは、可能な限りJSONとしてデータを構造化しようとします。 これにより、Fluentdは、ログデータの処理のすべての面を統合できます。複数のソースと宛先間でログを収集、フィルタリング、バッファリング、出力します。 JSONでは、厳格なスキーマを強制することなくアクセスできる十分な構造を備えているため、ダウンストリームのデータ処理ははるかに簡単です。

  • プラガブルアーキテクチャ: Fluentdには、コミュニティが機能を拡張できる柔軟なプラグインシステムがあります。 300以上のコミュニティが提供するプラグインは、必要に応じてデータを操作し、多数のデータソースを多数のデータ出力に接続します。 プラグインを使用することで、すぐにログを有効に活用できます。

  • *必要な最小リソース:*データコレクターは、ビジーなマシンで快適に実行できるように軽量でなければなりません。 FluentdはCとRubyの組み合わせで記述されており、最小限のシステムリソースが必要です。 バニラインスタンスは30〜40 MBのメモリで実行され、13,000イベント/秒/コアを処理できます。

  • *組み込みの信頼性:*データの損失は決して起こりません。 Fluentdはメモリベースおよびファイルベースのバッファリングをサポートし、ノード間のデータ損失を防ぎます。 Fluentdは堅牢なフェイルオーバーもサポートしており、高可用性のためにセットアップできます。

このチュートリアルでは、Fluentdをインストールし、Dockerコンテナーからログを収集するように構成する方法を学習します。 次に、同じUbuntu 16.04サーバーでElasticsearchを実行している別のコンテナーにデータをストリーミングし、ログをクエリします。

前提条件

このチュートリアルを完了するには、次のものが必要です。

ステップ1-Fluentdのインストール

http://www.fluentd.org [Fluentd]をインストールする最も一般的な方法は、 `+ td-agent `パッケージを使用することです。 Fluentdの元の著者であるhttps://www.treasuredata.com [Treasure Data]は、Fluentdを自己完結型のRubyランタイムにパッケージ化するため、Fluentdを実行するためにRuby環境をセットアップする必要はありません。 また、リポジトリを設定してパッケージをインストールする最新の ` td-agent`パッケージを取得するスクリプトも提供します。

非rootユーザーとしてサーバーにログインします。

ssh sammy@

次に、Treasure Dataが提供するスクリプトを使用して、「+ td-agent」をインストールします。 まず、スクリプトをダウンロードします。

\curl -L http://toolbelt.treasuredata.com/sh/install-ubuntu-xenial-td-agent2.sh -o install-td-agent.sh

スクリプトを監査する場合は、テキストエディターで開きます。

nano install-td-agent.sh

スクリプトの内容に満足したら、スクリプトを実行して `+ td-agent`をインストールします。

sh install-td-agent.sh

インストールが完了したら、 `+ td-agent`を起動します:

sudo systemctl start td-agent

ログをチェックして、正常にインストールされたことを確認します。

tail /var/log/td-agent/td-agent.log

次のような出力が表示されます。

Output    port 8888
 </source>
 <source>
   @type debug_agent
   bind 127.0.0.1
   port 24230
 </source>
</ROOT>
2016-12-02 19:45:31 +0000 [info]: listening fluent socket on 0.0.0.0:24224
2016-12-02 19:45:31 +0000 [info]: listening dRuby uri="druby://127.0.0.1:24230" object="Engine"

次に、 `+ td-agent-gem +`コマンドを使用してFluentdのElasticsearchプラグインをインストールします。

sudo td-agent-gem install fluent-plugin-elasticsearch

Fluentdは現在、デフォルト構成で稼働しています。 次に、Fluentdを構成して、Dockerイベントをリッスンし、Elasticsearchインスタンスに配信できるようにします。

ステップ2-Fluentdの構成

Fluentdは、情報をどこから収集し、どこに配信するかを知る必要があります。 これらのルールは、 `+ / etc / td-agent / td-agent.conf +`にあるFluentd設定ファイルで定義します。

このファイルをテキストエディターで開きます。

sudo nano /etc/td-agent/td-agent.conf

ファイルの内容を削除します。 このチュートリアルでは、独自のルールを最初から作成します。

「+ source +」セクションで情報源を定義します。 この構成をファイルに追加します。

/etc/td-agent/td-agent.conf

<source>
 @type
 port  24224
</source>

これは、ソースを「+ forward +」として定義します。これは、TCP上で実行されるFluentdプロトコルであり、ログをFluentdに送信するときにDockerによって使用されます。

ログレコードが入ってくると、それらには、「+ time」、「+ tag」、「+ messages」、「+ container_id」などの追加の関連フィールドがあります。 Fluentdがそのデータを送信する場所を決定するには、「+ _ tag_ +」フィールドの情報を使用します。 これは_data routing_と呼ばれます。

これを設定するには、 `+ tag `フィールドの内容に一致する ` match +`セクションを定義し、適切にルーティングします。 この構成をファイルに追加します。

/etc/td-agent/td-agent.conf

<match >
 @type
 logstash_format true
 host 127.0.0.1
 port 9200
 flush_interval
</match>

このルールは、「+ docker。」というプレフィックスが付いたタグを持つすべてのレコードが、ポート「+9200」の「127.0.0.1」で実行されているElasticsearchに送信されることを示しています。 `+ flush_interval +`は、FluentdにElasticsearchに記録する頻度を指示します。

新しい設定ファイルを保存したら、 `+ td-agent +`サービスを再起動して、変更を適用します:

sudo systemctl restart td-agent

Fluentdが目的に合わせて適切に構成されたので、ElasticsearchをインストールしてFluentdからログをキャプチャします。

ステップ3-Elasticsearchコンテナーの開始

Dockerを使用してElasticsearchのインスタンスを実行します。これは、自分で構成するよりも高速です。 Elasticsearch Docker imageを使用してコンテナーを作成します。 このイメージを使用するには、次のようにDockerホストの `+ max_map_count +`の値を増やします。

sudo sysctl -w vm.max_map_count=262144

次に、次のコマンドを実行してElasticsearchイメージをダウンロードし、コンテナーを開始します。

docker run -d -p 9200:9200 -p 9300:9300 elasticsearch

イメージがダウンロードされ、Elasticsearchコンテナーが起動します。 Dockerプロセスを確認し、コンテナーを探して、コンテナーが正しく実行されていることを確認します。

docker ps

次のような出力が表示されます。

OutputCONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                                            NAMES
76e96943491f               "/docker-entrypoint.s"   About a minute ago   Up 51 seconds

コンテナがリストにない場合は、「-d +」スイッチなしでコンテナを再起動して、コンテナがフォアグラウンドで実行されるようにします。 コマンド ` docker run -p 9200:9200 -p 9300:9300 elasticsearch `を実行し、特定のエラーメッセージを探します。 発生する可能性が最も高いエラーは、十分なシステムメモリがないか、Dockerホストの ` max_map_count +`の値が低すぎるという問題です。 このチュートリアルのすべてのステップをチェックして、何も見逃していないことを確認して、もう一度やり直してください。

Elasticsearchがコンテナで実行されたので、いくつかのログを生成してFluentdに取り込みましょう。

ステップ4-Dockerコンテナーからのログの生成

Dockerでは、標準出力( + STDOUT +)およびエラー( + STDERR +)インターフェースを介してログをデータのストリームとして扱うことができます。 Dockerアプリケーションを起動するときは、ネイティブのFluentdログドライバーを使用してログをフラッシュするようにDockerに指示するだけです。 Fluentdサービスはログを受信し、Elasticsearchに送信します。

次のようにDockerコンテナー内でBashコマンドを開始して、これをテストします。

docker run  ubuntu /bin/echo 'Hello world'

これにより、メッセージ「+ Hello world 」が標準出力に出力されますが、Docker Fluentdドライバーによってキャッチされ、以前に設定したFluentdサービスに配信されます。 約5秒後、レコードはElasticsearchにフラッシュされます。 Fluentd構成ファイルの ` match +`セクションでこの間隔を構成しました。

Elasticsearchにログを取得するにはこれで十分ですが、オプションの詳細についてはhttps://docs.docker.com/engine/admin/logging/fluentd/ [公式ドキュメント]をご覧ください。 Dockerを使用してFluentdドライバーを管理できます。

最後に、Elasticsearchがイベントを受信して​​いることを確認しましょう。 `+ curl +`を使用して、クエリをElasticsearchに送信します。

curl -XGET 'http://localhost:9200/_all/_search?q=*'

出力には、次のようなイベントが含まれます。

{"took":2,"timed_out":false,"_shards":{"total":1,"successful":1,"failed":0},"hits":{"total":1,"max_score":1.0,"hits":[{"_index":"logstash-2016.12.02","_type":"fluentd","_id":"AVQwUi-UHBhoWtOFQKVx","_score":1.0,"_source":{"container_id":"d16af3ad3f0d361a1764e9a63c6de92d8d083dcc502cd904155e217f0297e525","container_name":"","source":"stdout","log":"","@timestamp":"2016-12-02T14:59:26-06:00"}}]}}

設定によっては、かなりの数のイベントが記録される場合があります。 単一のイベントは、 `+ {" took ":+`で始まり、タイムスタンプで終わる必要があります。 また、ソースコンテナに関連する追加情報も含まれます。 この出力が示すように、ElasticsearchはDockerコンテナーからデータを受信して​​います。

結論

Dockerコンテナーからログを収集することは、Fluentdを使用する1つの方法にすぎません。 多くのユーザーがFluentdに来て、リアルタイムのログ検索と長期保存の両方を行うロギングパイプラインを構築します。 このアーキテクチャは、データストリームをコピーして複数のストレージシステムに出力するFluentdの機能を利用しています。 たとえば、リアルタイム検索にはElasticsearchを使用できますが、バッチ分析と長期ストレージにはMongoDBまたはHadoopを使用できます。

Webアプリケーションは大量のログを生成し、多くの場合、それらは任意にフォーマットされ、ローカルファイルシステムに保存されます。 これは、2つの理由で問題を引き起こす可能性があります。 まず、ログをプログラムで解析するのが難しく、多くのhttps://www.digitalocean.com/community/tutorials/an-introduction-to-regular-expressions [正規表現]が必要なため、アクセスしにくいユーザー統計分析、A / Bテストの結果の確認、または不正検出の実行を通じてユーザーの行動を理解したい。

第二に、テキストログはストレージシステムにバルクロードされるため、ログにはリアルタイムでアクセスできません。 さらに悪いことに、サーバーのディスクがバルクロード間で破損した場合、ログが失われたり破損したりします。

Fluentdは、さまざまなプログラミング言語用のロガーライブラリに一貫したAPIを提供することにより、これらの問題の両方を解決します。 各ロガーは、このチュートリアルで見たようなタイムスタンプ、タグ、JSON形式のイベントを含むレコードをFluentdに送信します。 Ruby、Node.js、Go、Python、Perl、PHP、Java、およびC ++用のhttp://www.fluentd.org/datasources[logger libraries]があります。 これにより、アプリケーションは「発火して忘れる」ことができます。ロガーはデータをFluentdに非同期的に送信し、バックエンドシステムにログオフする前にログをバッファリングします。

FluentdとElasticsearchでできることは他にもたくさんあります。 次のリンクが興味深いと思うかもしれません:

Related