ProHoster > Blogs > Administrācija > Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

KopÅ” 2008. gada mÅ«su uzņēmums galvenokārt nodarbojas ar infrastruktÅ«ras pārvaldÄ«bu un diennakts tehnisko atbalstu tÄ«mekļa projektiem: mums ir vairāk nekā 400 klientu, kas ir aptuveni 15% no Krievijas e-komercijas. AttiecÄ«gi tiek atbalstÄ«ta ļoti daudzveidÄ«ga arhitektÅ«ra. Ja kaut kas nokrÄ«t, mums tas ir jānovērÅ” 15 minÅ«Å”u laikā. Bet, lai saprastu, ka ir noticis negadÄ«jums, ir jāuzrauga projekts un jāreaģē uz incidentiem. Kā to izdarÄ«t?

Uzskatu, ka ir problēmas ar pareizas uzraudzÄ«bas sistēmas organizÄ“Å”anu. Ja nebÅ«tu bijuÅ”as problēmas, tad mana runa sastāvētu no vienas tēzes: "LÅ«dzu, instalējiet Prometheus + Grafana un spraudņus 1, 2, 3." Diemžēl tā vairs nedarbojas. Un galvenā problēma ir tā, ka programmatÅ«ras komponentu ziņā visi turpina ticēt kaut kam, kas pastāvēja 2008. gadā.

Runājot par uzraudzÄ«bas sistēmas organizāciju, es atļauÅ”os apgalvot, ka... projekti ar kompetentu uzraudzÄ«bu neeksistē. Un situācija ir tik slikta, ka, ja kaut kas nokrÄ«t, pastāv risks, ka tas paliks nepamanÄ«ts - galu galā visi ir pārliecināti, ka ā€œviss tiek uzraudzÄ«tsā€.
Varbūt viss tiek uzraudzīts. Bet kā?

Mēs visi esam saskāruÅ”ies ar Ŕādu stāstu: konkrēts devops, noteikts administrators strādā, pie viņiem pienāk izstrādes komanda un saka - "esam atbrÄ«voti, tagad uzraugiet." UzraudzÄ«t ko? Kā tas strādā?

LABI. Mēs uzraugām vecmodīgi. Un tas jau mainās, un izrādās, ka jūs uzraudzījāt pakalpojumu A, kas kļuva par pakalpojumu B, kas mijiedarbojas ar pakalpojumu C. Bet izstrādes komanda jums saka: "Instalējiet programmatūru, tai jāuzrauga viss!"

Kas tad ir mainījies? - Viss ir mainījies!

2008. gads Viss ir kārtībā

Ir pāris izstrādātāju, viens serveris, viens datu bāzes serveris. Tas viss iet no Å”ejienes. Mums ir neliela informācija, mēs uzstādām zabbix, Nagios, kaktusus. Un tad mēs iestatām skaidrus brÄ«dinājumus par centrālo procesoru, par diska darbÄ«bu un vietu diskā. Mēs arÄ« veicam dažas manuālas pārbaudes, lai pārliecinātos, ka vietne reaģē un pasÅ«tÄ«jumi nonāk datu bāzē. Un tas arÄ« viss ā€“ mēs esam vairāk vai mazāk aizsargāti.

Ja salÄ«dzina darba apjomu, ko administrators toreiz veica, lai nodroÅ”inātu monitoringu, tad 98% no tā bija automātiski: personai, kas veic monitoringu, ir jāsaprot, kā instalēt Zabbix, kā to konfigurēt un konfigurēt brÄ«dinājumus. Un 2% - par ārējām pārbaudēm: vai vietne atbild un veic pieprasÄ«jumu datu bāzei, ka ir ienākuÅ”i jauni pasÅ«tÄ«jumi.

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

2010. gads Slodze pieaug

Mēs sākam mērogot tÄ«mekli, pievienojot meklētājprogrammu. Mēs vēlamies pārliecināties, ka preču katalogā ir visas preces. Un Ŕī produktu meklÄ“Å”ana darbojas. Ka datu bāze darbojas, ka tiek veikti pasÅ«tÄ«jumi, ka vietne reaģē ārēji un atbild no diviem serveriem un lietotājs netiek izmests no vietnes, kamēr tā tiek pārbalansēta uz citu serveri utt. Ir vairāk entÄ«tiju.

Turklāt ar infrastruktÅ«ru saistÄ«tā vienÄ«ba joprojām ir lielākā pārvaldnieka galvā. Manā galvā joprojām ir doma, ka tas, kurÅ” veic monitoringu, ir tas, kurÅ” uzstādÄ«s zabbix un varēs to konfigurēt.

Bet tajā paŔā laikā parādās darbs pie ārējo pārbaužu veikÅ”anas, meklÄ“Å”anas indeksētāja vaicājumu skriptu kopas izveidoÅ”anas, skriptu kopas, lai pārbaudÄ«tu, vai meklÄ“Å”ana mainās indeksÄ“Å”anas procesa laikā, skriptu kopa, kas pārbauda, ā€‹ā€‹vai preces tiek pārsÅ«tÄ«tas uz piegādes pakalpojums utt. un tā tālāk.

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

