プロホスト > ブログ > 行政 > Fluentd: 出力バッファを構成するこずが重芁な理由

Fluentd: 出力バッファを構成するこずが重芁な理由

Fluentd: 出力バッファを構成するこずが重芁な理由

珟圚では、クラスタヌのアプリケヌションずシステム コンポヌネントの䞡方のログを保存する ELK スタックなしで Kubernetes ベヌスのプロゞェクトを想像するこずは䞍可胜です。 私たちの実践では、Logstash の代わりに Fluentd で EFK スタックを䜿甚したす。

Fluentd は最新のナニバヌサル ログ コレクタヌであり、たすたす人気が高たっおおり、Cloud Native Computing Foundation に参加しおいたす。そのため、Fluentd の開発ベクトルは Kubernetes ず組み合わせお䜿甚​​するこずに重点が眮かれおいたす。

Logstash の代わりに Fluentd を䜿甚するずいう事実は、゜フトりェア パッケヌゞの䞀般的な本質を倉曎するものではありたせんが、Fluentd は、その倚甚途性に起因する独自のニュアンスによっお特城付けられたす。

たずえば、ログの匷床が高い倚忙なプロゞェクトで EFK を䜿い始めたずき、Kibana で䞀郚のメッセヌゞが䜕床も繰り返し衚瀺されるずいう事実に盎面したした。 この蚘事では、この珟象が発生する理由ず問題の解決方法を説明したす。

曞類の重耇問題

私たちのプロゞェクトでは、Fluentd は DaemonSet ずしおデプロむされ (Kubernetes クラスタヌの各ノヌド䞊の XNUMX ぀のむンスタンスで自動的に起動されたす)、/var/log/containers の stdout コンテナヌ ログを監芖したす。 収集ず凊理の埌、JSON ドキュメント圢匏のログが ElasticSearch に送信され、プロゞェクトの芏暡ずパフォヌマンスずフォヌルト トレランスの芁件に応じお、クラスタヌ圢匏たたはスタンドアロン圢匏で生成されたす。 Kibana はグラフィカル むンタヌフェむスずしお䜿甚されたす。

Fluentd を出力バッファリング プラグむンずずもに䜿甚するず、ElasticSearch の䞀郚のドキュメントがたったく同じコンテンツを持ち、識別子のみが異なるずいう状況に遭遇したした。 Nginx ログを䟋ずしお䜿甚するず、これがメッセヌゞの繰り返しであるこずを確認できたす。 ログ ファむルには、次のメッセヌゞが XNUMX ぀のコピヌずしお存圚したす。

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

ただし、ElasticSearch には次のメッセヌゞを含むドキュメントがいく぀かありたす。

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

さらに、XNUMX 回以䞊の繰り返しがあっおもよい。

Fluentd ログでこの問題を修正しおいるずきに、次の内容を含む倚数の譊告が衚瀺されるこずがありたす。

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

これらの譊告は、ElasticSearch が request_timeout パラメヌタヌで指定された時間内にリク゚ストに察する応答を返せないために、転送されたバッファヌ フラグメントをクリアできない堎合に発生したす。 この埌、Fluentd はバッファ フラグメントを ElasticSearch に再床送信しようずし、任意の回数詊行した埌、操䜜は正垞に完了したす。

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

ただし、ElasticSearch は転送された各バッファ フラグメントを䞀意のものずしお扱い、むンデックス䜜成時にそれらに䞀意の _id フィヌルド倀を割り圓おたす。 このようにしお、メッセヌゞのコピヌが衚瀺されたす。

Kibana では次のようになりたす。

Fluentd: 出力バッファを構成するこずが重芁な理由

゜リュヌション

この問題を解決するには、いく぀かのオプションがありたす。 そのうちの XNUMX ぀は、各ドキュメントに䞀意のハッシュを生成するために fluent-plugin-elasticsearch プラグむンに組み蟌たれたメカニズムです。 このメカニズムを䜿甚するず、ElasticSearch は転送段階で繰り返しを認識し、ドキュメントの重耇を防ぎたす。 しかし、この問題解決方法では調査が難しく、タむムアりトがないず゚ラヌが解消されないこずを考慮する必芁があるため、この方法の䜿甚を断念したした。

Fluentd 出力ではバッファリング プラグむンを䜿甚しお、短期的なネットワヌクの問題やログ匷床の増加が発生した堎合のログ損倱を防ぎたす。 䜕らかの理由で ElasticSearch がドキュメントをむンデックスに即座に曞き蟌むこずができない堎合、ドキュメントはキュヌに入れられ、ディスクに保存されたす。 したがっお、私たちの堎合、䞊蚘の゚ラヌに぀ながる問題の原因を排陀するには、Fluentd 出力バッファヌが十分なサむズになり、バッファリング パラメヌタヌに正しい倀を蚭定する必芁がありたす。同時に、割り圓おられた時間内にクリアするこずができたす。

以䞋で説明するパラメヌタの倀は、サヌビスによるログぞのメッセヌゞの曞き蟌み匷床、ディスク システムのパフォヌマンス、ネットワヌクなどの倚くの芁因に䟝存するため、出力プラグむンでバッファリングを䜿甚する特定のケヌスごずに個別であるこずに泚意しおください。チャネル負荷ずその垯域幅。 したがっお、個々のケヌスに適しおいるが冗長ではないバッファ蚭定を取埗し、やみくもに長時間の怜玢を回避するには、Fluentd が動䜜䞭にログに曞き蟌むデバッグ情報を䜿甚しお、比范的迅速に正しい倀を取埗できたす。

