🥇Prometheus 2 TSDB ትንታኔ

የጊዜ ተከታታይ ዳታቤዝ (TSDB) በፕሮሜቲየስ 2 ውስጥ በፕሮሜቲየስ 2 ማከማቻ v1 ላይ በመረጃ አሰባሰብ እና መጠይቅ አፈፃፀም ፍጥነት እና በንብረት ቅልጥፍና ላይ ከፍተኛ መሻሻሎችን የሚያቀርብ የምህንድስና መፍትሄ ትልቅ ምሳሌ ነው። በፔርኮና ክትትል እና አስተዳደር (PMM) ውስጥ Prometheus 2 ን ተግባራዊ እያደረግን ነበር እና የPrometheus 2 TSDB አፈጻጸምን ለመረዳት እድሉን አግኝቻለሁ። በዚህ ጽሑፍ ውስጥ ስለ እነዚህ ምልከታዎች ውጤቶች እናገራለሁ.

የፕሮሜቲየስ አማካይ የሥራ ጫና

ከአጠቃላይ ዓላማ ዳታቤዝ ጋር ለመገናኘት ለተጠቀሙ፣ የተለመደው የፕሮሜቲየስ የሥራ ጫና በጣም አስደሳች ነው። የውሂብ ክምችት ፍጥነት ወደ የተረጋጋ እሴት ያዛባል፡ ብዙውን ጊዜ የሚቆጣጠራቸው አገልግሎቶች ተመሳሳይ መጠን ያላቸውን መለኪያዎች ይልካሉ፣ እና መሠረተ ልማት በአንፃራዊነት በዝግታ ይለወጣል።
የመረጃ ጥያቄዎች ከተለያዩ ምንጮች ሊመጡ ይችላሉ. አንዳንዶቹ፣ ልክ እንደ ማንቂያዎች፣ እንዲሁም ዓላማቸው የተረጋጋ እና ሊገመት የሚችል እሴት። ሌሎች፣ እንደ የተጠቃሚ ጥያቄዎች፣ ይህ ለአብዛኛዎቹ የስራ ጫናዎች ባይሆንም ሹል ሊፈጥር ይችላል።

የመጫን ሙከራ

በሙከራ ጊዜ, መረጃን የማከማቸት ችሎታ ላይ አተኮርኩ. ይህንን ስክሪፕት ተጠቅሜ ፕሮሜቴየስ 2.3.2ን ከጎ 1.10.1 (እንደ PMM 1.14 አካል) በLinode አገልግሎት አሰማርቻለሁ፡ StackScript. ለትክክለኛው የጭነት ማመንጨት, ከዚህ ጋር StackScript ብዙ MySQL ኖዶችን በእውነተኛ ጭነት (Sysbench TPC-C ሙከራ) ሮጥኩ፣ እያንዳንዳቸው 10 ሊኑክስ/MySQL ኖዶችን አምጥተዋል።
ሁሉም የሚከተሉት ሙከራዎች የተካሄዱት 32 ሎድ ሲሙሌሽን 20 MySQL ሁኔታዎችን በመከታተል ስምንት vCores እና 800GB ማህደረ ትውስታ ባለው የLinode አገልጋይ ላይ ነው። ወይም ከፕሮሜቴየስ አንፃር 440 ዒላማዎች (ዒላማዎች) ፣ 380 ክፍያዎች (ጭረቶች) በሴኮንድ ፣ 1,7 ሺህ መዝገቦች (ናሙናዎች) በሴኮንድ እና XNUMX ሚሊዮን ንቁ ጊዜ ተከታታይ።

ዕቅድ

በፕሮሜቲየስ 1.x ጥቅም ላይ የዋለውን ጨምሮ የተለመደው ባህላዊ የውሂብ ጎታ አቀራረብ ወደ የማስታወስ ገደብ. ጭነቱን ለመቋቋም በቂ ካልሆነ ከፍተኛ መዘግየት ያጋጥምዎታል እና አንዳንድ ጥያቄዎች አይሟሉም. በፕሮሜቲየስ 2 ውስጥ ያለው የማህደረ ትውስታ አጠቃቀም በቁልፍ ሊዋቀር ይችላል። storage.tsdb.min-block-duration, ወደ ዲስክ ከመታጠቡ በፊት መዝገቦች ለምን ያህል ጊዜ በማህደረ ትውስታ ውስጥ እንደሚቀመጡ የሚወስነው (ነባሪው 2 ሰዓት ነው). የሚያስፈልገው የማህደረ ትውስታ መጠን በጊዜ ተከታታይ፣ መለያዎች እና ቧጨራዎች እና በተጣራ ግቤት ላይ ይወሰናል። የዲስክ ቦታን በተመለከተ ፕሮሜቲየስ በአንድ ጽሁፍ 3 ባይት መጠቀምን ይፈልጋል። በሌላ በኩል, የማስታወሻ መስፈርቶች በጣም ከፍተኛ ናቸው.