PiezÄ«me: es uzrakstÄ«ju ā€œskriptu kopuā€ 3 reizes. Tas ir, par uzraudzÄ«bu atbildÄ«gā persona vairs nav tā, kas vienkārÅ”i instalē zabbix. Tas ir cilvēks, kurÅ” sāk kodēt. Taču komandas prātos nekas vēl nav mainÄ«jies.

Bet pasaule mainās, kļūst arvien sarežģītāka. Tiek pievienots virtualizācijas slānis un vairākas jaunas sistēmas. Viņi sāk mijiedarboties viens ar otru. KurÅ” teica: "smaržo pēc mikropakalpojumiem?" Bet katrs pakalpojums joprojām izskatās kā vietne atseviŔķi. Mēs varam tajā vērsties un saprast, ka tas sniedz nepiecieÅ”amo informāciju un darbojas pats no sevis. Un, ja jÅ«s esat administrators, kas pastāvÄ«gi iesaistās projektā, kas attÄ«stās 5-7-10 gadus, Ŕīs zināŔanas uzkrājas: parādās jauns lÄ«menis - jÅ«s to sapratāt, parādās cits lÄ«menis - jÅ«s to sapratāt...

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

Bet reti kurÅ” pavada projektu 10 gadus.

Monitoringman CV

Pieņemsim, ka esat nonācis pie jauna starta, kas nekavējoties nolÄ«ga 20 izstrādātājus, uzrakstÄ«ja 15 mikropakalpojumus un esat administrators, kuram saka: ā€œBuild CI/CD. LÅ«dzu." JÅ«s esat izveidojis CI/CD un pēkŔņi dzirdat: "Mums ir grÅ«ti strādāt ar ražoÅ”anu "kubā", nesaprotot, kā lietojumprogramma tajā darbosies. Izveidojiet mums smilÅ”u kasti tajā paŔā "kubā".
Å ajā kubā jÅ«s izveidojat smilÅ”u kasti. Viņi uzreiz saka: "Mēs vēlamies posmu datu bāzi, kas tiek atjaunināta katru dienu no ražoÅ”anas, lai mēs saprastu, ka tā darbojas datu bāzē, bet tajā paŔā laikā nesabojātu ražoÅ”anas datu bāzi."

JÅ«s dzÄ«vojat tajā visā. LÄ«dz izlaiÅ”anai atlikuÅ”as 2 nedēļas, viņi saka: ā€œTagad uzraudzÄ«sim visu Å”o...ā€ Tas ir. uzraudzÄ«t klastera infrastruktÅ«ru, uzraudzÄ«t mikropakalpojumu arhitektÅ«ru, pārraudzÄ«t darbu ar ārējiem pakalpojumiem...

Un kolēģi ņem ārā no galvas ierasto shēmu un saka: ā€œNu, te viss skaidrs! Instalējiet programmu, kas to visu uzraudzÄ«s. Jā, jā: Prometheus + Grafana + spraudņi.
Un viņi piebilst: "Jums ir divas nedēļas, pārliecinieties, ka viss ir droÅ”s."

Daudzos projektos, ko mēs redzam, uzraudzÄ«bai tiek atvēlēts viens cilvēks. Iedomājieties, ka mēs vēlamies nolÄ«gt cilvēku, kas veiktu monitoringu uz 2 nedēļām, un mēs uzrakstām viņam CV. Kādām prasmēm vajadzētu bÅ«t Å”im cilvēkam, ņemot vērā visu, ko mēs lÄ«dz Å”im esam teikuÅ”i?

  • Viņam jāsaprot dzelzs infrastruktÅ«ras uzraudzÄ«ba un darbÄ«bas specifika.
  • Viņam ir jāsaprot Kubernetes uzraudzÄ«bas specifika (un visi vēlas iet uz "kubu", jo jÅ«s varat abstrahēties no visa, paslēpties, jo ar pārējo tiks galā administrators) - sevi, tās infrastruktÅ«ru un saprast, kā uzraudzÄ«t lietojumprogrammas. iekŔā.
  • Viņam jāsaprot, ka dienesti savā starpā sazinās Ä«paÅ”os veidos, un jāzina pakalpojumu savstarpējās mijiedarbÄ«bas specifika. PilnÄ«gi iespējams redzēt projektu, kur daži servisi sazinās sinhroni, jo savādāk nevar. Piemēram, aizmugursistēma, izmantojot REST, caur gRPC dodas uz kataloga pakalpojumu, saņem produktu sarakstu un atgriež to atpakaļ. JÅ«s nevarat gaidÄ«t Å”eit. Un ar citiem pakalpojumiem tas darbojas asinhroni. PārsÅ«tÄ«t pasÅ«tÄ«jumu piegādes dienestam, nosÅ«tÄ«t vēstuli utt.
    Tu laikam jau esi nopeldējies no Ŕī visa? Un administrators, kuram tas jāuzrauga, kļuva vēl vairāk apmulsis.
  • Viņam jāprot pareizi plānot un plānot ā€“ jo darbu kļūst arvien vairāk.
  • Tāpēc viņam ir jāizveido stratēģija no izveidotā pakalpojuma, lai saprastu, kā to Ä«paÅ”i uzraudzÄ«t. Viņam nepiecieÅ”ama izpratne par projekta arhitektÅ«ru un tā attÄ«stÄ«bu + izpratne par izstrādē izmantotajām tehnoloÄ£ijām.

