Fluentd: ਆਉਟਪੁੱਟ ਬਫਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਅੱਜ ਕੱਲ੍ਹ, ELK ਸਟੈਕ ਤੋਂ ਬਿਨਾਂ ਕੁਬਰਨੇਟਸ-ਅਧਾਰਿਤ ਪ੍ਰੋਜੈਕਟ ਦੀ ਕਲਪਨਾ ਕਰਨਾ ਅਸੰਭਵ ਹੈ, ਜੋ ਕਿ ਕਲੱਸਟਰ ਦੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸਿਸਟਮ ਭਾਗਾਂ ਦੋਵਾਂ ਦੇ ਲੌਗਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਅਭਿਆਸ ਵਿੱਚ, ਅਸੀਂ Logstash ਦੀ ਬਜਾਏ Fluentd ਨਾਲ EFK ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

Fluentd ਇੱਕ ਆਧੁਨਿਕ, ਯੂਨੀਵਰਸਲ ਲੌਗ ਕੁਲੈਕਟਰ ਹੈ ਜੋ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਉਡ ਨੇਟਿਵ ਕੰਪਿਊਟਿੰਗ ਫਾਊਂਡੇਸ਼ਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਗਿਆ ਹੈ, ਜਿਸ ਕਾਰਨ ਇਸਦਾ ਵਿਕਾਸ ਵੈਕਟਰ ਕੁਬਰਨੇਟਸ ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਵਰਤੋਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ।

Logstash ਦੀ ਬਜਾਏ Fluentd ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਤੱਥ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ ਦੇ ਆਮ ਤੱਤ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ, ਹਾਲਾਂਕਿ, Fluentd ਨੂੰ ਇਸਦੀ ਬਹੁਪੱਖੀਤਾ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇਸਦੀਆਂ ਆਪਣੀਆਂ ਖਾਸ ਸੂਖਮਤਾਵਾਂ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਅਸੀਂ ਲੌਗਿੰਗ ਦੀ ਉੱਚ ਤੀਬਰਤਾ ਦੇ ਨਾਲ ਇੱਕ ਵਿਅਸਤ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ EFK ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਤਾਂ ਸਾਨੂੰ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕਿ ਕਿਬਾਨਾ ਵਿੱਚ ਕੁਝ ਸੰਦੇਸ਼ ਕਈ ਵਾਰ ਵਾਰ-ਵਾਰ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਗਏ ਸਨ। ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਇਹ ਘਟਨਾ ਕਿਉਂ ਵਾਪਰਦੀ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ.

ਦਸਤਾਵੇਜ਼ ਡੁਪਲੀਕੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ

ਸਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ, Fluentd ਨੂੰ ਇੱਕ ਡੈਮਨਸੈੱਟ ਵਜੋਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਹਰੇਕ ਨੋਡ 'ਤੇ ਇੱਕ ਵਾਰ ਆਪਣੇ ਆਪ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ) ਅਤੇ /var/log/containers ਵਿੱਚ stdout ਕੰਟੇਨਰ ਲੌਗਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਸੰਗ੍ਰਹਿ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਬਾਅਦ, JSON ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਲੌਗ ਇਲਾਸਟਿਕ ਸਰਚ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਦੇ ਪੈਮਾਨੇ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਕਲੱਸਟਰ ਜਾਂ ਸਟੈਂਡਅਲੋਨ ਰੂਪ ਵਿੱਚ ਉਭਾਰਿਆ ਜਾਂਦਾ ਹੈ। ਕਿਬਾਨਾ ਨੂੰ ਗ੍ਰਾਫਿਕਲ ਇੰਟਰਫੇਸ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਆਉਟਪੁੱਟ ਬਫਰਿੰਗ ਪਲੱਗਇਨ ਦੇ ਨਾਲ Fluentd ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਸਾਨੂੰ ਅਜਿਹੀ ਸਥਿਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਜਿੱਥੇ ElasticSearch ਵਿੱਚ ਕੁਝ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਸਮੱਗਰੀ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੀ ਸੀ ਅਤੇ ਸਿਰਫ਼ ਪਛਾਣਕਰਤਾ ਵਿੱਚ ਵੱਖਰਾ ਸੀ। ਤੁਸੀਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ Nginx ਲੌਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸੁਨੇਹਾ ਦੁਹਰਾਉਣਾ ਹੈ। ਲੌਗ ਫਾਈਲ ਵਿੱਚ, ਇਹ ਸੁਨੇਹਾ ਇੱਕ ਕਾਪੀ ਵਿੱਚ ਮੌਜੂਦ ਹੈ:

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"
  }
}

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਦੋ ਤੋਂ ਵੱਧ ਦੁਹਰਾਓ ਹੋ ਸਕਦੇ ਹਨ।

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 ਬੇਨਤੀ_ਟਾਈਮਆਉਟ ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਸਮੇਂ ਦੇ ਅੰਦਰ ਇੱਕ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਨਹੀਂ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਅੱਗੇ ਬਫਰ ਫਰੈਗਮੈਂਟ ਨੂੰ ਕਲੀਅਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, 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 ਫੀਲਡ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਸੰਦੇਸ਼ਾਂ ਦੀਆਂ ਕਾਪੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।

