¿Por qué los ingenieros no se preocupan por el monitoreo de aplicaciones?

Todo con el viernes! Amigos, hoy continuamos una serie de publicaciones dedicadas al curso de Prácticas y herramientas de DevOps , porque las clases en el nuevo grupo del curso comenzarán a fines de la próxima semana. ¡Entonces comencemos!



El monitoreo es fácil . Este es un hecho conocido. Levante Nagios, ejecute NRPE en el sistema remoto, configure Nagios en el puerto TCP NRPE 5666 y tendrá monitoreo.

Es tan fácil que no es interesante. Ahora tiene las métricas básicas para el tiempo de procesador, subsistema de disco, RAM, que vienen por defecto en Nagios y NRPE. Pero en realidad, esto no es "monitoreo" como tal. Esto es solo el comienzo.

(Por lo general, instalan PNP4Nagios, RRDtool y Thruk, configuran notificaciones en Slack y van directamente a nagiosexchange, pero por ahora lo dejen ir).

Un buen monitoreo es realmente bastante complicado, realmente necesita conocer el funcionamiento interno de la aplicación que está viendo.

¿Es difícil el monitoreo?

Cualquier servidor, ya sea Linux o Windows, por definición tendrá 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), interesantes para usted cuando el servidor está bajo carga.


Foto de Luke Chesser en Unsplash


(Me gustaría que mis tableros se pintaran en colores azul neón, suspirando soñador, ... hmm ...)

Cualquier software que brinde servicios debe tener un mecanismo para recopilar métricas. Apache tiene un módulo de mod-status que muestra la página de mod-status del servidor. Nginx tiene stub_status . Tomcat tiene JMX o aplicaciones web especiales que muestran métricas clave. MySQL tiene el comando "mostrar estado global", etc.
Entonces, ¿por qué los desarrolladores no incrustan tales mecanismos en las aplicaciones que crean?

¿Los desarrolladores solo hacen esto?

Un cierto nivel de indiferencia para incorporar métricas no se limita a los desarrolladores. Trabajé en compañías en las que desarrollé aplicaciones con Tomcat y no produje ninguna de mis métricas, ni registros de actividad de servicio, excepto los registros generales de errores de Tomcat. Algunos desarrolladores generan una gran cantidad de registros que no significan nada para el administrador del sistema, que tuvo mala suerte de leerlos a las 3:15 de la mañana.


Publicado por Tim Gouw en Unsplash

Los ingenieros de sistemas que permiten que se lancen dichos productos también deben tener cierta responsabilidad por la situación. Pocos ingenieros de sistemas tienen tiempo y cuidado para tratar de obtener métricas significativas de los registros, sin el contexto de estas métricas y la capacidad de interpretarlas a la luz de la actividad de la aplicación. Algunos no entienden qué beneficio pueden obtener de esto, a excepción de indicadores como "algo está mal actualmente (o lo estará pronto)".

Un cambio de pensamiento con respecto a la necesidad de métricas debería ocurrir no solo entre los desarrolladores, sino también entre los ingenieros de sistemas.

Para cualquier ingeniero de sistemas que necesite no solo responder a eventos críticos, sino también garantizar su ausencia, la ausencia de métricas suele ser un obstáculo para esto.

Sin embargo, los ingenieros de sistemas generalmente no profundizan en el código y ganan dinero para su empresa. Necesitan desarrolladores líderes que comprendan la importancia de la responsabilidad de un ingeniero de sistemas para detectar problemas, crear conciencia sobre los problemas de rendimiento y similares.

Esta cosa devops

La mentalidad devops describe la sinergia del pensamiento del desarrollador (devs) y la explotación (ops). Cualquier empresa que afirme estar haciendo "devops" debería:

1. para decir lo que probablemente no hacen (una pista sobre el meme de la película "Princess Bride" - "¡No creo que signifique lo que tú piensas que significa!")
2. Promover una posición de mejora continua del producto.

