Ufuatiliaji umekufa? - Ufuatiliaji wa muda mrefu

Tangu 2008, kampuni yetu imekuwa ikijishughulisha kimsingi na usimamizi wa miundombinu na usaidizi wa kiufundi wa saa-saa kwa miradi ya wavuti: tuna wateja zaidi ya 400, ambayo ni karibu 15% ya biashara ya kielektroniki ya Urusi. Ipasavyo, usanifu tofauti sana unasaidiwa. Ikiwa kitu kitaanguka, tunalazimika kurekebisha ndani ya dakika 15. Lakini kuelewa kwamba ajali imetokea, unahitaji kufuatilia mradi na kujibu matukio. Jinsi ya kufanya hili?

Ninaamini kwamba kuna tatizo katika kuandaa mfumo sahihi wa ufuatiliaji. Ikiwa hakukuwa na shida, basi hotuba yangu ingejumuisha nadharia moja: "Tafadhali sakinisha Prometheus + Grafana na programu-jalizi 1, 2, 3." Kwa bahati mbaya, haifanyi kazi kwa njia hiyo tena. Na shida kuu ni kwamba kila mtu anaendelea kuamini katika kitu kilichokuwepo mwaka 2008, kwa suala la vipengele vya programu.

Kuhusu upangaji wa mfumo wa ufuatiliaji, ningethubutu kusema kwamba... miradi yenye ufuatiliaji wa kutosha haipo. Na hali ni mbaya sana kwamba ikiwa kitu kitaanguka, kuna hatari kwamba haitatambuliwa - baada ya yote, kila mtu ana uhakika kwamba "kila kitu kinafuatiliwa."
Labda kila kitu kinafuatiliwa. Lakini jinsi gani?

Sote tumekumbana na hadithi kama ifuatayo: washiriki fulani, msimamizi fulani anafanya kazi, timu ya usanidi inakuja kwao na kusema - "tumeachiliwa, sasa fuatilia." Fuatilia nini? Inavyofanya kazi?

SAWA. Tunafuatilia mtindo wa zamani. Na tayari inabadilika, na inageuka kuwa ulifuatilia huduma A, ambayo ikawa huduma B, ambayo inaingiliana na huduma C. Lakini timu ya maendeleo inakuambia: "Sakinisha programu, inapaswa kufuatilia kila kitu!"

Kwa hivyo ni nini kimebadilika? - Kila kitu kimebadilika!

2008 Kila kitu kiko sawa

Kuna watengenezaji kadhaa, seva moja, seva moja ya hifadhidata. Yote inakwenda kutoka hapa. Tuna habari fulani, tunaweka zabbix, Nagios, cacti. Na kisha tunaweka arifu wazi kwenye CPU, kwenye operesheni ya diski, na kwenye nafasi ya diski. Pia tunafanya ukaguzi wa mikono ili kuhakikisha kuwa tovuti inajibu na kwamba maagizo yanafika katika hifadhidata. Na ndivyo ilivyo - tunalindwa zaidi au chini.

Ikiwa tunalinganisha kiasi cha kazi ambayo msimamizi alifanya kisha kutoa ufuatiliaji, basi 98% yake ilikuwa moja kwa moja: mtu anayefanya ufuatiliaji lazima aelewe jinsi ya kufunga Zabbix, jinsi ya kuisanidi na kusanidi tahadhari. Na 2% - kwa ukaguzi wa nje: kwamba tovuti inajibu na kufanya ombi kwa hifadhidata, kwamba maagizo mapya yamefika.

2010 Mzigo unakua

Tunaanza kupanua wavuti, na kuongeza injini ya utafutaji. Tunataka kuhakikisha kuwa orodha ya bidhaa ina bidhaa zote. Na utafutaji huo wa bidhaa unafanya kazi. Kwamba hifadhidata inafanya kazi, kwamba maagizo yanafanywa, kwamba tovuti inajibu nje na kujibu kutoka kwa seva mbili na mtumiaji hajatolewa nje ya tovuti wakati inasawazishwa kwa seva nyingine, nk. Kuna vyombo zaidi.

Zaidi ya hayo, chombo kinachohusishwa na miundombinu bado kinasalia kuwa kikubwa zaidi katika kichwa cha meneja. Bado kuna wazo katika kichwa changu kwamba mtu anayefanya ufuatiliaji ni mtu ambaye ataweka zabbix na kuweza kuisanidi.

