ProHoster > blog > Utawala > Fasaha: Kwa nini ni muhimu kusanidi bafa ya pato

Fasaha: Kwa nini ni muhimu kusanidi bafa ya pato

Fasaha: Kwa nini ni muhimu kusanidi bafa ya pato

Siku hizi, haiwezekani kufikiria mradi wa msingi wa Kubernetes bila stack ya ELK, ambayo huhifadhi kumbukumbu za programu zote mbili na vipengele vya mfumo wa nguzo. Katika mazoezi yetu, tunatumia rafu ya EFK iliyo na Fluentd badala ya Logstash.

Fluentd ni mkusanyaji wa kisasa wa kumbukumbu ulimwenguni kote ambaye anapata umaarufu zaidi na zaidi na amejiunga na Wakfu wa Cloud Native Computing, ndiyo maana vekta yake ya ukuzaji inalenga matumizi kwa kushirikiana na Kubernetes.

Ukweli wa kutumia Fluentd badala ya Logstash haibadilishi kiini cha jumla cha kifurushi cha programu, hata hivyo, Fluentd ina sifa ya nuances yake maalum inayotokana na uhodari wake.

Kwa mfano, tulipoanza kutumia EFK katika mradi wenye shughuli nyingi na nguvu ya juu ya ukataji miti, tulikabiliwa na ukweli kwamba huko Kibana baadhi ya ujumbe ulionyeshwa mara kwa mara. Katika makala hii tutakuambia kwa nini jambo hili hutokea na jinsi ya kutatua tatizo.

Tatizo la kurudia hati

Katika miradi yetu, Fluentd inatumwa kama DaemonSet (ilizinduliwa kiotomatiki katika mfano mmoja kwenye kila nodi ya nguzo ya Kubernetes) na inafuatilia kumbukumbu za kontena za stdout katika /var/log/containers. Baada ya kukusanya na kuchakata, kumbukumbu katika mfumo wa hati za JSON hutumwa kwa ElasticSearch, zikiwa zimeinuliwa katika makundi au fomu ya kujitegemea, kulingana na ukubwa wa mradi na mahitaji ya utendakazi na uvumilivu wa hitilafu. Kibana inatumika kama kiolesura cha picha.

Wakati wa kutumia Fluentd na programu-jalizi ya kuakibisha pato, tulikumbana na hali ambapo baadhi ya hati katika ElasticSearch zilikuwa na maudhui sawa kabisa na zilitofautiana katika kitambulishi pekee. Unaweza kuthibitisha kuwa hii ni marudio ya ujumbe kwa kutumia logi ya Nginx kama mfano. Katika faili ya kumbukumbu, ujumbe huu upo katika nakala moja:

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

Walakini, kuna hati kadhaa katika ElasticSearch ambazo zina ujumbe huu:

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

Aidha, kunaweza kuwa na marudio zaidi ya mawili.

Unaporekebisha tatizo hili kwenye kumbukumbu za Fluentd, unaweza kuona idadi kubwa ya maonyo yenye maudhui yafuatayo:

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"

Maonyo haya hutokea wakati ElasticSearch haiwezi kurudisha jibu la ombi ndani ya muda uliobainishwa na kigezo cha request_timeout, ndiyo maana kipande cha bafa kilichosambazwa hakiwezi kufutwa. Baada ya hayo, Fluentd inajaribu kutuma kipande cha bafa kwa ElasticSearch tena na baada ya idadi kiholela ya majaribio, operesheni inakamilika kwa mafanikio:

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"

Hata hivyo, ElasticSearch huchukulia kila vipande vya bafa vilivyohamishwa kuwa vya kipekee na huvipa _id thamani za uga za kipekee wakati wa kuorodhesha. Hivi ndivyo nakala za ujumbe zinavyoonekana.

Katika Kibana inaonekana kama hii:

Fasaha: Kwa nini ni muhimu kusanidi bafa ya pato

ufumbuzi

