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

📚 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 🤟

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.

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… 😝😝😝😝😝😝

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.

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

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.

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

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

me fue bien

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.