Lakini wakati huo huo, kazi inaonekana juu ya kufanya ukaguzi wa nje, juu ya kuunda seti ya maandishi ya swala la indexer ya utaftaji, seti ya maandishi ili kuangalia kuwa utaftaji unabadilika wakati wa mchakato wa kuorodhesha, seti ya maandishi ambayo huangalia kuwa bidhaa zinahamishiwa. huduma ya utoaji, nk. Nakadhalika.

Kumbuka: Niliandika "seti ya maandishi" mara 3. Hiyo ni, mtu anayehusika na ufuatiliaji sio tena yeye anayesakinisha zabbix. Huyu ni mtu anayeanza kuweka msimbo. Lakini hakuna kilichobadilika katika mawazo ya timu bado.

Lakini dunia inabadilika, inakuwa ngumu zaidi na zaidi. Safu ya uboreshaji na mifumo kadhaa mpya huongezwa. Wanaanza kuingiliana na kila mmoja. Nani alisema "inanuka kama huduma ndogo?" Lakini kila huduma bado inaonekana kama tovuti kibinafsi. Tunaweza kuigeukia na kuelewa kwamba inatoa taarifa muhimu na inafanya kazi yenyewe. Na ikiwa wewe ni msimamizi anayehusika kila wakati katika mradi ambao umekuwa ukiendelea kwa miaka 5-7-10, maarifa haya yanajilimbikiza: kiwango kipya kinaonekana - uligundua, kiwango kingine kinaonekana - uligundua ...

Lakini mara chache mtu yeyote huandamana na mradi kwa miaka 10.

Wasifu wa Monitoringman

Tuseme ulikuja kwenye uanzishaji mpya ambao uliajiri watengenezaji 20 mara moja, ukaandika huduma ndogo 15, na wewe ni msimamizi ambaye anaambiwa: "Jenga CI/CD. Tafadhali." Umejenga CI / CD na ghafla unasikia: "Ni vigumu kwetu kufanya kazi na uzalishaji katika "mchemraba", bila kuelewa jinsi programu itafanya kazi ndani yake. Tutengeneze sanduku la mchanga katika "mchemraba" sawa.
Unatengeneza sanduku la mchanga kwenye mchemraba huu. Wanakuambia mara moja: "Tunataka hifadhidata ya hatua ambayo inasasishwa kila siku kutoka kwa uzalishaji, ili tuelewe kuwa inafanya kazi kwenye hifadhidata, lakini wakati huo huo isiharibu hifadhidata ya uzalishaji."

Unaishi katika haya yote. Kuna wiki 2 zilizobaki kabla ya kutolewa, wanakuambia: "Sasa hebu tufuatilie haya yote ..." Hiyo ni. kufuatilia miundombinu ya nguzo, kufuatilia usanifu wa huduma ndogo, kufuatilia kazi na huduma za nje...

Na wenzangu huchukua mpango wa kawaida kutoka kwa vichwa vyao na kusema: "Kweli, kila kitu kiko wazi hapa! Sakinisha programu ambayo itafuatilia haya yote." Ndiyo, ndiyo: programu-jalizi za Prometheus + Grafana +.
Na wanaongeza: "Una wiki mbili, hakikisha kila kitu kiko salama."

Katika miradi mingi tunayoiona, mtu mmoja ametengwa kwa ajili ya ufuatiliaji. Fikiria kwamba tunataka kuajiri mtu kufanya ufuatiliaji kwa wiki 2, na tunaandika wasifu kwa ajili yake. Je, mtu huyu anapaswa kuwa na ujuzi gani, kutokana na kila kitu ambacho tumezungumza hadi sasa?

• Lazima aelewe ufuatiliaji na maalum ya uendeshaji wa miundombinu ya chuma.
• Lazima aelewe maelezo ya ufuatiliaji wa Kubernetes (na kila mtu anataka kwenda kwenye "mchemraba", kwa sababu unaweza kujificha kutoka kwa kila kitu, kujificha, kwa sababu msimamizi atashughulika na wengine) - yenyewe, miundombinu yake, na kuelewa jinsi ya kufuatilia maombi. ndani.
• Lazima aelewe kwamba huduma huwasiliana kwa njia maalum, na kujua mahususi jinsi huduma zinavyoingiliana. Inawezekana kabisa kuona mradi ambapo huduma zingine huwasiliana kwa usawa, kwa sababu hakuna njia nyingine. Kwa mfano, mazingira ya nyuma huenda kupitia REST, kupitia gRPC hadi kwenye huduma ya katalogi, hupokea orodha ya bidhaa na kuirejesha. Huwezi kusubiri hapa. Na kwa huduma zingine hufanya kazi kwa usawa. Tuma agizo kwa huduma ya uwasilishaji, tuma barua, nk.
  Labda tayari umeogelea kutoka kwa haya yote? Na msimamizi, ambaye anahitaji kufuatilia hili, alichanganyikiwa zaidi.