Kuna chaguzi kadhaa za kutatua tatizo hili. Mojawapo ni utaratibu uliojengwa kwenye programu-jalizi ya ufasaha-programu-jalizi-elasticsearch kwa ajili ya kutoa heshi ya kipekee kwa kila hati. Ukitumia utaratibu huu, ElasticSearch itatambua marudio katika hatua ya usambazaji na kuzuia nakala za hati. Lakini tunapaswa kuzingatia kwamba njia hii ya kutatua shida inajitahidi na uchunguzi na haiondoi kosa kwa ukosefu wa muda, kwa hiyo tuliacha matumizi yake.

Tunatumia programu-jalizi ya kuakibisha kwenye pato la Fluentd ili kuzuia upotevu wa kumbukumbu iwapo kutatokea matatizo ya muda mfupi ya mtandao au kuongezeka kwa kasi ya ukataji miti. Ikiwa kwa sababu fulani ElasticSearch haiwezi kuandika hati mara moja kwa index, waraka huo umewekwa kwenye foleni na kuhifadhiwa kwenye diski. Kwa hivyo, kwa upande wetu, ili kuondoa chanzo cha shida inayosababisha kosa lililoelezwa hapo juu, ni muhimu kuweka maadili sahihi kwa vigezo vya buffering, ambayo buffer ya pato la Fluentd itakuwa ya ukubwa wa kutosha na. wakati huo huo kusimamia kusafishwa kwa wakati uliowekwa.

Inafaa kumbuka kuwa maadili ya vigezo vilivyojadiliwa hapa chini ni vya mtu binafsi katika kila kesi maalum ya kutumia buffering katika programu-jalizi za pato, kwani zinategemea mambo mengi: ukubwa wa kuandika ujumbe kwa logi na huduma, utendaji wa mfumo wa diski, mtandao. upakiaji wa kituo na kipimo data chake. Kwa hivyo, ili kupata mipangilio ya bafa ambayo inafaa kwa kila kesi ya mtu binafsi, lakini sio ya ziada, kuzuia utafutaji wa muda mrefu kwa upofu, unaweza kutumia maelezo ya utatuzi ambayo Fluentd huandika kwenye logi yake wakati wa operesheni na kupata maadili sahihi kwa haraka.

Wakati tatizo lilirekodiwa, usanidi ulionekana kama hii:

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

Wakati wa kutatua shida, maadili ya vigezo vifuatavyo vilichaguliwa kwa mikono:
chunk_limit_size - ukubwa wa vipande ambavyo ujumbe katika bafa umegawanywa.

  • flush_interval - muda wa muda ambao bafa huondolewa.
  • queue_limit_length - idadi ya juu zaidi ya vipande kwenye foleni.
  • request_timeout ni wakati ambapo muunganisho kati ya Fluentd na ElasticSearch unaanzishwa.

Ukubwa wa jumla wa bafa unaweza kuhesabiwa kwa kuzidisha vigezo queue_limit_length na chunk_limit_size, ambayo inaweza kufasiriwa kama "idadi ya juu zaidi ya vipande kwenye foleni, ambavyo kila kimoja kina ukubwa fulani." Ikiwa saizi ya bafa haitoshi, onyo lifuatalo litaonekana kwenye kumbukumbu:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

Ina maana kwamba bafa haina muda wa kufutwa katika muda uliowekwa na data inayoingia kwenye bafa kamili imezuiwa, ambayo itasababisha upotevu wa sehemu ya kumbukumbu.

Unaweza kuongeza bafa kwa njia mbili: kwa kuongeza ukubwa wa kila kipande kwenye foleni, au idadi ya vipande vinavyoweza kuwa kwenye foleni.

Ukiweka ukubwa wa chunk_limit_size kuwa zaidi ya megabaiti 32, basi ElasticSeacrh haitakubali, kwa kuwa pakiti inayoingia itakuwa kubwa sana. Kwa hivyo, ikiwa unahitaji kuongeza bafa zaidi, ni bora kuongeza urefu wa juu wa foleni_limit_length.

