Jina langu ni Anton Baderin. Ninafanya kazi katika Kituo cha Teknolojia ya Juu na kufanya usimamizi wa mfumo. Mwezi mmoja uliopita, mkutano wetu wa ushirika uliisha, ambapo tulishiriki uzoefu wetu uliokusanywa na jumuiya ya IT ya jiji letu. Nilizungumza juu ya ufuatiliaji wa programu za wavuti. Nyenzo hiyo ilikusudiwa kwa kiwango cha chini au cha kati, ambao hawakuunda mchakato huu kutoka mwanzo.
Msingi wa mfumo wowote wa ufuatiliaji ni kutatua matatizo ya biashara. Ufuatiliaji kwa ajili ya ufuatiliaji hauna maslahi kwa mtu yeyote. Biashara inataka nini? Ili kila kitu kifanye kazi haraka na bila makosa. Biashara zinataka kuwa makini, ili sisi wenyewe tutambue matatizo katika huduma na kuyarekebisha haraka iwezekanavyo. Haya, kwa kweli, ni matatizo ambayo nilitatua mwaka jana wote kwenye mradi wa mmoja wa wateja wetu.
Kuhusu mradi
Mradi huo ni mojawapo ya programu kubwa zaidi za uaminifu nchini. Tunasaidia minyororo ya rejareja kuongeza mzunguko wa mauzo kupitia zana mbalimbali za uuzaji kama vile kadi za bonasi. Kwa jumla, mradi huo unajumuisha programu 14 zinazoendesha kwenye seva kumi.
Wakati wa mchakato wa mahojiano, niliona mara kwa mara kwamba wasimamizi huwa hawafikii programu za ufuatiliaji wa wavuti kwa usahihi kila wakati: wengi bado huzingatia vipimo vya mfumo wa uendeshaji na mara kwa mara hufuatilia huduma.
Kwa upande wangu, mfumo wa ufuatiliaji wa mteja hapo awali ulikuwa msingi wa Icinga. Haikusuluhisha shida zilizo hapo juu kwa njia yoyote. Mara nyingi mteja mwenyewe alitufahamisha juu ya shida, na mara nyingi zaidi kuliko hivyo, hatukuwa na data ya kutosha kufikia msingi wa sababu.
Kwa kuongeza, kulikuwa na ufahamu wazi wa ubatili wa maendeleo yake zaidi. Nadhani wanaomfahamu Icinga watanielewa. Kwa hivyo, tuliamua kuunda upya kabisa mfumo wa ufuatiliaji wa programu ya wavuti kwa mradi huo.
Prometheus
Tulichagua Prometheus kulingana na viashiria kuu vitatu:
- Idadi kubwa ya vipimo vinavyopatikana. Kwa upande wetu kuna elfu 60 kati yao. Bila shaka, ni muhimu kuzingatia kwamba hatutumii wengi wao (labda kuhusu 95%). Kwa upande mwingine, wote ni nafuu. Kwetu sisi, hii ndiyo iliyokithiri zaidi ikilinganishwa na Icinga iliyotumika hapo awali. Ndani yake, kuongeza metrics ilikuwa maumivu fulani: zilizopo zilikuwa za gharama kubwa (angalia tu msimbo wa chanzo wa programu-jalizi yoyote). Programu-jalizi yoyote ilikuwa hati katika Bash au Python, uzinduzi ambao ni ghali kwa suala la rasilimali zinazotumiwa.
- Mfumo huu hutumia kiasi kidogo cha rasilimali. MB 600 za RAM, 15% ya msingi mmoja na IOPS kadhaa zinatosha kwa vipimo vyetu vyote. Bila shaka, lazima uendeshe wasafirishaji wa vipimo, lakini zote zimeandikwa katika Go na pia hazina uchu wa nguvu nyingi. Sidhani kwamba katika hali halisi ya kisasa hii ni tatizo.
- Hutoa uwezo wa kuhamia Kubernetes. Kuzingatia mipango ya mteja, chaguo ni dhahiri.
ELK
Hapo awali, hatukukusanya au kuchakata kumbukumbu. Mapungufu ni wazi kwa kila mtu. Tulichagua ELK kwa sababu tayari tulikuwa na uzoefu na mfumo huu. Tunahifadhi kumbukumbu za programu tu huko. Vigezo kuu vya uteuzi vilikuwa utafutaji wa maandishi kamili na kasi yake.
Π‘lickhouse
Hapo awali, chaguo lilianguka kwenye InfluxDB. Tuligundua hitaji la kukusanya kumbukumbu za Nginx, takwimu kutoka pg_stat_statements, na kuhifadhi data ya kihistoria ya Prometheus. Hatukupenda Kuingia kwa wingi kwa sababu mara kwa mara ilianza kutumia kiasi kikubwa cha kumbukumbu na kuanguka. Kwa kuongezea, nilitaka kuweka maswali katika kikundi kwa remote_addr, lakini kuweka kambi katika DBMS hii ni kwa vitambulisho tu. Lebo ni ghali (kumbukumbu), idadi yao ni mdogo kwa masharti.
Tulianza utafutaji wetu tena. Kilichohitajika ni hifadhidata ya uchanganuzi na utumiaji mdogo wa rasilimali, ikiwezekana na ukandamizaji wa data kwenye diski.
Clickhouse inakidhi vigezo hivi vyote, na hatujawahi kujutia chaguo letu. Hatuandiki kiasi chochote cha ajabu cha data ndani yake (idadi ya kuingizwa ni karibu elfu tano tu kwa dakika).
NewRelic
NewRelic imekuwa nasi kihistoria kwa sababu lilikuwa chaguo la mteja. Tunaitumia kama APM.
Zabbix
Tunatumia Zabbix kufuatilia Kisanduku Nyeusi cha API mbalimbali.
Kufafanua Mbinu ya Ufuatiliaji
Tulitaka kuoza kazi na hivyo kupanga mfumo wa ufuatiliaji.
Ili kufanya hivyo, niligawanya mfumo wetu katika viwango vifuatavyo:
- vifaa na VMS;
- mfumo wa uendeshaji;
- huduma za mfumo, stack ya programu;
- maombi;
- mantiki ya biashara.
Kwa nini njia hii ni rahisi:
- tunajua ni nani anayehusika na kazi ya kila ngazi na, kwa kuzingatia hili, tunaweza kutuma arifa;
- tunaweza kutumia muundo wakati wa kukandamiza arifa - itakuwa ajabu kutuma arifa kuhusu kutopatikana kwa hifadhidata wakati mashine pepe kwa ujumla haipatikani.
Kwa kuwa jukumu letu ni kutambua ukiukaji katika utendakazi wa mfumo, ni lazima katika kila ngazi tuangazie seti fulani ya vipimo ambavyo vinafaa kuzingatiwa wakati wa kuandika sheria za arifa. Ifuatayo, hebu tuende kupitia ngazi "VMS", "Mfumo wa uendeshaji" na "Huduma za mfumo, stack ya programu".
Mashine halisi
Ukaribishaji hutupatia kichakataji, diski, kumbukumbu na mtandao. Na tulikuwa na shida na mbili za kwanza. Kwa hivyo, vipimo:
Muda ulioibiwa wa CPU - unaponunua mashine ya kawaida kwenye Amazon (t2.micro, kwa mfano), unapaswa kuelewa kuwa haujatengwa msingi mzima wa processor, lakini ni sehemu tu ya wakati wake. Na unapoimaliza, processor itachukuliwa kutoka kwako.
Kipimo hiki hukuruhusu kufuatilia matukio kama haya na kufanya maamuzi. Kwa mfano, ni muhimu kuchukua ushuru wa mafuta zaidi au kusambaza usindikaji wa kazi za nyuma na maombi ya API kwa seva tofauti?
Muda wa IOPS + CPU iowait - kwa sababu fulani, wapangishaji wengi wa wingu hufanya dhambi kwa kutotoa IOPS za kutosha. Zaidi ya hayo, ratiba yenye IOPS ya chini sio hoja kwao. Kwa hivyo, inafaa kukusanya CPU iowait. Kwa jozi hii ya grafu - na IOPS ya chini na kusubiri kwa I/O ya juu - unaweza tayari kuzungumza na mwenyeji na kutatua tatizo.
Mfumo wa uendeshaji
Vipimo vya mfumo wa uendeshaji:
- kiasi cha kumbukumbu inayopatikana katika%;
- badilisha shughuli ya matumizi: vmstat swapin, swapout;
- idadi ya ingizo zinazopatikana na nafasi ya bure kwenye mfumo wa faili katika%
- mzigo wa wastani;
- idadi ya viunganisho katika hali ya tw;
- contrack utimilifu wa meza;
- Ubora wa mtandao unaweza kufuatiliwa kwa kutumia matumizi ya ss, kifurushi cha iproute2 - pata kiashiria cha miunganisho ya RTT kutoka kwa pato lake na uipange kwa bandari ya dest.
Pia katika kiwango cha mfumo wa uendeshaji tuna chombo kama michakato. Ni muhimu kutambua katika mfumo seti ya taratibu ambazo zina jukumu muhimu katika uendeshaji wake. Ikiwa, kwa mfano, una pgpools kadhaa, basi unahitaji kukusanya taarifa kwa kila mmoja wao.
Seti ya vipimo ni kama ifuatavyo:
- CPU;
- kumbukumbu kimsingi ni mkazi;
- IO - ikiwezekana katika IOPS;
- FileFd - fungua na kikomo;
- kushindwa kwa ukurasa muhimu - kwa njia hii unaweza kuelewa ni mchakato gani unabadilishwa.
Tunaweka ufuatiliaji wote katika Docker, na tunatumia Advisor kukusanya data ya vipimo. Kwenye mashine zingine tunatumia process-exporter.
Huduma za mfumo, stack ya programu
Kila programu ina sifa zake maalum, na ni vigumu kubainisha seti mahususi ya vipimo.
Seti ya Universal ni:
- kiwango cha ombi;
- idadi ya makosa;
- utulivu;
- kueneza.
Mifano yetu ya kuvutia zaidi ya ufuatiliaji katika kiwango hiki ni Nginx na PostgreSQL.
Huduma iliyopakiwa zaidi katika mfumo wetu ni hifadhidata. Hapo awali, mara nyingi tulikuwa na shida kufahamu ni nini hifadhidata ilikuwa ikifanya.
Tuliona mzigo mkubwa kwenye diski, lakini magogo ya polepole hayakuonyesha chochote. Tulitatua tatizo hili kwa kutumia pg_stat_statements, mwonekano unaokusanya takwimu za hoja.
Hiyo ndiyo yote ambayo admin anahitaji.
Tunaunda grafu za shughuli za kusoma na kuandika maombi:
Kila kitu ni rahisi na wazi, kila ombi lina rangi yake mwenyewe.
Mfano wa kuvutia sawa ni kumbukumbu za Nginx. Haishangazi kwamba watu wachache huzichanganua au kuzitaja katika orodha ya vitu vya lazima. Umbizo la kawaida si la taarifa sana na linahitaji kupanuliwa.
Binafsi, niliongeza request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Tunapanga muda wa kujibu na idadi ya makosa:
Tunaunda grafu za muda wa majibu na idadi ya makosa. Unakumbuka? Nilizungumza juu ya kazi za biashara? Kwa haraka na bila makosa? Tayari tumeshughulikia masuala haya na chati mbili. Na unaweza tayari kuwaita wasimamizi wa zamu ukitumia.
Lakini tatizo moja zaidi linabakia - kuhakikisha uondoaji wa haraka wa sababu za tukio hilo.
Utatuzi wa tukio
Mchakato mzima kutoka kutambua hadi kutatua tatizo unaweza kugawanywa katika hatua kadhaa:
- kutambua tatizo;
- taarifa kwa msimamizi wa kazi;
- majibu kwa tukio;
- kuondolewa kwa sababu.
Ni muhimu kwamba lazima tufanye hivi haraka iwezekanavyo. Na ikiwa katika hatua za kutambua shida na kutuma arifa hatuwezi kupata muda mwingi - dakika mbili zitatumika kwao kwa hali yoyote, basi zinazofuata ni uwanja ambao haujakuzwa kwa uboreshaji.
Hebu fikiria kwamba simu ya ofisa wa zamu iliita. Atafanya nini? Tafuta majibu ya maswali - ni nini kilivunja, kilivunja wapi, jinsi ya kuguswa? Hivi ndivyo tunavyojibu maswali haya:
Tunajumuisha maelezo haya yote katika maandishi ya arifa, tupe kiunga cha ukurasa wa wiki unaoelezea jinsi ya kujibu tatizo hili, jinsi ya kulitatua na kuliongeza.
Bado sijasema chochote kuhusu safu ya maombi na mantiki ya biashara. Kwa bahati mbaya, programu zetu bado hazitekelezi ukusanyaji wa vipimo. Chanzo pekee cha taarifa yoyote kutoka kwa viwango hivi ni kumbukumbu.
michache ya pointi.
Kwanza, andika kumbukumbu zilizopangwa. Hakuna haja ya kujumuisha muktadha katika maandishi ya ujumbe. Hii inawafanya kuwa wagumu kuwakusanya na kuwachambua. Logstash inachukua muda mrefu kurekebisha haya yote.
Pili, tumia viwango vya ukali kwa usahihi. Kila lugha ina kiwango chake. Binafsi, ninatofautisha viwango vinne:
- hakuna kosa;
- kosa la upande wa mteja;
- kosa liko upande wetu, hatupotezi pesa, hatubeba hatari;
- Kosa liko upande wetu, tunapoteza pesa.
Hebu nifanye muhtasari. Unahitaji kujaribu kujenga ufuatiliaji kulingana na mantiki ya biashara. Jaribu kufuatilia programu yenyewe na kufanya kazi kwa kutumia vipimo kama vile idadi ya mauzo, idadi ya usajili wa watumiaji wapya, idadi ya watumiaji wanaofanya kazi kwa sasa, na kadhalika.
Ikiwa biashara yako yote ni kitufe kimoja kwenye kivinjari, unahitaji kufuatilia ikiwa inabofya na kufanya kazi vizuri. Mengine yote haijalishi.
Ikiwa huna hii, unaweza kujaribu kuipata kwenye kumbukumbu za programu, kumbukumbu za Nginx, na kadhalika, kama tulivyofanya. Unapaswa kuwa karibu na programu iwezekanavyo.
Vipimo vya mfumo wa uendeshaji bila shaka ni muhimu, lakini biashara haipendezwi navyo, hatulipwi.
Chanzo: mapenzi.com