በPrometheus፣ Clickhouse እና ELK ላይ ክትትልን እንዴት እንደገነባን

ስሜ አንቶን ባደሪን እባላለሁ። በከፍተኛ የቴክኖሎጂ ማእከል እሰራለሁ እና የስርዓት አስተዳደር እሰራለሁ. ከአንድ ወር በፊት የተከማቸ ልምዳችንን ለከተማችን የአይቲ ማህበረሰብ አካፍለናል። የድር መተግበሪያዎችን ስለመቆጣጠር ተናገርኩ። ቁሱ ይህንን ሂደት ከባዶ ያልገነባው ለታዳጊ ወይም መካከለኛ ደረጃ የታሰበ ነው።

የማንኛውም የክትትል ስርዓት የመሰረት ድንጋይ የንግድ ችግሮችን መፍታት ነው። ለክትትል ሲባል መከታተል ለማንም ምንም ፍላጎት የለውም. ንግድ ምን ይፈልጋል? ስለዚህ ሁሉም ነገር በፍጥነት እና ያለ ስህተቶች እንዲሰራ። እኛ እራሳችን በአገልግሎቱ ውስጥ ያሉ ችግሮችን ለይተን በተቻለ ፍጥነት እንድናስተካክል ንግዶች ንቁ መሆን ይፈልጋሉ። እነዚህ, በእውነቱ, ለደንበኞቻችን በአንድ ፕሮጀክት ላይ ባለፈው አመት የፈታኋቸው ችግሮች ናቸው.

ስለ ፕሮጀክቱ

ፕሮጀክቱ በአገሪቱ ውስጥ ካሉት ትላልቅ የታማኝነት ፕሮግራሞች አንዱ ነው. የችርቻሮ ሰንሰለቶች የሽያጭ ድግግሞሾችን በተለያዩ የግብይት መሳሪያዎች እንደ ቦነስ ካርዶች እንዲጨምሩ እናግዛለን። በአጠቃላይ ፕሮጀክቱ በአስር አገልጋዮች ላይ የሚሰሩ 14 አፕሊኬሽኖችን ያካትታል።

በቃለ መጠይቁ ሂደት ውስጥ አስተዳዳሪዎች ሁልጊዜ የድር መተግበሪያዎችን መከታተል እንደማይችሉ ደጋግሜ አስተውያለሁ፡ ብዙዎች አሁንም በስርዓተ ክወና ልኬቶች ላይ ያተኩራሉ እና አልፎ አልፎ አገልግሎቶችን ይቆጣጠራሉ።

በእኔ ሁኔታ, የደንበኛው የክትትል ስርዓት ቀደም ሲል በ Icinga ላይ የተመሰረተ ነበር. ከላይ የተጠቀሱትን ችግሮች በምንም መንገድ ሊፈታ አልቻለም። ብዙውን ጊዜ ደንበኛው ራሱ ስለ ችግሮች ያሳውቀናል, እና ብዙውን ጊዜ, በቀላሉ ምክንያቱን ለማግኘት በቂ መረጃ አልነበረንም.

በተጨማሪም, ስለ ተጨማሪ እድገቱ ከንቱነት ግልጽ የሆነ ግንዛቤ ነበር. ኢሲንጋን የሚያውቁ የሚረዱኝ ይመስለኛል። ስለዚህ ለፕሮጀክቱ የድረ-ገጽ አፕሊኬሽን መከታተያ ስርዓቱን ሙሉ በሙሉ ለመንደፍ ወስነናል።

ፕሮሚትየስ

በሦስት ዋና ዋና አመልካቾች ላይ በመመርኮዝ ፕሮሜቲየስን መርጠናል-