Atcerēsimies pilnÄ«gi normālu gadÄ«jumu: daži pakalpojumi ir PHP, daži pakalpojumi ir Go, daži pakalpojumi ir JS. Viņi kaut kā strādā viens ar otru. No Å”ejienes nāk termins ā€œmikropakalpojumsā€: ir tik daudz atseviŔķu sistēmu, ka izstrādātāji nevar saprast projektu kopumā. Viena daļa no komandas raksta pakalpojumus JS, kas darbojas paÅ”i un nezina, kā darbojas pārējā sistēma. Otra daļa raksta pakalpojumus Python un netraucē citu pakalpojumu darbÄ«bu; tie ir izolēti savā apgabalā. TreÅ”ais ir pakalpojumu rakstÄ«Å”ana PHP vai kaut ko citu.
Visi Å”ie 20 cilvēki ir sadalÄ«ti 15 pakalpojumos, un ir tikai viens administrators, kuram tas viss ir jāsaprot. Stop! mēs vienkārÅ”i sadalÄ«jām sistēmu 15 mikropakalpojumos, jo 20 cilvēki nevar saprast visu sistēmu.

Bet tas kaut kā jāuzrauga...

Kāds ir rezultāts? Rezultātā ir viens cilvēks, kurÅ” izdomā visu, ko nevar saprast visa izstrādātāju komanda, un tajā paŔā laikā viņam ir arÄ« jāzina un jāspēj izdarÄ«t tas, ko mēs iepriekÅ” norādÄ«jām - aparatÅ«ras infrastruktÅ«ra, Kubernetes infrastruktÅ«ra utt.

Ko lai saka... Hjūstona, mums ir problēmas.

Mūsdienu programmatūras projekta uzraudzība ir programmatūras projekts pats par sevi

No maldÄ«giem uzskatiem, ka uzraudzÄ«ba ir programmatÅ«ra, mēs veidojam ticÄ«bu brÄ«numiem. Bet brÄ«numi, diemžēl, nenotiek. JÅ«s nevarat instalēt zabbix un gaidÄ«t, ka viss darbosies. Nav jēgas instalēt Grafānu un cerēt, ka viss bÅ«s ok. Lielākā daļa laika tiks veltÄ«ta pakalpojumu darbÄ«bas un to savstarpējās mijiedarbÄ«bas pārbaužu organizÄ“Å”anai, pārbaudot, kā darbojas ārējās sistēmas. PatiesÄ«bā 90% laika tiks veltÄ«ts nevis skriptu rakstÄ«Å”anai, bet gan programmatÅ«ras izstrādei. Un tas bÅ«tu jārisina komandai, kas saprot projekta darbu.
Ja Å”ajā situācijā viens cilvēks tiek iemests uzraudzÄ«bā, tad notiks katastrofa. Kas arÄ« notiek visur.

Piemēram, ir vairāki pakalpojumi, kas savā starpā sazinās, izmantojot Kafka. Pasūtījums atnāca, nosūtījām Kafkai ziņu par pasūtījumu. Ir pakalpojums, kas noklausās informāciju par pasūtījumu un nosūta preces. Ir serviss, kas noklausās informāciju par pasūtījumu un nosūta lietotājam vēstuli. Un tad parādās vēl daudz pakalpojumu, un mēs sākam apjukt.

Un, ja jÅ«s to nododat arÄ« administratoram un izstrādātājiem posmā, kad lÄ«dz izlaiÅ”anai ir atlicis Ä«ss laiks, personai bÅ«s jāsaprot viss protokols. Tie. Šāda mēroga projekts aizņem ievērojamu laiku, un tas ir jāņem vērā sistēmas izstrādē.
Taču ļoti bieži, it Ä«paÅ”i jaunuzņēmumos, redzam, kā uzraudzÄ«ba tiek atlikta uz vēlāku laiku. ā€œTagad mēs izveidosim Proof of Concept, mēs ar to startēsim, ļaujiet tam nokrist - mēs esam gatavi upurēties. Un tad mēs to visu uzraudzÄ«sim.ā€ Kad (vai ja) projekts sāk pelnÄ«t naudu, uzņēmums vēlas pievienot vēl vairāk funkciju - jo tas ir sācis darboties, tāpēc tas ir jāattÄ«sta tālāk! Un jÅ«s esat tajā brÄ«dÄ«, kad vispirms ir jāuzrauga viss iepriekŔējais, kas aizņem nevis 1% laika, bet daudz vairāk. Un, starp citu, uzraudzÄ«bai bÅ«s nepiecieÅ”ami izstrādātāji, un viņiem ir vieglāk ļaut strādāt pie jaunām funkcijām. Rezultātā tiek rakstÄ«tas jaunas funkcijas, viss tiek sabojāts, un jÅ«s nonākat bezgalÄ«gā strupceļā.

