Monitoreo de un sistema

Monitoreo
Acto de recolectar constantemente datos del sistema y rendimiento.
Con la finalidad de ser visualizados y trakeados , para identificar lo que va mal y resolverlo

APM: Significa Aplication Performance Monitoring
Un Ejemplo: Monitoreo de bebé.

Cuatro pasos para monitorear:

• Planear
• Instrumentar
• Observar:
• Detectar y resolver

Este proceso debe ser un ciclo, Ocurre constantemente

El monitoreo debe responder con SI/NO

• ¿Nuestro servicio esta en línea y disponible?
• ¿Está funcionando correctamente?
• ¿Está funcionando bien?

MTTD: Tiempo promedio a detección (debería ser lo mas bajo)
MTTR: Tiempo en resolver el problema y logró resolverlo

Esta clase tiene mucho tema por delante como comentaba Celis el equipo SRE esta muy enfocado a estas metricas pero tambien se basan en 3 importantes que son el SLI, SLO, SLA si les interesa les comparto un link que habla a detalle de estas metricas SRE Metrics

En la cultura DevOps, el éxito de un equipo se mide en cuanto tiempo/costo les toma contestar a todas las preguntas del monitoreo de forma positiva.

Para medir el éxito del equipo DevOps se hace de forma cuantificada y de forma numérica (mediante un rango) y utilizando 2 métricas clave utilizadas en la industria:

MTTD (Mean Time-to-Detection): Tiempo promedio a detectar un problema (debería ser lo mas bajo).

MTTR (Mean Time-to-Resolution): Tiempo promedio en resolver el problema.

Hay un puesto en la industria Tech llamado “Site Reliability Engineering” que forman parte del equipo DevOps e Infraestructura, y suelen estar muy atentos a estas métricas (MTTD y MTTR).
.
¿Tú que piensas qué debe hacer un equipo para poder tener unas métricas bajas en MTTD y MTTR?

• Para tener métricas bajas en MTTD lo mejor es tener un buen sistema de monitoreo, ya sea de todo el sistema o poner más atención en las partes de la aplicación donde acceden más los usuarios, así como también un buen sistema de Test lo más parecido al uso en producción.

• Para tener métricas bajas en MTTS lo mejor es simular errores en la aplicación una vez al día en un ambiente controlado (Test), y tomar métricas para ir mejorando la velocidad de solución y de esta manera, el equipo de Developments, DevOps y Infraestructura comprenden como funciona la aplicación y como va evolucionando.

📚 Google SRE Engineering
.

Al hacer preguntas amplias, obtendrás respuestas amplias e incertidumbre sin contexto.

.
Como bien es dicho en la sesión:
.
Existe un rol llamado Site Reliability Engineering (SRE) en DevOps, los cuales se enfocan en la construcción e implementación de servicios que permiten a los equipos de TI y/o soporte realizar mejor su trabajo.
.
Entre sus responsabilidades, se enfocan en la preparación, monitoreo y respuestas a incidentes de un sitio o plataforma.
.
Sin embargo, recordemos que DevOps es también una cultura transversal en una empresa. Por lo que en un desarrollo maduro, generar ciertas métricas, requiere que:
.

1. Tu negocio permita esas métricas
2. Tu equipo en cuestión, madure en ese ámbito
3. Tu aplicación / plataforma, sea extendido para ese fin

.
Recordemos que:
.

Partiendo de buenas prácticas de desarrollo, documentadas y actualizadas, requieren de intención que si no son llevadas al acto, todo SRE quedará reducido.

.
Yo empezaría para MTTD y MTTR:
.

1. Documentando
2. Proyectar MVPs, de servicios o módulos internos.

.
Con la mejora del 1%, se toma un banderazo de partida 🤟

¿Qué significa monitoreo?

• Es la manera en que recolectamos datos de nuestro sistema y el rendimiento
• para poder observarlo de manera rápida y eficaz
• con el fin de tomar medidas respecto a cualquier problema que pueda suceder con nuestra aplicación y resolverlo.
• Con el fin de que tenga poco o nada de impacto hacia tus clientes o negocio

¿Cómo vamos a monitorear?

Aplicaremos Application Performance Monitoring(APM), que es una serie de pasos que seguiremos para realizar un buen monitoreo.

Pero primero

¿Qué vamos a monitorear?

En general, los desarrolladores monitorean

• Tráfico del sitio
• Velocidad de carga
• poder de cómputo que estamos usando
  • CPUS,
  • memoria servidor
• bases de datos
• servicios de terceros
• micro servicios
• etc

Sabiendo que podemos monitorear prácticamente todo de nuestra aplicación, seguiremos el siguiente proceso para realizar un buen monitoreo.

1. Plan
   1. Proceso en el que se decide que se va a monitorear
2. Instrument
   1. En la instrumentación adecuaremos nuestro código para poder obtener los datos que necesitamos ********************
3. Observe
   1. Estaremos observando constantemente lo que decidimos monitorear, con el fin de detectar cualquier problema lo antes posible