ਕਿਬਾਨਾ ਵਿੱਚ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਸਮੱਸਿਆ ਨਿਵਾਰਣ

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕਈ ਵਿਕਲਪ ਹਨ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਰੇਕ ਦਸਤਾਵੇਜ਼ ਲਈ ਇੱਕ ਵਿਲੱਖਣ ਹੈਸ਼ ਬਣਾਉਣ ਲਈ fluent-plugin-elasticsearch ਪਲੱਗਇਨ ਵਿੱਚ ਬਣੀ ਵਿਧੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ElasticSearch ਫਾਰਵਰਡਿੰਗ ਪੜਾਅ 'ਤੇ ਦੁਹਰਾਓ ਦੀ ਪਛਾਣ ਕਰੇਗਾ ਅਤੇ ਡੁਪਲੀਕੇਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਰੋਕੇਗਾ। ਪਰ ਸਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਇਹ ਤਰੀਕਾ ਜਾਂਚ ਦੇ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਘਾਟ ਨਾਲ ਗਲਤੀ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ।

ਅਸੀਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀਆਂ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਜਾਂ ਵਧੀ ਹੋਈ ਲੌਗਿੰਗ ਤੀਬਰਤਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਲਾਗ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਣ ਲਈ Fluentd ਆਉਟਪੁੱਟ 'ਤੇ ਇੱਕ ਬਫਰਿੰਗ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ElasticSearch ਇੰਡੈਕਸ ਵਿੱਚ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਤੁਰੰਤ ਲਿਖਣ ਵਿੱਚ ਅਸਮਰੱਥ ਹੈ, ਤਾਂ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਸਮੱਸਿਆ ਦੇ ਸਰੋਤ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਜੋ ਉੱਪਰ ਦੱਸੀ ਗਈ ਗਲਤੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਬਫਰਿੰਗ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਸਹੀ ਮੁੱਲਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਸ 'ਤੇ ਫਲੂਐਂਟਡ ਆਉਟਪੁੱਟ ਬਫਰ ਕਾਫੀ ਆਕਾਰ ਦਾ ਹੋਵੇਗਾ ਅਤੇ ਉਸੇ ਸਮੇਂ ਨਿਰਧਾਰਤ ਸਮੇਂ ਵਿੱਚ ਕਲੀਅਰ ਹੋਣ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ।

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਹੇਠਾਂ ਦੱਸੇ ਗਏ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਮੁੱਲ ਆਉਟਪੁੱਟ ਪਲੱਗਇਨਾਂ ਵਿੱਚ ਬਫਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਹਰੇਕ ਖਾਸ ਮਾਮਲੇ ਵਿੱਚ ਵਿਅਕਤੀਗਤ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਕਈ ਕਾਰਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਲੌਗ ਵਿੱਚ ਸੰਦੇਸ਼ ਲਿਖਣ ਦੀ ਤੀਬਰਤਾ, ​​ਡਿਸਕ ਸਿਸਟਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ, ਨੈਟਵਰਕ. ਚੈਨਲ ਲੋਡ ਅਤੇ ਇਸਦੀ ਬੈਂਡਵਿਡਥ। ਇਸਲਈ, ਬਫਰ ਸੈਟਿੰਗਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਜੋ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਕੇਸ ਲਈ ਢੁਕਵੇਂ ਹਨ, ਪਰ ਬੇਲੋੜੀਆਂ ਨਹੀਂ ਹਨ, ਲੰਮੀਆਂ ਖੋਜਾਂ ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਤਰੀਕੇ ਨਾਲ ਟਾਲਣ ਤੋਂ ਬਚਣ ਲਈ, ਤੁਸੀਂ ਡੀਬਗਿੰਗ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ 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 — ਭਾਗਾਂ ਦਾ ਆਕਾਰ ਜਿਸ ਵਿੱਚ ਬਫਰ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਨੂੰ ਵੰਡਿਆ ਗਿਆ ਹੈ।