የማገጃውን መጠን ማዋቀር ቢቻልም, በእጅ ማዋቀር አይመከርም, ስለዚህ ለስራ ጫናዎ የሚያስፈልገውን ያህል ፕሮሜቲየስን የማስታወስ ችሎታን የመስጠት ስራ ይቀርዎታል.
የሚመጣውን የመለኪያ ዥረት ለመደገፍ በቂ ማህደረ ትውስታ ከሌለ፣ፕሮሜቲየስ ከማስታወስ ችሎታው ይወድቃል ወይም በOOM ገዳይ ይያዛል።
ፕሮሜቲየስ የማስታወስ ችሎታው ሲያልቅ ብልሽቱን ለማዘግየት ስዋፕ መጨመር ምንም አይጠቅምም ምክንያቱም ይህን ባህሪ መጠቀም የማስታወሻ ፍንዳታዎችን ያስከትላል። ስለ Go፣ የቆሻሻ አሰባሳቢው እና በስዋፕ እንዴት እንደሚሰራ ይመስለኛል።
ሌላው አስደሳች አቀራረብ ሂደቱ ከተጀመረበት ጊዜ ጀምሮ ከመቁጠር ይልቅ የጭንቅላት ማገጃውን በተወሰነ ጊዜ ወደ ዲስክ እንዲፈስ ማድረግ ነው.

ከግራፉ ላይ እንደሚታየው በየሁለት ሰዓቱ ወደ ዲስክ መፍሰስ ይከሰታል። ደቂቃ-ብሎክ-ቆይታ መለኪያውን ወደ አንድ ሰዓት ከቀየሩት እነዚህ ዳግም ማስጀመሪያዎች በግማሽ ሰዓት ውስጥ በየሰዓቱ ይከናወናሉ።
በፕሮሜቲየስ መጫኛ ውስጥ ይህንን እና ሌሎች ግራፎችን ለመጠቀም ከፈለጉ ይህንን መጠቀም ይችላሉ። ዳሽቦርድ. ለፒኤምኤም የተቀየሰ ነው፣ ነገር ግን ከጥቂት ማሻሻያዎች ጋር ለማንኛውም የፕሮሜቲየስ ጭነት ተስማሚ ነው።
በማህደረ ትውስታ ውስጥ የተከማቸ ጭንቅላት ተብሎ የሚጠራ ንቁ ብሎክ አለን ። የቆዩ ውሂብ ያላቸው ብሎኮች በ በኩል ይገኛሉ mmap(). ይህ መሸጎጫውን በተናጥል የማዋቀርን አስፈላጊነት ያስወግዳል, ነገር ግን ከጭንቅላት ብሎክ በላይ የቆየ መረጃን ለመጠየቅ ከፈለጉ ለስርዓተ ክወናው መሸጎጫ የሚሆን በቂ ቦታ መተው አለብዎት ማለት ነው.
እንዲሁም የፕሮሜቴየስ ምናባዊ ማህደረ ትውስታ ፍጆታ በጣም ከፍ ያለ ይመስላል ማለት ነው ፣ ይህ ምንም የሚያስጨንቅ አይደለም።

ሌላው ትኩረት የሚስብ የንድፍ ነጥብ WAL (የፊት መዝገብ ይጻፉ) መጠቀም ነው. ከማከማቻ ሰነዱ ላይ እንደሚታየው፣ ፕሮሜቲየስ ብልሽትን ለማስወገድ WAL ይጠቀማል። የውሂብ መትረፍን የሚያረጋግጡ ልዩ ስልቶች፣ በሚያሳዝን ሁኔታ፣ በደንብ አልተመዘገቡም። Prometheus 2.3.2 በየ10 ሰከንድ WALን ወደ ዲስክ ያጥባል እና ይህ ቅንብር በተጠቃሚ ሊዋቀር የሚችል አይደለም።

ማህተሞች

