ProHoster > Blog > administratĂ« > Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD

Tani tema e DevOps është në bujë. Tubacioni i Integrimit dhe Ofrimit të Vazhdueshëm CI / CD të gjithë po e zbatojnë atë. Por shumica jo gjithmonë i kushtojnë vëmendjen e duhur garantimit të besueshmërisë së sistemeve të informacionit në faza të ndryshme të tubacionit CI/CD. Në këtë artikull do të doja të flisja për përvojën time në automatizimin e kontrolleve të cilësisë së softuerit dhe zbatimin e skenarëve të mundshëm për "vetë-shërimin" e tij.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Unë punoj si inxhinier në departamentin e menaxhimit të shërbimit IT të një kompanie "LANIT-Integrimi". Fusha ime kryesore e ekspertizës është zbatimi i sistemeve të ndryshme të monitorimit të performancës dhe disponueshmërisë së aplikacioneve. Unë shpesh komunikoj me klientët e IT-së nga segmente të ndryshme të tregut në lidhje me çështjet aktuale në lidhje me monitorimin e cilësisë së shërbimeve të tyre IT. Qëllimi kryesor është të minimizohet koha e ciklit të lëshimit dhe të rritet frekuenca e lëshimeve. Kjo, natyrisht, është gjithçka mirë: më shumë publikime - më shumë veçori të reja - përdorues më të kënaqur - më shumë fitim. Por në realitet, gjërat jo gjithmonë shkojnë mirë. Me norma shumë të larta të vendosjes, menjëherë lind pyetja për cilësinë e lëshimeve tona. Edhe me një tubacion plotësisht të automatizuar, një nga sfidat më të mëdha është lëvizja e shërbimeve nga testimi në prodhim pa ndikuar në kohën e përdorimit të aplikacionit dhe përvojën e përdoruesit.

Bazuar në rezultatet e bisedave të shumta me klientët, mund të them se liron kontrollin e cilësisë, problemin e besueshmërisë së aplikacionit dhe mundësinë e "vetë-shërimit" të tij (për shembull, rikthimi në një version të qëndrueshëm) në faza të ndryshme të CI /Cd pipeline janë ndër temat më emocionuese dhe më të rëndësishme.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD
Kohët e fundit, unë vetë kam punuar në anën e klientit - në shërbimin e mbështetjes së softuerit të aplikacioneve bankare në internet. Arkitektura e aplikacionit tonë përdori një numër të madh mikroshërbimesh të shkruara vetë. Gjëja më e trishtueshme është se jo të gjithë zhvilluesit mund të përballonin ritmin e lartë të zhvillimit që pësoi cilësia e disa mikroshërbimeve, gjë që shkaktoi pseudonime qesharake për ta dhe krijuesit e tyre. Kishte histori se nga çfarë materialesh ishin bërë këto produkte.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD

"Formulimi i problemit"

Frekuenca e lartë e lëshimeve dhe numri i madh i mikroshërbimeve e bëjnë të vështirë kuptimin e funksionimit të aplikacionit në tërësi, si në fazën e testimit ashtu edhe në atë operacional. Ndryshimet ndodhin vazhdimisht dhe është shumë e vështirë t'i kontrollosh ato pa mjete të mira monitorimi. Shpesh, pas një lëshimi natën në mëngjes, zhvilluesit ulen si në një fuçi pluhuri dhe presin që asgjë të mos prishet, megjithëse të gjitha kontrollet ishin të suksesshme në fazën e testimit.

Ka edhe një pikë. Në fazën e testimit, kontrollohet funksionaliteti i softuerit: zbatimi i funksioneve kryesore të aplikacionit dhe mungesa e gabimeve. Vlerësimet cilësore të performancës ose mungojnë ose nuk marrin parasysh të gjitha aspektet e aplikacionit dhe shtresën e integrimit. Disa metrika mund të mos kontrollohen fare. Si rezultat, kur ndodh një avari në një mjedis prodhimi, departamenti i mbështetjes teknike e merr vesh vetëm kur përdoruesit e vërtetë fillojnë të ankohen. Do të doja të minimizoja ndikimin e softuerit me cilësi të ulët tek përdoruesit përfundimtarë.

