No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Monitoreo de un sistema

5/15
Recursos

Monitorizaci贸n es la actividad de recolectar aquello que describe, en conjunto, el estado actual de un sistema.

Para monitorear un sistema, se empieza por avaluar aquellos puntos claves que describen tanto el rendimiento como su interacci贸n con el mundo real, lo que es llamado APM o Application-Permormance-Monitory.

Al hacer preguntas amplias, obtendr谩s respuestas amplias con incertidumbre sin contexto.

Qu茅 es AMP

AMP o Application Performance Monitory, es la actividad que monitorea aquellos puntos claves que permiten evaluar el rendimiento de una aplicaci贸n o plataforma web.

SRE como rol en IT (Tecnolog铆as de la Informaci贸n)

Existe un rol llamado SRE o Site-Reliability-Engineering 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 turno, madure en ese 谩mbito.
  3. Tu aplicaci贸n y/o plataforma, sea extendido para ese fin

Partiendo de buenas pr谩cticas de desarrollo, documentadas y actualizadas, requieren de intenci贸n que s铆 no son llevadas al acto, todo SRE quedar谩 reducido.

Qu茅 es MTTD

MTTD o Mean Time-to-Detection, es el tiempo promedio en el que se detecta un problema y el equipo, en cuesti贸n, logr贸 sesgarlo.

Qu茅 es MTTR

MTTR o Mean Time-to-Detection, es el tiempo promedio en el que se detecta y se solucion贸 el problema.

Y recuerda:

Con la mejora del 1% en diferentes 谩reas, tendr谩s una cambio notable en poco tiempo.

Para mejorar las m茅tricas MTTD y MTTR: 驴Ser谩 necesario proyectar un MVP para ese fin? 驴Documentar nuestros servicios y/o m贸dulos internos?

Contribuci贸n creada por: Emmanuel Rodr铆guez

Aportes 33

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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 鈥淪ite 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 鈥渁lertas鈥 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鈥檚 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.