Tātad, kā pārraudzīt projektu, sākot no sākuma, un ko darīt, ja saņemat projektu, kas ir jāuzrauga, bet nezināt, ar ko sākt?

Pirmkārt, jums ir jāplāno.

Liriska atkāpe: ļoti bieži tās sākas ar infrastruktÅ«ras uzraudzÄ«bu. Piemēram, mums ir Kubernetes. Sāksim ar Prometheus instalÄ“Å”anu ar Grafana, instalējot spraudņus ā€œkubaā€ uzraudzÄ«bai. Ne tikai izstrādātājiem, bet arÄ« administratoriem ir neveiksmÄ«ga prakse: "Mēs instalēsim Å”o spraudni, bet spraudnis, iespējams, zina, kā to izdarÄ«t." Cilvēkiem patÄ«k sākt ar vienkārÅ”u un saprotamu, nevis ar svarÄ«gām darbÄ«bām. Un infrastruktÅ«ras uzraudzÄ«ba ir vienkārÅ”a.

Vispirms izlemiet, ko un kā vēlaties pārraudzÄ«t, un pēc tam atlasiet rÄ«ku, jo citi cilvēki nevar domāt jÅ«su vietā. Un vai viņiem vajadzētu? Citi cilvēki domāja par universālu sistēmu vai vispār nedomāja, kad tika rakstÄ«ts Å”is spraudnis. Un tas, ka Å”im spraudnim ir 5 tÅ«kstoÅ”i lietotāju, nenozÄ«mē, ka tas ir noderÄ«gs. Iespējams, jÅ«s kļūsiet par 5001. vienkārÅ”i tāpēc, ka tur jau iepriekÅ” bija 5000 cilvēku.

Ja sākat uzraudzÄ«t infrastruktÅ«ru un jÅ«su lietojumprogrammas aizmugure pārstāj reaģēt, visi lietotāji zaudēs savienojumu ar mobilo lietojumprogrammu. ParādÄ«sies kļūda. Viņi nāks pie jums un teiks: "Aplikācija nedarbojas, ko jÅ«s Å”eit darāt?" - "Mēs uzraugām." ā€” "Kā jÅ«s uzraugāt, ja neredzat, ka lietojumprogramma nedarbojas?!"

  1. Es uzskatu, ka jums ir jāsāk uzraudzÄ«ba tieÅ”i no lietotāja ieejas punkta. Ja lietotājs neredz, ka lietojumprogramma darbojas, tas ir, tā ir kļūme. Un uzraudzÄ«bas sistēmai par to vispirms vajadzētu brÄ«dināt.
  2. Un tikai tad mēs varam uzraudzÄ«t infrastruktÅ«ru. Vai arÄ« dariet to paralēli. Ar infrastruktÅ«ru tas ir vienkārŔāk ā€” Å”eit mēs beidzot varam vienkārÅ”i instalēt zabbix.
  3. Un tagad jums ir jāiet pie lietojumprogrammas saknēm, lai saprastu, kur lietas nedarbojas.

Mana galvenā doma ir tāda, ka uzraudzÄ«bai jānotiek paralēli izstrādes procesam. Ja novērsÄ«sit uzraudzÄ«bas komandas uzmanÄ«bu uz citiem uzdevumiem (CI/CD izveide, smilÅ”kastes izveide, infrastruktÅ«ras reorganizācija), uzraudzÄ«ba sāks aizkavēties, un jÅ«s, iespējams, nekad nepanāksit attÄ«stÄ«bu (vai agrāk vai vēlāk jums tas bÅ«s jāpārtrauc).

Viss pēc līmeņiem

Tā es redzu uzraudzības sistēmas organizāciju.

1) Lietojuma līmenis:

  • lietojumprogrammu biznesa loÄ£ikas uzraudzÄ«ba;
  • pakalpojumu veselÄ«bas rādÄ«tāju uzraudzÄ«ba;
  • integrācijas uzraudzÄ«ba.

2) Infrastruktūras līmenis:

  • orÄ·estrācijas lÄ«meņa uzraudzÄ«ba;
  • sistēmas programmatÅ«ras uzraudzÄ«ba;
  • dzelzs lÄ«meņa uzraudzÄ«ba.