Një nga zgjidhjet është zbatimi i proceseve për kontrollimin e cilësisë së softuerit në faza të ndryshme të tubacionit CI/CD dhe shtimi i skenarëve të ndryshëm për rikthimin e sistemit në rast emergjence. Ne gjithashtu kujtojmë se kemi DevOps. Bizneset presin të marrin një produkt të ri sa më shpejt që të jetë e mundur. Prandaj, të gjitha kontrollet dhe skriptet tona duhet të jenë të automatizuara.

Detyra është e ndarë në dy komponentë:

  • kontrolli i cilĂ«sisĂ« sĂ« montimeve nĂ« fazĂ«n e testimit (pĂ«r tĂ« automatizuar procesin e kapjes sĂ« montimeve me cilĂ«si tĂ« ulĂ«t);
  • kontrolli i cilĂ«sisĂ« sĂ« softuerit nĂ« mjedisin e prodhimit (mekanizmat pĂ«r zbulimin automatik tĂ« problemeve dhe skenarĂ«t e mundshĂ«m pĂ«r vetĂ«-shĂ«rimin e tyre).

Mjet për monitorimin dhe mbledhjen e metrikës

Për të realizuar qëllimet e vendosura, kërkohet një sistem monitorimi që mund të zbulojë problemet dhe t'i transferojë ato në sistemet e automatizimit në faza të ndryshme të tubacionit CI/CD. Do të jetë gjithashtu një gjë pozitive nëse ky sistem ofron metrika të dobishme për ekipe të ndryshme: zhvillim, testim, funksionim. Dhe është absolutisht e mrekullueshme nëse është edhe për biznes.

Për të mbledhur metrikë, mund të përdorni një grup sistemesh të ndryshme (Prometheus, ELK Stack, Zabbix, etj.), Por, për mendimin tim, zgjidhjet e klasës APM janë më të përshtatshmet për këto detyra (Monitorimi i Performancës së Aplikimit), të cilat mund ta thjeshtojnë shumë jetën tuaj.

Si pjesë e punës sime në shërbimin mbështetës, fillova të bëj një projekt të ngjashëm duke përdorur një zgjidhje të klasës APM nga Dynatrace. Tani, duke punuar për një integrues, e njoh mjaft mirë tregun e sistemeve të monitorimit. Mendimi im subjektiv: Dynatrace është më i përshtatshmi për zgjidhjen e problemeve të tilla.
Dynatrace ofron një pamje horizontale të çdo operacioni të përdoruesit në një nivel të grimcuar deri në nivelin e ekzekutimit të kodit. Ju mund të gjurmoni të gjithë zinxhirin e ndërveprimit midis shërbimeve të ndryshme të informacionit: nga nivelet e përparme të aplikacioneve në ueb dhe celular, serverët e aplikacioneve në fund, autobusi i integrimit deri te një thirrje specifike në bazën e të dhënave.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim. NdĂ«rtimi automatik i tĂ« gjitha varĂ«sive ndĂ«rmjet komponentĂ«ve tĂ« sistemit

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim. Zbulimi automatik dhe ndĂ«rtimi i rrugĂ«s sĂ« funksionimit tĂ« shĂ«rbimit

Ne gjithashtu kujtojmë se duhet të integrohemi me mjete të ndryshme automatizimi. Këtu zgjidhja ka një API të përshtatshme që ju lejon të dërgoni dhe merrni metrika dhe ngjarje të ndryshme.

Më pas, le të kalojmë në një vështrim më të detajuar se si t'i zgjidhim këto probleme duke përdorur sistemin Dynatrace.

Detyra 1. Automatizimi i kontrollit të cilësisë së montimeve në fazën e testimit

Sfida e parë është gjetja e problemeve sa më shpejt që të jetë e mundur në tubacionin e dorëzimit të aplikacionit. Vetëm ndërtimet e kodeve "të mira" duhet të arrijnë në prodhim. Për ta bërë këtë, tubacioni juaj në fazën e testimit duhet të përfshijë monitorues shtesë për të kontrolluar cilësinë e shërbimeve tuaja.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD

Le të hedhim një vështrim hap pas hapi se si ta zbatojmë këtë dhe të automatizojmë këtë proces:

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Figura tregon rrjedhën e hapave të automatizuar të testimit të cilësisë së softuerit:

  1. vendosja e një sistemi monitorimi (instalimi i agjentëve);
  2. identifikimin e ngjarjeve për vlerësimin e cilësisë së softuerit tuaj (metrika dhe vlerat e pragut) dhe transferimi i tyre në sistemin e monitorimit;
  3. gjenerimi i testeve të ngarkesës dhe performancës;
  4. mbledhjen e të dhënave të performancës dhe disponueshmërisë në sistemin e monitorimit;
  5. transferimi i të dhënave të testimit bazuar në ngjarjet e vlerësimit të cilësisë së softuerit nga sistemi i monitorimit në sistemin CI/CD. Analiza automatike e montimeve.

Hapi 1. Vendosja e sistemit të monitorimit

Së pari, duhet të instaloni agjentë në mjedisin tuaj të testimit. Dynatrace ka një veçori të mirë: përdor një agjent universal, OneAgent, i cili instalohet në instancën e sistemit operativ (Windows, Linux, AIX), zbulon automatikisht shërbimet tuaja dhe fillon të mbledhë të dhëna monitorimi mbi to. Nuk keni nevojë të konfiguroni një agjent të veçantë për secilin proces. E njëjta gjë vlen edhe për platformat cloud dhe container. Gjithashtu mund të automatizoni procesin e instalimit të agjentit. Dynatrace përshtatet në mënyrë të përkryer në konceptin "infrastrukturë si kod" (Infrastruktura si kod ose IaC): Ka skripta dhe udhëzime të gatshme për të gjitha platformat e njohura. Ju e futni agjentin në konfigurimin e shërbimit tuaj dhe kur e vendosni atë, merrni menjëherë një shërbim të ri me një agjent tashmë që punon.

Hapi 2: Përcaktoni ngjarjet e cilësisë së softuerit tuaj

Tani ju duhet tĂ« vendosni pĂ«r listĂ«n e shĂ«rbimeve dhe operacioneve tĂ« biznesit. ËshtĂ« e rĂ«ndĂ«sishme tĂ« merren parasysh pikĂ«risht ato operacione tĂ« pĂ«rdoruesve qĂ« janĂ« kritike tĂ« biznesit pĂ«r shĂ«rbimin tuaj. KĂ«tu unĂ« rekomandoj konsultimin me analistĂ« tĂ« biznesit dhe sistemeve.

Më pas, duhet të përcaktoni se cilat metrika dëshironi të përfshini në rishikim për çdo nivel. Për shembull, kjo mund të jetë koha e ekzekutimit (e ndarë në mesatare, mesatare, përqindje, etj.), gabime (logjike, shërbimi, infrastrukture, etj.) dhe metrika të ndryshme të infrastrukturës (grumbull i kujtesës, mbledhës i mbeturinave, numërimi i fijeve, etj.).

Për automatizimin dhe lehtësinë e përdorimit nga ekipi i DevOps, shfaqet koncepti i "Monitorimit si kod". Ajo që dua të them me këtë është se një zhvillues/testues mund të shkruajë një skedar të thjeshtë JSON që përcakton matjet e sigurimit të cilësisë së softuerit.