• Lazima awe na uwezo wa kupanga na kupanga kwa usahihi - kadiri kazi inavyozidi kuongezeka.
• Kwa hivyo lazima atengeneze mkakati kutoka kwa huduma iliyoundwa ili kuelewa jinsi ya kuifuatilia haswa. Anahitaji ufahamu wa usanifu wa mradi na maendeleo yake + ufahamu wa teknolojia zinazotumiwa katika maendeleo.

Hebu tukumbuke kesi ya kawaida kabisa: huduma zingine ziko katika PHP, huduma zingine ziko kwenye Go, huduma zingine ziko katika JS. Wanafanya kazi kwa namna fulani na kila mmoja. Hapa ndipo neno "microservice" linatoka: kuna mifumo mingi ya kibinafsi ambayo watengenezaji hawawezi kuelewa mradi kwa ujumla. Sehemu moja ya timu huandika huduma katika JS zinazofanya kazi zenyewe na hazijui jinsi mfumo mwingine unavyofanya kazi. Sehemu nyingine huandika huduma katika Python na haiingilii jinsi huduma zingine zinavyofanya kazi; wametengwa katika eneo lao. Ya tatu ni kuandika huduma katika PHP au kitu kingine.
Watu hawa wote 20 wamegawanywa katika huduma 15, na kuna msimamizi mmoja tu ambaye lazima aelewe haya yote. Acha! tumegawanyika tu mfumo katika huduma ndogo 15 kwa sababu watu 20 hawawezi kuelewa mfumo mzima.

Lakini inahitaji kufuatiliwa kwa njia fulani ...

Matokeo ni nini? Kama matokeo, kuna mtu mmoja ambaye anakuja na kila kitu ambacho timu nzima ya watengenezaji haiwezi kuelewa, na wakati huo huo lazima pia ajue na aweze kufanya kile tulichoonyesha hapo juu - miundombinu ya vifaa, miundombinu ya Kubernetes, nk.

Ninaweza kusema nini ... Houston, tuna matatizo.

Ufuatiliaji wa mradi wa kisasa wa programu ni mradi wa programu yenyewe

Kutokana na imani potofu kwamba ufuatiliaji ni programu, tunakuza imani katika miujiza. Lakini miujiza, ole, haifanyiki. Huwezi kusakinisha zabbix na kutarajia kila kitu kufanya kazi. Hakuna maana katika kusakinisha Grafana na kutumaini kwamba kila kitu kitakuwa sawa. Wakati mwingi utatumika katika kuandaa ukaguzi wa utendakazi wa huduma na mwingiliano wao na kila mmoja, kuangalia jinsi mifumo ya nje inavyofanya kazi. Kwa kweli, 90% ya muda itatumika si kwa kuandika maandiko, lakini katika kuendeleza programu. Na inapaswa kushughulikiwa na timu inayoelewa kazi ya mradi huo.
Ikiwa katika hali hii mtu mmoja anatupwa katika ufuatiliaji, basi maafa yatatokea. Ambayo ndiyo hufanyika kila mahali.

Kwa mfano, kuna huduma kadhaa zinazowasiliana kupitia Kafka. Agizo lilifika, tulituma ujumbe kuhusu agizo hilo kwa Kafka. Kuna huduma inayosikiliza habari kuhusu agizo na kusafirisha bidhaa. Kuna huduma inayosikiliza habari kuhusu agizo na kutuma barua kwa mtumiaji. Na kisha rundo la huduma zaidi huonekana, na tunaanza kuchanganyikiwa.