1. እጅግ በጣም ብዙ የሚገኙ መለኪያዎች። በእኛ ሁኔታ 60 ሺህ የሚሆኑት አሉ. እርግጥ ነው፣ አብዛኞቹን (ምናልባትም 95% ገደማ) የማንጠቀም መሆናችንን ልብ ሊባል ይገባል። በሌላ በኩል, ሁሉም በአንጻራዊ ሁኔታ ርካሽ ናቸው. ለእኛ ይህ ቀደም ሲል ጥቅም ላይ ከዋለው Icinga ጋር ሲነጻጸር ሌላኛው ጽንፍ ነው. በእሱ ውስጥ, መለኪያዎችን መጨመር ልዩ ህመም ነበር: ነባሮቹ ውድ ነበሩ (የማንኛውም ተሰኪ ምንጭ ኮድ ይመልከቱ). ማንኛውም ፕለጊን በባሽ ወይም በፓይዘን ውስጥ ያለ ስክሪፕት ነበር፣ ይህም ጅምር ከሚጠቀሙት ሀብቶች አንፃር ውድ ነው።
2. ይህ ስርዓት በአንጻራዊ ሁኔታ አነስተኛ መጠን ያላቸውን ሀብቶች ይጠቀማል. 600 ሜባ RAM፣ 15% የአንድ ኮር እና ሁለት ደርዘን IOPS ለሁሉም መለኪያዎች በቂ ናቸው። እርግጥ ነው፣ ሜትሪክስ ላኪዎችን ማካሄድ አለቦት፣ ነገር ግን ሁሉም በ Go ውስጥ የተፃፉ እና እንዲሁም የኃይል ፍላጎት የላቸውም። በዘመናዊ እውነታዎች ይህ ችግር ነው ብዬ አላምንም.
3. ወደ ኩበርኔትስ የመሰደድ ችሎታን ይሰጣል። የደንበኞችን እቅዶች ግምት ውስጥ በማስገባት ምርጫው ግልጽ ነው.

ወ.ዘ.ተ.

ከዚህ ቀደም ምዝግብ ማስታወሻዎችን አንሰበስብም ወይም አላካሂድም ነበር። ድክመቶቹ ለሁሉም ሰው ግልጽ ናቸው. እኛ ኤልኬን የመረጥነው በዚህ ስርዓት ልምድ ስላለን ነው። የመተግበሪያ ምዝግብ ማስታወሻዎችን ብቻ እናከማቻለን. ዋናው የመምረጫ መስፈርት የሙሉ ጽሑፍ ፍለጋ እና ፍጥነቱ ነበር።

ክሊክ ሃውስ

መጀመሪያ ላይ ምርጫው በ InfluxDB ላይ ወድቋል። የNginx ምዝግብ ማስታወሻዎችን፣ ስታቲስቲክስን ከpg_stat_statements መሰብሰብ እና የፕሮሜቲየስ ታሪካዊ መረጃዎችን ማከማቸት እንደሚያስፈልግ ተገነዘብን። ኢንፍሉክስን አልወደድንም ምክንያቱም በየጊዜው ከፍተኛ መጠን ያለው ማህደረ ትውስታን ይወስድ ስለነበረ እና ይወድቃል። በተጨማሪም፣ መጠይቆችን በ remote_addr መቧደን ፈልጌ ነበር፣ ነገር ግን በዚህ ዲቢኤምኤስ መቧደን በመለያዎች ብቻ ነው። መለያዎች ውድ ናቸው (ትውስታ)፣ ቁጥራቸው በሁኔታ የተገደበ ነው።

ፍለጋችንን እንደገና ጀመርን። የሚያስፈልገው አነስተኛ የሃብት ፍጆታ ያለው የትንታኔ ዳታቤዝ ነበር፣ በተለይም በዲስክ ላይ ካለው የመረጃ መጨናነቅ ጋር።

Clickhouse እነዚህን ሁሉ መመዘኛዎች ያሟላል፣ እና በምርጫችን ተጸጽተን አናውቅም። ወደ እሱ ምንም ያልተለመደ መጠን አንጽፍም (የማስገቢያዎች ብዛት በደቂቃ አምስት ሺህ ያህል ብቻ ነው)።

NewRelic

NewRelic በታሪክ ከእኛ ጋር ነበር ምክንያቱም የደንበኛው ምርጫ ነው። እንደ ኤፒኤም እንጠቀማለን.

ዚብሊክስ

የተለያዩ ኤፒአይዎችን ብላክ ሣጥን ለመቆጣጠር ዛቢክስን ብቻ እንጠቀማለን።

የክትትል አቀራረብን መወሰን

እኛ ሥራውን መበስበስ እና በዚህም የክትትል ዘዴን ማደራጀት እንፈልጋለን.

ይህንን ለማድረግ ስርዓታችንን በሚከተሉት ደረጃዎች ከፋፍዬዋለሁ።

• ሃርድዌር እና ቪኤምኤስ;
• የአሰራር ሂደት;
• የስርዓት አገልግሎቶች, የሶፍትዌር ቁልል;
• ማመልከቻ;
• የንግድ ሎጂክ.