Prometheus TSDB የተነደፈው ልክ እንደ LSM (Log Structured merge) ማከማቻ ነው፡ የጭንቅላት ማገጃው በየጊዜው ወደ ዲስክ ይታጠባል፣ የመጠቅለል ዘዴው ግን ብዙ ብሎኮችን በማዋሃድ በጥያቄዎች ላይ ብዙ ብሎኮችን እንዳይቃኙ ያደርጋል። እዚህ ከአንድ ቀን ጭነት በኋላ በሙከራ ስርዓቱ ላይ ያየሁትን የብሎኮች ብዛት ማየት ይችላሉ።

ስለ ማከማቻ የበለጠ ለማወቅ ከፈለጉ፣ ስላሉት ብሎኮች እና እንዴት እንደመጡ መረጃ የያዘውን የmeta.json ፋይል ማየት ይችላሉ።

{
       "ulid": "01CPZDPD1D9R019JS87TPV5MPE",
       "minTime": 1536472800000,
       "maxTime": 1536494400000,
       "stats": {
               "numSamples": 8292128378,
               "numSeries": 1673622,
               "numChunks": 69528220
       },
       "compaction": {
               "level": 2,
               "sources": [
                       "01CPYRY9MS465Y5ETM3SXFBV7X",
                       "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                       "01CPZ6NR4Q3PDP3E57HEH760XS"
               ],
               "parents": [
                       {
                               "ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
                               "minTime": 1536472800000,
                               "maxTime": 1536480000000
                       },
                       {
                               "ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                               "minTime": 1536480000000,
                               "maxTime": 1536487200000
                       },
                       {
                               "ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
                               "minTime": 1536487200000,
                               "maxTime": 1536494400000
                       }
               ]
       },
       "version": 1
}

በፕሮሜቲየስ ውስጥ ያሉት ማኅተሞች የጭንቅላት እገዳው ወደ ዲስክ ከታጠበበት ጊዜ ጋር የተሳሰሩ ናቸው። በዚህ ጊዜ ብዙ እንደዚህ ያሉ ስራዎች ሊከናወኑ ይችላሉ.

መጠቅለያዎች በምንም መልኩ ያልተገደቡ እና በአፈፃፀም ወቅት ትልቅ የዲስክ I/O ፍንጮችን ሊያስከትሉ የሚችሉ ይመስላል።

የሲፒዩ ጭነት ጫፎች

በእርግጥ ይህ በሲስተሙ ፍጥነት ላይ አሉታዊ ተጽእኖ አለው፣ እና ለኤልኤስኤም ማከማቻዎችም ከባድ ፈተና ነው፡ ብዙ ወጪ ሳያስከትል ከፍተኛ የጥያቄ ፍጥነትን ለመደገፍ እንዴት ኮምፓክት ማድረግ ይቻላል?
በማስታወሻ ሂደት ውስጥ የማህደረ ትውስታ አጠቃቀም እንዲሁ የማወቅ ጉጉ ይመስላል።

ከተጨመቀ በኋላ አብዛኛው ማህደረ ትውስታ ከካሼድ ወደ ነፃ እንዴት እንደሚቀየር ማየት እንችላለን፡ ይህ ማለት ጠቃሚ ሊሆን የሚችል መረጃ ከዚያ ተወግዷል ማለት ነው። እዚህ ጥቅም ላይ ከዋለ ለማወቅ ጉጉ fadvice() ወይም ሌላ የማሳነስ ቴክኒክ፣ ወይንስ መሸጎጫው በጥቅል ከተበላሹ ብሎኮች ስለተለቀቀ ነው?

ማገገም አለመሳካቱ

የአደጋ ማገገሚያ ጊዜ ይወስዳል, እና ጥሩ ምክንያት. በሴኮንድ ለአንድ ሚሊዮን መዝገቦች ገቢ ዥረት፣ ማገገሚያው የኤስኤስዲ ድራይቭን ከግምት ውስጥ በማስገባት 25 ደቂቃ ያህል መጠበቅ ነበረብኝ።

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."

የማገገሚያ ሂደቱ ዋናው ችግር ከፍተኛ የማስታወስ ፍጆታ ነው. ምንም እንኳን አገልጋዩ በተለመደው ሁኔታ በተመሳሳይ የማህደረ ትውስታ መጠን በተረጋጋ ሁኔታ መሮጥ ቢችልም፣ ቢበላሽ ግን በOOM ምክንያት ላይነሳ ይችላል። ያገኘሁት ብቸኛ መፍትሄ የውሂብ መሰብሰብን ማጥፋት፣ አገልጋዩን ማምጣት፣ እንዲያገግም ማድረግ እና መሰብሰብ በነቃ ዳግም ማስጀመር ነው።

ማሟሟቅ