3) Atkal lietojuma lÄ«menis ā€” bet kā inženierijas produkts:

  • lietojumprogrammu žurnālu apkopoÅ”ana un uzraudzÄ«ba;
  • APM;
  • izsekoÅ”ana.

4) Brīdinājums:

  • brÄ«dināŔanas sistēmas organizÄ“Å”ana;
  • dežūras sistēmas organizÄ“Å”ana;
  • ā€œzināŔanu bāzesā€ un darbplÅ«smas organizÄ“Å”ana incidentu apstrādei.

Tas ir svarÄ«gi: pie brÄ«dinājuma nonākam nevis pēc, bet uzreiz! Nav nepiecieÅ”ams uzsākt uzraudzÄ«bu un ā€œkaut kā vēlākā€ noskaidrot, kurÅ” saņems brÄ«dinājumus. Galu galā, kāds ir uzraudzÄ«bas uzdevums: saprast, kur sistēmā kaut kas nedarbojas, un informēt par to pareizajiem cilvēkiem. Ja atstāsit to lÄ«dz beigām, tad pareizie cilvēki uzzinās, ka kaut kas nav kārtÄ«bā, tikai nosaucot ā€œmums nekas nelÄ«dzā€.

Lietojumprogrammu slānis ā€” biznesa loÄ£ikas uzraudzÄ«ba

Å eit mēs runājam par paÅ”a fakta pārbaudi, vai lietojumprogramma darbojas lietotāja labā.

Šis līmenis jāveic izstrādes posmā. Piemēram, mums ir nosacīts Prometheus: tas iet uz serveri, kas veic pārbaudes, izvelk galapunktu, bet galapunkts pārbauda API.

Kad bieži tiek lÅ«gts pārraudzÄ«t sākumlapu, lai pārliecinātos, ka vietne darbojas, programmētāji dod rokturi, kuru var pavilkt ikreiz, kad nepiecieÅ”ams, lai pārliecinātos, ka API darbojas. Un programmētāji Å”obrÄ«d joprojām ņem un raksta /api/test/helloworld
Vienīgais veids, kā pārliecināties, ka viss darbojas? - Nē!

  • Šādu pārbaužu izveide bÅ«tÄ«bā ir izstrādātāju uzdevums. VienÄ«bas testi jāraksta programmētājiem, kuri raksta kodu. Tā kā, ja jÅ«s to noplÅ«dÄ«sit administratoram: "Draugs, Å”eit ir API protokolu saraksts visām 25 funkcijām, lÅ«dzu, uzraugiet visu!" - nekas neizdosies.
  • Ja izdrukāsiet ā€œsveiki pasauleā€, neviens nekad neuzzinās, ka API jādarbojas un tā darbojas. Katrai API izmaiņai ir jāmaina pārbaudes.
  • Ja jums jau ir Ŕāda problēma, pārtrauciet funkcijas un pieŔķiriet izstrādātājus, kas izrakstÄ«s Ŕīs pārbaudes, vai pieņems zaudējumus, piekrÄ«tiet, ka nekas netiek pārbaudÄ«ts un neizdosies.

Tehniskie padomi:

  • Noteikti organizējiet ārēju serveri, lai organizētu pārbaudes - jums ir jābÅ«t pārliecinātiem, ka jÅ«su projekts ir pieejams ārpasaulei.
  • Organizējiet pārbaudes visā API protokolā, nevis tikai atseviŔķos galapunktos.
  • Izveidojiet prometheus gala punktu ar testa rezultātiem.

Lietojumprogrammas slānis ā€“ veselÄ«bas rādÄ«tāju uzraudzÄ«ba

Tagad mēs runājam par pakalpojumu ārējo veselības rādītāju.

Mēs nolēmām, ka uzraugām visus lietojumprogrammas ā€œrokturusā€, izmantojot ārējās pārbaudes, kuras izsaucam no ārējas uzraudzÄ«bas sistēmas. Bet tie ir ā€œrokturiā€, kurus lietotājs ā€œredzā€. Mēs vēlamies bÅ«t pārliecināti, ka paÅ”i mÅ«su pakalpojumi darbojas. Å eit ir labāks stāsts: K8s ir veselÄ«bas pārbaudes, lai vismaz pats "kubs" varētu pārliecināties, ka pakalpojums darbojas. Bet puse no čekiem, ko esmu redzējis, ir tas pats drukātais "sveika pasaule". Tie. Tāpēc viņŔ velk vienu reizi pēc izvietoÅ”anas, viņŔ atbildēja, ka viss ir kārtÄ«bā - tas arÄ« viss. Un pakalpojumam, ja tas nodroÅ”ina savu API, ir ļoti daudz ieejas punktu Å”ai paÅ”ai API, kas arÄ« ir jāuzrauga, jo mēs vēlamies zināt, ka tas darbojas. Un mēs to jau uzraugām iekŔā.