Wakati bafa inapoacha kufurika na ujumbe ambao hautoshi umeisha tu, unaweza kuanza kuongeza kigezo cha request_timeout. Hata hivyo, ukiweka thamani kwa zaidi ya sekunde 20, maonyo yafuatayo yataanza kuonekana kwenye kumbukumbu za 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"

Ujumbe huu hauathiri utendakazi wa mfumo kwa njia yoyote ile na inamaanisha kuwa muda wa kufichua bafa ulichukua muda mrefu kuliko ulivyowekwa na kigezo cha slow_flush_log_threshold. Haya ni maelezo ya utatuzi na tunayatumia tunapochagua thamani ya kigezo cha request_timeout.

Algorithm ya uteuzi wa jumla ni kama ifuatavyo.

  1. Weka request_timeout kwa thamani iliyohakikishwa kuwa kubwa kuliko inavyohitajika (mamia ya sekunde). Wakati wa kuanzisha, kigezo kuu cha kuweka sahihi ya parameter hii itakuwa kutoweka kwa maonyo kwa ukosefu wa muda.
  2. Subiri ujumbe kuhusu kuzidi kizingiti cha slow_flush_log_threshold. Maandishi ya onyo katika uga wa elapsed_time yataonyesha muda halisi ambapo bafa ilifutwa.
  3. Weka request_timeout kwa thamani kubwa zaidi ya upeo wa juu wa thamani uliyopita uliopatikana katika kipindi cha uchunguzi. Tunakokotoa thamani ya request_timeout kama ilipita_time + 50%.
  4. Ili kuondoa maonyo kuhusu umiminiko wa bafa ndefu kutoka kwenye logi, unaweza kuongeza thamani ya slow_flush_log_threshold. Tunakokotoa thamani hii kama muda_uliopita + 25%.

Maadili ya mwisho ya vigezo hivi, kama ilivyoonyeshwa hapo awali, hupatikana kila mmoja kwa kila kesi. Kwa kufuata algorithm hapo juu, tumehakikishiwa kuondoa hitilafu ambayo husababisha ujumbe unaorudiwa.

Jedwali hapa chini linaonyesha jinsi idadi ya makosa kwa siku, na kusababisha kurudia kwa ujumbe, mabadiliko katika mchakato wa kuchagua maadili ya vigezo vilivyoelezwa hapo juu:

nodi-1
nodi-2
nodi-3
nodi-4

Kabla baada
Kabla baada
Kabla baada
Kabla baada

imeshindwa kufuta bafa
1749/2
694/2
47/0
1121/2

kujaribu tena kumefaulu
410/2
205/1
24/0
241/2

Inafaa pia kuzingatia kuwa mipangilio inayosababisha inaweza kupoteza umuhimu wao wakati mradi unakua na, ipasavyo, idadi ya magogo huongezeka. Ishara ya msingi ya kuisha kwa muda hautoshi ni urejeshaji wa ujumbe kuhusu kibadilishaji kihifadhi kirefu kwenye logi ya Fluentd, yaani, kuzidi kizingiti_cha_logi_ya polepole. Kuanzia wakati huu, bado kuna ukingo mdogo kabla ya parameter ya request_timeout kupitishwa, kwa hiyo ni muhimu kujibu ujumbe huu kwa wakati unaofaa na kurudia mchakato wa kuchagua mipangilio bora iliyoelezwa hapo juu.

Hitimisho

Kurekebisha vyema bafa ya pato la Fluentd ni mojawapo ya hatua kuu za kusanidi mrundikano wa EFK, kuamua uthabiti wa uendeshaji wake na uwekaji sahihi wa hati katika faharasa. Kulingana na algoriti ya usanidi iliyoelezwa, unaweza kuwa na uhakika kwamba kumbukumbu zote zitaandikwa kwa faharasa ya ElasticSearch kwa mpangilio sahihi, bila marudio au hasara.

Pia soma nakala zingine kwenye blogi yetu:

Chanzo: mapenzi.com

Kuongeza maoni