በሞቃት ወቅት ሊታወስ የሚገባው ሌላው ባህሪ ዝቅተኛ አፈፃፀም እና ከጅምር በኋላ ከፍተኛ የሃብት ፍጆታ ጥምርታ ነው። አንዳንድ ጊዜ, ነገር ግን ሁሉም መጀመር አይደለም, እኔ ሲፒዩ እና ትውስታ ላይ ከባድ ጭነት ተመልክተዋል.

የማህደረ ትውስታ አጠቃቀም ፕሮሜቴየስ ሁሉንም ክፍያዎች ከጅምሩ ማዋቀር እንደማይችል እና አንዳንድ መረጃዎች እንደጠፉ ያሳያሉ።
ለከፍተኛ ሲፒዩ እና ማህደረ ትውስታ አጠቃቀም ትክክለኛ ምክንያቶችን አላገኘሁም። ይህ የሆነበት ምክንያት ከፍተኛ ድግግሞሽ ባለው የጭንቅላት ክፍል ውስጥ አዲስ የሰዓት ተከታታዮች በመፈጠሩ ነው ብዬ እገምታለሁ።

የሲፒዩ ስፒሎች

በቂ የሆነ ከፍተኛ የአይ/ኦ ጭነት ከሚፈጥሩት ጥቅጥቅሞች በተጨማሪ በየሁለት ደቂቃው በሲፒዩ ጭነት ላይ ከባድ ሽኮኮዎች አስተውያለሁ። ፍንዳታዎቹ ከከፍተኛ ገቢ ትራፊክ ጋር ረዘም ያሉ ናቸው እና በ Go ቆሻሻ ሰብሳቢው የተከሰቱ ይመስላሉ፣ ቢያንስ አንዳንድ ኮሮች ሙሉ በሙሉ ተጭነዋል።

እነዚህ መዝለሎች ያን ያህል ቀላል አይደሉም። በሚከሰቱበት ጊዜ የፕሮሜቲየስ ውስጣዊ የመግቢያ ነጥብ እና ሜትሪክስ የማይገኙ ይመስላሉ፣ይህም በተመሳሳይ የጊዜ ክፍተቶች ውስጥ የውሂብ መጥለቅለቅን ያስከትላል።

እንዲሁም የፕሮሜቲየስ ላኪው ለአንድ ሰከንድ ሲዘጋ ሊያስተውሉ ይችላሉ።

ከቆሻሻ ማጠራቀሚያ (ጂሲ) ጋር ያለውን ግንኙነት ማየት እንችላለን.

መደምደሚያ

በፕሮሜቲየስ 2 ውስጥ ያለው TSDB ፈጣን ነው፣ በሚሊዮኖች የሚቆጠሩ ተከታታይ ጊዜዎችን እና በተመሳሳይ ጊዜ በሺዎች የሚቆጠሩ መዝገቦችን በመጠኑ ሃርድዌር በመጠቀም ማስተናገድ ይችላል። የሲፒዩ እና የዲስክ I/O አጠቃቀምም አስደናቂ ነው። የእኔ ምሳሌ በአንድ ጥቅም ላይ የዋለ እምብርት በሰከንድ እስከ 200 ሜትሪክስ አሳይቷል።

ለማስፋፋት ለማቀድ, በቂ ማህደረ ትውስታ እንዳለ ማስታወስ ያስፈልግዎታል, እና እውነተኛ ማህደረ ትውስታ መሆን አለበት. ጥቅም ላይ የዋለው የማህደረ ትውስታ መጠን በ5 ሬኮርዶች በሰከንድ ወደ መጪው ዥረት 100 ጂቢ ነበር ፣ ይህም በአጠቃላይ ከስርዓተ ክወናው መሸጎጫ ጋር ፣ 000 ጂቢ ያህል የተያዘ ማህደረ ትውስታን ይሰጣል።

በእርግጥ፣ ሲፒዩ እና የዲስክ አይ/ኦ ሹልፎችን ለመግራት ገና ብዙ የሚሠራ ሥራ አለ፣ እና ይህ የሚያስደንቅ አይደለም፣ ወጣቱ TSDB Prometheus 2 ከ InnoDB፣ TokuDB፣ RocksDB፣ WiredTiger ጋር ሲወዳደር ግን ይህ አያስገርምም። በህይወት ዑደታቸው መጀመሪያ ላይ ተመሳሳይ ችግሮች.

ምንጭ: hab.com

የ TSDB ትንተና በፕሮሜቲየስ 2 ውስጥ