Na ikiwa pia utampa msimamizi na wasanidi programu hii katika hatua ambapo kuna muda mfupi uliosalia kabla ya kutolewa, mtu huyo atahitaji kuelewa itifaki hii yote. Wale. Mradi wa kiwango hiki unachukua muda mwingi, na hii inapaswa kuzingatiwa katika maendeleo ya mfumo.
Lakini mara nyingi sana, hasa katika kuanza, tunaona jinsi ufuatiliaji unavyoahirishwa hadi baadaye. "Sasa tutafanya Uthibitisho wa Dhana, tutazindua nayo, iachwe - tuko tayari kujitolea. Na kisha tutafuatilia yote." Wakati (au ikiwa) mradi unaanza kupata pesa, biashara inataka kuongeza vipengele zaidi - kwa sababu imeanza kufanya kazi, kwa hivyo inahitaji kutekelezwa zaidi! Na wewe ni mahali ambapo kwanza unahitaji kufuatilia kila kitu kilichopita, ambacho huchukua si 1% ya muda, lakini mengi zaidi. Na kwa njia, watengenezaji watahitajika kwa ufuatiliaji, na ni rahisi kuwaruhusu kufanya kazi kwenye vipengele vipya. Kwa hivyo, vipengele vipya huandikwa, kila kitu huharibika, na uko kwenye msuguano usio na mwisho.

Hivyo jinsi ya kufuatilia mradi kuanzia mwanzo, na nini cha kufanya ikiwa unapata mradi unaohitaji kufuatiliwa, lakini hujui wapi kuanza?

Kwanza, unahitaji kupanga.

Upungufu wa sauti: mara nyingi huanza na ufuatiliaji wa miundombinu. Kwa mfano, tuna Kubernetes. Wacha tuanze kwa kusakinisha Prometheus na Grafana, kusanikisha programu-jalizi za kuangalia "mchemraba". Sio tu watengenezaji, lakini pia wasimamizi wana mazoezi ya bahati mbaya ya: "Tutasakinisha programu-jalizi hii, lakini programu-jalizi labda inajua jinsi ya kuifanya." Watu wanapenda kuanza na rahisi na moja kwa moja, badala ya vitendo muhimu. Na ufuatiliaji wa miundombinu ni rahisi.

Kwanza, amua ni nini na jinsi unavyotaka kufuatilia, na kisha uchague chombo, kwa sababu watu wengine hawawezi kukufikiria. Na wanapaswa? Watu wengine walijifikiria wenyewe, juu ya mfumo wa ulimwengu wote - au hawakufikiria kabisa wakati programu-jalizi hii iliandikwa. Na kwa sababu programu-jalizi hii ina watumiaji elfu 5 haimaanishi kuwa ni ya matumizi yoyote. Labda utakuwa wa 5001 kwa sababu tayari kulikuwa na watu 5000 hapo awali.

Ukianza kufuatilia miundombinu na upande wa nyuma wa programu yako utaacha kujibu, watumiaji wote watapoteza muunganisho na programu ya simu. Hitilafu itaonekana. Watakuja kwako na kusema "Ombi haifanyi kazi, unafanya nini hapa?" - "Tunafuatilia." — "Unafuatiliaje ikiwa huoni kuwa programu haifanyi kazi?!"

1. Ninaamini kuwa unahitaji kuanza kufuatilia haswa kutoka kwa mahali pa kuingilia kwa mtumiaji. Ikiwa mtumiaji haoni kwamba programu inafanya kazi, ndivyo ilivyo, ni kushindwa. Na mfumo wa ufuatiliaji unapaswa kuonya kuhusu hili kwanza.
2. Na hapo ndipo tunaweza kufuatilia miundombinu. Au fanya kwa sambamba. Ni rahisi na miundombinu - hapa tunaweza tu kusakinisha zabbix.
3. Na sasa unahitaji kwenda kwenye mizizi ya maombi ili kuelewa ambapo mambo hayafanyi kazi.

Wazo langu kuu ni kwamba ufuatiliaji uende sambamba na mchakato wa maendeleo. Ukivuruga timu ya ufuatiliaji kwa ajili ya kazi nyingine (kuunda CI/CD, sanduku la mchanga, kupanga upya miundombinu), ufuatiliaji utaanza kulegalega na huenda usiwahi kupata maendeleo (au mapema au baadaye utalazimika kuisimamisha).

Kila kitu kwa viwango

Hivi ndivyo ninavyoona shirika la mfumo wa ufuatiliaji.

1) Kiwango cha maombi:

• ufuatiliaji wa mantiki ya biashara ya maombi;
• ufuatiliaji wa vipimo vya huduma za afya;
• ufuatiliaji wa ujumuishaji.

