Fluentd: ಔಟ್‌ಪುಟ್ ಬಫರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಏಕೆ ಮುಖ್ಯ

ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ELK ಸ್ಟಾಕ್ ಇಲ್ಲದೆ ಕುಬರ್ನೆಟ್ಸ್ ಆಧಾರಿತ ಯೋಜನೆಯನ್ನು ಕಲ್ಪಿಸುವುದು ಅಸಾಧ್ಯ, ಇದು ಕ್ಲಸ್ಟರ್‌ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ಘಟಕಗಳೆರಡರ ಲಾಗ್‌ಗಳನ್ನು ಉಳಿಸುತ್ತದೆ. ನಮ್ಮ ಅಭ್ಯಾಸದಲ್ಲಿ, ನಾವು Logstash ಬದಲಿಗೆ Fluentd ಜೊತೆಗೆ EFK ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

Fluentd ಆಧುನಿಕ, ಸಾರ್ವತ್ರಿಕ ಲಾಗ್ ಸಂಗ್ರಾಹಕವಾಗಿದ್ದು ಅದು ಹೆಚ್ಚು ಹೆಚ್ಚು ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸುತ್ತಿದೆ ಮತ್ತು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಕಂಪ್ಯೂಟಿಂಗ್ ಫೌಂಡೇಶನ್‌ಗೆ ಸೇರಿಕೊಂಡಿದೆ, ಅದಕ್ಕಾಗಿಯೇ ಅದರ ಅಭಿವೃದ್ಧಿ ವೆಕ್ಟರ್ ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆಯಲ್ಲಿ ಬಳಕೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದೆ.

Logstash ಬದಲಿಗೆ Fluentd ಅನ್ನು ಬಳಸುವ ಅಂಶವು ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಯಾಕೇಜ್‌ನ ಸಾಮಾನ್ಯ ಸಾರವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಆದಾಗ್ಯೂ, Fluentd ಅದರ ಬಹುಮುಖತೆಯ ಪರಿಣಾಮವಾಗಿ ತನ್ನದೇ ಆದ ನಿರ್ದಿಷ್ಟ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿಂದ ನಿರೂಪಿಸಲ್ಪಟ್ಟಿದೆ.

ಉದಾಹರಣೆಗೆ, ಲಾಗಿಂಗ್‌ನ ಹೆಚ್ಚಿನ ತೀವ್ರತೆಯೊಂದಿಗೆ ನಾವು ಬಿಡುವಿಲ್ಲದ ಯೋಜನೆಯಲ್ಲಿ EFK ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಕಿಬಾನಾದಲ್ಲಿ ಕೆಲವು ಸಂದೇಶಗಳನ್ನು ಹಲವಾರು ಬಾರಿ ಪದೇ ಪದೇ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ. ಈ ವಿದ್ಯಮಾನವು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು ಎಂದು ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ.

ಡಾಕ್ಯುಮೆಂಟ್ ನಕಲು ಸಮಸ್ಯೆ

ನಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ, Fluentd ಅನ್ನು DaemonSet ಆಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ (ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒಂದು ನಿದರ್ಶನದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ) ಮತ್ತು /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"

ವಿನಂತಿಯ_ಟೈಮ್‌ಔಟ್ ಪ್ಯಾರಾಮೀಟರ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಮಯದೊಳಗೆ ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಈ ಎಚ್ಚರಿಕೆಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಅದಕ್ಕಾಗಿಯೇ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಬಫರ್ ತುಣುಕನ್ನು ತೆರವುಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ. ಇದರ ನಂತರ, 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 ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಸಂದೇಶಗಳ ಪ್ರತಿಗಳು ಈ ರೀತಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.

ಕಿಬಾನಾದಲ್ಲಿ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ನಿವಾರಣೆ

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಹಲವಾರು ಆಯ್ಕೆಗಳಿವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಪ್ರತಿ ಡಾಕ್ಯುಮೆಂಟ್‌ಗೆ ವಿಶಿಷ್ಟವಾದ ಹ್ಯಾಶ್ ಅನ್ನು ಉತ್ಪಾದಿಸಲು ನಿರರ್ಗಳ-ಪ್ಲಗಿನ್-ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್ ಪ್ಲಗಿನ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ನೀವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿದರೆ, ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಹಂತದಲ್ಲಿ ಪುನರಾವರ್ತನೆಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ನಕಲಿ ದಾಖಲೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ಆದರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಈ ವಿಧಾನವು ತನಿಖೆಯೊಂದಿಗೆ ಹೋರಾಡುತ್ತದೆ ಮತ್ತು ಸಮಯಾವಧಿಯ ಕೊರತೆಯೊಂದಿಗೆ ದೋಷವನ್ನು ನಿವಾರಿಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಆದ್ದರಿಂದ ನಾವು ಅದರ ಬಳಕೆಯನ್ನು ತ್ಯಜಿಸಿದ್ದೇವೆ.