ይህ ዘዴ ለምን ምቹ ነው-

• ለእያንዳንዱ ደረጃ ሥራ ተጠያቂው ማን እንደሆነ እናውቃለን እናም በዚህ ላይ በመመስረት ማንቂያዎችን መላክ እንችላለን;
• ማንቂያዎችን በምንጭንበት ጊዜ አወቃቀሩን መጠቀም እንችላለን - ቨርቹዋል ማሽን በአጠቃላይ በማይገኝበት ጊዜ ስለ የውሂብ ጎታ አለመገኘት ማንቂያ መላክ እንግዳ ነው።

የእኛ ተግባር በስርዓቱ አሠራር ውስጥ ያሉ ጥሰቶችን መለየት ስለሆነ በእያንዳንዱ ደረጃ የማስጠንቀቂያ ደንቦችን በሚጽፉበት ጊዜ ትኩረት ሊሰጣቸው የሚገቡ የተወሰኑ መለኪያዎችን ማጉላት አለብን. በመቀጠል "VMS", "Operating System" እና "System Services, Software Stack" ያሉትን ደረጃዎች እንለፍ.

ምናባዊ ማሽኖች

ማስተናገጃ ፕሮሰሰር፣ ዲስክ፣ ማህደረ ትውስታ እና ኔትወርክ ይመድበናል። እና በመጀመሪያዎቹ ሁለት ችግሮች ነበሩብን. ስለዚህ፣ መለኪያዎቹ፡-

ሲፒዩ የተሰረቀ ጊዜ - በአማዞን ላይ ምናባዊ ማሽን ሲገዙ (ለምሳሌ ፣ t2.micro) ፣ እርስዎ ሙሉ ፕሮሰሰር ኮር እንዳልተመደቡ መረዳት አለብዎት ፣ ግን የእሱ ጊዜ ኮታ ብቻ። እና ሲደክሙ, ማቀነባበሪያው ከእርስዎ ይወሰዳል.

ይህ ልኬት እንደነዚህ ያሉ አፍታዎችን ለመከታተል እና ውሳኔዎችን ለማድረግ ያስችልዎታል. ለምሳሌ ወፍራም ታሪፍ መውሰድ ወይም የበስተጀርባ ተግባራትን እና የኤፒአይ ጥያቄዎችን ለተለያዩ አገልጋዮች ማሰራጨት አስፈላጊ ነው?

IOPS + CPU iowait time - በሆነ ምክንያት ብዙ የደመና ማስተናገጃዎች በቂ IOPS ባለማቅረብ ይበደላሉ። ከዚህም በላይ ዝቅተኛ IOPS ያለው የጊዜ ሰሌዳ ለእነሱ ክርክር አይደለም. ስለዚህ, CPU iowait መሰብሰብ ጠቃሚ ነው. በዚህ ጥንድ ግራፍ - ዝቅተኛ IOPS እና ከፍተኛ I/O መጠበቅ - አስቀድመው አስተናጋጁን ማነጋገር እና ችግሩን መፍታት ይችላሉ።

ስርዓተ ክወና

የስርዓተ ክወና መለኪያዎች፡-

• በ% ውስጥ ያለው የማህደረ ትውስታ መጠን;
• የአጠቃቀም እንቅስቃሴን መለዋወጥ: vmstat ስዋፒን, ስዋፑት;
• የሚገኙ የኢኖዶች ብዛት እና በፋይል ስርዓቱ ላይ ነፃ ቦታ በ%
• አማካይ ጭነት;
• በ tw ግዛት ውስጥ የግንኙነት ብዛት;
• የኮንትራክ ጠረጴዛ ሙላት;
• የአውታረ መረቡ ጥራት በኤስኤስ መገልገያ ፣ iproute2 ጥቅል በመጠቀም ቁጥጥር ሊደረግበት ይችላል - የ RTT ግንኙነቶችን ከውጤቱ ያግኙ እና በዴስት ወደብ ይቧድኑት።

እንዲሁም በስርዓተ ክወናው ደረጃ እንደ ሂደቶች ያለ አካል አለን. በስርዓቱ ውስጥ በአሠራሩ ውስጥ ጠቃሚ ሚና የሚጫወቱትን የሂደቶች ስብስብ መለየት አስፈላጊ ነው. ለምሳሌ, ብዙ pgpools ካለዎት, ለእያንዳንዳቸው መረጃ መሰብሰብ ያስፈልግዎታል.