2) Kiwango cha miundombinu:

• ufuatiliaji wa kiwango cha orchestration;
• ufuatiliaji wa programu ya mfumo;
• ufuatiliaji wa kiwango cha chuma.

3) Tena kiwango cha maombi - lakini kama bidhaa ya uhandisi:

• kukusanya na kufuatilia kumbukumbu za maombi;
• APM;
• kufuatilia.

4) Tahadhari:

• shirika la mfumo wa onyo;
• shirika la mfumo wa wajibu;
• shirika la "msingi wa maarifa" na mtiririko wa kazi kwa usindikaji wa tukio.

Ni muhimu: tunapata tahadhari sio baada, lakini mara moja! Hakuna haja ya kuzindua ufuatiliaji na "kwa namna fulani baadaye" kutambua nani atapokea arifa. Baada ya yote, ni kazi gani ya ufuatiliaji: kuelewa ni wapi katika mfumo kuna kitu kibaya, na kuruhusu watu sahihi kujua kuhusu hilo. Ukiacha hii hadi mwisho, basi watu wanaofaa watajua kuwa kuna kitu kinakwenda vibaya kwa kuita tu "hakuna kinachofanya kazi kwetu."

Safu ya Maombi - Ufuatiliaji wa Mantiki ya Biashara

Hapa tunazungumza juu ya kuangalia ukweli kwamba programu inafanya kazi kwa mtumiaji.

Ngazi hii inapaswa kufanyika wakati wa awamu ya maendeleo. Kwa mfano, tuna Prometheus ya masharti: inakwenda kwa seva inayofanya ukaguzi, inavuta sehemu ya mwisho, na mwisho huenda na kuangalia API.

Inapoulizwa mara kwa mara kufuatilia ukurasa wa nyumbani ili kuhakikisha kuwa tovuti inafanya kazi, watayarishaji programu hutoa mpini unaoweza kuvutwa kila wakati wanapohitaji kuhakikisha kuwa API inafanya kazi. Na watengenezaji programu kwa wakati huu bado wanachukua na kuandika /api/test/helloworld
Njia pekee ya kuhakikisha kuwa kila kitu kinafanya kazi? - Hapana!

• Kuunda hundi kama hizo kimsingi ni kazi ya watengenezaji. Vipimo vya kitengo vinapaswa kuandikwa na waandaaji wa programu wanaoandika nambari. Kwa sababu ukiivujisha kwa msimamizi, "Jamani, hii hapa orodha ya itifaki za API kwa vipengele vyote 25, tafadhali fuatilia kila kitu!" - hakuna kitakachofanya kazi.
• Ukichapisha "hello world", hakuna mtu atakayejua kuwa API inapaswa kufanya kazi na kufanya kazi. Kila mabadiliko ya API lazima yaongoze kwenye mabadiliko ya hundi.
• Ikiwa tayari una tatizo kama hilo, acha vipengele na utenge watengenezaji ambao wataandika hundi hizi, au kukubali hasara, kukubali kuwa hakuna kitu kinachoangaliwa na kitashindwa.

Vidokezo vya Kiufundi:

• Hakikisha kuwa umepanga seva ya nje ili kupanga ukaguzi - lazima uhakikishe kuwa mradi wako unapatikana kwa ulimwengu wa nje.
• Panga ukaguzi katika itifaki nzima ya API, sio tu miisho ya kibinafsi.
• Unda prometheus-endpoint na matokeo ya mtihani.

Safu ya maombi - ufuatiliaji wa vipimo vya afya

Sasa tunazungumza juu ya vipimo vya afya vya nje vya huduma.

Tuliamua kwamba tufuatilie "vipini" vyote vya programu kwa kutumia ukaguzi wa nje, ambao tunauita kutoka kwa mfumo wa ufuatiliaji wa nje. Lakini hizi ni "hushughulikia" ambazo mtumiaji "huona". Tunataka kuwa na uhakika kwamba huduma zetu zinafanya kazi. Kuna hadithi bora hapa: K8s ina hundi ya afya, ili angalau "mchemraba" yenyewe inaweza kuwa na hakika kwamba huduma inafanya kazi. Lakini nusu ya hundi nimeona ni magazeti sawa "hello dunia". Wale. Kwa hivyo anavuta mara moja baada ya kupelekwa, akajibu kwamba kila kitu ni sawa - ndivyo tu. Na huduma, ikiwa inatoa API yake mwenyewe, ina idadi kubwa ya pointi za kuingia kwa API hiyo hiyo, ambayo pia inahitaji kufuatiliwa, kwa sababu tunataka kujua kwamba inafanya kazi. Na tayari tunaifuatilia ndani.