Kā to pareizi tehniski ieviest: katrs pakalpojums parāda galapunktu par tā paÅ”reizējo veiktspēju, un Grafana (vai jebkuras citas lietojumprogrammas) grafikos mēs redzam visu pakalpojumu statusu.

  • Katrai API izmaiņai ir jāmaina pārbaudes.
  • Nekavējoties izveidojiet jaunu pakalpojumu ar veselÄ«bas rādÄ«tājiem.
  • Administrators var nākt pie izstrādātājiem un lÅ«gt ā€œpievienot man pāris lÄ«dzekļus, lai es visu saprastu un pievienotu informāciju par to manai uzraudzÄ«bas sistēmaiā€. Bet izstrādātāji parasti atbild: "Mēs neko nepievienosim divas nedēļas pirms izlaiÅ”anas."
    Dariet zināmu attÄ«stÄ«bas vadÄ«tājiem, ka bÅ«s Ŕādi zaudējumi, dariet to zināmu arÄ« izstrādes vadÄ«tāju vadÄ«bai. Jo, kad viss nokrÄ«t, kāds joprojām zvanÄ«s un pieprasÄ«s uzraudzÄ«t "pastāvÄ«gi krÄ«toÅ”o pakalpojumu" (c)
  • Starp citu, pieŔķiriet izstrādātājiem Grafana spraudņu rakstÄ«Å”anu - tas bÅ«s labs palÄ«gs administratoriem.

Lietojumprogrammu slānis ā€” integrācijas uzraudzÄ«ba

Integrācijas uzraudzība ir vērsta uz sakaru pārraudzību starp biznesam kritiskām sistēmām.

Piemēram, ir 15 pakalpojumi, kas sazinās savā starpā. Å Ä«s vairs nav atseviŔķas vietnes. Tie. mēs nevaram izvilkt pakalpojumu pats par sevi, iegÅ«t /helloworld un saprast, ka pakalpojums darbojas. Tā kā pasÅ«tÄ«Å”anas tÄ«mekļa servisam ir jānosÅ«ta informācija par pasÅ«tÄ«jumu uz autobusu - no autobusa, noliktavas dienestam jāsaņem Å”is ziņojums un jāstrādā ar to tālāk. Un e-pasta izplatÄ«Å”anas pakalpojumam tas kaut kā tālāk ir jāapstrādā utt.

AttiecÄ«gi mēs nevaram saprast, bakstoties uz katru atseviŔķu servisu, ka tas viss darbojas. Jo mums ir noteikts autobuss, caur kuru viss sazinās un mijiedarbojas.
Tāpēc Å”im posmam vajadzētu iezÄ«mēt pakalpojumu testÄ“Å”anas posmu mijiedarbÄ«bai ar citiem pakalpojumiem. Nav iespējams organizēt komunikācijas uzraudzÄ«bu, uzraugot ziņojumu brokeri. Ja ir pakalpojums, kas izsniedz datus, un pakalpojums, kas tos saņem, uzraugot brokeri, mēs redzēsim tikai datus, kas lido no vienas puses uz otru. Pat ja mums kaut kā izdevās iekŔēji uzraudzÄ«t Å”o datu mijiedarbÄ«bu - ka kāds ražotājs ievieto datus, kāds tos nolasa, Ŕī plÅ«sma turpina iet uz Kafku - tas mums joprojām nesniegs informāciju, ja viens dienests nosÅ«tÄ«ja ziņojumu vienā versijā. , bet otrs pakalpojums Å”o versiju nesagaidÄ«ja un to izlaida. Mēs par to neuzzināsim, jo ā€‹ā€‹dienesti mums pateiks, ka viss darbojas.

Ko iesaku darīt:

  • Sinhronai saziņai: galapunkts veic pieprasÄ«jumus saistÄ«tajiem pakalpojumiem. Tie. mēs ņemam Å”o beigu punktu, ievelkam skriptu servisa iekÅ”ienē, kas iet uz visiem punktiem un saka ā€œEs varu vilkt tur, un vilkt tur, es varu vilkt tur...ā€
  • Asinhronai komunikācijai: ienākoÅ”ie ziņojumi ā€” galapunkts pārbauda, ā€‹ā€‹vai kopnē nav testa ziņojumu, un parāda apstrādes statusu.
  • Asinhronai komunikācijai: izejoÅ”ie ziņojumi - galapunkts nosÅ«ta testa ziņojumus uz kopni.

Kā tas parasti notiek: mums ir pakalpojums, kas iemet datus autobusā. Mēs nākam uz Å”o pakalpojumu un lÅ«dzam pastāstÄ«t mums par tā integrācijas stāvokli. Un, ja pakalpojumam ir jārada ziņojums kaut kur tālāk (WebApp), tas izveidos Å”o testa ziņojumu. Un, ja mēs palaižam pakalpojumu OrderProcessing pusē, tas vispirms ievieto to, ko var ievietot neatkarÄ«gi, un, ja ir dažas atkarÄ«gas lietas, tad tas nolasa testa ziņojumu kopu no autobusa, saprot, ka var tos apstrādāt, ziņot un , ja vajag, ievieto tos tālāk, un par Å”o viņŔ saka - viss ir ok, esmu dzÄ«vs.

