ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች

2019 ነው፣ እና አሁንም በኩበርኔትስ ውስጥ ለሎግ ማሰባሰብ መደበኛ መፍትሄ የለንም። በዚህ ጽሑፍ ውስጥ፣ ከእውነተኛ ልምምድ ምሳሌዎችን በመጠቀም ፍለጋዎቻችንን፣ ያጋጠሙ ችግሮችን እና መፍትሄዎቻቸውን ለማካፈል እንፈልጋለን።

ነገር ግን፣ መጀመሪያ፣ የተለያዩ ደንበኞች የምዝግብ ማስታወሻዎችን በመሰብሰብ በጣም የተለያዩ ነገሮችን እንዲረዱ የሚያስችል ቦታ አዘጋጃለሁ።

  • አንድ ሰው የደህንነት እና የኦዲት ምዝግብ ማስታወሻዎችን ማየት ይፈልጋል;
  • አንድ ሰው - የመሠረተ ልማት ማእከላዊ ምዝግብ ማስታወሻ;
  • እና ለአንዳንዶች የመተግበሪያ ምዝግብ ማስታወሻዎችን ብቻ መሰብሰብ በቂ ነው, ለምሳሌ, ሚዛን ሰጭዎችን ሳይጨምር.

ከዚህ በታች የተለያዩ "የምኞት ዝርዝሮችን" እንዴት እንደተገበርን እና ምን ችግሮች እንዳጋጠሙን ከዚህ በታች ቀርቧል።

ጽንሰ-ሐሳብ: ስለ መዝገቦች መሳሪያዎች

በመዝገብ ስርዓት አካላት ላይ ዳራ

የምዝግብ ማስታወሻዎች ረጅም መንገድ ተጉዘዋል, በዚህ ምክንያት የምዝግብ ማስታወሻዎችን ለመሰብሰብ እና ለመተንተን የትኞቹ ዘዴዎች ተዘጋጅተዋል, ይህም ዛሬ የምንጠቀመው ነው. እ.ኤ.አ. በ1950ዎቹ ውስጥ፣ ፎርትራን መደበኛ የግብዓት/ውጤት ዥረቶችን አናሎግ አስተዋወቀ፣ ይህም ፕሮግራመር ፕሮግራሙን እንዲያርመው ረድቶታል። በእነዚያ ጊዜያት ለነበሩ ፕሮግራመሮች ሕይወትን ቀላል ያደረጉት እነዚህ የመጀመሪያዎቹ የኮምፒዩተር ምዝግብ ማስታወሻዎች ናቸው። ዛሬ በእነሱ ውስጥ የሎግ ስርዓቱን የመጀመሪያ አካል እናያለን - የምዝግብ ማስታወሻዎች ምንጭ ወይም "አምራች"..

የኮምፒዩተር ሳይንስ አሁንም አልቆመም: የኮምፒዩተር ኔትወርኮች ታዩ, የመጀመሪያዎቹ ዘለላዎች ... በርካታ ኮምፒውተሮችን ያቀፉ ውስብስብ ስርዓቶች መስራት ጀመሩ. አሁን የስርዓት አስተዳዳሪዎች ከበርካታ ማሽኖች ምዝግብ ማስታወሻዎችን እንዲሰበስቡ ተገድደዋል፣ እና በልዩ ሁኔታዎች የስርዓት ውድቀትን ለመመርመር ከፈለጉ የ OS kernel መልዕክቶችን ማከል ይችላሉ። የተማከለ የምዝግብ ማስታወሻ አሰባሰብ ስርዓቶችን ለመግለጽ በ2000ዎቹ መጀመሪያ ላይ ታትሟል RFC 3164የርቀት_syslog ደረጃውን የጠበቀ። ሌላ አስፈላጊ አካል የሚታየው በዚህ መንገድ ነው- ሎግ ሰብሳቢ እና ማከማቻቸው።

የምዝግብ ማስታወሻዎች መጠን መጨመር እና የድረ-ገጽ ቴክኖሎጂዎች በስፋት ሲገቡ, የምዝግብ ማስታወሻዎች ለተጠቃሚዎች ምቹ በሆነ ሁኔታ መታየት ያለባቸው ምን ጥያቄዎች ተነሳ. ቀላል የኮንሶል መሳሪያዎች (awk/sed/grep) በበለጠ የላቁ ተተክተዋል። የምዝግብ ማስታወሻ ተመልካቾች - ሦስተኛው አካል.

