¡Feliz Viernes a todos! Amigos, hoy continuamos la serie de publicaciones dedicadas al curso. , porque las clases del nuevo grupo del curso empezarán a finales de la próxima semana. ¡Vamos a empezar!
El monitoreo es sólo. Este es un hecho conocido. Abra Nagios, ejecute NRPE en el sistema remoto, configure Nagios en el puerto TCP 5666 de NRPE y tendrá monitoreo.
Es tan fácil que no es interesante. Ahora tiene métricas básicas para el tiempo de CPU, subsistema de disco, RAM, proporcionadas de forma predeterminada a Nagios y NRPE. Pero en realidad esto no es un “seguimiento” como tal. Este es solo el comienzo.
(Por lo general, instalan PNP4Nagios, RRDtool y Thruk, configuran notificaciones en Slack y van directamente a nagiosexchange, pero dejemos eso de lado por ahora).
Buen seguimiento En realidad es bastante complejo, realmente necesita conocer los aspectos internos de la aplicación que está monitoreando.
¿Es difícil el seguimiento?
Cualquier servidor, ya sea Linux o Windows, por definición cumplirá algún propósito. Apache, Samba, Tomcat, almacenamiento de archivos, LDAP: todos estos servicios son más o menos únicos en uno o más aspectos. Cada uno tiene su propia función, sus propias características. Hay diferentes formas de obtener métricas, KPI (indicadores clave de rendimiento), que le resultarán interesantes cuando el servidor está bajo carga.
autor de la foto en
(Ojalá mis tableros fueran de color azul neón - suspirando soñadoramente -... hmm...)
Cualquier software que proporcione servicios debe tener un mecanismo para recopilar métricas. Apache tiene un módulo mod-status, mostrando la página de estado del servidor. Nginx tiene - stub_status. Tomcat tiene JMX o aplicaciones web personalizadas que muestran métricas clave. MySQL tiene un comando "mostrar estado global", etc.
Entonces, ¿por qué los desarrolladores no incorporan mecanismos similares a las aplicaciones que crean?
¿Solo los desarrolladores hacen esto?
Un cierto nivel de indiferencia hacia la incorporación de métricas no se limita a los desarrolladores. Trabajé en empresas donde desarrollaban aplicaciones utilizando Tomcat y no proporcionaban ninguna métrica propia, ni registros de actividad del servicio, excepto los registros de errores generales de Tomcat. Algunos desarrolladores generan muchos registros que no significan nada para el administrador del sistema, que tiene la mala suerte de leerlos a las 3:15 de la mañana.
autor de la foto en
Los ingenieros de sistemas que permiten el lanzamiento de dichos productos también deben asumir cierta responsabilidad por la situación. Pocos ingenieros de sistemas tienen el tiempo o la atención para intentar extraer métricas significativas de los registros, sin el contexto de esas métricas y la capacidad de interpretarlas a la luz de la actividad de la aplicación. Algunos no entienden cómo pueden beneficiarse de ello, aparte de los indicadores de "algo está actualmente (o pronto estará) mal".
Debe producirse un cambio de mentalidad sobre la necesidad de métricas no sólo entre los desarrolladores, sino también entre los ingenieros de sistemas.
Para cualquier ingeniero de sistemas que necesite no sólo responder a eventos críticos, sino también asegurarse de que no ocurran, la falta de métricas suele ser una barrera para hacerlo.
Sin embargo, los ingenieros de sistemas normalmente no modifican el código para ganar dinero para su empresa. Necesitan desarrolladores líderes que comprendan la importancia de la responsabilidad del ingeniero de sistemas a la hora de identificar problemas, crear conciencia sobre problemas de rendimiento y cosas similares.
Esta cosa devops
La mentalidad devops describe la sinergia entre el pensamiento de desarrollo (dev) y operaciones (ops). Cualquier empresa que afirme "hacer devops" debe:
- diciendo cosas que probablemente no dicen (refiriéndose al meme de La princesa prometida: "¡No creo que signifique lo que tú crees que significa!")
- Fomentar una actitud de mejora continua del producto.
No puedes mejorar un producto y saber que ha sido mejorado si no sabes cómo funciona actualmente. No se puede saber cómo funciona un producto si no se comprende cómo funcionan sus componentes, los servicios de los que depende, sus principales puntos débiles y cuellos de botella.
Si no está atento a posibles obstáculos, no podrá seguir la técnica de los cinco porqués al escribir una autopsia. No podrás poner todo en una pantalla para ver cómo funciona un producto o saber cómo se ve "normal y feliz".
Shift a la izquierda, IZQUIERDA, DIJE LEEEE—
Para mí, uno de los principios clave de Devops es "desplazarse hacia la izquierda". Desplazarse hacia la izquierda en este contexto significa desplazar la posibilidad (sin responsabilidad, pero solo capacidades) para hacer cosas que normalmente interesan a los ingenieros de sistemas, como crear métricas de rendimiento, usar registros de manera más eficiente, etc., a la izquierda del ciclo de vida de entrega de software.
autor de la foto en
Los desarrolladores de software deben ser capaces de utilizar y conocer las herramientas de monitoreo que utiliza la empresa para poder realizar el monitoreo en todas sus formas, métricas, logs, interfaces de monitoreo y, lo más importante, observe cómo funciona su producto en producción. No se puede lograr que los desarrolladores inviertan esfuerzo y tiempo en el monitoreo hasta que puedan ver las métricas e influir en su apariencia, cómo el propietario del producto las presenta al CTO en la próxima sesión informativa, etc.
Brevemente hablando
- Lleva a tu caballo al agua. Muestre a los desarrolladores cuántos problemas pueden evitarse, ayúdelos a identificar los KPI y métricas correctos para sus aplicaciones para que haya menos gritos por parte del propietario del producto al que le grita el CTO. Llévalos a la luz, con suavidad y calma. Si eso no funciona, soborne, amenace y engatuse a ellos o al propietario del producto para que implementen la obtención de estas métricas de las aplicaciones lo más rápido posible y luego dibujen los diagramas. Esto será difícil ya que no se considerará una prioridad y la hoja de ruta del producto tendrá pendientes muchos proyectos generadores de ingresos. Por lo tanto, necesitará un caso de negocio para justificar el tiempo y los gastos invertidos en implementar el seguimiento en el producto.
- Ayude a los ingenieros de sistemas a dormir bien por la noche. Muéstreles que usar una lista de verificación de “liberar” para cualquier producto que se lance es algo bueno. Y asegurarse de que todas las aplicaciones en producción estén cubiertas con métricas le ayudará a dormir mejor por la noche al permitir a los desarrolladores ver qué va mal y dónde. Sin embargo, la forma correcta de irritar y frustrar a cualquier desarrollador, propietario de producto o CTO es persistir y resistir. Este comportamiento afectará la fecha de lanzamiento de cualquier producto si vuelve a esperar hasta el último minuto, así que cambie a la izquierda nuevamente e incluya estos problemas en su plan de proyecto lo antes posible. Si es necesario, dirígete a las reuniones de productos. Lleva bigote postizo y fieltro o algo así, nunca fallará. Comunique sus inquietudes, demuestre beneficios claros y evangelice.
- Asegúrese de que tanto el desarrollo (dev) como las operaciones (ops) comprendan el significado y las consecuencias de que las métricas del producto pasen a la zona roja. No deje a Ops como el único guardián de la salud del producto, asegúrese de que los desarrolladores también participen (#productsquads).
- Los registros son una gran cosa, pero también lo son las métricas. Combínalos y no dejes que tus troncos se conviertan en basura en una enorme bola llameante de inutilidad. Explique y muestre a los desarrolladores por qué nadie más entenderá sus registros, muéstreles cómo es mirar registros inútiles a las 3:15 de la mañana.
autor de la foto en
Eso es todo. La próxima semana se lanzará nuevo material. Si deseas conocer más sobre el curso, te invitamos a , que tendrá lugar el lunes. Y ahora tradicionalmente estamos esperando sus comentarios.
Fuente: habr.com