የመለኪያዎች ስብስብ እንደሚከተለው ነው.

• ሲፒዩ;
• ማህደረ ትውስታ በዋነኝነት ነዋሪ ነው;
• IO - በ IOPS ውስጥ ይመረጣል;
• FileFd - ክፍት እና ገደብ;
• ጉልህ ገጽ አለመሳካቶች - በዚህ መንገድ ምን ሂደት እየተቀየረ እንደሆነ መረዳት ይችላሉ።

ሁሉንም ክትትል በDocker ውስጥ እናሰማራዋለን፣ እና የሜትሪ መረጃን ለመሰብሰብ አማካሪን እንጠቀማለን። በሌሎች ማሽኖች ላይ ፕሮሰስ-ላኪን እንጠቀማለን.

የስርዓት አገልግሎቶች, የሶፍትዌር ቁልል

እያንዳንዱ መተግበሪያ የራሱ የሆነ ዝርዝር አለው፣ እና የተወሰኑ የመለኪያዎችን ስብስብ ለመለየት አስቸጋሪ ነው።

ሁለንተናዊ ስብስብ የሚከተለው ነው-

• የጥያቄ መጠን;
• የስህተት ብዛት;
• መዘግየት;
• ሙሌት

በዚህ ደረጃ የእኛ በጣም አስገራሚ የክትትል ምሳሌዎች Nginx እና PostgreSQL ናቸው።

በእኛ ስርዓት ውስጥ በጣም የተጫነው አገልግሎት የውሂብ ጎታ ነው. ቀደም ባሉት ጊዜያት የመረጃ ቋቱ ምን እየሰራ እንደሆነ ለማወቅ ብዙ ጊዜ እንቸገር ነበር።

በዲስኮች ላይ ከፍተኛ ጭነት አየን, ነገር ግን ዘገምተኛ ምዝግብ ማስታወሻዎች ምንም ነገር አላሳዩም. ይህን ችግር የፈታነው የጥያቄ ስታቲስቲክስን የሚሰበስብ እይታ የሆነውን pg_stat_statements በመጠቀም ነው።

አስተዳዳሪው የሚያስፈልገው ያ ብቻ ነው።

የማንበብ እና የመጻፍ ጥያቄዎችን እንቅስቃሴ ግራፎችን እንገነባለን-

ሁሉም ነገር ቀላል እና ግልጽ ነው, እያንዳንዱ ጥያቄ የራሱ ቀለም አለው.

አንድ እኩል አስገራሚ ምሳሌ Nginx ምዝግብ ማስታወሻዎች ነው። ጥቂት ሰዎች እነሱን መተንተን ወይም የግድ የግድ ዝርዝር ውስጥ ቢጠቅሷቸው ምንም አያስደንቅም። መደበኛው ቅርጸት በጣም መረጃ ሰጭ አይደለም እናም መስፋፋት አለበት።

በግሌ የጥያቄ_ሰዓት ፣ የምላሽ_ጊዜ ፣የሰው_ባይት_ተላኩ ፣የጥያቄ_ርዝመት ፣የጥያቄ_መታወቂያ ጨምሬያለሁ።የምላሽ ጊዜ እና የስህተቶች ብዛት እናቀርባለን።

የምላሽ ጊዜ እና የስህተቶች ብዛት ግራፎችን እንገነባለን. አስታውስ? ስለ ንግድ ዓላማዎች ተናገርኩ? በፍጥነት እና ያለ ስህተቶች? እነዚህን ጉዳዮች በሁለት ገበታዎች አስቀድመናል. እና እነሱን ተጠቅመው በስራ ላይ ያሉትን አስተዳዳሪዎች አስቀድመው መደወል ይችላሉ።

ነገር ግን አንድ ተጨማሪ ችግር ይቀራል - የአደጋ መንስኤዎችን በፍጥነት ማስወገድን ለማረጋገጥ.

የአደጋ መፍትሄ

ችግሩን ከመለየት ጀምሮ እስከ መፍታት ድረስ ያለው አጠቃላይ ሂደት በበርካታ ደረጃዎች ሊከፈል ይችላል-

• ችግሩን መለየት;
• ለግዳጅ አስተዳዳሪ ማስታወቂያ;
• ለአንድ ክስተት ምላሽ;
• መንስኤዎችን ማስወገድ.

