சரளமாக: வெளியீட்டு இடையகத்தை உள்ளமைப்பது ஏன் முக்கியம்

இப்போதெல்லாம், 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"

Request_timeout அளவுருவால் குறிப்பிடப்பட்ட நேரத்திற்குள் 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"

எவ்வாறாயினும், எலாஸ்டிக் தேடல் மாற்றப்பட்ட இடையகத் துண்டுகள் ஒவ்வொன்றையும் தனித்தன்மை வாய்ந்ததாகக் கருதுகிறது மற்றும் அட்டவணைப்படுத்தலின் போது அவற்றிற்கு தனித்துவமான _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

ஒதுக்கப்பட்ட நேரத்தில் இடையகத்தை அழிக்க நேரம் இல்லை மற்றும் முழு இடையகத்திற்குள் நுழையும் தரவு தடுக்கப்பட்டுள்ளது, இது பதிவுகளின் ஒரு பகுதியை இழக்க வழிவகுக்கும்.

நீங்கள் இரண்டு வழிகளில் இடையகத்தை அதிகரிக்கலாம்: வரிசையில் உள்ள ஒவ்வொரு துண்டின் அளவையும் அல்லது வரிசையில் இருக்கக்கூடிய துண்டுகளின் எண்ணிக்கையையும் அதிகரிப்பதன் மூலம்.

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" 

இந்தச் செய்தியானது கணினியின் செயல்பாட்டை எந்த வகையிலும் பாதிக்காது, மேலும் மெதுவாக_flush_log_threshold அளவுருவால் அமைக்கப்பட்டதை விட இடையக ஃப்ளஷ் நேரம் அதிக நேரம் எடுத்தது. இது பிழைத்திருத்தத் தகவல் மற்றும் கோரிக்கை_நேரமுடிவு அளவுருவின் மதிப்பைத் தேர்ந்தெடுக்கும்போது அதைப் பயன்படுத்துவோம்.

பொதுவான தேர்வு அல்காரிதம் பின்வருமாறு:

1. கோரிக்கை_நேரமுடிவைத் தேவையானதை விட அதிகமாக இருக்கும் (நூற்றுக்கணக்கான வினாடிகள்) மதிப்பிற்கு அமைக்கவும். அமைப்பின் போது, ​​இந்த அளவுருவின் சரியான அமைப்பிற்கான முக்கிய அளவுகோல் நேரமின்மைக்கான எச்சரிக்கைகள் காணாமல் போகும்.
2. slow_flush_log_threshold வரம்பை மீறுவது பற்றிய செய்திகளுக்காக காத்திருக்கவும். 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 பதிவிற்குத் திரும்பச் செய்வதாகும், அதாவது slow_flush_log_threshold வரம்பைத் தாண்டியது. இந்தக் கட்டத்தில் இருந்து, request_timeout அளவுருவை மீறுவதற்கு முன் இன்னும் ஒரு சிறிய அளவு உள்ளது, எனவே இந்த செய்திகளுக்கு சரியான நேரத்தில் பதிலளிக்கவும், மேலே விவரிக்கப்பட்ட உகந்த அமைப்புகளைத் தேர்ந்தெடுக்கும் செயல்முறையை மீண்டும் செய்யவும்.

முடிவுக்கு

Fluentd வெளியீட்டு இடையகத்தை நன்றாகச் சரிசெய்வது EFK அடுக்கை உள்ளமைக்கும் முக்கிய கட்டங்களில் ஒன்றாகும், அதன் செயல்பாட்டின் நிலைத்தன்மையையும் குறியீடுகளில் ஆவணங்களின் சரியான இடத்தையும் தீர்மானிக்கிறது. விவரிக்கப்பட்ட உள்ளமைவு வழிமுறையின் அடிப்படையில், அனைத்து பதிவுகளும் மீண்டும் மீண்டும் அல்லது இழப்புகள் இல்லாமல் சரியான வரிசையில் ElasticSearch குறியீட்டில் எழுதப்படும் என்பதை நீங்கள் உறுதியாக நம்பலாம்.

எங்கள் வலைப்பதிவில் உள்ள மற்ற கட்டுரைகளையும் படிக்கவும்:

• Go மற்றும் Zabbix 5.0 நண்பர்கள் ஆனது
• வேலையில்லா நேரம் இல்லாமல் குபெர்னெட்ஸ் கிளஸ்டரை மேம்படுத்துகிறது
• குபெர்னெட்ஸ்: கணினி வள நிர்வாகத்தை உள்ளமைப்பது ஏன் மிகவும் முக்கியமானது?
• டோக்கர் படங்களை சுருக்க மூன்று எளிய தந்திரங்கள்
• ஏராளமான பன்முக வலைத் திட்டங்களின் காப்புப்பிரதி

ஆதாரம்: www.habr.com