ፕሮሆስተር > ጦማር > አስተዳደር > ፍሉንትድ፡ ለምንድነው የውጤት ቋቱን ማዋቀር አስፈላጊ የሆነው

ፍሉንትድ፡ ለምንድነው የውጤት ቋቱን ማዋቀር አስፈላጊ የሆነው

ፍሉንትድ፡ ለምንድነው የውጤት ቋቱን ማዋቀር አስፈላጊ የሆነው

በአሁኑ ጊዜ፣ የሁለቱም አፕሊኬሽኖች እና የክላስተር የስርዓት ክፍሎችን ምዝግብ ማስታወሻዎች የሚያስቀምጥ የ ELK ቁልል ከሌለ በኩበርኔትስ ላይ የተመሠረተ ፕሮጀክት መገመት አይቻልም። በእኛ ልምምድ፣ ከሎግስታሽ ይልቅ የEFK ቁልል ከ Fluentd ጋር እንጠቀማለን።

ፍሉንትድ ከጊዜ ወደ ጊዜ ተወዳጅነትን እያገኘ የመጣ እና የ Cloud Native Computing ፋውንዴሽን የተቀላቀለው ዘመናዊ፣ ሁለንተናዊ ሎግ ሰብሳቢ ነው፣ ለዚህም ነው የልማቱ ቬክተር ከኩበርኔትስ ጋር በጥምረት ጥቅም ላይ ያተኮረው።

ከሎግስታሽ ይልቅ ፍሉንትድን የመጠቀም እውነታ የሶፍትዌር ፓኬጁን አጠቃላይ ይዘት አይለውጠውም ፣ ሆኖም ፣ ፍሉንትድ በተለዋዋጭነቱ ምክንያት የራሱ ልዩ ልዩነቶች ተለይቶ ይታወቃል።

ለምሳሌ፣ EFKን መጠቀም በጀመርንበት ወቅት ከፍተኛ መጠን ያለው የዛፍ እንጨት በተጨናነቀ ፕሮጀክት ውስጥ፣ በኪባና ውስጥ አንዳንድ መልእክቶች ብዙ ጊዜ ደጋግመው መታየታቸውን አጋጥሞናል። በዚህ ጽሑፍ ውስጥ ይህ ክስተት ለምን እንደተከሰተ እና ችግሩን እንዴት እንደሚፈታ እንነግርዎታለን.

የሰነድ ማባዛት ችግር

በፕሮጀክቶቻችን ውስጥ፣ Fluentd እንደ DaemonSet (በእያንዳንዱ የኩበርኔትስ ክላስተር መስቀለኛ መንገድ በራስ-ሰር ተጀምሯል) እና በ /var/log/containers ውስጥ የ stdout ኮንቴይነር ምዝግብ ማስታወሻዎችን ይከታተላል። ከተሰበሰበ እና ከተሰራ በኋላ፣ በJSON ሰነዶች መልክ ያሉ ምዝግብ ማስታወሻዎች ወደ ElasticSearch ይላካሉ፣ በክላስተር ወይም በተናጥል ፎርም የተነሱ፣ እንደ ፕሮጀክቱ መጠን እና ለአፈጻጸም እና ለስህተት መቻቻል በሚያስፈልጉት መስፈርቶች ላይ በመመስረት። ኪባና እንደ ግራፊክ በይነገጽ ጥቅም ላይ ይውላል.

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 መስክ እሴቶችን ይመድባቸዋል። የመልእክቶች ቅጂዎች የሚታዩት በዚህ መንገድ ነው።

በኪባና ይህን ይመስላል፡-

ፍሉንትድ፡ ለምንድነው የውጤት ቋቱን ማዋቀር አስፈላጊ የሆነው

መላ መፈለግ

ይህንን ችግር ለመፍታት ብዙ አማራጮች አሉ. ከመካከላቸው አንዱ ለእያንዳንዱ ሰነድ ልዩ የሆነ ሃሽ ለመፍጠር በፍሉዌን-ፕለጊን-ላስቲክ ፍለጋ ተሰኪ ውስጥ የተገነባው ዘዴ ነው። ይህን ዘዴ ከተጠቀሙ፣ 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 መካከል ያለው ግንኙነት የተመሰረተበት ጊዜ ነው።

የጠቅላላው የቋት መጠን መለኪያዎች ወረፋ_limit_ርዝማኔ እና 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 አይቀበለውም። ስለዚህ፣ ቋቱን የበለጠ መጨመር ካስፈለገዎት ከፍተኛውን የወረፋ ርዝመት ወረፋ_limit_ርዝመት መጨመር የተሻለ ነው።

ቋት መሙላቱን ሲያቆም እና ጊዜው ያለፈበት በቂ ያልሆነ መልእክት ሲቀር፣ የጥያቄ_ጊዜ ማብቂያ መለኪያውን መጨመር መጀመር ይችላሉ። ነገር ግን እሴቱን ከ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. የዝግተኛ_flush_log_threshold ገደብን ስለበለጠ መልእክት ይጠብቁ። በባለፈው_ጊዜ መስክ ላይ ያለው የማስጠንቀቂያ ጽሁፍ ቋቱ የተጸዳበትን ትክክለኛ ጊዜ ያሳያል።
  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 ምዝግብ ማስታወሻው ረጅም ቋት ፍሰትን የሚመለከቱ መልዕክቶችን መመለስ ነው፣ ይህም ከ slow_flush_log_threshold ጣራ ይበልጣል። ከዚህ ጊዜ ጀምሮ የጥያቄ_ጊዜ ገደብ መለኪያው ከመተላለፉ በፊት ትንሽ ህዳግ አለ ስለዚህ ለእነዚህ መልእክቶች በወቅቱ ምላሽ መስጠት እና ከላይ የተገለጹትን ምርጥ መቼቶች የመምረጥ ሂደቱን መድገም ያስፈልጋል።

መደምደሚያ

የ Fluentd ውፅዓት ቋት በጥሩ ሁኔታ ማስተካከል የ EFK ቁልል የማዋቀር ዋና ደረጃዎች አንዱ ነው ፣ የአሠራሩን መረጋጋት እና የሰነዶች ትክክለኛ አቀማመጥ በመረጃ ጠቋሚዎች ውስጥ። በተገለጸው የውቅረት ስልተ-ቀመር መሰረት, ሁሉም ምዝግብ ማስታወሻዎች ወደ ElasticSearch ኢንዴክስ በትክክለኛ ቅደም ተከተል, ያለ ድግግሞሽ እና ኪሳራ እንደሚፃፉ እርግጠኛ መሆን ይችላሉ.

በብሎጋችን ላይ ሌሎች ጽሑፎችን ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