Jinsi ya kutekeleza hili kwa usahihi kiufundi: kila huduma inafichua mwisho kuhusu utendaji wake wa sasa, na katika grafu za Grafana (au programu nyingine yoyote) tunaona hali ya huduma zote.

• Kila mabadiliko ya API lazima yaongoze kwenye mabadiliko ya hundi.
• Unda huduma mpya mara moja ukitumia vipimo vya afya.
• Msimamizi anaweza kuja kwa wasanidi programu na kuuliza "niongeze vipengele kadhaa ili nielewe kila kitu na kuongeza maelezo kuhusu hili kwenye mfumo wangu wa ufuatiliaji." Lakini kwa kawaida watengenezaji hujibu, "Hatutaongeza chochote wiki mbili kabla ya kutolewa."
  Wasimamizi wa maendeleo wajue kutakuwa na hasara hiyo, wajulishe menejimenti ya wasimamizi wa maendeleo pia. Kwa sababu kila kitu kinapoanguka, mtu bado atapiga simu na kudai kufuatilia "huduma inayoanguka mara kwa mara" (c)
• Kwa njia, tenga watengenezaji kuandika programu-jalizi za Grafana - hii itakuwa msaada mzuri kwa wasimamizi.

Safu ya Maombi - Ufuatiliaji wa Ujumuishaji

Ufuatiliaji wa ujumuishaji huzingatia ufuatiliaji wa mawasiliano kati ya mifumo muhimu ya biashara.

Kwa mfano, kuna huduma 15 zinazowasiliana na kila mmoja. Hizi si tovuti tofauti tena. Wale. hatuwezi kuvuta huduma peke yake, kupata /helloworld na kuelewa kuwa huduma inaendelea. Kwa sababu huduma ya wavuti ya kuagiza lazima itume habari kuhusu agizo kwa basi - kutoka kwa basi, huduma ya ghala lazima ipokee ujumbe huu na ifanye kazi nayo zaidi. Na huduma ya usambazaji wa barua pepe inapaswa kusindika hii kwa namna fulani zaidi, nk.

Ipasavyo, hatuwezi kuelewa, kwa kutumia kila huduma ya mtu binafsi, kwamba yote hufanya kazi. Kwa sababu tuna basi fulani ambayo kila kitu huwasiliana na kuingiliana.
Kwa hivyo, hatua hii inapaswa kuashiria hatua ya huduma za upimaji kwa mwingiliano na huduma zingine. Haiwezekani kupanga ufuatiliaji wa mawasiliano kwa kufuatilia wakala wa ujumbe. Ikiwa kuna huduma inayotoa data na huduma inayopokea, wakati wa kufuatilia wakala tutaona data tu ambayo inaruka kutoka upande hadi upande. Hata ikiwa kwa namna fulani tuliweza kufuatilia mwingiliano wa data hii ndani - kwamba mtayarishaji fulani anachapisha data, mtu anaisoma, mtiririko huu unaendelea kwenda Kafka - hii bado haitatupa habari ikiwa huduma moja ilituma ujumbe katika toleo moja. , lakini huduma nyingine haikutarajia toleo hili na ikaruka. Hatutajua kuhusu hili, kwa kuwa huduma zitatuambia kuwa kila kitu kinafanya kazi.

Ninachopendekeza kufanya:

• Kwa mawasiliano ya usawazishaji: mwisho hufanya maombi kwa huduma zinazohusiana. Wale. tunachukua sehemu hii ya mwisho, vuta hati ndani ya huduma, ambayo huenda kwa pointi zote na kusema "Naweza kuvuta huko, na kuvuta huko, naweza kuvuta huko..."
• Kwa mawasiliano ya asynchronous: ujumbe unaoingia - mwisho huangalia basi kwa ujumbe wa mtihani na kuonyesha hali ya usindikaji.
• Kwa mawasiliano ya asynchronous: ujumbe unaotoka - mwisho hutuma ujumbe wa mtihani kwa basi.