የምዝግብ ማስታወሻዎች መጠን በመጨመሩ ሌላ ነገር ግልጽ ሆነ-ምዝግብ ማስታወሻዎች ያስፈልጋሉ, ግን ሁሉም አይደሉም. እና የተለያዩ ምዝግብ ማስታወሻዎች የተለያዩ የጥበቃ ደረጃዎች ያስፈልጋቸዋል: አንዳንዶቹ በአንድ ቀን ውስጥ ሊጠፉ ይችላሉ, ሌሎች ደግሞ ለ 5 ዓመታት ማከማቸት አለባቸው. ስለዚህ የውሂብ ፍሰቶችን ለማጣራት እና ለማዛወር አንድ አካል ወደ መዝገቡ ስርዓት ተጨምሯል - እንጥራው። ማጣሪያ.

ማከማቻ እንዲሁ ትልቅ ዝላይ አድርጓል፡ ከመደበኛ ፋይሎች ወደ ተዛማጅ የውሂብ ጎታዎች፣ እና ከዚያም ወደ ሰነድ-ተኮር ማከማቻ (ለምሳሌ፣ Elasticsearch)። ስለዚህ ማከማቻው ከአሰባሳቢው ተለይቷል.

በመጨረሻ፣ የሎግ ጽንሰ-ሐሳብ ወደ አንድ ረቂቅ የክስተት ጅረት ተስፋፍቷል ለታሪክ ልናቆየው ወደምንፈልገው። ወይም ይልቁንስ ምርመራ ለማካሄድ ወይም የትንታኔ ዘገባ ለማዘጋጀት ከፈለጉ...

በውጤቱም፣ በአንጻራዊ ሁኔታ በአጭር ጊዜ ውስጥ፣ የምዝግብ ማስታወሻዎች መሰብሰብ ወደ አንድ አስፈላጊ ንዑስ ስርዓት አድጓል፣ እሱም በትክክል በትልቁ ዳታ ውስጥ ካሉት ንዑስ ክፍሎች ውስጥ አንዱ ሊባል ይችላል።

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች
አንድ ጊዜ ተራ ህትመቶች ለ "ሎግ ስርዓት" በቂ ሊሆኑ ከቻሉ አሁን ሁኔታው ​​በጣም ተለውጧል.

Kubernetes እና ምዝግብ ማስታወሻዎች

ኩበርኔትስ ወደ መሠረተ ልማቱ ሲመጣ ቀደም ሲል የነበረው የምዝግብ ማስታወሻ የመሰብሰብ ችግርም አላለፈውም። በአንዳንድ መንገዶች, የበለጠ ህመም ሆነ: የመሠረተ ልማት መድረክን ማስተዳደር ቀላል ብቻ ሳይሆን በተመሳሳይ ጊዜ ውስብስብ ነበር. ብዙ የቆዩ አገልግሎቶች ወደ ማይክሮ አገልግሎት መስደድ ጀምረዋል። በሎግ አውድ ውስጥ፣ ይህ ከጊዜ ወደ ጊዜ እየጨመረ የሚሄደው የምዝግብ ማስታወሻ ምንጮች፣ ልዩ የሕይወት ዑደታቸው፣ እና የሁሉንም የሥርዓት አካላት ግንኙነት በምዝግብ ማስታወሻዎች የመከታተል አስፈላጊነት...

ወደ ፊት ስመለከት፣ አሁን፣ እንደ አለመታደል ሆኖ፣ ለኩበርኔትስ ምንም አይነት ደረጃውን የጠበቀ የምዝግብ ማስታወሻ አማራጭ እንደሌለ መግለጽ እችላለሁ፣ ይህም ከሌሎች ጋር የሚወዳደር ነው። በማህበረሰቡ ውስጥ በጣም ታዋቂው መርሃግብሮች የሚከተሉት ናቸው ።

  • አንድ ሰው ቁልልውን ይከፍታል ኢኤፍኬ (Elasticsearch, Fluentd, Kibana);
  • አንድ ሰው በቅርቡ የተፈታውን እየሞከረ ነው። Loki ወይም ይጠቀማል የምዝግብ ማስታወሻ ኦፕሬተር;
  • нас (እና ምናልባት እኛ ብቻ ሳንሆን?...) በራሴ እድገት ረክቻለሁ - ሎግ ቤት...