• flush_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

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਫਰ ਕੋਲ ਨਿਰਧਾਰਤ ਸਮੇਂ ਵਿੱਚ ਕਲੀਅਰ ਹੋਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ ਅਤੇ ਪੂਰੇ ਬਫਰ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਵਾਲੇ ਡੇਟਾ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਲੌਗਸ ਦੇ ਕੁਝ ਹਿੱਸੇ ਦੇ ਨੁਕਸਾਨ ਹੋ ਜਾਣਗੇ।

ਤੁਸੀਂ ਬਫਰ ਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹੋ: ਜਾਂ ਤਾਂ ਕਤਾਰ ਵਿੱਚ ਹਰੇਕ ਹਿੱਸੇ ਦਾ ਆਕਾਰ ਵਧਾ ਕੇ, ਜਾਂ ਕਤਾਰ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਭਾਗਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਕੇ।

ਜੇਕਰ ਤੁਸੀਂ 32 ਮੈਗਾਬਾਈਟ ਤੋਂ ਵੱਧ ਚੰਕ ਦਾ ਆਕਾਰ chunk_limit_size ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ElasticSeacrh ਇਸਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਆਉਣ ਵਾਲਾ ਪੈਕੇਟ ਬਹੁਤ ਵੱਡਾ ਹੋਵੇਗਾ। ਇਸ ਲਈ, ਜੇਕਰ ਤੁਹਾਨੂੰ ਬਫਰ ਨੂੰ ਹੋਰ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕਤਾਰ ਦੀ ਲੰਬਾਈ queue_limit_length ਨੂੰ ਵਧਾਉਣਾ ਬਿਹਤਰ ਹੈ।

ਜਦੋਂ ਬਫਰ ਓਵਰਫਲੋ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸਮਾਂ ਸਮਾਪਤੀ ਨਾਕਾਫ਼ੀ ਸੁਨੇਹਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਬੇਨਤੀ_ਟਾਈਮਆਉਟ ਪੈਰਾਮੀਟਰ ਨੂੰ ਵਧਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਸੀਂ ਮੁੱਲ ਨੂੰ 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" 

ਇਹ ਸੁਨੇਹਾ ਸਿਸਟਮ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਫਰ ਫਲੱਸ਼ ਸਮਾਂ ਹੌਲੀ_ਫਲਸ਼_ਲੌਗ_ਥ੍ਰੈਸ਼ਹੋਲਡ ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ। ਇਹ ਡੀਬੱਗਿੰਗ ਜਾਣਕਾਰੀ ਹੈ ਅਤੇ ਅਸੀਂ ਬੇਨਤੀ_ਟਾਈਮਆਉਟ ਪੈਰਾਮੀਟਰ ਦੇ ਮੁੱਲ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਆਮ ਚੋਣ ਐਲਗੋਰਿਦਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