4. Detect & Resolve
   1. Aquí nos centramos en detectar el problema para darle su solución lo antes posible, antes de que pueda afectar algún usuario o en su defecto a la menor cantidad de ellos.

¿Cómo válido que todo esté funcionando bien? - 3 Preguntas Claves

Nos haremos 3 preguntas que nos ayudaran a guiarnos, y estas se deben hacer constantemente, para comprobar que todo esté funcionando como debería.

1. ¿Nuestro servicio está en línea y disponible?
   1. Validamos su disponibilidad
2. ¿Está funcionando correctamente?
   1. Validamos este cumpliendo correctamente sus funciones. Por ejemplo
      1. Se puede comprar?
      2. Se puede logear?
      3. Puede hacer alguna orden?
3. ¿Está funcionando bien?
   1. Aquí verificamos el rendimiento,
      1. Si carga lento o rápido?

<aside>
📌 El éxito de un equipo o empresa radica en CUANTO LES TOMA HACER que todas las respuestas a esas preguntas sean Si

</aside>

¿Qué nos puede diferenciar como compañía o desarrollador de los demás?

Podríamos decir que el éxito de monitorear algo reside en 2 puntos.

• Detectar el problema
• Resolverlo

Por lo tanto, existen dos métricas para esto.

1. **********************Promedio de tiempo hasta la detección del problema.
   1. Mean Time-to-Detectition(MTTD)
2. ******************************************************************Promedio de tiempo hasta resolver el problema.
   1. Mean Time-to-Resolution(MTTR)

Por lo tanto, el éxito radica en que el tiempo de nuestras dos métricas sea el menor posible.

En conclusión

Mientras más rápido detectemos el problema, y obtengamos los datos necesarios según nuestro monitoreo, podremos crear soluciones más rápidas y eficaces. Al entender realmente el motivo del problema, podremos dar soluciones más sólidas.

Para detectar en menor tiempo posible cualquier falla, es necesario conocer muy bien los servicios y aplicaciones, monitorearlos e identificar los puntos crítios en sus flujos y tener el monitoreo en etapas previas a producción, como pruebas y desarrollo.

Primero que todo no soy un experto, así que digo esto no más, por puro entusiasmo jajajaj.

Considero que para tener un buen --rated-- (MTTD)%, se debe medir la latencia por la cantidad --request-- que está teniendo el servicio. Y comparar el tiempo – request-- en relacion al tiempo de latencia que toma al servidor para cargar los diferentes paquetes al cliente.

Y en el caso – rated-- (MTTR)%, se me ocurren un par:
Desde medir las frecuencias de los algoritmos.
Validar las altas concurrencias de cada servicio para determinar que lenguaje compila más rápido para trabajar esos servicios, sin descuidar escalabilidad, seguridad, optimización.