ይህንን በተቻለ ፍጥነት ማድረግ አለብን. እና ችግርን በመለየት እና ማሳወቂያ በመላክ ደረጃዎች ላይ ብዙ ጊዜ ማግኘት ካልቻልን - በማንኛውም ሁኔታ ሁለት ደቂቃዎች በእነሱ ላይ ያሳልፋሉ ፣ ከዚያ ተከታዮቹ በቀላሉ ለማሻሻያ መስክ ያልታረሱ ናቸው።

የግዳጅ ኦፊሰሩ ስልክ እንደጮኸ እናስብ። ምን ያደርጋል? ለጥያቄዎች መልስ ይፈልጉ - ምን ተበላሽቷል ፣ የት ተሰብሯል ፣ እንዴት ምላሽ መስጠት? እነዚህን ጥያቄዎች እንዴት እንደምንመልስ እነሆ፡-

በቀላሉ እነዚህን ሁሉ መረጃዎች በማስታወቂያው ጽሁፍ ውስጥ እናካትታለን፣ ለዚህ ​​ችግር እንዴት ምላሽ መስጠት እንደሚቻል፣ እንዴት እንደሚፈታ እና እንደሚባባስ የሚገልጽ የዊኪ ገጽ አገናኝ እንሰጠዋለን።

አሁንም ስለ አፕሊኬሽኑ ንብርብር እና የንግድ ሥራ አመክንዮ ምንም አልተናገርኩም። እንደ አለመታደል ሆኖ የእኛ መተግበሪያ የልኬቶች ስብስብን ገና ተግባራዊ አላደረጉም። ከእነዚህ ደረጃዎች ውስጥ የማንኛውም መረጃ ብቸኛው ምንጭ ምዝግብ ማስታወሻዎች ናቸው.

ሁለት ነጥቦች.

በመጀመሪያ, የተዋቀሩ ምዝግቦችን ይጻፉ. በመልእክቱ ጽሑፍ ውስጥ አውድ ማካተት አያስፈልግም። ይህ እነሱን ለመቧደን እና ለመተንተን አስቸጋሪ ያደርጋቸዋል. Logstash ይህን ሁሉ መደበኛ ለማድረግ ረጅም ጊዜ ይወስዳል.

በሁለተኛ ደረጃ, የክብደት ደረጃዎችን በትክክል ይጠቀሙ. እያንዳንዱ ቋንቋ የራሱ የሆነ ደረጃ አለው። በግለሰብ ደረጃ አራት ደረጃዎችን እለያለሁ-

1. ምንም ስህተት የለም;
2. የደንበኛ ጎን ስህተት;
3. ስህተቱ ከጎናችን ነው, ገንዘብ አናጣም, አደጋዎችን አንሸከምም;
4. ስህተቱ ከጎናችን ነው, ገንዘብ እናጣለን.

ላጠቃልል። በቢዝነስ አመክንዮ ላይ የተመሰረተ ክትትልን ለመገንባት መሞከር ያስፈልግዎታል. አፕሊኬሽኑን እራሱ ለመከታተል ይሞክሩ እና እንደ የሽያጭ ብዛት፣ የአዳዲስ የተጠቃሚ ምዝገባዎች ብዛት፣ አሁን ያሉ ንቁ ተጠቃሚዎች እና የመሳሰሉትን መለኪያዎች በመጠቀም ለመስራት ይሞክሩ።

አጠቃላይ ንግድዎ በአሳሹ ውስጥ አንድ ቁልፍ ከሆነ ፣ ጠቅ አድርጎ በትክክል እንደሚሰራ መከታተል ያስፈልግዎታል። የተቀረው ሁሉ ምንም አይደለም.

ይህ ከሌለዎት, እኛ እንዳደረግነው በመተግበሪያ ምዝግብ ማስታወሻዎች, በ Nginx ምዝግብ ማስታወሻዎች እና በመሳሰሉት ውስጥ ለመያዝ መሞከር ይችላሉ. በተቻለ መጠን ወደ ማመልከቻው ቅርብ መሆን አለብዎት.

የስርዓተ ክወና መለኪያዎች በእርግጥ አስፈላጊ ናቸው, ነገር ግን ንግድ ለእነሱ ፍላጎት የለውም, ለእነሱ አልተከፈለንም.

ምንጭ: hab.com