1. ਬੇਨਤੀ_ਟਾਈਮਆਉਟ ਨੂੰ ਲੋੜ ਤੋਂ ਵੱਧ (ਸੈਂਕੜੇ ਸਕਿੰਟਾਂ) ਦੀ ਗਾਰੰਟੀਸ਼ੁਦਾ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰੋ। ਸੈੱਟਅੱਪ ਦੇ ਦੌਰਾਨ, ਇਸ ਪੈਰਾਮੀਟਰ ਦੀ ਸਹੀ ਸੈਟਿੰਗ ਲਈ ਮੁੱਖ ਮਾਪਦੰਡ ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਘਾਟ ਲਈ ਚੇਤਾਵਨੀਆਂ ਦਾ ਗਾਇਬ ਹੋਣਾ ਹੋਵੇਗਾ।
2. ਹੌਲੀ_ਫਲਸ਼_ਲੌਗ_ਥ੍ਰੈਸ਼ਹੋਲਡ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪਾਰ ਕਰਨ ਬਾਰੇ ਸੰਦੇਸ਼ਾਂ ਦੀ ਉਡੀਕ ਕਰੋ। elapsed_time ਖੇਤਰ ਵਿੱਚ ਚੇਤਾਵਨੀ ਟੈਕਸਟ ਬਫਰ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦਾ ਅਸਲ ਸਮਾਂ ਦਿਖਾਏਗਾ।
3. ਬੇਨਤੀ_ਟਾਈਮਆਊਟ ਨੂੰ ਨਿਰੀਖਣ ਅਵਧੀ ਦੌਰਾਨ ਪ੍ਰਾਪਤ ਕੀਤੇ ਅਧਿਕਤਮ ਬੀਤ ਗਏ_ਸਮਾਂ ਮੁੱਲ ਤੋਂ ਵੱਧ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰੋ। ਅਸੀਂ ਬੇਨਤੀ_ਸਮਾਂ ਸਮਾਪਤੀ ਮੁੱਲ ਦੀ ਗਣਨਾ ਬੀਤ ਗਏ_ਸਮਾਂ + 50% ਵਜੋਂ ਕਰਦੇ ਹਾਂ।
4. ਲੌਗ ਤੋਂ ਲੰਬੇ ਬਫਰ ਫਲੱਸ਼ਾਂ ਬਾਰੇ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਹਟਾਉਣ ਲਈ, ਤੁਸੀਂ slow_flush_log_threshold ਦਾ ਮੁੱਲ ਵਧਾ ਸਕਦੇ ਹੋ। ਅਸੀਂ ਇਸ ਮੁੱਲ ਦੀ ਗਣਨਾ ਬੀਤ ਗਏ_ਸਮਾਂ + 25% ਵਜੋਂ ਕਰਦੇ ਹਾਂ।

ਇਹਨਾਂ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਅੰਤਮ ਮੁੱਲ, ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਹਰੇਕ ਕੇਸ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਉਪਰੋਕਤ ਐਲਗੋਰਿਦਮ ਦੀ ਪਾਲਣਾ ਕਰਕੇ, ਅਸੀਂ ਉਸ ਗਲਤੀ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਾਂ ਜੋ ਦੁਹਰਾਉਣ ਵਾਲੇ ਸੁਨੇਹਿਆਂ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਪ੍ਰਤੀ ਦਿਨ ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ, ਸੁਨੇਹਿਆਂ ਦੀ ਡੁਪਲੀਕੇਸ਼ਨ ਵੱਲ ਅਗਵਾਈ ਕਰਦੀ ਹੈ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਮਾਪਦੰਡਾਂ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਚੁਣਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਤਬਦੀਲੀਆਂ:

ਨੋਡ-1
ਨੋਡ-2
ਨੋਡ-3
ਨੋਡ-4