No puede mejorar un producto y sabe que se ha mejorado si no sabe cómo funciona actualmente. No podrá averiguar cómo funciona un producto si no comprende cómo funcionan sus componentes, los servicios de los que depende, sus principales puntos débiles y cuellos de botella.
A menos que esté observando posibles cuellos de botella, no puede seguir la técnica Five Why al escribir Postmortem. No puede recopilar todo en una pantalla para ver cómo funciona el producto o para saber cómo se ve "normal y feliz".

Desplazamiento a la izquierda, IZQUIERDA, DIJE, NOOOOOOOO—

Para mí, uno de los principios clave de Devops es "cambiar a la izquierda". Un cambio a la izquierda en este contexto significa un cambio en la capacidad ( no responsabilidad , sino solo la capacidad) de hacer lo que a los ingenieros de sistemas generalmente les importa, por ejemplo, crear métricas de rendimiento, usar registros de manera más eficiente, etc., a la izquierda en el ciclo de vida de entrega del software ( Software Delivery Life Cycle).


Foto de NESA por Makers en Unsplash

Los desarrolladores de software deben poder usar y conocer las herramientas de monitoreo que la compañía usa para monitorear en todas sus formas, métricas, registros, interfaces de monitoreo y, lo más importante, observar cómo funciona su producto en la producción . No puede obligar a los desarrolladores a invertir tiempo y esfuerzo en el monitoreo hasta que puedan ver las métricas e influir en cómo se ven, cómo el propietario del producto presentará sus CTO en la próxima sesión informativa, etc.

En resumen

1. Trae el caballo al agua. Muestre a los desarrolladores cuántos problemas pueden evitar por sí mismos, ayúdelos a identificar los KPI y las métricas correctas para sus aplicaciones, de modo que el propietario del producto tenga menos gritos que el CTO. Tráigalos a la luz, suave y calmadamente. Si esto no funciona, soborne, amenace y persuada a ellos o al propietario del producto para obtener rápidamente estas métricas de las aplicaciones, y luego dibuje diagramas. Esto será difícil, ya que no se considerará una prioridad, y habrá muchos proyectos generadores de ingresos en espera de implementación en la hoja de ruta del producto. Por lo tanto, necesitará un caso de negocios para justificar el tiempo y el dinero gastados en implementar el monitoreo en el producto.
2. Ayuda a los ingenieros del sistema a dormir lo suficiente. Muéstreles que usar una lista de verificación de lanzamiento de lanzamiento para cualquier producto es bueno. Y comprobar que todas las aplicaciones en producción están cubiertas con métricas lo ayudará a dormir bien, permitiendo a los desarrolladores ver qué funciona y dónde no. Sin embargo, la manera correcta de molestar y molestar a cualquier desarrollador, propietario de producto y CTO es empujar los palos en las ruedas y resistir. Este comportamiento afectará la fecha de lanzamiento de cualquier producto si espera nuevamente hasta el último minuto, por lo tanto, vuelva a girar a la izquierda e incluya estos problemas lo antes posible en el plan del proyecto. Si es necesario, diríjase a las reuniones de productos. Use un bigote falso y fieltro o algo así, nunca falla. Informe sus inquietudes, muestre beneficios obvios y evangelice.
3. Asegúrese de que tanto los desarrolladores (dev) como las operaciones (ops) entiendan el significado y las consecuencias de mover las métricas del producto a la zona roja. No deje la operación como la única protección sobre el rendimiento del producto; asegúrese de que los desarrolladores también participen en él (#productsquads).
4. Los registros son una gran cosa, pero las métricas también. Combínalos y no dejes que tus troncos se conviertan en basura en una enorme bola de futilidad en llamas. Explique y muestre a los desarrolladores por qué nadie, excepto ellos, comprenderá sus registros, muéstreles cómo se siente ver registros inútiles a las 3:15 de la mañana.

Foto de Marko Horvat en Unsplash

Eso es todo. Se lanzará nuevo material la próxima semana. Si desea obtener más información sobre el curso, lo invitamos a una jornada de puertas abiertas , que se realizará el lunes. Y ahora estamos tradicionalmente esperando sus comentarios.