እንደ ደንቡ፣ የሚከተሉትን ቅርቅቦች በK8s ስብስቦች ውስጥ እንጠቀማለን (በራስ ለሚስተናገዱ መፍትሄዎች)

ሆኖም ግን, ስለ ጭነታቸው እና አወቃቀራቸው መመሪያዎች ላይ አልቆይም. ይልቁንስ ጉድለቶቻቸውን እና ስለ ሁኔታው ​​የበለጠ ዓለም አቀፋዊ መደምደሚያዎች በአጠቃላይ የምዝግብ ማስታወሻዎች ላይ አተኩራለሁ.

በK8s ውስጥ በምዝግብ ማስታወሻዎች ይለማመዱ

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች

“የዕለት ምዝግብ ማስታወሻዎች”፣ ምን ያህሎቻችሁ አላችሁ?

ከትላልቅ መሠረተ ልማቶች የተማከለ የምዝግብ ማስታወሻ መሰብሰብ ብዙ ሀብቶችን ይፈልጋል። የተለያዩ ፕሮጀክቶች በሚሰሩበት ወቅት የተለያዩ መስፈርቶች እና ከነሱ የሚነሱ የአሰራር ችግሮች አጋጥመውናል.

ክሊክ ሃውስን እንሞክር

ምዝግብ ማስታወሻዎችን በንቃት የሚያመነጭ መተግበሪያ ባለው ፕሮጀክት ላይ የተማከለ ማከማቻን እንይ፡ በሰከንድ ከ5000 በላይ መስመሮች። ወደ ClickHouse በማከል ከእሱ ምዝግብ ማስታወሻዎች ጋር መስራት እንጀምር።

ከፍተኛው ቅጽበታዊ ጊዜ እንደሚያስፈልገው ፣ ClickHouse ያለው ባለ 4-ኮር አገልጋይ ቀድሞውኑ በዲስክ ንዑስ ስርዓት ላይ ይጫናል።

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች

የዚህ ዓይነቱ ጭነት በተቻለ ፍጥነት በ ClickHouse ውስጥ ለመጻፍ በመሞከር ምክንያት ነው. እና የመረጃ ቋቱ ለዚህ የዲስክ ጭነት ምላሽ ይሰጣል ፣ ይህም የሚከተሉትን ስህተቶች ያስከትላል ።

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

ነጥብ ነው የተዋሃዱ ዛፍ ጠረጴዛዎች በ ClickHouse ውስጥ (የሎግ ዳታ ይዘዋል) በመፃፍ ጊዜ የራሳቸው ችግሮች አሏቸው። በእነሱ ውስጥ የገባው መረጃ ጊዜያዊ ክፋይ ይፈጥራል, ከዚያም ከዋናው ሠንጠረዥ ጋር ይቀላቀላል. በውጤቱም ፣ ቀረጻው በዲስክ ላይ በጣም የሚፈለግ ሆኖ ተገኝቷል ፣ እና ከዚህ በላይ ማስታወቂያ ለተቀበልነው ገደብ ተገዢ ነው-ከ 1 በላይ ንዑስ ክፍሎች በ 300 ሰከንድ ውስጥ ሊዋሃዱ አይችሉም (በእርግጥ ይህ 300 ማስገቢያዎች ነው) በሰከንድ).

ይህንን ባህሪ ለማስወገድ, ወደ ClickHouse መፃፍ አለበት። በተቻለ መጠን ትላልቅ ቁርጥራጮች እና በየ 1 ሰከንድ ከ 2 ጊዜ ያልበለጠ. ነገር ግን፣ በትልቅ ፍንዳታ መፃፍ በ ClickHouse ውስጥ ብዙ ጊዜ መፃፍ እንዳለብን ይጠቁማል። ይህ ደግሞ ወደ ቋት መጨናነቅ እና የምዝግብ ማስታወሻዎች መጥፋት ሊያስከትል ይችላል. መፍትሄው የ Fluentd ቋት መጨመር ነው, ነገር ግን ከዚያ የማስታወሻ ፍጆታ እንዲሁ ይጨምራል.