Ä»oti bieži mēs dzirdam jautājumu "kā mēs varam to pārbaudÄ«t ar kaujas datiem?" Piemēram, mēs runājam par vienu un to paÅ”u pasÅ«tÄ«Å”anas pakalpojumu. PasÅ«tÄ«jums nosÅ«ta ziņojumus uz noliktavu, kurā preces tiek norakstÄ«tas: mēs nevaram to pārbaudÄ«t uz kaujas datiem, jo ā€‹ā€‹"manas preces tiks norakstÄ«tas!" Risinājums: plānojiet visu Å”o pārbaudi jau paŔā sākumā. Jums ir arÄ« vienÄ«bu testi, kas izsmejas. Tāpēc dariet to dziļākā lÄ«menÄ«, kur jums ir komunikācijas kanāls, kas nekaitē uzņēmuma darbÄ«bai.

Infrastruktūras līmenis

Infrastruktūras uzraudzība jau sen tiek uzskatīta par paŔu uzraudzību.

  • InfrastruktÅ«ras uzraudzÄ«bu var un vajag uzsākt kā atseviŔķu procesu.
  • Jums nevajadzētu sākt ar esoŔā projekta infrastruktÅ«ras uzraudzÄ«bu, pat ja jÅ«s patieŔām vēlaties. Tas ir sāpes visiem devops. ā€œVispirms uzraudzÄ«Å”u klasteri, uzraudzÄ«Å”u infrastruktÅ«ruā€ ā€“ t.i. Pirmkārt, tas pārraudzÄ«s to, kas atrodas zemāk, bet neiedziļinās lietojumprogrammā. Jo aplikācija devopiem ir nesaprotama lieta. Tas viņam tika nopludināts, un viņŔ nesaprot, kā tas darbojas. Bet viņŔ saprot infrastruktÅ«ru un sāk ar to. Bet nē - vispirms vienmēr ir jāuzrauga lietojumprogramma.
  • NepārspÄ«lējiet ar brÄ«dinājumu skaitu. Ņemot vērā mÅ«sdienu sistēmu sarežģītÄ«bu, brÄ«dinājumi nepārtraukti lido, un jums ir kaut kā jāsadzÄ«vo ar Å”o brÄ«dinājumu kopumu. Un dežūrpersona, apskatÄ«jusi simts nākamo brÄ«dinājumu, nolems: ā€œEs nevēlos par to domātā€. BrÄ«dinājumiem vajadzētu ziņot tikai par kritiskām lietām.

Lietojumprogrammas līmenis kā biznesa vienība

Galvenie punkti:

  • ELK. Å is ir nozares standarts. Ja kāda iemesla dēļ neapkopojat žurnālus, sāciet to darÄ«t nekavējoties.
  • APM. Ārējie APM kā veids, kā ātri aizvērt lietojumprogrammu uzraudzÄ«bu (NewRelic, BlackFire, Datadog). Varat uz laiku instalēt Å”o lietu, lai vismaz kaut kā saprastu, kas ar jums notiek.
  • IzsekoÅ”ana. Desmitiem mikropakalpojumu viss ir jāizseko, jo pieprasÄ«jums vairs nedzÄ«vo pats no sevis. To ir ļoti grÅ«ti pievienot vēlāk, tāpēc labāk ir nekavējoties ieplānot izsekoÅ”anu izstrādes laikā - tas ir izstrādātāju darbs un lietderÄ«ba. Ja vēl neesi to ieviesis, tad ievies! SkatÄ«t Jēgeru/Zipkinu