Kama kawaida hufanyika: tuna huduma ambayo hutupa data kwenye basi. Tunakuja kwa huduma hii na kukuuliza utuambie kuhusu afya ya ujumuishaji wake. Na ikiwa huduma inahitaji kutoa ujumbe mahali pengine zaidi (WebApp), basi itazalisha ujumbe huu wa mtihani. Na ikiwa tunaendesha huduma kwa upande wa OrderProcessing, kwanza huchapisha kile inachoweza kuchapisha kwa kujitegemea, na ikiwa kuna vitu fulani tegemezi, basi inasoma seti ya ujumbe wa majaribio kutoka kwa basi, inaelewa kuwa inaweza kuzichakata, kuripoti na. , ikiwa ni lazima, wachapishe zaidi, na kuhusu hili anasema - kila kitu ni sawa, niko hai.

Mara nyingi tunasikia swali "tunawezaje kujaribu hii kwenye data ya mapigano?" Kwa mfano, tunazungumzia huduma sawa ya kuagiza. Agizo hutuma ujumbe kwa ghala ambapo bidhaa zimefungwa: hatuwezi kujaribu hii kwenye data ya mapigano, kwa sababu "bidhaa zangu zitafutwa!" Suluhisho: Panga jaribio hili lote mwanzoni. Pia una majaribio ya vitengo ambayo hufanya dhihaka. Kwa hivyo, fanya kwa kiwango cha kina ambapo una njia ya mawasiliano ambayo haidhuru uendeshaji wa biashara.

Kiwango cha miundombinu

Ufuatiliaji wa miundombinu ni jambo ambalo limezingatiwa kwa muda mrefu kama ufuatiliaji wenyewe.

• Ufuatiliaji wa miundombinu unaweza na unapaswa kuzinduliwa kama mchakato tofauti.
• Hupaswi kuanza na ufuatiliaji wa miundombinu kwenye mradi unaoendeshwa, hata kama unataka kweli. Huu ni uchungu kwa waabudu wote. "Kwanza nitafuatilia nguzo, nitafuatilia miundombinu" - i.e. Kwanza, itafuatilia kile kilicho chini, lakini haitaingia kwenye programu. Kwa sababu maombi ni jambo lisiloeleweka kwa waabudu. Ilivuja kwake, na haelewi jinsi inavyofanya kazi. Lakini anaelewa miundombinu na anaanza nayo. Lakini hapana - daima unahitaji kufuatilia maombi kwanza.
• Usizidishe idadi ya arifa. Kwa kuzingatia ugumu wa mifumo ya kisasa, arifu zinaruka kila wakati, na lazima kwa njia fulani uishi na kundi hili la arifa. Na mtu anayepigiwa simu, akiangalia mamia ya arifa zinazofuata, ataamua "Sitaki kufikiria juu yake." Arifa zinafaa tu kuarifu kuhusu mambo muhimu.

Kiwango cha maombi kama kitengo cha biashara

Mambo muhimu:

• ELK. Hiki ndicho kiwango cha sekta. Ikiwa kwa sababu fulani haukusanyi magogo, anza kufanya hivyo mara moja.
• APM. APM za Nje kama njia ya kufunga ufuatiliaji wa programu haraka (NewRelic, BlackFire, Datadog). Unaweza kusakinisha kitu hiki kwa muda ili angalau kwa namna fulani uelewe kinachoendelea kwako.
• Kufuatilia. Katika kadhaa ya huduma ndogo, lazima ufuate kila kitu, kwa sababu ombi haliishi tena peke yake. Ni vigumu sana kuongeza baadaye, hivyo ni bora mara moja kupanga ufuatiliaji katika maendeleo - hii ni kazi na matumizi ya watengenezaji. Ikiwa bado haujaitekeleza, itekeleze! Tazama Jaeger/Zipkin

Kutahadharisha