አመለከተከ ClickHouse ጋር የመፍትሄያችን ሌላው ችግር ያለበት ጉዳይ በእኛ ጉዳይ (ሎግሃውስ) መከፋፈል በተያያዙ ውጫዊ ጠረጴዛዎች መተግበሩ ጋር የተያያዘ ነው። ጠረጴዛን አዋህድ. ይህ ወደ እውነታ ይመራል ትልቅ የጊዜ ክፍተቶችን በሚመዘንበት ጊዜ ከመጠን በላይ ራም ያስፈልጋል ፣ ምክንያቱም ሜታብል በሁሉም ክፍልፋዮች ውስጥ ስለሚደጋገም - አስፈላጊ መረጃዎችን የማይይዙትም እንኳን። ሆኖም፣ አሁን ይህ አካሄድ ለአሁኑ የ ClickHouse ስሪቶች (ሐ 18.16).

በውጤቱም, እያንዳንዱ ፕሮጀክት በ ClickHouse ውስጥ በእውነተኛ ጊዜ ምዝግብ ማስታወሻዎችን ለመሰብሰብ በቂ ሀብቶች እንደሌለው ግልጽ ይሆናል (በተጨማሪ በትክክል, ስርጭታቸው ተገቢ አይሆንም). በተጨማሪ, መጠቀም ያስፈልግዎታል የማጠራቀሚያወደ በኋላ የምንመለስበት። ከላይ የተገለጸው ጉዳይ እውነት ነው። እና በዛን ጊዜ ለደንበኛው የሚስማማ እና በትንሹ በመዘግየቱ ምዝግብ ማስታወሻዎችን ለመሰብሰብ የሚያስችል አስተማማኝ እና የተረጋጋ መፍትሄ ማቅረብ አልቻልንም ...

ሾለ Elasticsearchሾ?

Elasticsearch ከባድ የሥራ ጫናዎችን እንደሚይዝ ይታወቃል። በተመሳሳዩ ፕሮጀክት ውስጥ እንሞክር. አሁን ጭነቱ ይህን ይመስላል።

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች

Elasticsearch የመረጃ ዥረቱን ማዋሃድ ችሏል፣ነገር ግን እንዲህ አይነት ጥራዞችን ለእሱ መጻፍ ሲፒዩውን በእጅጉ ይጠቀማል። ይህ ክላስተር በማደራጀት ይወሰናል. በቴክኒክ ፣ ይህ ችግር አይደለም ፣ ግን የሎግ አሰባሰብ ስርዓቱን ለማስኬድ ብቻ 8 ያህል ኮርሞችን እንጠቀማለን እና በስርዓቱ ውስጥ ተጨማሪ በጣም የተጫነ አካል አለን…

ቁም ነገር፡- ይህ አማራጭ ሊጸድቅ የሚችለው ግን ፕሮጀክቱ ትልቅ ከሆነ እና አስተዳደሩ በተማከለ የሎግ ሥርዓት ላይ ከፍተኛ ሀብት ለማዋል ዝግጁ ከሆነ ብቻ ነው።

ከዚያም ተፈጥሯዊ ጥያቄ ይነሳል.

ምን ምዝግብ ማስታወሻዎች በእርግጥ ያስፈልጋሉ?

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች አቀራረቡን በራሱ ለመለወጥ እንሞክር-ምዝግብ ማስታወሻዎች በተመሳሳይ ጊዜ መረጃ ሰጪ እንጂ ሽፋን የሌላቸው መሆን አለባቸው እያንዳንዱ በስርዓቱ ውስጥ ክስተት.

ስኬታማ የመስመር ላይ መደብር አለን እንበል። ምን ምዝግብ ማስታወሻዎች ጠቃሚ ናቸው? በተቻለ መጠን ብዙ መረጃዎችን መሰብሰብ, ለምሳሌ, ከክፍያ መግቢያ በር, በጣም ጥሩ ሀሳብ ነው. ነገር ግን በምርት ካታሎግ ውስጥ ከሚገኙት የምስሎች መቆራረጥ አገልግሎት ሁሉም ምዝግብ ማስታወሻዎች ለእኛ ወሳኝ አይደሉም፡ ስህተቶች እና የላቀ ክትትል ብቻ በቂ ናቸው (ለምሳሌ ይህ ክፍል የሚያመነጨው የ 500 ስህተቶች መቶኛ)።

