Feliz venres a todos! Amigos, hoxe continuamos a serie de publicacións dedicadas ao curso , porque as clases do novo grupo do curso comezarán a finais da vindeira semana. Entón, imos comezar!
O seguimento é xusto. Este é un feito coñecido. Abre Nagios, executa NRPE no sistema remoto, configura Nagios no porto NRPE TCP 5666 e tes un seguimento.
É tan sinxelo que non é interesante. Agora tes métricas básicas para o tempo da CPU, o subsistema de disco, a RAM, que se proporcionan por defecto a Nagios e NRPE. Pero isto non é realmente un "seguimento" como tal. Este é só o comezo.
(Normalmente instalan PNP4Nagios, RRDtool e Thruk, configuran notificacións en Slack e van directamente a nagiosexchange, pero deixémolo por agora).
Bo seguimento é en realidade bastante complexo, realmente necesitas coñecer os elementos internos da aplicación que estás supervisando.
É difícil o seguimento?
Calquera servidor, xa sexa Linux ou Windows, terá por definición algún propósito. Apache, Samba, Tomcat, almacenamento de ficheiros, LDAP: todos estes servizos son máis ou menos únicos nun ou máis aspectos. Cada un ten a súa propia función, as súas propias características. Hai diferentes formas de obter métricas, KPI (indicadores clave de rendemento), que son interesantes para ti cando o servidor está baixo carga.
Autor da foto en
(Gustaríame que os meus cadros fosen azul neón - suspirando soñador -... hmm...)
Calquera software que proporcione servizos debe ter un mecanismo para recoller métricas. Apache ten un módulo mod-status, mostrando a páxina de estado do servidor. Nginx ten - stub_status. Tomcat ten JMX ou aplicacións web personalizadas que mostran métricas clave. MySQL ten un comando "mostrar o estado global", etc.
Entón, por que os desenvolvedores non crean mecanismos similares nas aplicacións que crean?
Só fan isto os desenvolvedores?
Un certo nivel de indiferenza cara á incorporación de métricas non se limita aos desenvolvedores. Traballei en empresas onde desenvolveron aplicacións usando Tomcat e non proporcionou ningunha das súas propias métricas, nin rexistros de actividade do servizo, excepto os rexistros xerais de erros de Tomcat. Algúns desenvolvedores xeran moitos rexistros que non significan nada para o administrador do sistema que ten a mala sorte de lelos ás 3:15 da mañá.
Autor da foto en
Os enxeñeiros de sistemas que permiten que estes produtos sexan liberados tamén deben asumir algunha responsabilidade pola situación. Poucos enxeñeiros de sistemas teñen o tempo ou o coidado para intentar extraer métricas significativas dos rexistros, sen o contexto desas métricas e a capacidade de interpretalas á luz da actividade da aplicación. Algúns non entenden como poden beneficiarse diso, ademais dos indicadores "actualmente (ou pronto estará) mal".
Un cambio no pensamento sobre a necesidade de métricas debe producirse non só entre os desenvolvedores, senón tamén entre os enxeñeiros de sistemas.
Para calquera enxeñeiro de sistemas que necesite non só responder a eventos críticos, senón asegurarse de que non se produzan, a falta de métricas adoita ser unha barreira para facelo.
Non obstante, os enxeñeiros de sistemas normalmente non xogan co código para gañar cartos para a súa empresa. Necesitan desenvolvedores principais que comprendan a importancia da responsabilidade do enxeñeiro de sistemas para identificar problemas, concienciar sobre os problemas de rendemento e similares.
Isto devops cousa
A mentalidade devops describe a sinerxía entre o desenvolvemento (dev) e o pensamento de operacións (ops). Calquera empresa que diga "facer devops" debe:
- dicindo cousas que probablemente non fan (referíndose ao meme de The Princess Bride - "Non creo que signifique o que ti pensas que significa!")
- Fomentar unha actitude de mellora continua do produto.
Non podes mellorar un produto e saber que foi mellorado se non sabes como funciona actualmente. Non podes saber como funciona un produto se non entendes como funcionan os seus compoñentes, os servizos dos que depende, os seus principais puntos de dor e pescozos de botella.
Se non observas posibles pescozos de botella, non poderás seguir a técnica de Five Whys ao escribir unha autopsia. Non poderás poñer todo nunha pantalla para ver como funciona un produto nin saber como é "normal e feliz".
Desprácese á esquerda, á ESQUERDA, DÍN QUE LEEEE—
Para min, un dos principios fundamentais de Devops é "cambiar á esquerda". Cambiar á esquerda neste contexto significa cambiar a posibilidade (ningunha responsabilidade, pero só capacidades) para facer cousas que normalmente lles importan aos enxeñeiros de sistemas, como crear métricas de rendemento, usar rexistros de forma máis eficiente, etc., á esquerda no Ciclo de vida de entrega de software.
Autor da foto en
Os desenvolvedores de software deben ser capaces de utilizar e coñecer as ferramentas de vixilancia que utiliza a empresa para realizar o seguimento en todas as súas formas, métricas, rexistros, interfaces de monitorización e, o máis importante, observa como funciona o seu produto na produción. Non podes conseguir que os desenvolvedores invisten esforzo e tempo na supervisión ata que poidan ver as métricas e influír no seu aspecto, como as presenta o propietario do produto ao CTO na próxima reunión informativa, etc.
En breve
- Conduce o teu cabalo á auga. Amosalles aos desenvolvedores cantos problemas poden evitar por si mesmos, axúdalles a identificar os KPI e as métricas axeitados para as súas aplicacións para que haxa menos gritos do propietario do produto ao que o CTO está a berrar. Tráeos á luz, suavemente e con calma. Se iso non funciona, suborna, ameaza e engade a eles ou ao propietario do produto para que implemente a obtención destas métricas das aplicacións o máis rápido posible e despois debuxa os diagramas. Isto será difícil xa que non será visto como unha prioridade e a folla de ruta do produto terá pendentes moitos proxectos xeradores de ingresos. Polo tanto, necesitará un caso de negocio para xustificar o tempo e os gastos dedicados á implementación do seguimento no produto.
- Axuda aos enxeñeiros do sistema a durmir unha boa noite. Demostralles que usar unha lista de verificación "imos lanzar" para calquera produto que se lance é unha boa cousa. E asegurarte de que todas as aplicacións en produción estean cubertas con métricas axudarache a durmir mellor pola noite, xa que permitirá aos desenvolvedores ver o que está a fallar e onde. Non obstante, a forma correcta de irritar e frustrar a calquera desenvolvedor, propietario de produto ou CTO é persistir e resistir. Este comportamento afectará a data de lanzamento de calquera produto se volves a esperar ata o último minuto, polo que volve a cambiar á esquerda e incorpora estes problemas ao teu plan de proxecto canto antes. Se é necesario, diríxese ás reunións de produtos. Use un bigote falso e fieltro ou algo así, nunca fallará. Comunica as túas preocupacións, demostra beneficios claros e evanxeliza.
- Asegúrese de que tanto o desenvolvemento (desenvolvemento) como as operacións (operacións) comprendan o significado e as consecuencias das métricas do produto que se moven á zona vermella. Non deixes a Ops como o único gardián da saúde do produto, asegúrate de que os desenvolvedores tamén participen (#productsquads).
- Os rexistros son unha gran cousa, pero tamén o son as métricas. Combínaos e non deixes que os teus rexistros se convertan nun lixo nunha enorme bola de inutilidade. Explica e móstralles aos desenvolvedores por que ninguén máis entenderá os seus rexistros, móstralles como é mirar rexistros inútiles ás 3:15 da mañá.
Autor da foto en
Iso é todo. Novo material será lanzado a vindeira semana. Se queres saber máis sobre o curso, invitámoste , que terá lugar o luns. E agora, tradicionalmente, esperamos os teus comentarios.
Fonte: www.habr.com