ಅಲ್ಪಾವಧಿಯ ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಹೆಚ್ಚಿದ ಲಾಗಿಂಗ್ ತೀವ್ರತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಲಾಗ್ ನಷ್ಟವನ್ನು ತಡೆಯಲು ನಾವು 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

ಇದರರ್ಥ ಬಫರ್ ನಿಗದಿಪಡಿಸಿದ ಸಮಯದಲ್ಲಿ ತೆರವುಗೊಳಿಸಲು ಸಮಯವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಪೂರ್ಣ ಬಫರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಡೇಟಾವನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ, ಇದು ಲಾಗ್ಗಳ ಭಾಗದ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ನೀವು ಬಫರ್ ಅನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚಿಸಬಹುದು: ಸರದಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಚಂಕ್‌ನ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಅಥವಾ ಸರದಿಯಲ್ಲಿರಬಹುದಾದ ತುಂಡುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ.

ನೀವು ಚಂಕ್ ಗಾತ್ರದ chunk_limit_size ಅನ್ನು 32 ಮೆಗಾಬೈಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಹೊಂದಿಸಿದರೆ, ಒಳಬರುವ ಪ್ಯಾಕೆಟ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿರುವುದರಿಂದ ElasticSeacrh ಅದನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನೀವು ಬಫರ್ ಅನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸಬೇಕಾದರೆ, ಗರಿಷ್ಠ ಕ್ಯೂ ಉದ್ದ ಕ್ಯೂ_ಲಿಮಿಟ್_ಲೆಂಗ್ತ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು ಉತ್ತಮ.

ಬಫರ್ ಉಕ್ಕಿ ಹರಿಯುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಮತ್ತು ಸಮಯ ಮೀರಿದ ಸಂದೇಶವು ಸಾಕಾಗದೇ ಉಳಿದಿರುವಾಗ, ನೀವು 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 ಪ್ಯಾರಾಮೀಟರ್‌ನಿಂದ ಹೊಂದಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದರ್ಥ. ಇದು ಡೀಬಗ್ ಮಾಡುವ ಮಾಹಿತಿಯಾಗಿದೆ ಮತ್ತು ವಿನಂತಿ_ಟೈಮ್‌ಔಟ್ ಪ್ಯಾರಾಮೀಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ.

ಸಾಮಾನ್ಯ ಆಯ್ಕೆಯ ಅಲ್ಗಾರಿದಮ್ ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:

1. ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸಿದ ಮೌಲ್ಯಕ್ಕೆ ವಿನಂತಿ_ಟೈಮ್‌ಔಟ್ ಅನ್ನು ಹೊಂದಿಸಿ (ನೂರಾರು ಸೆಕೆಂಡುಗಳು). ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ, ಈ ಪ್ಯಾರಾಮೀಟರ್ನ ಸರಿಯಾದ ಸೆಟ್ಟಿಂಗ್ಗೆ ಮುಖ್ಯ ಮಾನದಂಡವೆಂದರೆ ಸಮಯಾವಧಿಯ ಕೊರತೆಯಿಂದಾಗಿ ಎಚ್ಚರಿಕೆಗಳ ಕಣ್ಮರೆಯಾಗುವುದು.
2. ನಿಧಾನ_ಫ್ಲಶ್_ಲಾಗ್_ಥ್ರೆಶೋಲ್ಡ್ ಮಿತಿಯನ್ನು ಮೀರುವ ಸಂದೇಶಗಳಿಗಾಗಿ ನಿರೀಕ್ಷಿಸಿ. elapsed_time ಕ್ಷೇತ್ರದಲ್ಲಿರುವ ಎಚ್ಚರಿಕೆ ಪಠ್ಯವು ಬಫರ್ ಅನ್ನು ತೆರವುಗೊಳಿಸಿದ ನೈಜ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತದೆ.
3. ವೀಕ್ಷಣಾ ಅವಧಿಯಲ್ಲಿ ಪಡೆದ ಗರಿಷ್ಟ ಎಲ್ಯಾಪ್ಸ್ಡ್_ಟೈಮ್ ಮೌಲ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೌಲ್ಯಕ್ಕೆ ವಿನಂತಿ_ಟೈಮ್ಔಟ್ ಅನ್ನು ಹೊಂದಿಸಿ. ನಾವು ವಿನಂತಿ_ಸಮಯ ಮೀರುವ ಮೌಲ್ಯವನ್ನು elapsed_time + 50% ಎಂದು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ.
4. ಲಾಗ್‌ನಿಂದ ದೀರ್ಘವಾದ ಬಫರ್ ಫ್ಲಶ್‌ಗಳ ಕುರಿತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ತೆಗೆದುಹಾಕಲು, ನೀವು slow_flush_log_threshold ನ ಮೌಲ್ಯವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ನಾವು ಈ ಮೌಲ್ಯವನ್ನು elapsed_time + 25% ಎಂದು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ.