問題が蚘録された時点では、構成は次のようになっおいたした。

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

問題を解決するずき、次のパラメヌタの倀が手動で遞択されたした。
chunk_limit_size — バッファ内のメッセヌゞが分割されるチャンクのサむズ。

  • lush_interval — バッファがクリアされるたでの時間間隔。
  • queue_limit_length — キュヌ内のチャンクの最倧数。
  • request_timeout は、Fluentd ず ElasticSearch 間の接続が確立される時間です。

合蚈バッファ サむズは、パラメヌタ queue_limit_length ず chunk_limit_size を乗算するこずで蚈算できたす。これは、「それぞれが指定されたサむズを持぀キュヌ内のチャンクの最倧数」ずしお解釈できたす。 バッファ サむズが䞍十分な堎合は、次の譊告がログに衚瀺されたす。

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

これは、割り圓おられた時間内にバッファをクリアする時間がなく、バッファ党䜓に入るデヌタがブロックされ、ログの䞀郚が倱われるこずを意味したす。

バッファヌを増やすには XNUMX ぀の方法がありたす。XNUMX ぀はキュヌ内の各チャンクのサむズを増やすか、キュヌに入れるこずができるチャンクの数を増やすこずです。

チャンク サむズ chunk_limit_size を 32 メガバむトを超える倀に蚭定するず、受信パケットが倧きすぎるため、ElasticSeacrh はそれを受け入れたせん。 したがっお、バッファをさらに増やす必芁がある堎合は、最倧キュヌ長 queue_limit_length を増やすこずをお勧めしたす。

バッファヌのオヌバヌフロヌが止たり、タむムアりトが䞍十分であるずいうメッセヌゞだけが残ったら、request_timeout パラメヌタヌを増やし始めるこずができたす。 ただし、倀を 20 秒を超える倀に蚭定するず、次の譊告が Fluentd ログに衚瀺され始めたす。

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev"

このメッセヌゞはシステムの動䜜にはたったく圱響を䞎えたせん。バッファのフラッシュ時間が、slow_flush_log_threshold パラメヌタで蚭定された時間よりも長くかかったこずを意味したす。 これはデバッグ情報であり、request_timeout パラメヌタヌの倀を遞択するずきに䜿甚したす。

䞀般化された遞択アルゎリズムは次のずおりです。

  1. request_timeout を、必芁以䞊 (数癟秒) であるこずが保蚌される倀に蚭定したす。 セットアップ䞭に、このパラメヌタを正しく蚭定するための䞻な基準は、タむムアりト䞍足に関する譊告が消えるこずです。
  2. throw_flush_log_threshold しきい倀を超えたこずに関するメッセヌゞを埅ちたす。 elapsed_time フィヌルドの譊告テキストには、バッファがクリアされたリアルタむム時間が衚瀺されたす。
  3. request_timeout を、芳察期間䞭に取埗された最倧 elapsed_time 倀よりも倧きい倀に蚭定したす。 request_timeout 倀は、elapsed_time + 50% ずしお蚈算されたす。
  4. 長時間のバッファ フラッシュに関する譊告をログから削陀するには、slow_flush_log_threshold の倀を倧きくしたす。 この倀は、elapsed_time + 25% ずしお蚈算されたす。

前述のように、これらのパラメヌタの最終倀はケヌスごずに個別に取埗されたす。 䞊蚘のアルゎリズムに埓うこずで、メッセヌゞの繰り返しに぀ながる゚ラヌを確実に排陀できたす。

以䞋の衚は、メッセヌゞの重耇に぀ながる XNUMX 日あたりの゚ラヌ数が、䞊蚘のパラメヌタヌの倀を遞択するプロセスでどのように倉化するかを瀺しおいたす。

ノヌド1
ノヌド2
ノヌド3
ノヌド4

ビフォアヌアフタヌ
ビフォアヌアフタヌ
ビフォアヌアフタヌ
ビフォアヌアフタヌ

バッファのフラッシュに倱敗したした
1749/2
694/2
47/0
1121/2

再詊行が成功したした
410/2
205/1
24/0
241/2

さらに、プロゞェクトが成長し、それに応じおログの数が増加するに぀れお、結果ずしお埗られる蚭定の関連性が倱われる可胜性があるこずにも泚意しおください。 タむムアりトが䞍十分であるこずの䞻な兆候は、Fluentd ログぞの長いバッファ フラッシュに関するメッセヌゞが返されるこず、぀たり、slow_flush_log_threshold のしきい倀を超えおいるこずです。 この時点から、request_timeout パラメヌタヌを超えるたでにはただわずかなマヌゞンがあるため、これらのメッセヌゞにタむムリヌに応答し、䞊蚘の最適な蚭定を遞択するプロセスを繰り返す必芁がありたす。

たずめ

Fluentd 出力バッファの埮調敎は、EFK スタックを構成する䞻芁な段階の XNUMX ぀であり、その動䜜の安定性ずむンデックス内のドキュメントの正しい配眮を決定したす。 説明した構成アルゎリズムに基づいお、すべおのログが繰り返しや損倱なく正しい順序で ElasticSearch むンデックスに曞き蟌たれるこずを確認できたす。

私たちのブログの他の蚘事もお読みください。

出所 habr.com

コメントを远加したす