ስለዚህ መደምደሚያ ላይ ደርሰናል። የተማከለ ምዝግብ ማስታወሻ ሁልጊዜ ትክክል አይደለም. በጣም ብዙ ጊዜ ደንበኛው ሁሉንም ምዝግብ ማስታወሻዎች በአንድ ቦታ መሰብሰብ ይፈልጋል ፣ ምንም እንኳን በእውነቱ ፣ ከጠቅላላው ምዝግብ ማስታወሻ ፣ ለንግድ ሥራው ወሳኝ የሆኑ 5% ቅድመ ሁኔታዎች ብቻ ያስፈልጋሉ ።

  • አንዳንድ ጊዜ የመያዣ ምዝግብ ማስታወሻውን መጠን እና የስህተት ሰብሳቢውን (ለምሳሌ ሴንትሪ) ማዋቀር በቂ ነው።
  • የስህተት ማስታወቂያ እና ትልቅ የአካባቢ ሎግ እራሱ ብዙ ጊዜ ክስተቶችን ለመመርመር በቂ ሊሆን ይችላል።
  • በብቸኝነት በተግባራዊ ሙከራዎች እና የስህተት አሰባሰብ ስርዓቶች የተሰሩ ፕሮጀክቶች ነበሩን። ገንቢው እንደዚህ አይነት ምዝግብ ማስታወሻዎች አያስፈልጉትም - ሁሉንም ነገር ከስህተት ዱካዎች አይተዋል.

የሕይወት ምሳሌ

ሌላ ታሪክ ጥሩ ምሳሌ ሊሆን ይችላል። ኩበርኔትስ ከመጀመሩ ከረጅም ጊዜ በፊት የተሰራውን የንግድ መፍትሄ እየተጠቀመ ከነበረው ከደንበኞቻችን የደህንነት ቡድን ጥያቄ ደርሶናል።

በኮርፖሬት ችግር መፈለጊያ ዳሳሽ - QRadar ጋር የተማከለውን የምዝግብ ማስታወሻ አሰባሰብ ስርዓት "ጓደኛ ማፍራት" አስፈላጊ ነበር. ይህ ስርዓት ምዝግብ ማስታወሻዎችን በ syslog ፕሮቶኮል መቀበል እና ከኤፍቲፒ ሊያወጣቸው ይችላል። ነገር ግን፣ ለቅልጥፍና ከርቀት_syslog ፕለጊን ጋር ወዲያውኑ ማዋሃድ አልተቻለም (እንደ ተለወጠ, ብቻችንን አይደለንም።). QRadarን በማዋቀር ላይ ያሉ ችግሮች ከደንበኛው የደህንነት ቡድን ጎን ሆነው ተገኝተዋል።

በውጤቱም፣ የቢዝነስ-ወሳኝ ምዝግብ ማስታወሻዎች ክፍል ወደ ኤፍቲፒ QRadar ተሰቅሏል፣ ሌላኛው ክፍል ደግሞ በሩቅ syslog በቀጥታ ከአንጓዎች ተዘዋውሯል። ለዚህም እንኳን ጽፈናል። ቀላል ገበታ - ምናልባት አንድ ሰው ተመሳሳይ ችግር ለመፍታት ይረዳዋል ... ለተፈጠረው እቅድ ምስጋና ይግባውና ደንበኛው ራሱ ወሳኝ የሆኑ ምዝግቦችን ተቀብሎ መተንተን (የሚወዷቸውን መሳሪያዎች በመጠቀም) እና የምዝግብ ማስታወሻ ስርዓቱን ዋጋ መቀነስ ችለናል. ባለፈው ወር.

ሌላ ምሳሌ ምን ማድረግ እንደሌለበት በጣም አመላካች ነው። ለሂደቱ ከደንበኞቻችን አንዱ እያንዳንዳቸው ከተጠቃሚው የሚመጡ ክስተቶች፣ መልቲላይን የተሰራ ያልተደራጀ ውጤት መረጃ በምዝግብ ማስታወሻ ውስጥ. እርስዎ እንደሚገምቱት ፣ እንደዚህ ያሉ ምዝግብ ማስታወሻዎች ለማንበብ እና ለማከማቸት በጣም ምቹ አልነበሩም።

የምዝግብ ማስታወሻዎች መስፈርቶች