Brīdinājums

  • Paziņojumu sistēmas organizācija: daudzu lietu uzraudzÄ«bas apstākļos vajadzētu bÅ«t vienotai paziņojumu nosÅ«tÄ«Å”anas sistēmai. JÅ«s varat Grafānā. Rietumos visi izmanto PagerDuty. BrÄ«dinājumiem jābÅ«t skaidriem (piemēram, no kurienes tie nāk...). Un vēlams kontrolēt, lai paziņojumi vispār tiktu saņemti
  • Dežūru sistēmas organizācija: brÄ«dinājumus nevajadzētu sÅ«tÄ«t visiem (vai nu visi reaģēs pÅ«lÄ«, vai arÄ« neviens nereaģēs). Izstrādātājiem arÄ« jābÅ«t dežūrām: noteikti definējiet atbildÄ«bas jomas, sniedziet skaidrus norādÄ«jumus un ierakstiet tajās, kam tieÅ”i zvanÄ«t pirmdien un treÅ”dien un kam zvanÄ«t otrdien un piektdien (pretējā gadÄ«jumā viņi nevienam nezvanÄ«s pat lielas problēmas gadÄ«jumā - viņi baidÄ«sies jÅ«s pamodināt vai traucēt: cilvēkiem parasti nepatÄ«k zvanÄ«t un modināt citus cilvēkus, it Ä«paÅ”i naktÄ«). Un paskaidrojiet, ka palÄ«dzÄ«bas lÅ«gÅ”ana nav nekompetences rādÄ«tājs (ā€œes lÅ«dzu palÄ«dzÄ«bu, tas nozÄ«mē, ka esmu slikts darbinieksā€), veiciniet palÄ«dzÄ«bas lÅ«gumus.
  • ā€œZināŔanu bāzesā€ organizÄ“Å”ana un darbplÅ«sma incidentu apstrādei: katram nopietnam incidentam ir jāplāno pēcnāves pārbaude un kā pagaidu pasākums jāreÄ£istrē darbÄ«bas, kas atrisinās incidentu. Un padariet to par praksi, ka atkārtoti brÄ«dinājumi ir grēks; tie ir jālabo kodā vai infrastruktÅ«ras darbā.

Tehnoloģiju kaudze

Iedomāsimies, ka mūsu kaudze ir Ŕāda:

  • datu vākÅ”ana - Prometejs + Grafana;
  • baļķu analÄ«ze - ELK;
  • APM vai Tracing ā€” Jaeger (Zipkin).

Vai uzraudzÄ«ba ir mirusi? ā€” Lai dzÄ«vo uzraudzÄ«ba

Opciju izvēle nav kritiska. Jo, ja sākumā sapratāt, kā uzraudzÄ«t sistēmu, un pierakstÄ«jāt plānu, tad sākat izvēlēties rÄ«kus atbilstoÅ”i savām prasÄ«bām. Jautājums ir par to, ko jÅ«s izvēlējāties pārraudzÄ«t vispirms. Jo, iespējams, sākumā izvēlētais rÄ«ks nemaz neatbilst jÅ«su prasÄ«bām.

Daži tehniski punkti, ko pēdējā laikā redzu visur:

Prometejs tiek stumts iekŔā Kubernetes - kurÅ” to izdomāja?! Ja jÅ«su klasteris avarē, ko jÅ«s darÄ«sit? Ja jums ir sarežģīts klasteris iekÅ”pusē, tad klastera iekÅ”ienē un ārpusē ir jābÅ«t kādai uzraudzÄ«bas sistēmai, kas apkopos datus no klastera iekÅ”puses.

Klastera iekÅ”pusē mēs savācam baļķus un visu pārējo. Bet uzraudzÄ«bas sistēmai jābÅ«t ārpusē. Ä»oti bieži klasterÄ«, kur iekŔēji ir uzstādÄ«ts Promtheus, ir arÄ« sistēmas, kas veic vietnes darbÄ«bas ārējās pārbaudes. Ko darÄ«t, ja jÅ«su sakari ar ārpasauli ir pārtrÅ«kuÅ”i un lietojumprogramma nedarbojas? Izrādās, ka iekŔā viss ir kārtÄ«bā, taču tas lietotājiem neatvieglo darbu.

Atzinumi

  • Izstrādes uzraudzÄ«ba nav utilÄ«tu instalÄ“Å”ana, bet gan programmatÅ«ras produkta izstrāde. 98% mÅ«sdienu monitoringa ir kodÄ“Å”ana. KodÄ“Å”ana pakalpojumos, ārējo pārbaužu kodÄ“Å”ana, ārējo pakalpojumu pārbaude un tas arÄ« viss.
  • Netērējiet savu izstrādātāju laiku uzraudzÄ«bai: tas var aizņemt lÄ«dz pat 30% no viņu darba, taču tas ir tā vērts.
  • Devops, neuztraucieties, ka nevarat kaut ko uzraudzÄ«t, jo dažas lietas ir pilnÄ«gi atŔķirÄ«gas domāŔanas veids. JÅ«s nebijāt programmētājs, un pārraudzÄ«bas darbs ir tieÅ”i viņu darbs.
  • Ja projekts jau darbojas un netiek uzraudzÄ«ts (un jÅ«s esat vadÄ«tājs), pieŔķiriet resursus uzraudzÄ«bai.
  • Ja produkts jau tiek ražots, un jÅ«s esat devops, kuram tika teikts ā€œiestatÄ«t uzraudzÄ«buā€ - mēģiniet paskaidrot vadÄ«bai, par ko es to visu rakstÄ«ju.

Å Ä« ir Saint Highload++ konferences ziņojuma paplaÅ”ināta versija.

Ja jÅ«s interesē manas idejas un domas par to un saistÄ«tajām tēmām, tad Å”eit varat lasÄ«t kanālu ????

Avots: www.habr.com

Pievieno komentāru