filebeat to elasticsearch針filebeat端のパフォーマンス最適化--パフォーマンス向上230%

1.filebeatの紹介
filebeatは当初logstash-forwarderソースコードに基づくログデータshipperであった.Filebeatは,サーバ上にエージェントとしてインストールされてログディレクトリや特定のログファイルを監視し,ログをLogstashに転送して解析するか,ElasticsearchやRedisなどのコンポーネントに送信してインデックス化する.
2.filebeatはlogstashより長所と短所がある
filebeatの利点:

logstashはJVMベースであり、リソースの追加コストは非常に大きい.filebeatはGolangに基づいて開発され、リソース消費がより小さく、より便利なlogstash

に相当する.

filebeatはelasticです.co社が開発した、公式はfilebeatに最も全面的なサポートを提供した.filebeatのパフォーマンスは非常に良く、導入が簡単で、非常に理想的なファイル収集ツール

です.

filebeatはelasticに基づく.coが公式に提供したlibbeatライブラリは開発され、コード量は大きくなく、filebeatを迅速に把握し、

を改造し、最適化することができます.
filebeatの欠点:
filebeatが公式に提供している機能は比較的単一で、私たちのニーズを満たすことができないことが多い(例えばRedisへの書き込みは許可されているがReidsからの読み取りは許可されていない.読む必要がある場合はlogstashのような重いコンポーネントを借りる必要がある.Metaqのようなミドルウェアを書いてメッセージストレージをしてES側の圧力を緩和することは許されていない)
2.問題の由来–なぜfilebeatを最適化する必要があるのか.
filebeatはパフォーマンスに優れたファイル収集ツールであり、ほとんどのビジネスログはelasticsearchに1秒で簡単に収集できます.ただし、個別業務の大ログ数業務ログは収集できません
私たちはこのようなテストをしたことがあります.filebeatはKubernetesクラスタに実行され、私はfilebeatコンテナに「1コア」CPUを割り当てました.これは公式のデフォルト構成に従ってESを書く速度が1 M/s未満です.
十分な構成とテストを修正し、最終的に2.3 M/s程度のパフォーマンスを最適化しました.しかし、この性能は依然として私たちの一部の業務の日品質の需要を満たすことができません.そこでfilebeatについてソースレベルの最適化を行います
3.まずfilebeat.ymlプロファイルの最適化
便宜上、私は直接写真を貼りました.もちろん、これらの構成は参考にするしかありません.マシンの性能、ネットワーク帯域幅などに応じた構成も同じではありません
Inputエンドコンフィギュレーションチューニング
output.Elasticsearchエンドコンフィギュレーションチューニング
4.filebeatソースレベルの最適化
上端の配置最適化により、filebeat書き込みの性能が向上し、「1コア単位」CPUの場合、書き込みES効率は2.3 M/sに達する.間違いなく、このログ量はほとんどのビジネスを満たすことができます.しかし、それは依然として私たちの個別の大ログ業務を満たすことができません.
ソースコードにlogを付けてpublish関連のソースコードを遮断することにより、filebeat read to spoolの効率は25.3 M/s(1コア単位CPUのコンテナ環境下)に達し、filebeatの性能ボトルネックはpublishレベルであることが分かった.すなわちwrite to esの効率が不十分である.
p.Publish()に実行するたびに、プログラムはes側の収集ログが完了するまでブロックされます.spool_sizeのログの後、filebeatにフィードバックしてpublishを続行します.これにより、書き込みが読み取り速度に全く追いつかない.公式にはasyncは現在試験段階で、使用を提案していないという.本人はasync方式をテストしたことがありますが、性能は著しく増加していません.
このコードの一部を次のように変更しました.

const MAX_PUBLISH_CNT int = 5

func (p *syncLogPublisher) Start() {
    // init connection pool
    for index := 0; index < MAX_PUBLISH_CNT; index++ {
        p.client[index] = p.pub.Connect()
    }

    p.wg.Add(MAX_PUBLISH_CNT)

    runtime.GOMAXPROCS(MAX_PUBLISH_CNT)

    for index := 0; index < MAX_PUBLISH_CNT; index++ {
        go func(index int) {
            defer p.wg.Done()

            logp.Info("Start sending events to output")
            defer logp.Debug("publisher", "Shutting down sync publisher")

            // logp.Info("index: %d", index)
            for {
                err := p.Publish(index)
                if err != nil {
                    return
                }
            }
        } (index)
    }
}

golangの利便性とfilebeat自体の優れた設計により、スレッドセキュリティの問題がないことを保証しました.効果の向上は明らかで、性能はもとの基礎の上で100%向上して、下図のようです:
どうしてそう書けるの?では、filebeatのいくつかのポイントについてお話しします.

Publish、何行のログをアップロードしますか?この値はfilebeatです.spool_sizeで定義する

Publishで何をしましたか?ワークを起動してfilebeatをプッシュします.spool_size行ログはESにブロックされ、すべてのコヒーレントプッシュが完了した後に実行されます.したがって、上記のコードの一部は、ここで

に影響を及ぼさない.

offsetの問題、offsetは異なるpublishスレッドが重複データを送信することを招きますか?Harvesterコンポーネントはoffsetを修正する(Publishではログコンポーネントを読む)前にoffsetはログpublish重複問題

に影響しない.
5.さらに最適化可能な項目

filebeat.template-es2x.json

filebeat.template.json

filebeatがログに追加する不要なフィールドを減らします.パフォーマンスの見積りは再び50%向上します.これにより、当社のすべての業務のログ読み取り問題(6.5 M/s/ODの日質引き出し速度)を十分に満たすことができます.
6.展望:filebeatのために何ができるの?
ますます多くのビジネスアクセスに伴い、ESはボトルネックに達することは間違いなく、esパフォーマンスボトルネックの問題を単一のレベル拡張だけで解決することはできません.RedisやMetaqのようなコンポーネントはミドルウェアとして格納されることが考えられる.ESリソースを活用することで、ピーク時のESのパフォーマンスのボトルネックを回避できます.流量が低いピーク時に不要な資源浪費問題.これらはいずれもソースレベルでfilebeatの機能拡張を行うことができる