Fijne vrijdag iedereen! Vrienden, vandaag gaan we verder met de reeks publicaties die aan de cursus zijn gewijd , want eind volgende week starten de lessen in de nieuwe groep voor de cursus. Dus laten we beginnen!
Toezicht wel gewoon. Dit is een bekend feit. Open Nagios, voer NRPE uit op het externe systeem, configureer Nagios op NRPE TCP-poort 5666 en je hebt monitoring.
Het is zo eenvoudig dat het niet interessant is. Nu beschikt u over basisstatistieken voor CPU-tijd, schijfsubsysteem en RAM, die standaard worden geleverd aan Nagios en NRPE. Maar dit is eigenlijk geen ‘monitoring’ als zodanig. Dit is nog maar het begin.
(Meestal installeren ze PNP4Nagios, RRDtool en Thruk, stellen ze meldingen in Slack in en gaan ze rechtstreeks naar nagiosexchange, maar laten we dat voorlopig achterwege laten).
Goede monitoring is eigenlijk behoorlijk complex, je moet echt de interne werking kennen van de applicatie die je bewaakt.
Is monitoren lastig?
Elke server, of het nu Linux of Windows is, zal per definitie een bepaald doel dienen. Apache, Samba, Tomcat, bestandsopslag, LDAP - al deze diensten zijn in één of meerdere opzichten min of meer uniek. Elk heeft zijn eigen functie, zijn eigen kenmerken. Er zijn verschillende manieren om statistieken, KPI's (key performance indicators), te verkrijgen die voor u interessant zijn wanneer de server onder belasting staat.
Auteur van de foto op
(Ik wou dat mijn dashboards neonblauw waren - dromerig zuchtend -... hmm...)
Alle software die diensten levert, moet een mechanisme hebben om statistieken te verzamelen. Apache heeft een module mod-status, waarbij de serverstatuspagina wordt weergegeven. Nginx heeft - stub_status. Tomcat heeft JMX of aangepaste webapplicaties die belangrijke statistieken tonen. MySQL heeft een commando "show global status" enz.
Dus waarom bouwen ontwikkelaars geen vergelijkbare mechanismen in de applicaties die ze maken?
Doen alleen ontwikkelaars dit?
Een zekere mate van onverschilligheid ten aanzien van het insluiten van statistieken is niet beperkt tot ontwikkelaars. Ik heb in bedrijven gewerkt waar ze applicaties ontwikkelden met Tomcat en geen eigen statistieken verstrekten, geen logs van serviceactiviteiten, behalve de algemene Tomcat-foutenlogboeken. Sommige ontwikkelaars genereren veel logboeken die niets betekenen voor de systeembeheerder, die de pech heeft om ze om 3 uur 's ochtends te lezen.
Auteur van de foto op
Systeemingenieurs die ervoor zorgen dat dergelijke producten op de markt komen, moeten ook een zekere verantwoordelijkheid voor de situatie dragen. Er zijn maar weinig systeemingenieurs die de tijd of de zorg hebben om zinvolle meetgegevens uit logboeken te halen, zonder de context van die meetgegevens en de mogelijkheid om ze te interpreteren in het licht van de applicatieactiviteit. Sommigen begrijpen niet hoe ze hiervan kunnen profiteren, afgezien van de indicatoren dat er momenteel iets mis is (of binnenkort zal zijn).
Er moet een verandering in het denken over de noodzaak van metrieken plaatsvinden, niet alleen onder ontwikkelaars, maar ook onder systeemingenieurs.
Voor elke systeemingenieur die niet alleen moet reageren op kritieke gebeurtenissen, maar er ook voor moet zorgen dat deze niet plaatsvinden, vormt het gebrek aan meetgegevens doorgaans een belemmering om dit te doen.
Systeemingenieurs sleutelen echter doorgaans niet aan code om geld voor hun bedrijf te verdienen. Ze hebben hoofdontwikkelaars nodig die het belang begrijpen van de verantwoordelijkheid van de systeemingenieur bij het identificeren van problemen, het vergroten van het bewustzijn over prestatieproblemen en dergelijke.
Dit devops-ding
De devops-mentaliteit beschrijft de synergie tussen ontwikkelings- (dev) en operations- (ops) denken. Elk bedrijf dat beweert "devops te doen" moet:
- dingen zeggen die ze waarschijnlijk niet doen (verwijzend naar de meme van The Princess Bride - "Ik denk niet dat het betekent wat jij denkt dat het betekent!")
- Stimuleer een houding van voortdurende productverbetering.
Je kunt een product niet verbeteren en weten dat het verbeterd is als je niet weet hoe het momenteel werkt. Je kunt niet weten hoe een product werkt als je niet begrijpt hoe de componenten ervan werken, van welke diensten het afhankelijk is, en wat de belangrijkste pijnpunten en knelpunten zijn.
Als je niet op potentiële knelpunten let, kun je de Five Whys-techniek niet volgen bij het schrijven van een postmortem. Je kunt niet alles op één scherm zetten om te zien hoe een product werkt of om te weten hoe het er ‘normaal en gelukkig’ uitziet.
Shift naar links, naar links, ik zei LEEEE-
Voor mij is een van de belangrijkste principes van Devops ‘shift left’. Naar links verschuiven betekent in deze context het verschuiven van de mogelijkheid (geen verantwoordelijkheid, maar alleen mogelijkheden) om dingen te doen waar systeemingenieurs doorgaans om geven, zoals het creëren van prestatiestatistieken, het efficiënter gebruiken van logs, enz., aan de linkerkant van de Software Delivery Life Cycle.
Auteur van de foto op
Softwareontwikkelaars moeten de monitoringtools kunnen gebruiken en kennen die het bedrijf gebruikt om monitoring uit te voeren in al zijn vormen, metrieken, loggen, monitoringinterfaces en, belangrijker nog, kijk hoe hun product werkt in de productie. Je kunt ontwikkelaars niet zover krijgen dat ze moeite en tijd investeren in monitoring totdat ze de statistieken kunnen zien en invloed kunnen uitoefenen op hoe ze eruitzien, hoe de producteigenaar ze tijdens de volgende briefing aan de CTO presenteert, enz.
kortom:
- Leid je paard naar het water. Laat ontwikkelaars zien hoeveel problemen ze voor zichzelf kunnen vermijden, help hen de juiste KPI’s en metrics voor hun applicaties te identificeren, zodat er minder geschreeuw komt van de producteigenaar waar de CTO tegen schreeuwt. Breng ze zachtjes en kalm in het licht. Als dat niet werkt, kun je hen of de producteigenaar omkopen, bedreigen en overhalen om deze statistieken zo snel mogelijk uit de applicaties te halen, en vervolgens de diagrammen te tekenen. Dit zal moeilijk zijn omdat het niet als een prioriteit zal worden gezien en er op de productroadmap nog veel inkomstengenererende projecten in behandeling zullen zijn. Daarom heeft u een business case nodig om de tijd en kosten te rechtvaardigen die zijn besteed aan het implementeren van monitoring in het product.
- Help systeemingenieurs aan een goede nachtrust. Laat ze zien dat het een goede zaak is om een ‘let’s release’-checklist te gebruiken voor elk product dat wordt uitgebracht. En door ervoor te zorgen dat alle applicaties in productie zijn voorzien van statistieken, kun je 's nachts beter slapen, omdat ontwikkelaars kunnen zien wat er misgaat en waar. De juiste manier om een ontwikkelaar, producteigenaar of CTO te irriteren en frustreren is echter door te volharden en weerstand te bieden. Dit gedrag zal van invloed zijn op de releasedatum van elk product als u weer tot het laatste moment wacht. Schakel dus weer naar links en zorg ervoor dat deze problemen zo snel mogelijk in uw projectplan worden opgenomen. Ga indien nodig naar productbijeenkomsten. Draag een nepsnor en vilt of zoiets, het zal nooit falen. Communiceer uw zorgen, laat duidelijke voordelen zien en evangeliseer.
- Zorg ervoor dat zowel ontwikkeling (dev) als operations (ops) de betekenis en gevolgen begrijpen van productstatistieken die in de rode zone terechtkomen. Laat Ops niet de enige bewaker van de productgezondheid achter, maar zorg ervoor dat ontwikkelaars er ook bij betrokken zijn (#productsquads).
- Logboeken zijn geweldig, maar dat geldt ook voor statistieken. Combineer ze en zorg ervoor dat je houtblokken geen afval worden in een enorme vlammende bal van nutteloosheid. Leg de ontwikkelaars uit en laat ze zien waarom niemand anders hun logs zal begrijpen, laat ze zien hoe het is om om kwart voor drie in de ochtend naar nutteloze logs te kijken.
Auteur van de foto op
Dat is alles. Volgende week komt er nieuw materiaal uit. Wilt u meer weten over de cursus, dan nodigen wij u graag uit , die maandag zal plaatsvinden. En nu wachten we traditioneel op uw commentaar.
Bron: www.habr.com