እንደነዚህ ያሉ ምሳሌዎች የምዝግብ ማስታወሻ መሰብሰብ ስርዓትን ከመምረጥ በተጨማሪ ያስፈልግዎታል ወደሚል መደምደሚያ ይመራሉ በተጨማሪም ምዝግብ ማስታወሻዎቹን እራሳቸው ይንደፉ! እዚህ ምን መስፈርቶች አሉ?

  • ምዝግብ ማስታወሻዎች በማሽን ሊነበብ በሚችል ቅርጸት (ለምሳሌ JSON) መሆን አለባቸው።
  • ምዝግብ ማስታወሻዎች የታመቁ እና ሊሆኑ የሚችሉ ችግሮችን ለማረም የመግቢያውን ደረጃ የመቀየር ችሎታ ያላቸው መሆን አለባቸው። በተመሳሳይ ጊዜ, በምርት አካባቢዎች ውስጥ እንደ የምዝግብ ማስታወሻ ደረጃ ያሉ ስርዓቶችን ማሄድ አለብዎት ማስጠንቀቂያ ወይም ስሕተት.
  • ምዝግብ ማስታወሻዎች መደበኛ መሆን አለባቸው, ማለትም, በሎግ ነገር ውስጥ, ሁሉም መስመሮች አንድ አይነት የመስክ አይነት ሊኖራቸው ይገባል.

ያልተስተካከሉ ምዝግብ ማስታወሻዎች ወደ ማከማቻው በመጫን እና በሂደታቸው ላይ ሙሉ በሙሉ ማቆም ወደ ችግር ያመራሉ. እንደ ምሳሌ ፣ ብዙዎች በእርግጠኝነት በጥሩ ምዝግብ ማስታወሻዎች ያጋጠሙት ስህተት 400 ያለው ምሳሌ እዚህ አለ ።

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

ስህተቱ ማለት አይነቱ ያልተረጋጋ ዝግጁ በሆነ ካርታ ወደ መረጃ ጠቋሚው እየላኩ ነው ማለት ነው። በጣም ቀላሉ ምሳሌ በ nginx መዝገብ ውስጥ ከተለዋዋጭ ጋር ያለ መስክ ነው። $upstream_status. እሱ ቁጥር ወይም ሕብረቁምፊ ሊይዝ ይችላል። ለምሳሌ:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

ምዝግብ ማስታወሻዎቹ እንደሚያሳዩት አገልጋይ 10.100.0.10 በ 404 ስህተት ምላሽ እንደሰጠ እና ጥያቄው ወደ ሌላ የይዘት ማከማቻ ተልኳል። በውጤቱም ፣ በምዝግብ ማስታወሻዎች ውስጥ ያለው ዋጋ እንደዚህ ሆነ ።

"upstream_response_time": "0.001, 0.007"

ይህ ሁኔታ በጣም የተለመደ ስለሆነ የተለየ እንኳን ይገባዋል በሰነድ ውስጥ ማጣቀሻዎች.

ስለ አስተማማኝነትስ?

ሁሉም የምዝግብ ማስታወሻዎች ያለ ምንም ልዩነት አስፈላጊ የሆኑባቸው ጊዜያት አሉ። እና ከዚህ ጋር፣ ከዚህ በላይ በቀረበው/የተብራራው ለK8s የተለመደው የምዝግብ ማስታወሻ ማሰባሰብያ እቅዶች ችግር አለባቸው።

ለምሳሌ ቅልጥፍና ያለው ከአጭር ጊዜ ከሚቆዩ ዕቃዎች ምዝግብ ማስታወሻዎችን መሰብሰብ አይችልም። በአንደኛው ፕሮጄክታችን ውስጥ የመረጃ ቋቱ የፍልሰት መያዣ ከ 4 ሰከንድ ባነሰ ጊዜ ውስጥ ኖሯል እና ከዚያ ተሰርዟል - በተዛማጅ ማብራሪያ መሠረት-

"helm.sh/hook-delete-policy": hook-succeeded

በዚህ ምክንያት የፍልሰት ማስፈጸሚያ ምዝግብ ማስታወሻ በማከማቻው ውስጥ አልተካተተም። በዚህ ጉዳይ ላይ ፖለቲካ ሊረዳ ይችላል. before-hook-creation.

ሌላው ምሳሌ Docker log rotation ነው. በሎግ ላይ በንቃት የሚጽፍ መተግበሪያ አለ እንበል። በመደበኛ ሁኔታዎች ውስጥ ሁሉንም ምዝግብ ማስታወሻዎች ለማስኬድ እናስተዳድራለን, ነገር ግን አንድ ችግር እንደመጣ - ለምሳሌ, ከላይ እንደተገለፀው በተሳሳተ ቅርጸት - ማቀናበሩ ይቆማል, እና ዶከር ፋይሉን ያሽከረክራል. ውጤቱ የንግድ-ወሳኝ ምዝግብ ማስታወሻዎች ሊጠፉ ይችላሉ.