ਬਾਅਦ ਤੋਂ ਪਹਿਲਾਂ
ਬਾਅਦ ਤੋਂ ਪਹਿਲਾਂ
ਬਾਅਦ ਤੋਂ ਪਹਿਲਾਂ
ਬਾਅਦ ਤੋਂ ਪਹਿਲਾਂ

ਬਫਰ ਨੂੰ ਫਲੱਸ਼ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ
1749/2
694/2
47/0
1121/2

ਮੁੜ ਕੋਸ਼ਿਸ਼ ਸਫਲ ਹੋਈ
410/2
205/1
24/0
241/2

ਇਹ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਨਤੀਜੇ ਵਜੋਂ ਸੈਟਿੰਗਾਂ ਆਪਣੀ ਸਾਰਥਕਤਾ ਨੂੰ ਗੁਆ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਜੈਕਟ ਵਧਦਾ ਹੈ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਲੌਗਸ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਹੈ. ਨਾਕਾਫ਼ੀ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਦਾ ਮੁੱਖ ਸੰਕੇਤ ਫਲੂਐਂਟ ਲੌਗ 'ਤੇ ਲੰਬੇ ਬਫ਼ਰ ਫਲੱਸ਼ ਬਾਰੇ ਸੁਨੇਹਿਆਂ ਦੀ ਵਾਪਸੀ ਹੈ, ਯਾਨੀ ਹੌਲੀ_ਫਲਸ਼_ਲੌਗ_ਥ੍ਰੈਸ਼ਹੋਲਡ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪਾਰ ਕਰਨਾ। ਇਸ ਬਿੰਦੂ ਤੋਂ, ਬੇਨਤੀ_ਟਾਈਮਆਉਟ ਪੈਰਾਮੀਟਰ ਨੂੰ ਪਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਜੇ ਵੀ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਮਾਰਜਿਨ ਹੈ, ਇਸ ਲਈ ਇਹਨਾਂ ਸੁਨੇਹਿਆਂ ਦਾ ਸਮੇਂ ਸਿਰ ਜਵਾਬ ਦੇਣਾ ਅਤੇ ਉੱਪਰ ਦੱਸੇ ਗਏ ਅਨੁਕੂਲ ਸੈਟਿੰਗਾਂ ਨੂੰ ਚੁਣਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਹਰਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ।

ਸਿੱਟਾ

Fluentd ਆਉਟਪੁੱਟ ਬਫਰ ਨੂੰ ਫਾਈਨ-ਟਿਊਨਿੰਗ EFK ਸਟੈਕ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਮੁੱਖ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸਦੇ ਸੰਚਾਲਨ ਦੀ ਸਥਿਰਤਾ ਅਤੇ ਸੂਚਕਾਂਕ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਸਹੀ ਪਲੇਸਮੈਂਟ ਦਾ ਪਤਾ ਲਗਾਉਣਾ। ਵਰਣਿਤ ਸੰਰਚਨਾ ਐਲਗੋਰਿਦਮ ਦੇ ਅਧਾਰ 'ਤੇ, ਤੁਸੀਂ ਨਿਸ਼ਚਤ ਹੋ ਸਕਦੇ ਹੋ ਕਿ ਸਾਰੇ ਲੌਗ ਦੁਹਰਾਓ ਜਾਂ ਨੁਕਸਾਨ ਦੇ ਬਿਨਾਂ, ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ElasticSearch ਇੰਡੈਕਸ ਵਿੱਚ ਲਿਖੇ ਜਾਣਗੇ।

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਹੋਰ ਲੇਖ ਵੀ ਪੜ੍ਹੋ:

• ਜਾਓ ਅਤੇ ਜ਼ੈਬਿਕਸ 5.0 ਦੋਸਤ ਬਣ ਗਏ
• ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ
• ਕੁਬਰਨੇਟਸ: ਸਿਸਟਮ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ?
• ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਸੁੰਗੜਨ ਲਈ ਤਿੰਨ ਸਧਾਰਨ ਟ੍ਰਿਕਸ
• ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਵਿਪਰੀਤ ਵੈੱਬ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਬੈਕਅੱਪ

ਸਰੋਤ: www.habr.com