Nota final: recordad!!! + cores/ram = it`s a lot of money, BUDDY… Y de eso no se trata… 😝😝😝😝😝😝

El MTTD podría ser automatizado, si tenemos buenas herramientas de monitoreo podríamos lanzar alertas integradas con mail, slack etc informando sobre errores rapidamente.

Equipo de Platzi esta clase y otras no estan cargando en dispositivos moviles.

La frase más importante de esta clase:

El éxito de un equipo de DevOps se mide en cuento tiempo tardan en responder a estas preguntas:

• ¿Nuestro servicio está en línea y disponible?
• ¿Está funcionando correctamente?
• ¿Está funcionando bien?

Esto es cuantificable

Monitoreo de un sistema

El monitoreo consiste en recolectar datos del sistema y de su rendimiento, visualizar dichos datos mediante un dashboard para poderlos interpretar de manera rápida, así mismo, al estar recolectando estos datos, se puede realizar un seguimiento de su comportamiento.

APM

Significa Application Performance Monitoring y es el tipo de monitoreo mas utilizado actualmente.

• Planear: El equipo decide que es lo que se va a monitorear
• Instrumentar: El sistema se crea con instrumentación para que el equipo pueda recolectar información
• Observar: Observar los datos generados por los módulos del sistema que están instrumentados
• Detectar y Resolver: Cuando se detectan problemas, se comienza a tomar medidas de acción para resolverlo

Este proceso es constante, cada que hay cambios dentro del flujo de desarrollo.

Guía del correcto monitoreo

Durante el proceso de monitoreo, es necesario responder estas preguntas:

• ¿Nuestro servicio esta en línea y disponible?
• ¿Está funcionando correctamente?
• ¿Está rindiendo bien?

Si alguna de las respuestas de estas preguntas es NO, se deben consultar los datos recolectados durante el monitoreo para poder resolver el problema.

Métricas de monitoreo

• MTTD: Tiempo promedio a detección, ¿Cuánto tardamos en darnos cuenta de que existe un problema?
• MTTR: Tiempo en resolver el problema y logró resolverlo, ¿Cuánto tardamos en atender y/o solucionar el problema?

SRE

Significa Site reliability engineering y son las personas que forman parte del equipo de DevOps y están atentos a las métricas de monitoreo.

Esto de los Quiz le añade valor a los cursos aquí en platzi, me gustan!

me fue bien

Creería que se podría reducir el MTTD por medio de un sistema de alertas automatizado. El sistema de alertas podría conectarse con sistemas de incidentes como OpsGenie para alertar a las personas encargadas. Un script automatizado podría encargarse de evaluar ciertos aspectos del sistema constantemente para detectar cualquier anomalía y crear las alertas de ser necesario. Adicional al script, también se podrían publicar métricas de uso constantemente desde los servicios (uso de recursos, tiempos de respuestas, cantidad de respuesta con códigos de error, etc) y conectar grandes cantidades de outliers seguidos al sistema de incidentes.
 
 
Para reducir el MTTR creo que depende del tipo de error que ocurra:

• Suponiendo que se cayó una de las zonas que usamos. Podríamos tener un mecanismo que automáticamente deje de rutear hacia la zona que está fallando hacia otra zona que esté funcionando correctamente.
• Suponiendo que se introdujo un bug en el código. Podríamos tener un mecanismo que vuelva a llevar al sistema a un estado anterior que se sabía funcionaba correctamente.
• En caso de que sea otro problema, igual es importante tener sistema de logs que nos permita capturar la mayor información posible sobre errores, como por ejemplo Sentry, para reducir el tiempo necesario para diagnosticar el problema.

6/6 👺

Monitoreo: observar datos y analizarlos para detectar errores y fallas para darles solución.

Un Ejemplo: Monitoreo de bebé.

Cuatro pasos para monitorear:

Planear
Instrumentar
Observar:
Detectar y resolver

Este proceso debe ser un ciclo, Ocurre constantemente

El monitoreo debe responder con SI/NO

¿Nuestro servicio esta en línea y disponible?
¿Está funcionando correctamente?
¿Está funcionando bien?
MTTD: Tiempo promedio a detección (debería ser lo mas bajo)
MTTR: Tiempo en resolver el problema y logró resolverlo

5/6

Testing, testing, testing

Hola, a mi consideración podemos hacer las siguientes acciones:
MTTD (Mean Time-to-Detection): Tiempo promedio a detectar un problema (debería ser lo mas bajo).

• Generar alertas de monitoreo que nos ayuden a identificar de manera oportuna cuando existe un evento o un incidente y generar canales de comunicación que ayuden a notificar de manera mas rápida y oportuna.

MTTR (Mean Time-to-Resolution): Tiempo promedio en resolver el problema.

• Generar autómatas que ayuden a resolver incidentes

En el quiz acerté 5 de 6, la última pregunta no estaba seguro y erré el tiro.

Para reducir tiempos en los procesos yo lo veo desde la óptica de la administración. Primero que nada, si uno tiene un equipo ya capacitado y adaptado al MTTD y MTTR, lo mejor creo que es hacer simulaciones para mejorar las marcas, o bien hacer brainstorming para escuchar sugerencias desde lo empírico. Siempre habrá alguien creativo que aporte algo distinto.

6/6 en el quiz. Me sentí muy bien porque refleja que he prestado atención y aprendido lo enseñado por el profe Ricardo Celis.

¡Vamos por mas!.

Esta clase contiene excelentes definiciones. En la empresa donde trabajo, tenemos metricas de salud de dos tipos principalmente, metricas asociadas al performance y consumo de los recursos de infraestructura del servicio (uso de memoria, cpu del contenedor en el que estan desplegados) y tipos mas particulares a la ejecucion y disponibilidad de los servicios (duracion de un request, confirmacion de ejecucion de un flujo como se espera)

El MTTD depende, tenemos alertas asociadas a estas metricas como por ejemplo si no detectamos que un cron que se debe de ejecutar al menos una vez por dia, alertamos al equipo para investigar.

El MTTR tambien va a depender del tipo y complejidad del problema. Asi mismo tenemos la cultura de documentar los post mortems y compartir soluciones por escrito en wikis o articulos de conocimiento para que eventualmente este sea menor.

Súper…!

Este curso es clave para iterar óptimamente.

En el quiz 5/6, excelente contenido del curso.

El quiz estuvo excelente! Muy divertido! Me fue muy bien 6/6 😄

Excelente me fue muy bien con el quiz

mmm se me ocurre “alertas” y personas expertas en el negocio y con buen skill de programación para solucionar rápido.

PD. no dejar de guardia al jr. jejeje :v

Para reducir el MTTD se me ocurre que el sistema de orquestación puede indicar cuando algo no funciona como estaba previsto. Así como nos ayuda con herramientas y tareas repitivas podrían sumarle data points numéricos que nos indiquen que todo está okey.
Para reducir el MTTR creo que tendría que ser clave el trabajo del equipo. Profecionales que entiendad tanto ell funcionamiento de los microservicios como el conjunto macro de los contendores ubicados en la nube.

6/6 =D

6/6 Como evoluciona a pasos agigantados las tegnologias, todavia recuerdo cuando se usaba arquitecturas distribuidas; Con os EJB’s que eran un dolor de cabeza.

me fue bien saque 5 d 6 solo la ultima me equivoque cambie al final. pero me gusto esos quiz rápidos.