オリジナル：https://www.cnblogs.com/liang1101/p/8509978.html
特定の問題を次の図に示します。
INFO情報は次のように出力されます。
[2018-03-05T16:26:08,711][INFO ][logstash.setting.writabledirectory] Creating directory {
:setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"} <br>[2018-03-05T16:26:08,727][INFO ][logstash.agent ] No persistent UUID file found. Generating new UUID {
:uuid=>"f4d5f9a9-42ca-4765-b3fb-0f4566f440df", :path=>"/usr/share/logstash/data/uuid"}
[2018-03-05T16:26:09,175][INFO ][logstash.outputs.elasticsearch] Elasticsearch pool URLs updated {
:changes=>{
:removed=>[], :added=>[http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s]}} <br>[2018-03-05T16:26:09,176][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working {
:healthcheck_url=>http://logstash_system:xxxxxx@localhost:9200/, :path=>"/"} <br>[2018-03-05T16:26:09,262][WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. {
:url=>#<URI::HTTP:0x59e42e4f URL:http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s>, :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [http://logstash_system:xxxxxx@localhost:9200/][Manticore::SocketException] Connection refused (Connection refused)"}
まず、ログから、esが死に至るまで書き込まれた可能性がある、つまり、これ以上データを書き込むことができないことがわかります。この場合、現在制限されているログスタッシュデータの書き込み、構成のlogstash-5.4.1/config/logstash.yml変更について考えるのは自然です。
パイプラインの労働者の数を減らし、由原来的 32 -> 16， batch size 修改 1000 -> 500， delay 修改 200 -> 1000， output.workers: 16 -> 8
変更後、logstashを再起動したところ、しばらくすると対応するログが表示されることがわかりました。長時間検索した後、ようやくgoogleでxpackによるヘルスチェックの影響を受ける可能性のある外国人を見つけました。ログは実際には1秒ごとに対応していることがわかりました。 esのヘルスチェックを行うため、logstash.ymlに行を追加します。
xpack.monitoring.enabled: false
つまり、xpackの監視を削除し、logstashを再起動して一定期間監視すると、WARNおよびERRORログはなくなり、問題は解決されます。
総括する
これは、1秒ごとにes状態をpingするので、これは確かにxpackの問題だと思います。クラスターがビジー状態の場合、タイムアウトが発生するのは簡単です。現時点では、logstashはesに到達できず、ポーリングと待機を続けます。xpackのヘルスチェックなどの監視を削除し、logstashが単独で書き込むときに判断します。
【2018-03-06 18:08:56記録】
昨日修正を終えましたが、本日確認したところ、上記の異常ログがまだ残っているので、引き続き確認しました。対応するlogstashとElasticSearchサーバーの負荷とCPUが高すぎない最初に、それはioの問題である可能性がある、つまりioの相互作用が非常に頻繁であると考えられています。
ログを確認すると、「elasticsearchに一括リクエストを送信する」というエラーが何度も繰り返し表示されることがわかりました。つまり、logstashは常に、大量のリクエストをESに迅速に送信しています。logstashの構成を確認したところ、デフォルトの構成は次のとおりです。
# How many events to retrieve from inputs
pipeline.batch.size: 125
# milliseconds
pipeline.batch.delay: 5
そして私の現在の設定は：
pipeline:
workers: 32
batch:
size: 200
delay: 100
output:
workers: 8
unsafe_shutdown: false
queue:
type: persisted
page_capacity: 250mb
max_events: 10000
max_bytes: 1gb
checkpoint:
acks: 10000
writes: 10000
interval: 1000
ここでの単位はミリ秒です。つまり、logstashのインスタンスごとに200リクエストが100ミリ秒ごとにESクラスターに送信され、ESクラスターのネットワークI / Oが過負荷になります。
それでは、各バッチの間隔を増やし、各バッチのサイズを増やす必要があるということですか。たとえば、batch.size = 500、batch.delay = 500の場合、上記の問題を回避できますか？
これはテスト後に実現可能です。
以下で構成されているmax_bytesとmax_eventsの制限により、変更された構成は次のようになります（参照のみ）。
pipeline:
workers: 16
batch:
size: 500
delay: 200
output:
workers: 12
unsafe_shutdown: false
queue:
type: persisted
page_capacity: 250mb
max_events: 10000
max_bytes: 1gb
checkpoint:
acks: 10000
writes: 10000
interval: 1000
この構成にはいくつかの目的があります。
-
ESとのIOの相互作用を最小限に抑えるために、一度に最大のデータを読み取るようにしてください。
-
間隔を長くすることはできません。1000の構成の最初に、エラーが500に減少し、エラーが減少したことがわかりました。分析により、間隔を長くする必要があり、logstashによってキューでブロックされるデータが増加するため、読み取りの頻度が高くなります。特に一定期間が経過した後は、決して減少することはなく、比較的大量の太陽光品質を伴う一部の収集遅延が大きくなることがわかります。そのため、総合的に検討した結果、遅延時間が200に修正されました。
-
CPUコアの数は40を超えるため、output.workersスレッドの数を増やして、処理能力を向上させ、データの輻輳を減らし、レイテンシを減らします。
最後に、要約すると：以上报错信息其实并不影响整体日志收集，这个错误只是 logstash 自己认为可能不可达はその中のコンポーネントが原因です。githubのステートメントを確認してください。最新バージョンのフォローアップでこの誤検知の問題を解決できる可能性がありますが、無視しないという意味ではありません。而是要想办法将这个错误频次降低，尽最大可能使其运行良好。
【2018-05-06 10:18:56記録】
この期間中、ELKがログを欠落してログが欠落する問題は解決されます。主な理由は、無理な設定です。この問題の理由は、構成されたファイルビートで到達できない待機時間が3分であることです。ログスタッシュの輻輳が途中で深刻で、elasticsearchの負荷が高い場合、ファイルビートが3分以上スリープする可能性があります。最新バージョンのファイルビートを確認してください。デフォルトは1日です。実際には、構成は妥当です。少し大きいですが、データを失うよりはましです。構成を1時間に増やした後、ログは失われません。
ELKによるログ収集の比較的高い遅延の問題を解決しました。多くの最適化を試みたところ、根本的に解決できないことが判明したため、最もリソースを集中的に使用するnginx_logとpush_logがそれぞれの小さなクラスターに移行され、他のすべてのログは既存のログに残りましたそれ以降、クラスターではさまざまな問題が解決されています。要約すると、1つの文になります。有多大能力就干多大的事，不要超过其最大承受能力。