• Mpangilio wa mfumo wa arifa: katika hali ya ufuatiliaji wa vitu vingi, kunapaswa kuwa na mfumo uliounganishwa wa kutuma arifa. Unaweza huko Grafana. Katika nchi za Magharibi, kila mtu hutumia PagerDuty. Tahadhari zinapaswa kuwa wazi (km zilitoka wapi...). Na inashauriwa kudhibiti kwamba arifa zinapokelewa kabisa
• Shirika la mfumo wa wajibu: tahadhari hazipaswi kutumwa kwa kila mtu (ama kila mtu ataitikia katika umati, au hakuna mtu atakayeguswa). Watengenezaji pia wanahitaji kuwa kwenye simu: hakikisha unafafanua maeneo ya uwajibikaji, fanya maagizo wazi na uandike ndani yake ni nani wa kupiga simu Jumatatu na Jumatano, na ni nani wa kupiga simu Jumanne na Ijumaa (vinginevyo hawatampigia mtu yeyote hata kwenye tukio la shida kubwa - wataogopa kukuamsha au kukusumbua : watu kwa ujumla hawapendi kupiga simu na kuamsha watu wengine, haswa usiku). Na ueleze kwamba kuomba msaada sio kiashiria cha kutokuwa na uwezo ("Ninaomba msaada, hiyo ina maana mimi ni mfanyakazi mbaya"), kuhimiza maombi ya usaidizi.
• Mpangilio wa "msingi wa maarifa" na mtiririko wa kazi kwa usindikaji wa tukio: kwa kila tukio kubwa, uchunguzi wa maiti unapaswa kupangwa, na kama hatua ya muda, hatua ambazo zitasuluhisha tukio zinapaswa kurekodiwa. Na fanya mazoea kwamba kutahadharisha mara kwa mara ni dhambi; zinahitaji kurekebishwa katika kanuni au kazi ya miundombinu.

Mkusanyiko wa teknolojia

Wacha tufikirie kuwa safu yetu ni kama ifuatavyo.

• ukusanyaji wa data - Prometheus + Grafana;
• uchambuzi wa logi - ELK;
• kwa APM au Kufuatilia - Jaeger (Zipkin).

Uchaguzi wa chaguzi sio muhimu. Kwa sababu ikiwa mwanzoni ulielewa jinsi ya kufuatilia mfumo na kuandika mpango, basi unaanza kuchagua zana zinazofaa mahitaji yako. Swali ni nini ulichagua kufuatilia hapo kwanza. Kwa sababu labda chombo ulichochagua mwanzoni hakiendani na mahitaji yako hata kidogo.

Mambo machache ya kiufundi ambayo ninaona kila mahali hivi majuzi:

Prometheus anasukumwa ndani ya Kubernetes - ni nani aliyekuja na hii?! Ikiwa nguzo yako itaanguka, utafanya nini? Ikiwa una nguzo tata ndani, basi kunapaswa kuwa na aina fulani ya mfumo wa ufuatiliaji ndani ya nguzo, na baadhi ya nje, ambayo itakusanya data kutoka ndani ya nguzo.

Ndani ya nguzo tunakusanya magogo na kila kitu kingine. Lakini mfumo wa ufuatiliaji lazima uwe nje. Mara nyingi sana, katika nguzo ambapo kuna Promtheus imewekwa ndani, pia kuna mifumo inayofanya ukaguzi wa nje wa uendeshaji wa tovuti. Je, ikiwa miunganisho yako kwa ulimwengu wa nje imeshuka na programu haifanyi kazi? Inabadilika kuwa kila kitu kiko sawa ndani, lakini haifanyi mambo kuwa rahisi kwa watumiaji.

Matokeo

• Maendeleo ya ufuatiliaji sio usakinishaji wa huduma, lakini ukuzaji wa bidhaa ya programu. 98% ya ufuatiliaji wa leo ni usimbaji. Kuweka misimbo katika huduma, kusimba hundi za nje, kuangalia huduma za nje, na ndivyo tu.
• Usipoteze muda wa wasanidi programu wako kwa ufuatiliaji: inaweza kuchukua hadi 30% ya kazi yao, lakini inafaa.
• Devops, usijali kwamba huwezi kufuatilia kitu, kwa sababu baadhi ya mambo ni njia tofauti kabisa ya kufikiri. Hukuwa mtayarishaji programu, na kazi ya ufuatiliaji ndiyo kazi yao hasa.
• Ikiwa mradi tayari unaendeshwa na haufuatiliwi (na wewe ni meneja), tenga rasilimali za ufuatiliaji.
• Ikiwa bidhaa tayari iko katika uzalishaji, na wewe ni mshiriki ambaye aliambiwa "kuweka ufuatiliaji" - jaribu kuelezea usimamizi kile nilichoandika juu yake.

Hili ni toleo lililopanuliwa la ripoti katika mkutano wa Saint Highload++.

Ikiwa una nia ya mawazo na mawazo yangu juu yake na mada zinazohusiana, basi hapa unaweza soma kituo 🙂

Chanzo: mapenzi.com