Bon divendres a tothom! Amics, avui continuem la sèrie de publicacions dedicades al curs , perquè les classes del nou grup del curs començaran a finals de la setmana vinent. Així doncs, comencem!
El seguiment és només. Aquest és un fet conegut. Obriu Nagios, executeu NRPE al sistema remot, configureu Nagios al port TCP NRPE 5666 i teniu la supervisió.
És tan fàcil que no és interessant. Ara teniu mètriques bàsiques per al temps de la CPU, el subsistema del disc, la memòria RAM, subministrades per defecte a Nagios i NRPE. Però això no és realment un "monitoratge" com a tal. Això només és el començament.
(En general, instal·len PNP4Nagios, RRDtool i Thruk, configuren notificacions a Slack i van directament a nagiosexchange, però deixem-ho de moment).
Bon seguiment En realitat, és bastant complex, realment necessiteu conèixer els elements interns de l'aplicació que esteu supervisant.
És difícil el seguiment?
Qualsevol servidor, ja sigui Linux o Windows, per definició servirà algun propòsit. Apache, Samba, Tomcat, emmagatzematge de fitxers, LDAP: tots aquests serveis són més o menys únics en un o més aspectes. Cadascú té la seva pròpia funció, les seves pròpies característiques. Hi ha diferents maneres d'obtenir mètriques, KPI (indicadors clau de rendiment), que us resulten interessants quan el servidor està en càrrega.
Autor de la foto en
(M'agradaria que els meus taulers fossin blau neó - sospirant somiador -... hmm...)
Qualsevol programari que ofereixi serveis ha de tenir un mecanisme per recopilar mètriques. Apache té un mòdul mod-status, mostrant la pàgina d'estat del servidor. Nginx té - stub_status. Tomcat té JMX o aplicacions web personalitzades que mostren mètriques clau. MySQL té una comanda "mostrar l'estat global", etc.
Aleshores, per què els desenvolupadors no incorporen mecanismes similars a les aplicacions que creen?
Només ho fan els desenvolupadors?
Un cert nivell d'indiferència per a la incorporació de mètriques no es limita als desenvolupadors. Vaig treballar en empreses on desenvolupaven aplicacions amb Tomcat i no proporcionava cap mètrica pròpia, ni registres d'activitat del servei, excepte els registres d'errors generals de Tomcat. Alguns desenvolupadors generen molts registres que no signifiquen res per a l'administrador del sistema que té la mala sort de llegir-los a les 3:15 del matí.
Autor de la foto en
Els enginyers de sistemes que permeten el llançament d'aquests productes també han de ser responsables de la situació. Pocs enginyers de sistemes tenen el temps o la cura per intentar extreure mètriques significatives dels registres, sense el context d'aquestes mètriques i la capacitat d'interpretar-les a la llum de l'activitat de l'aplicació. Alguns no entenen com se'n poden beneficiar, a part dels indicadors "actualment (o aviat serà) incorrecte".
Un canvi de pensament sobre la necessitat de mètriques s'ha de produir no només entre els desenvolupadors, sinó també entre els enginyers de sistemes.
Per a qualsevol enginyer de sistemes que necessiti no només respondre als esdeveniments crítics, sinó també assegurar-se que no es produeixin, la manca de mètriques sol ser una barrera per fer-ho.
No obstant això, els enginyers de sistemes normalment no juguen amb el codi per guanyar diners per a la seva empresa. Necessiten desenvolupadors principals que entenguin la importància de la responsabilitat de l'enginyer de sistemes a l'hora d'identificar problemes, conscienciar sobre els problemes de rendiment i similars.
Això devops
La mentalitat devops descriu la sinergia entre el pensament de desenvolupament (dev) i operacions (ops). Qualsevol empresa que digui "fer devops" ha de:
- dient coses que probablement no ho fan (referint-se al meme de The Princess Bride: "No crec que signifiqui el que creieu que significa!")
- Fomentar una actitud de millora contínua del producte.
No pots millorar un producte i saber que s'ha millorat si no saps com funciona actualment. No pots saber com funciona un producte si no entens com funcionen els seus components, els serveis dels quals depèn, els seus principals problemes i colls d'ampolla.
Si no observeu possibles colls d'ampolla, no podreu seguir la tècnica dels cinc per què quan escriviu una autopsia. No podreu posar-ho tot en una pantalla per veure com funciona un producte o saber com és "normal i feliç".
Canvieu a l'esquerra, a l'esquerra, vaig dir que LEEEE...
Per a mi, un dels principis clau de Devops és "canviar a l'esquerra". Moure a l'esquerra en aquest context significa canviar la possibilitat (cap responsabilitat, però només capacitats) per fer coses que solen interessar als enginyers de sistemes, com ara crear mètriques de rendiment, utilitzar registres de manera més eficient, etc., a l'esquerra del Cicle de vida de lliurament de programari.
Autor de la foto en
Els desenvolupadors de programari han de ser capaços d'utilitzar i conèixer les eines de monitorització que utilitza l'empresa per dur a terme el monitoratge en totes les seves formes, mètriques, registres, interfícies de monitoratge i, el més important, veure com funciona el seu producte en producció. No podeu aconseguir que els desenvolupadors inverteixin esforços i temps en el seguiment fins que no puguin veure les mètriques i influir en com es veuen, com el propietari del producte les presenta al CTO a la propera sessió informativa, etc.
En resum
- Condueix el teu cavall a l'aigua. Mostreu als desenvolupadors quants problemes poden evitar per ells mateixos, ajudeu-los a identificar els KPI i mètriques adequats per a les seves aplicacions de manera que hi hagi menys crits per part del propietari del producte que està sent cridat pel CTO. Porta-los a la llum, amb suavitat i calma. Si això no funciona, suborna, amenaça i enganya a ells o al propietari del producte perquè implementi l'obtenció d'aquestes mètriques de les aplicacions el més aviat possible i, a continuació, dibuixeu els diagrames. Això serà difícil, ja que no es veurà com una prioritat i el full de ruta del producte tindrà pendents molts projectes generadors d'ingressos. Per tant, necessitareu un cas de negoci per justificar el temps i les despeses invertides en la implementació del monitoratge al producte.
- Ajudeu els enginyers de sistemes a dormir bé. Demostreu-los que fer servir una llista de verificació "alliberarem" per a qualsevol producte que es llança és una bona cosa. I assegurar-vos que totes les aplicacions en producció estiguin cobertes amb mètriques us ajudarà a dormir millor a la nit, ja que permetrà als desenvolupadors veure què passa i on. Tanmateix, la manera correcta d'irritar i frustrar qualsevol desenvolupador, propietari de producte o CTO és persistir i resistir. Aquest comportament afectarà la data de llançament de qualsevol producte si torneu a esperar fins a l'últim minut, així que torneu a moure's cap a l'esquerra i introduïu aquests problemes al vostre pla de projecte tan aviat com sigui possible. Si cal, aneu a les reunions de producte. Porta un bigoti i feltre falsos o alguna cosa així, mai fallarà. Comuniqueu les vostres inquietuds, demostreu beneficis clars i evangelitzeu.
- Assegureu-vos que tant el desenvolupament (desenvolupament) com les operacions (operacions) entenguin el significat i les conseqüències de les mètriques del producte que passen a la zona vermella. No deixeu Ops com a únic guardià de la salut del producte, assegureu-vos que els desenvolupadors també hi participin (#productsquads).
- Els registres són una gran cosa, però també ho són les mètriques. Combina'ls i no deixis que els teus troncs es converteixin en escombraries en una enorme bola flamejant d'inutilitat. Expliqueu i mostreu als desenvolupadors per què ningú més entendrà els seus registres, mostreu-los com és mirar registres inútils a les 3:15 del matí.
Autor de la foto en
Això és tot. Nou material es publicarà la setmana vinent. Si voleu saber més sobre el curs, us convidem , que tindrà lloc dilluns. I ara tradicionalment estem esperant els vostres comentaris.
Font: www.habr.com