ለዚያም ነው የሎግ ጅረቶችን መለየት አስፈላጊ ነው፣ ደህንነታቸውን ለማረጋገጥ በጣም ጠቃሚ የሆኑትን በቀጥታ ወደ መተግበሪያ በመላክ ላይ። በተጨማሪም, ጥቂቶችን መፍጠር ከመጠን በላይ አይሆንም የምዝግብ ማስታወሻዎች "ማጠራቀሚያ".ወሳኝ መልዕክቶችን በሚያስቀምጡበት ጊዜ አጭር ማከማቻ አለመገኘት ሊተርፍ የሚችል።

በመጨረሻም, ያንን መዘንጋት የለብንም ማንኛውንም ንዑስ ስርዓት በትክክል መከታተል አስፈላጊ ነው. አለበለዚያ ቅልጥፍና ባለው ሁኔታ ውስጥ ወደሚገኝበት ሁኔታ መሮጥ ቀላል ነው CrashLoopBackOff እና ምንም ነገር አይልክም, እና ይህ አስፈላጊ መረጃን ማጣት ተስፋ ይሰጣል.

ግኝቶች

በዚህ ጽሑፍ ውስጥ እንደ ዳታዶግ ያሉ የ SaaS መፍትሄዎችን አንመለከትም. እዚህ ላይ የተገለጹት ብዙዎቹ ችግሮች ምዝግብ ማስታወሻዎችን በመሰብሰብ ላይ በተማሩ የንግድ ኩባንያዎች በአንድ ወይም በሌላ መንገድ ተፈትተዋል ነገርግን ሁሉም ሰው በተለያዩ ምክንያቶች ሳአኤስን መጠቀም አይችልም. (ዋናዎቹ ዋጋ እና ከ 152-FZ ጋር መጣጣም ናቸው).

የተማከለ የምዝግብ ማስታወሻ መሰብሰብ መጀመሪያ ላይ ቀላል ስራ ይመስላል፣ ግን በጭራሽ አይደለም። ያንን ማስታወስ ጠቃሚ ነው:

  • ወሳኝ አካላት ብቻ በዝርዝር መግባት አለባቸው, ክትትል እና የስህተት መሰብሰብ ለሌሎች ስርዓቶች ሊዋቀር ይችላል.
  • አላስፈላጊ ጭነት እንዳይጨምሩ በምርት ላይ ያሉ የምዝግብ ማስታወሻዎች በትንሹ መቀመጥ አለባቸው።
  • ምዝግብ ማስታወሻዎች በማሽን ሊነበቡ የሚችሉ፣ የተለመዱ እና ጥብቅ ቅርጸት ያላቸው መሆን አለባቸው።
  • በእውነቱ ወሳኝ የሆኑ ምዝግቦች በተለየ ዥረት ውስጥ መላክ አለባቸው, ይህም ከዋና ዋናዎቹ መለየት አለበት.
  • ከከፍተኛ ጭነት ፍንዳታ ሊያድነዎት የሚችል እና በማከማቻው ላይ ያለው ጭነት የበለጠ ተመሳሳይነት ያለው የሎግ አከማቸን ግምት ውስጥ ማስገባት ተገቢ ነው።

ዛሬ Kubernetes (እና ብቻ ሳይሆን) ምዝግብ ማስታወሻዎች: የሚጠበቁ እና እውነታዎች
እነዚህ ቀላል ደንቦች በሁሉም ቦታ ላይ ቢተገበሩ, ከላይ የተገለጹት ወረዳዎች እንዲሰሩ ያስችላቸዋል - ምንም እንኳን አስፈላጊ ክፍሎች (ባትሪው) ቢያጡም. እንደነዚህ ያሉትን መርሆዎች ካልተከተሉ, ስራው በቀላሉ እርስዎን እና መሠረተ ልማቶችን ወደ ሌላ ከፍተኛ የተጫነ (እና በተመሳሳይ ጊዜ ውጤታማ ያልሆነ) የስርዓቱ አካል ይመራዎታል.

PS

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