ಈ ನಿಯತಾಂಕಗಳ ಅಂತಿಮ ಮೌಲ್ಯಗಳನ್ನು, ಮೊದಲೇ ಗಮನಿಸಿದಂತೆ, ಪ್ರತಿಯೊಂದು ಪ್ರಕರಣಕ್ಕೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಪಡೆಯಲಾಗುತ್ತದೆ. ಮೇಲಿನ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ, ಪುನರಾವರ್ತಿತ ಸಂದೇಶಗಳಿಗೆ ಕಾರಣವಾಗುವ ದೋಷವನ್ನು ತೆಗೆದುಹಾಕಲು ನಮಗೆ ಭರವಸೆ ಇದೆ.

ಕೆಳಗಿನ ಕೋಷ್ಟಕವು ದಿನಕ್ಕೆ ದೋಷಗಳ ಸಂಖ್ಯೆಯು ಸಂದೇಶಗಳ ನಕಲುಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಮೇಲೆ ವಿವರಿಸಿದ ನಿಯತಾಂಕಗಳ ಮೌಲ್ಯಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ:

ನೋಡ್-1
ನೋಡ್-2
ನೋಡ್-3
ನೋಡ್-4

ನಂತರ ಮೊದಲು
ನಂತರ ಮೊದಲು
ನಂತರ ಮೊದಲು
ನಂತರ ಮೊದಲು

ಬಫರ್ ಅನ್ನು ಫ್ಲಶ್ ಮಾಡಲು ವಿಫಲವಾಗಿದೆ
1749/2
694/2
47/0
1121/2

ಮರುಪ್ರಯತ್ನ ಯಶಸ್ವಿಯಾಯಿತು
410/2
205/1
24/0
241/2

ಯೋಜನೆಯು ಬೆಳೆದಂತೆ ಪರಿಣಾಮವಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ತಮ್ಮ ಪ್ರಸ್ತುತತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಲಾಗ್‌ಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂದು ಹೆಚ್ಚುವರಿಯಾಗಿ ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ. ಸಾಕಷ್ಟು ಸಮಯ ಮೀರುವಿಕೆಯ ಪ್ರಾಥಮಿಕ ಸಂಕೇತವೆಂದರೆ ಫ್ಲುಯೆಂಟ್ ಲಾಗ್‌ಗೆ ದೀರ್ಘವಾದ ಬಫರ್ ಫ್ಲಶ್‌ನ ಸಂದೇಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವುದು, ಅಂದರೆ, ನಿಧಾನ_ಫ್ಲಶ್_ಲಾಗ್_ಥ್ರೆಶೋಲ್ಡ್ ಮಿತಿಯನ್ನು ಮೀರುವುದು. ಈ ಹಂತದಿಂದ, ವಿನಂತಿಯ_ಟೈಮ್‌ಔಟ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಮೀರುವ ಮೊದಲು ಇನ್ನೂ ಸಣ್ಣ ಅಂಚು ಇದೆ, ಆದ್ದರಿಂದ ಈ ಸಂದೇಶಗಳಿಗೆ ಸಮಯೋಚಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದ ಸೂಕ್ತ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

Fluentd ಔಟ್‌ಪುಟ್ ಬಫರ್ ಅನ್ನು ಫೈನ್-ಟ್ಯೂನಿಂಗ್ ಮಾಡುವುದು EFK ಸ್ಟಾಕ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಮುಖ್ಯ ಹಂತಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿರತೆ ಮತ್ತು ಸೂಚ್ಯಂಕಗಳಲ್ಲಿ ದಾಖಲೆಗಳ ಸರಿಯಾದ ನಿಯೋಜನೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ವಿವರಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಧರಿಸಿ, ಎಲ್ಲಾ ಲಾಗ್‌ಗಳನ್ನು ಪುನರಾವರ್ತನೆಗಳು ಅಥವಾ ನಷ್ಟಗಳಿಲ್ಲದೆ ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ElasticSearch ಸೂಚ್ಯಂಕಕ್ಕೆ ಬರೆಯಲಾಗುವುದು ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ಹೇಳಬಹುದು.

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:

• ಹೋಗಿ ಮತ್ತು Zabbix 5.0 ಸ್ನೇಹಿತರಾದರು
• ಡೌನ್‌ಟೈಮ್ ಇಲ್ಲದೆ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ
• ಕುಬರ್ನೆಟ್ಸ್: ಸಿಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆಯನ್ನು ಹೊಂದಿಸುವುದು ಏಕೆ ಮುಖ್ಯ?
• ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ಕುಗ್ಗಿಸಲು ಮೂರು ಸರಳ ತಂತ್ರಗಳು
• ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವೈವಿಧ್ಯಮಯ ವೆಬ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಬ್ಯಾಕಪ್

ಮೂಲ: www.habr.com