Head reedet kõigile! Sõbrad, täna jätkame kursusele pühendatud väljaannete sarja , sest järgmise nädala lõpus algavad tunnid kursuse uues rühmas. Niisiis, alustame!
Järelevalve on lihtsalt. See on teada-tuntud fakt. Tooge üles Nagios, käivitage kaugsüsteemis NRPE, konfigureerige Nagios NRPE TCP-porti 5666 ja teil on järelevalve.
See on nii lihtne, et pole huvitav. Nüüd on teil põhilised mõõdikud protsessori aja, ketta alamsüsteemi ja RAM-i kohta, mis on vaikimisi saadaval Nagiosele ja NRPE-le. Kuid see ei ole tegelikult "seire" kui selline. See on alles algus.
(Tavaliselt installivad nad PNP4Nagiose, RRDtooli ja Thruki, seadistavad Slackis märguanded ja lähevad otse nagiosexchange'i, kuid jätame selle praegu välja).
Hea jälgimine on tegelikult üsna keeruline, peate tõesti teadma jälgitava rakenduse sisemisi omadusi.
Kas jälgimine on keeruline?
Iga server, olgu see siis Linux või Windows, teenib oma olemuselt mingit eesmärki. Apache, Samba, Tomcat, failisalvestus, LDAP – kõik need teenused on ühes või mitmes aspektis enam-vähem ainulaadsed. Igal neist on oma funktsioon, oma omadused. Mõõdikute, KPI-de (peamised jõudlusnäitajad), mis on teile huvitavad, kui server on koormatud, hankimiseks on erinevaid viise.
Foto autor edasi
(Ma soovin, et mu armatuurlauad oleksid neoonsinised - ohkab unistavalt -... hmm...)
Igal teenuseid pakkuval tarkvaral peab olema mõõdikute kogumise mehhanism. Apachel on moodul mod-status, kuvab serveri oleku lehe. Nginxil on - stub_status. Tomcatil on JMX või kohandatud veebirakendused, mis näitavad põhimõõdikuid. MySQL-il on käsk "show global status" jne.
Miks siis arendajad ei ehita enda loodud rakendustesse sarnaseid mehhanisme?
Kas seda teevad ainult arendajad?
Teatav ükskõiksus mõõdikute manustamise suhtes ei piirdu ainult arendajatega. Töötasin ettevõtetes, kus nad arendasid rakendusi Tomcati abil ja ei esitanud ühtegi oma mõõdikut ega teenusetegevuse logisid, välja arvatud üldised Tomcati vealogid. Mõned arendajad genereerivad palju logisid, mis ei tähenda midagi süsteemiadministraatorile, kes ei ole piisavalt õnnelik, et lugeda neid kell 3:15 hommikul.
Foto autor edasi
Süsteemiinsenerid, kes lubavad selliseid tooteid välja anda, peavad samuti olukorra eest teatud määral vastutama. Vähestel süsteemiinseneridel on aega või hoolt, et püüda logidest sisukaid mõõdikuid eraldada, ilma nende mõõdikute kontekstita ja võimaluseta neid rakendustegevuse valguses tõlgendada. Mõned ei saa aru, kuidas nad sellest kasu saavad, välja arvatud "midagi on praegu (või varsti) valesti" näitajad.
Mõõdikute vajalikkusest mõtlemise muutus peab toimuma mitte ainult arendajate, vaid ka süsteemiinseneride seas.
Kõigile süsteemiinseneridele, kes ei pea mitte ainult reageerima kriitilistele sündmustele, vaid tagama ka nende esinemise, on mõõdikute puudumine tavaliselt takistuseks.
Süsteemiinsenerid aga tavaliselt ei tegele koodiga, et oma ettevõttele raha teenida. Nad vajavad juhtivaid arendajaid, kes mõistavad süsteemiinseneri vastutuse tähtsust probleemide tuvastamisel, jõudlusprobleemide teadlikkuse tõstmisel ja muul sarnasel.
See devops asi
Devopsi mentaliteet kirjeldab sünergiat arendus- (dev) ja operatsioonide (ops) mõtlemise vahel. Iga ettevõte, kes väidab, et teeb devopsi, peab:
- öelda asju, mida nad ilmselt ei tee (viidates The Princess Bride meemile – "Ma ei usu, et see tähendab seda, mida sa arvad, et see tähendab!")
- Julgustage suhtumist toote pideva täiustamise poole.
Te ei saa toodet täiustada ja teate, et seda on täiustatud, kui te ei tea, kuidas see praegu töötab. Sa ei saa teada, kuidas toode töötab, kui sa ei mõista selle komponentide toimimist, teenuseid, millest see sõltub, selle peamisi valupunkte ja kitsaskohti.
Kui te ei jälgi võimalikke kitsaskohti, ei saa te postmortemi kirjutamisel järgida viie põhjuse tehnikat. Te ei saa panna kõike ühele ekraanile, et näha, kuidas toode töötab, ega teada, kuidas see "tavaline ja õnnelik" välja näeb.
Nihuta vasakule, VASAKULE, MA ÜTLESIN LEEEE-
Minu jaoks on Devopsi üks põhiprintsiipe “nihutamine vasakule”. Vasakule nihutamine tähendab selles kontekstis võimaluse nihutamist (ei mingit vastutust, kuid ainult võimalused), et teha asju, millest süsteemiinsenerid tavaliselt korda lähevad, nagu näiteks jõudlusmõõdikute loomine, logide tõhusam kasutamine jne. Tarkvara tarnimise elutsüklist vasakul.
Foto autor edasi
Tarkvaraarendajad peavad suutma kasutada ja tundma jälgimistööriistu, mida ettevõte kasutab, et teostada monitoorimist kõigis selle vormides, mõõdikutes, logimises, jälgimisliidestes ja mis kõige tähtsam, jälgige, kuidas nende toode tootmises töötab. Te ei saa panna arendajaid jälgimisse jõupingutusi ja aega investeerima enne, kui nad näevad mõõdikuid ja saavad mõjutada nende välimust, seda, kuidas tooteomanik neid järgmisel briifingul CTO-le esitleb jne.
Lühidalt
- Vii oma hobune vette. Näidake arendajatele, kui palju probleeme nad saavad enda jaoks vältida, aidake neil tuvastada nende rakenduste jaoks õiged KPI-d ja mõõdikud, et tooteomanik, kelle peale CTO karjub, oleks vähem karjunud. Tooge need valguse kätte, õrnalt ja rahulikult. Kui see ei aita, andke altkäemaksu, ähvardage ja meelitage neid või toote omanikku, et need mõõdikud rakendustest võimalikult kiiresti kätte saaksid, ja seejärel joonistage diagrammid. See on keeruline, kuna seda ei peeta prioriteediks ja toote tegevuskavas on pooleli palju tulu teenivaid projekte. Seetõttu vajate ärijuhtumit, et põhjendada tootes jälgimise juurutamiseks kulutatud aega ja kulutusi.
- Aidake süsteemiinseneridel korralikult magada. Näidake neile, et „vabastame” kontroll-loendi kasutamine mis tahes välja lastud toote puhul on hea. Ja veendudes, et kõik tootmisrakendused on mõõdikutega kaetud, aitab teil öösel paremini magada, võimaldades arendajatel näha, mis ja kus valesti läheb. Õige viis arendajat, tooteomanikku või tehnoloogiajuhti ärritada ja frustreerida on aga püsida ja vastu seista. See käitumine mõjutab iga toote väljalaskekuupäeva, kui ootate uuesti viimase minutini, nii et nihutage uuesti vasakule ja lisage need probleemid oma projektiplaani niipea kui võimalik. Vajadusel suunduge tootekohtumistele. Kandke võltsvuntsid ja vilt või midagi, see ei vea kunagi alt. Rääkige oma muredest, näidake selgeid eeliseid ja kuulutage evangelisatsiooni.
- Veenduge, et nii arendus (dev) kui ka toimingud (ops) mõistaksid tootemõõdikute punasesse tsooni liikumise tähendust ja tagajärgi. Ärge jätke Opsi toote tervise ainsaks valvuriks, vaid veenduge, et ka arendajad oleksid kaasatud (#productsquads).
- Logid on suurepärane asi, aga ka mõõdikud. Kombineerige need ja ärge laske oma palkidel tohutus leegitsevas kasutusepallis prügikastiks muutuda. Selgitage ja näidake arendajatele, miks keegi teine nende logidest aru ei saa, näidake neile, mis tunne on vaadata kasutuid logisid kell 3:15 hommikul.
Foto autor edasi
See on kõik. Uus materjal ilmub järgmisel nädalal. Kui soovite kursuse kohta rohkem teada saada, kutsume teid üles , mis toimub esmaspäeval. Ja nüüd ootame traditsiooniliselt teie kommentaare.
Allikas: www.habr.com