Noflike freed elkenien! Freonen, hjoed geane wy troch mei de searje publikaasjes wijd oan 'e kursus , want de lessen yn de nije groep foar de kursus begjinne ein nije wike. Dus, lit ús begjinne!
Monitoring is just. Dit is in bekend feit. Bring Nagios op, rinne NRPE op it systeem op ôfstân, konfigurearje Nagios op NRPE TCP-poarte 5666 en jo hawwe tafersjoch.
It is sa maklik dat it net ynteressant is. No hawwe jo basismetriken foar CPU-tiid, skiifsubsysteem, RAM, standert levere oan Nagios en NRPE. Mar dit is eins net "monitoring" as sadanich. Dit is noch mar it begjin.
(Meastentiids ynstallearje se PNP4Nagios, RRDtool en Thruk, set notifikaasjes yn Slack op en gean direkt nei nagiosexchange, mar litte wy dat no litte).
Goede tafersjoch is eins frij kompleks, jo moatte echt de ynterne kennen fan 'e applikaasje dy't jo kontrolearje.
Is tafersjoch lestich?
Elke server, itsij Linux as Windows, sil per definysje wat doel tsjinje. Apache, Samba, Tomcat, triem opslach, LDAP - al dizze tsjinsten binne mear of minder unyk yn ien of mear opsichten. Elk hat syn eigen funksje, syn eigen skaaimerken. D'r binne ferskate manieren om metriken, KPI's (key performance indicators) te krijen, dy't jo ynteressant binne as de tsjinner ûnder load is.
Auteur fan de foto op
(Ik winskje dat myn dashboards neonblau wiene - dreamerich suchtet -... hmm...)
Elke software dy't tsjinsten leveret moat in meganisme hawwe om metriken te sammeljen. Apache hat in module mod-status, werjaan fan de tsjinner status side. Nginx hat - stub_status. Tomcat hat JMX as oanpaste webapplikaasjes dy't wichtige metriken sjen litte. MySQL hat in kommando "toane globale status" ensfh.
Dus wêrom bouwe ûntwikkelders gjin ferlykbere meganismen yn 'e applikaasjes dy't se meitsje?
Doch allinich ûntwikkelders dit?
In bepaald nivo fan ûnferskilligens foar ynbêding fan metriken is net beheind ta ûntwikkelders. Ik wurke yn bedriuwen dêr't se ûntwikkele applikaasjes mei help fan Tomcat en joech gjin ien fan harren eigen metriken, gjin logs fan tsjinst aktiviteit, útsein foar algemiene Tomcat flater logs. Guon ûntwikkelders generearje in protte logs dy't neat betsjutte foar de systeembehearder dy't pech genôch is om se moarns om 3:15 oere te lêzen.
Auteur fan de foto op
Systeemingenieurs dy't it mooglik meitsje om sokke produkten frij te litten moatte ek wat ferantwurdlikens drage foar de situaasje. In pear systeemingenieurs hawwe de tiid of soarch om te besykjen betsjuttingsfolle metriken út logs te heljen, sûnder de kontekst fan dy metriken en de mooglikheid om se te ynterpretearjen yn it ljocht fan applikaasjeaktiviteit. Guon begripe net hoe't se der fan profitearje kinne, oars as "wat is op it stuit (of sil gau) ferkeard wêze" yndikatoaren.
In feroaring yn tinken oangeande de needsaak foar metriken moat net allinich foarkomme by ûntwikkelders, mar ek by systeemingenieurs.
Foar elke systeemyngenieur dy't net allinich moat reagearje op krityske eveneminten, mar ek soargje dat se net foarkomme, is it gebrek oan metriken normaal in barriêre om dit te dwaan.
Systeemingenieurs dogge lykwols gewoanlik net mei koade om jild te meitsjen foar har bedriuw. Se hawwe leadûntwikkelders nedich dy't it belang begripe fan 'e ferantwurdlikens fan' e systeemingenieur by it identifisearjen fan problemen, it fergrutsjen fan bewustwêzen fan prestaasjesproblemen, en sa.
Dit devops ding
De devops mentaliteit beskriuwt de synergy tusken ûntwikkeling (dev) en operaasjes (ops) tinken. Elk bedriuw dat beweart "devops te dwaan" moat:
- dingen sizze dy't se wierskynlik net dogge (ferwizend nei The Princess Bride meme - "Ik tink net dat it betsjut wat jo tinke dat it betsjut!")
- Stimulearje in hâlding fan trochgeande produktferbettering.
Jo kinne in produkt net ferbetterje en witte dat it ferbettere is as jo net witte hoe't it op it stuit wurket. Jo kinne net witte hoe't in produkt wurket as jo net begripe hoe't de komponinten wurkje, de tsjinsten wêrfan it hinget, de wichtichste pinepunten en knelpunten.
As jo net sjogge nei potinsjele knelpunten, kinne jo de Five Whys-technyk net folgje by it skriuwen fan in Postmortem. Jo sille net alles op ien skerm kinne pleatse om te sjen hoe't in produkt wurket of witte hoe't it liket "normaal en lokkich."
Skift lofts, lofts, ik sei LEEEE-
Foar my is ien fan 'e kaaiprinsipes fan Devops "ferskowing lofts". Nei links yn dit ferbân betsjut it ferskowen fan de mooglikheid (gjin ferantwurdlikens.
Auteur fan de foto op
Software-ûntwikkelders moatte de tafersjochynstruminten kinne brûke en kennen dy't it bedriuw brûkt om tafersjoch út te fieren yn al har foarmen, metriken, logging, tafersjoch-ynterfaces en, it wichtichste, sjoch hoe't har produkt wurket yn produksje. Jo kinne ûntwikkelders net krije om ynspanning en tiid te ynvestearjen yn tafersjoch oant se de metriken kinne sjen en beynfloedzje hoe't se der útsjen, hoe't de produkteigner se presintearret oan 'e CTO by de folgjende briefing, ensfh.
Koartsein
- Lied jo hynder nei it wetter. Lit ûntwikkelders sjen hoefolle problemen se foar harsels kinne mije, help har de juste KPI's en metriken foar har applikaasjes te identifisearjen, sadat d'r minder roppen wurdt fan 'e produkteigner dy't troch de CTO wurdt raasd. Bring se yn it ljocht, sêft en kalm. As dat net wurket, dan omkeapje, bedrige, en lokje of har as de produkteigner om dizze metriken sa rap mooglik út 'e applikaasjes te heljen, en tekenje dan de diagrammen. Dit sil lestich wêze, om't it net sil wurde sjoen as in prioriteit en de produktroadkaart sil in protte ynkomsten generearjende projekten yn ôfwachting hawwe. Dêrom sille jo in saaklike saak nedich wêze om de tiid en kosten te rjochtfeardigjen dy't bestege oan it ymplementearjen fan tafersjoch yn it produkt.
- Help systeemingenieurs in goede nacht sliepe krije. Lit har sjen dat it brûken fan in checklist "lit ús frijlitte" foar elk produkt dat wurdt frijjûn in goede saak is. En it soargjen dat alle applikaasjes yn produksje binne bedekt mei metriken sil jo helpe nachts better te sliepen troch ûntwikkelders te tastean om te sjen wat der mis giet en wêr. De juste manier om elke ûntwikkelder, produkteigner of CTO te irritearjen en te frustrearjen is lykwols oanhâlde en fersette. Dit gedrach sil ynfloed hawwe op de releasedatum fan elk produkt as jo wachtsje oant de lêste minút wer, dus ferskowe wer lofts en krije dizze problemen sa gau mooglik yn jo projektplan. As it nedich is, meitsje jo wei nei produktgearkomsten. Draach in falske snor en filt of sa, it sil nea mislearje. Kommunisearje jo soargen, demonstrearje dúdlike foardielen en evangelisearje.
- Soargje derfoar dat sawol ûntwikkeling (dev) as operaasjes (ops) de betsjutting en konsekwinsje begripe fan produktmetriken dy't yn 'e reade sône ferpleatse. Lit Ops net as de ienige hoeder fan produkt sûnens, soargje derfoar dat ûntwikkelders ek belutsen binne (#productsquads).
- Logs binne in geweldich ding, mar ek metriken. Kombinearje se en lit jo logs net jiskefet wurde yn in enoarme flammende bal fan nutteloosheid. Ferklearje en lit de ûntwikkelders sjen wêrom't gjinien oars har logs sil begripe, lit se sjen hoe't it is om te sjen nei nutteleaze logs om 3:15 oere moarns.
Auteur fan de foto op
Da's alles. Nij materiaal komt nije wike frij. As jo mear wolle leare oer de kursus, noegje wy jo út , dat sil plakfine op moandei. En no wachtsje wy tradisjoneel op jo opmerkings.
Boarne: www.habr.com