Le të shohim një shembull të një skedari të tillë JSON. Objektet nga Dynatrace API përdoren si çifte çelësi/vlere (përshkrimi i API-së mund të gjendet këtu Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

Skedari është një grup përkufizimesh të serive kohore:

  • timeseriesId – metrika qĂ« kontrollohet, pĂ«r shembull, Koha e pĂ«rgjigjes, Numri i gabimeve, Kujtesa e pĂ«rdorur, etj.;  
  • grumbullimi - niveli i grumbullimit tĂ« metrikĂ«s, nĂ« rastin tonĂ« mesatar, por ju mund tĂ« pĂ«rdorni cilindo qĂ« ju nevojitet (mesatar, min, max, shuma, numĂ«rimi, pĂ«rqindja);
  • etiketat – etiketa e objektit nĂ« sistemin e monitorimit, ose mund tĂ« specifikoni njĂ« identifikues specifik tĂ« objektit;
  • i ashpĂ«r dhe paralajmĂ«rues - kĂ«ta tregues rregullojnĂ« vlerat e pragut tĂ« metrikĂ«s sonĂ« nĂ«se vlera e provĂ«s tejkalon pragun e rĂ«ndĂ«, atĂ«herĂ« ndĂ«rtimi ynĂ« shĂ«nohet si jo i suksesshĂ«m;

Figura e mëposhtme tregon një shembull të përdorimit të pragjeve të tilla.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Hapi 3: Gjenerimi i ngarkesës

Pasi të kemi përcaktuar nivelet e cilësisë së shërbimit tonë, duhet të gjenerojmë një ngarkesë testimi. Ju mund të përdorni cilindo nga mjetet e testimit me të cilat jeni të kënaqur, si Jmeter, Selenium, Neotys, Gatling, etj.

Sistemi i monitorimit të Dynatrace ju lejon të kapni meta të dhëna të ndryshme nga testet tuaja dhe të njihni se cilat teste i përkasin cilit cikël lëshimi dhe cilit shërbim. Rekomandohet të shtoni tituj shtesë në kërkesat e testit HTTP.

Figura e mëposhtme tregon një shembull ku, duke përdorur titullin shtesë X-Dynatrace-Test, ne tregojmë se ky test lidhet me testimin e funksionimit të shtimit të një artikulli në karrocë.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Kur kryeni çdo test ngarkimi, ju dërgoni informacion shtesë kontekstual në Dynatrace duke përdorur API-në e ngjarjeve nga serveri CI/CD. Në këtë mënyrë, sistemi mund të bëjë dallimin midis testeve të ndryshme.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim. Ngjarje nĂ« sistemin e monitorimit pĂ«r fillimin e testimit tĂ« ngarkesĂ«s

Hapi 4-5. Mblidhni të dhëna të performancës dhe transferoni të dhënat në sistemin CI/CD

Së bashku me testin e gjeneruar, një ngjarje i transmetohet sistemit të monitorimit për nevojën për të mbledhur të dhëna për kontrollin e treguesve të cilësisë së shërbimit. Ai gjithashtu specifikon skedarin tonë JSON, i cili përcakton matjet kryesore.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNgjarje nĂ« lidhje me nevojĂ«n pĂ«r tĂ« kontrolluar cilĂ«sinĂ« e softuerit tĂ« krijuar nĂ« serverin CI/CD pĂ«r dĂ«rgimin nĂ« sistemin e monitorimit

NĂ« shembullin tonĂ«, thirret ngjarja e kontrollit tĂ« cilĂ«sisĂ« perfSigDynatraceReport (Performanca_NĂ«nshkrimi) - kjo Ă«shtĂ« gati plugin pĂ«r integrimin me Jenkins, i cili u zhvillua nga djemtĂ« nga T-Systems Multimedia Solutions. Çdo ngjarje e nisjes sĂ« testit pĂ«rmban informacion nĂ« lidhje me shĂ«rbimin, numrin e ndĂ«rtimit dhe kohĂ«n e testimit. Shtojca mbledh vlerat e performancĂ«s nĂ« kohĂ«n e ndĂ«rtimit, i vlerĂ«son ato dhe e krahason rezultatin me ndĂ«rtimet e mĂ«parshme dhe kĂ«rkesat jofunksionale.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNgjarje nĂ« sistemin e monitorimit pĂ«r fillimin e njĂ« kontrolli tĂ« cilĂ«sisĂ« sĂ« ndĂ«rtimit. Burim

Pas përfundimit të testit, të gjitha metrikat për vlerësimin e cilësisë së softuerit transferohen përsëri në një sistem integrimi të vazhdueshëm, për shembull, Jenkins, i cili gjeneron një raport mbi rezultatet.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDRezultati i statistikave mbi montimet nĂ« serverin CI/CD. Burim

Për çdo ndërtim individual, ne shohim statistika për secilën metrikë që kemi vendosur gjatë gjithë testit. Ne gjithashtu shohim nëse ka pasur shkelje në vlera të caktuara të pragut (paralajmërim dhe pragje të rënda). Bazuar në matjet e përgjithshme, i gjithë ndërtimi shënohet si i qëndrueshëm, i paqëndrueshëm ose i dështuar. Gjithashtu, për lehtësi, mund të shtoni tregues në raport duke krahasuar ndërtimin aktual me atë të mëparshëm.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDShikoni statistika tĂ« detajuara mbi montimet nĂ« serverin CI/CD. Burim

Krahasimi i detajuar i dy asambleve

Nëse është e nevojshme, mund të shkoni te ndërfaqja Dynatrace dhe atje mund të shikoni statistikat për secilën prej ndërtimeve tuaja në më shumë detaje dhe t'i krahasoni ato me njëra-tjetrën.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDKrahasimi i statistikave tĂ« ndĂ«rtimit nĂ« Dynatrace. Burim
 
Gjetjet

Si rezultat, ne marrim një shërbim "monitorimi si shërbim", i automatizuar në linjën e integrimit të vazhdueshëm. Zhvilluesi ose testuesi duhet vetëm të përcaktojë një listë metrike në një skedar JSON dhe gjithçka tjetër ndodh automatikisht. Ne marrim kontroll transparent të cilësisë së publikimeve: të gjitha njoftimet për performancën, konsumin e burimeve ose regresionet arkitekturore.

Detyra 2. Automatizimi i kontrollit të cilësisë së softuerit në një mjedis prodhimi

Pra, ne kemi zgjidhur problemin se si të automatizojmë procesin e monitorimit në fazën e testimit në Pipeline. Në këtë mënyrë ne minimizojmë përqindjen e montimeve me cilësi të ulët që arrijnë në mjedisin e prodhimit.

Por çfarë të bëni nëse softueri i keq përfundon duke u shitur, ose diçka thjesht prishet. Për një utopi, ne donim mekanizma për të zbuluar automatikisht problemet dhe, nëse është e mundur, vetë sistemi të rivendoste funksionalitetin e tij, të paktën gjatë natës.

Për ta bërë këtë, ne duhet, në analogji me pjesën e mëparshme, të parashikojmë kontrolle automatike të cilësisë së softuerit në mjedisin e prodhimit dhe t'i bazojmë ato në skenarë për vetë-shërimin e sistemit.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD
Korrigjimi automatik si kod

Shumica e kompanive tashmë kanë një bazë njohurish të akumuluar për lloje të ndryshme problemesh të zakonshme dhe një listë veprimesh për t'i rregulluar ato, për shembull, rinisja e proceseve, pastrimi i burimeve, rikthimi i versioneve, rivendosja e ndryshimeve të pavlefshme të konfigurimit, rritja ose zvogëlimi i numrit të komponentëve në grupi, ndërrimi i skicës blu ose jeshile etj.

Ndërsa këto raste përdorimi janë të njohura për shumë ekipe me të cilat flas prej vitesh, pak kanë menduar ose investuar në automatizimin e tyre.

Nëse mendoni për këtë, nuk ka asgjë tepër të komplikuar në zbatimin e proceseve për performancën e aplikacionit vetë-shërues, ju duhet të paraqisni skenarët e punës tashmë të njohur të administratorëve tuaj në formën e skripteve të kodit (koncepti "auto-rregullim si kod"); , të cilën e keni shkruar paraprakisht për çdo rast specifik. Skriptet e riparimit automatik duhet të synojnë eliminimin e shkakut rrënjësor të problemit. Ju vetë përcaktoni veprimet e duhura për t'iu përgjigjur një incidenti.

Çdo metrikĂ« nga sistemi juaj i monitorimit mund tĂ« veprojĂ« si njĂ« shkas pĂ«r tĂ« nisur skenarin, gjĂ«ja kryesore Ă«shtĂ« qĂ« kĂ«to metrikĂ« tĂ« pĂ«rcaktojnĂ« me saktĂ«si se gjithçka Ă«shtĂ« e keqe, pasi nuk do tĂ« dĂ«shironit tĂ« merrni pozitive false nĂ« njĂ« mjedis produktiv.

Ju mund të përdorni çdo sistem ose grup sistemesh: Prometheus, ELK Stack, Zabbix, etj. Por unë do të jap disa shembuj të bazuar në një zgjidhje APM (Dynatrace do të jetë përsëri një shembull) që do t'ju ndihmojnë gjithashtu ta bëni jetën tuaj më të lehtë.

Së pari, ka gjithçka që lidhet me performancën për sa i përket funksionimit të aplikacionit. Zgjidhja ofron qindra metrika në nivele të ndryshme që mund t'i përdorni si nxitës:

  • niveli i pĂ«rdoruesit (shfletuesit, aplikacionet celulare, pajisjet IoT, sjellja e pĂ«rdoruesit, konvertimi, etj.);
  • niveli i shĂ«rbimit dhe operacioneve (performanca, disponueshmĂ«ria, gabimet, etj.);
  • niveli i infrastrukturĂ«s sĂ« aplikacionit (metrika e OS host, JMX, MQ, web-server, etj.);
  • niveli i platformĂ«s (virtualizim, re, kontejner, etj.).

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNivelet e monitorimit nĂ« Dynatrace. Burim

Së dyti, siç thashë më herët, Dynatrace ka një API të hapur, gjë që e bën shumë të lehtë integrimin me sisteme të ndryshme të palëve të treta. Për shembull, dërgimi i një njoftimi në sistemin e automatizimit kur tejkalohen parametrat e kontrollit.

Më poshtë është një shembull për të bashkëvepruar me Ansible.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Më poshtë do të jap disa shembuj se çfarë lloj automatizimi mund të bëhet. Kjo është vetëm një pjesë e rasteve, lista e tyre në mjedisin tuaj mund të kufizohet vetëm nga imagjinata juaj dhe aftësitë e mjeteve tuaja monitoruese.

1. Vendosje e keqe – rikthimi i versionit

Edhe nëse testojmë gjithçka shumë mirë në një mjedis testimi, ka ende një shans që një version i ri mund të vrasë aplikacionin tuaj në një mjedis prodhimi. I njëjti faktor njerëzor nuk është anuluar.

Në figurën e mëposhtme shohim se ka një kërcim të mprehtë në kohën e ekzekutimit të operacioneve në shërbim. Fillimi i këtij kërcimi përkon me kohën e vendosjes në aplikacion. Ne i transmetojmë të gjitha këto informacione si ngjarje në sistemin e automatizimit. Nëse performanca e shërbimit nuk kthehet në normale pas kohës që kemi vendosur, atëherë thirret automatikisht një skript që e kthen versionin në versionin e vjetër.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDDegradimi i performancĂ«s sĂ« operacioneve pas vendosjes. Burim

2. Ngarkimi i burimeve në 100% - shtoni një nyje në rrugëtim

Në shembullin e mëposhtëm, sistemi i monitorimit përcakton që një nga komponentët po përjeton ngarkesë 100% të CPU.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNgarkesa e CPU-sĂ« 100%
 
Ka disa skenarë të ndryshëm të mundshëm për këtë ngjarje. Për shembull, sistemi i monitorimit kontrollon gjithashtu nëse mungesa e burimeve shoqërohet me një rritje të ngarkesës në shërbim. Nëse po, atëherë ekzekutohet një skript që shton automatikisht një nyje në rrugëzim, duke rikthyer kështu funksionalitetin e sistemit në tërësi.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDShkallĂ«zimi pas njĂ« incidenti

3. Mungesa e hapësirës në hard disk - pastrimi i diskut

UnĂ« mendoj se shumĂ« njerĂ«z tashmĂ« i kanĂ« automatizuar kĂ«to procese. Duke pĂ«rdorur APM, ju gjithashtu mund tĂ« monitoroni hapĂ«sirĂ«n e lirĂ« nĂ« nĂ«nsistemin e diskut. NĂ«se nuk ka hapĂ«sirĂ« ​​ose disku po funksionon ngadalĂ«, ne thĂ«rrasim njĂ« skript pĂ«r ta pastruar ose pĂ«r tĂ« shtuar hapĂ«sirĂ«.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD
Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNgarkesa e diskut 100%
 
4. Aktivitet i ulët i përdoruesit ose konvertim i ulët - kalimi midis degëve blu dhe jeshile

Unë shpesh shoh klientët që përdorin dy sythe (vendosje blu-jeshile) për aplikacione në një mjedis prodhimi. Kjo ju lejon të kaloni shpejt ndërmjet degëve kur jepni botime të reja. Shpesh, pas vendosjes, mund të ndodhin ndryshime dramatike që nuk janë të dukshme menjëherë. Në këtë rast, degradimi në performancë dhe disponueshmëri mund të mos vërehet. Për t'iu përgjigjur shpejt ndryshimeve të tilla, është më mirë të përdorni metrika të ndryshme që pasqyrojnë sjelljen e përdoruesit (numri i seancave dhe veprimeve të përdoruesit, konvertimi, shkalla e fryrjes). Figura e mëposhtme tregon një shembull në të cilin, kur normat e konvertimit bien, ndodh kalimi midis degëve të softuerit.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDShkalla e konvertimit bie pas kalimit midis degĂ«ve tĂ« softuerit. Burim

Mekanizmat për zbulimin automatik të problemeve

Më në fund, do t'ju jap një shembull tjetër se pse më pëlqen më shumë Dynatrace.

Në pjesën e tregimit tim në lidhje me automatizimin e kontrolleve të cilësisë së montimeve në një mjedis testimi, ne përcaktuam të gjitha vlerat e pragut me dorë. Kjo është normale për një mjedis testimi, vetë testuesi përcakton treguesit para çdo testi në varësi të ngarkesës. Në një mjedis prodhimi, është e dëshirueshme që problemet të zbulohen automatikisht, duke marrë parasysh mekanizmat e ndryshëm bazë.

Dynatrace ka mjete interesante të integruara të inteligjencës artificiale që, bazuar në mekanizmat për përcaktimin e metrikës anormale (bazimin) dhe ndërtimin e një harte të ndërveprimit midis të gjithë komponentëve, duke krahasuar dhe korreluar ngjarjet me njëri-tjetrin, përcaktojnë anomalitë në funksionimin e shërbimit tuaj dhe ofrojnë të detajuara informacion për çdo problem dhe shkakun rrënjësor.

Duke analizuar automatikisht varësitë midis komponentëve, Dynatrace përcakton jo vetëm nëse shërbimi problematik është shkaku kryesor, por edhe varësia e tij nga shërbimet e tjera. Në shembullin e mëposhtëm, Dynatrace monitoron dhe vlerëson automatikisht shëndetin e secilit shërbim brenda ekzekutimit të transaksionit, duke identifikuar shërbimin Golang si shkakun kryesor.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDNjĂ« shembull i pĂ«rcaktimit tĂ« shkakut rrĂ«njĂ«sor tĂ« njĂ« dĂ«shtimi. Burim

Figura e mëposhtme tregon procesin e monitorimit të problemeve me aplikacionin tuaj që nga fillimi i një incidenti.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDVizualizimi i njĂ« problemi nĂ« zhvillim me shfaqjen e tĂ« gjithĂ« komponentĂ«ve dhe ngjarjeve nĂ« to

Sistemi i monitorimit mblodhi një kronologji të plotë të ngjarjeve në lidhje me problemin e lindur. Në dritaren poshtë afatit kohor ne shohim të gjitha ngjarjet kryesore në secilin nga komponentët. Bazuar në këto ngjarje, ju mund të vendosni procedura për korrigjimin automatik në formën e skripteve të kodit.

Për më tepër, unë ju këshilloj të integroni një sistem monitorimi me Shërbimin Desk ose një gjurmues të gabimeve. Kur shfaqet një problem, zhvilluesit marrin shpejt informacion të plotë për ta analizuar atë në nivelin e kodit në mjedisin e prodhimit.

PĂ«rfundim

Si rezultat, ne përfunduam me një tubacion CI/CD me kontrolle të integruara të cilësisë së softuerit të automatizuar në Pipeline. Ne minimizojmë numrin e asambleve me cilësi të ulët, rrisim besueshmërinë e sistemit në tërësi dhe nëse sistemi ynë ende dështon, ne lëshojmë mekanizma për ta rivendosur atë.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CD
Padyshim që ia vlen të investoni për të automatizuar monitorimin e cilësisë së softuerit, nuk është gjithmonë një proces i shpejtë, por me kalimin e kohës do të japë fryte. Unë rekomandoj që pas zgjidhjes së një incidenti të ri në mjedisin e prodhimit, të mendoni menjëherë se cilët monitorë të shtoni për kontrolle në mjedisin e provës, në mënyrë që të shmangni hyrjen e një ndërtimi të keq në prodhim, dhe gjithashtu të krijoni një skenar për të korrigjuar automatikisht këto probleme.

Shpresoj që shembujt e mi do t'ju ndihmojnë në përpjekjet tuaja. Do të jem i interesuar gjithashtu të shoh shembujt tuaj të matjeve të përdorura për zbatimin e sistemeve të vetë-shërimit.

Monitorimi i vazhdueshĂ«m – automatizimi i kontrolleve tĂ« cilĂ«sisĂ« sĂ« softuerit nĂ« tubacionin CI/CDBurim

Burimi: www.habr.com

Bleni njĂ« host tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, serverĂ« VPS VDS đŸ”„ Bleni hosting tĂ« besueshĂ«m tĂ« faqeve tĂ« internetit me mbrojtje DDoS, servera VPS VDS | ProHoster