¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Tomás Calleja 08/03/2023 Cargando comentarios…
Cuando pensamos en la nube pública, nos vienen a la cabeza las opciones de flexibilidad a la hora de levantar y apagar máquinas virtuales o servicios serverless como Cloud Run y BigQuery que nos solucionan problemas de una manera sencilla y barata. Lo que no suele venir tan rápido es la cantidad de servicios de valor añadido que nos ofrecen las nubes públicas para mejorar nuestro día a día. Hoy vamos a dedicar un rato a hablar de uno de estos grandes olvidados, en concreto la monitorización de servicios de Cloud Monitoring. Gracias a esta opción, podemos controlar de una manera efectiva y moderna nuestros servicios que corren en Google Cloud haciendo uso de SLIs, SLOs y alertas.
Hace ya varios años desde que Google decidió cambiar el nombre a su suite de servicios de logging, monitorización y similares (tracing, profiling…) pasando de Stackdriver a Operations suite. Dicho esto, la mayoría de nosotros continúa usando stackdriver para referirse a esta suite de servicios.
Dentro de esta suite tenemos los sistemas de logging, la monitorización de servicios, el análisis de trazas y el profiling (el servicio debugger se va a deprecar, por lo que ya no lo tenemos en cuenta 💀). Vamos a ver por encima estos servicios y sus puntos fuertes.
Para poder entender la propuesta de Google sobre monitorización de servicios es imprescindible conocer el significado de algunos acrónimos.
Una vez que tenemos claros los conceptos del punto anterior vamos a hablar de cómo podemos llevar esto a nuestras cargas de trabajo sin recurrir a herramientas ad hoc o externas, todo dentro de la consola de Google.
Lo primero que tenemos que hacer ir al apartado de monitorización donde encontraremos el apartado de servicios:
Una vez en el apartado correspondiente nos toca el turno a la definición de nuestros servicios. Dependiendo de donde se ejecuten nuestros servicios veremos que la definición es diferente, vamos a ver los 3 tipos de servicios que tenemos:
Ahora que ya tenemos nuestra lista de servicios ha llegado el turno de definir los SLIs y SLOs. Aunque tenemos total libertad para hacer nuestros propios SLIs, el sistema nos ayuda a crear dos de los más habituales si el servicio es autodescubierto o sugerido, estamos hablando de availability y latency que nos ayudan a saber si nuestros servicios están disponibles y con unos tiempos de respuesta aceptables.
Vamos a ver cómo crearlos en la consola de administración.
Lo primero que hacemos es crear nuestro SLI, para este ejemplo usaremos
Availability:
Una vez decidido el tipo de SLI lo siguiente es definir si queremos hacer un recuento basado en el número de llamadas o por ventana. El primer método nos ofrece un SLI más simple, pero en determinadas ocasiones nos puede jugar malas pasadas, imaginemos que nuestro servicio tiene 1000 llamadas al segundo de media y el servicio está caído durante 1 minuto, lo normal sería tener 60.000 llamadas erróneas, pero seguramente serán muchas más si contamos los reintentos al fallar las llamadas… Esto nos puede causar que nuestro SLI baje en gran medida cuando “solo” hemos fallado durante 1 minutillo de nada. El método basado en ventanas soluciona este problema contando los minutos buenos contra los malos, de esta forma tendremos más en cuenta cuánto tiempo nuestro servicio está funcionando bien o mal en lugar de solo el número de llamadas.
En el siguiente paso, tenemos que seleccionar la métrica a tener en cuenta, al ser unos de los SLIs predefinidos no tenemos opción a modificarla. Al haber seleccionado el recuento por ventana lo que sí tenemos que hacer es definir el tiempo de la venta y el porcentaje de llamadas que consideramos correcto. Pondremos, por ejemplo, 5 minutos y 99%. ¡Vamos a por el SLO!
Anteriormente en este post, decíamos que un SLO se componía de 3 cosas, el SLI que ya lo tenemos, el tiempo a considerar y el objetivo a cumplir. A la hora de poner el objetivo tenemos que tener en cuenta que la idea de un SLO es indicar que es servicio es correcto, no perfecto, poner un objetivo irreal no es recomendable. Ponemos, por ejemplo, 98% de minutos correctos.
A la hora de escoger el tiempo nos vuelven a dar dos opciones, o considerar periodos fijos de calendario como semana o mes u optar por un número de días hacia atrás que se van moviendo dinámicamente. Para este ejemplo optamos por los últimos 30 días.
En la última fase de configuración veremos un resumen de nuestra configuración y un JSON muy útil si queremos terraformar el proceso.
{
"displayName": "98% - Windowed Availability - Rolling 30 days",
"goal": 0.98,
"rollingPeriod": "2592000s",
"serviceLevelIndicator": {
"windowsBased": {
"windowPeriod": "300s",
"goodTotalRatioThreshold": {
"basicSliPerformance": {
"availability": {}
},
"threshold": 0.99
}
}
}
}
Por último, vamos a configurar una alerta para que nos avise en caso de que nuestro budget de error se reduzca rápidamente. De esta forma, podemos remediarlo antes de que sea tarde y nos quedemos sin margen de error durante el tiempo definido en el SLO.
¿Por qué es importante tener controlado cuando nos queda de SLO? La respuesta viene dada por el principal uso de los SLOs en SRE. Uno de los principales problemas a la hora de mantener nuestros servicios fiables es saber cuándo tenemos que enfocarnos en sacar nueva funcionalidad y cuándo en mejorar la estabilidad del sistema. Según SRE, podemos usar los SLOs para este objetivo, si nuestro servicio está cumpliendo con los objetivos, podemos centrarnos en nueva funcionalidad mientras que si vemos comprometidos los SLOs tendremos que retrasar los despliegues de nuevas versiones para centrarnos en hacer que lo que tenemos funcione con la seguridad que hemos acordado mediante la definición del SLO.
Vamos a ver lo fácil que es configurar una de estas alertas. Para hacerlo solo tenemos que ir al detalle del servicio que hemos creado para ver, entre otras cosas, los SLOs definidos:
A primera vista, ya podemos imaginarnos cuál es el siguiente paso lógico viendo el aviso que sale por pantalla…. Necesitamos configurar nuestra alarma, lo cual se hace pinchando en el icono de la campana con el más. Veamos el modal de configuración:
Los dos parámetros a configurar son: el tiempo que vamos a considerar para el cálculo y el porcentaje de reducción del budget. Como valores por defecto tenemos 1 hora de tiempo y un 10% de pérdida como disparadores de la alarma. Si aumentamos el tiempo o reducimos el porcentaje podemos tener alarmas demasiado frecuentes que saltan en situaciones normales que no requieren nuestra intervención. Por otro lado, si pecamos de conservadores puede pasar que cuando nos llegue el aviso nuestro budget ya esté consumido del todo. Como casi siempre, lo recomendable es el término medio e ir ajustando estos valores para adaptarlos a nuestro caso particular.
Gracias a esta nueva funcionalidad de Cloud Monitoring podemos fácilmente definir nuestros indicadores, objetivos y alarmas de pérdida de budget. Todo ello nos va a permitir poder saber qué pasa en nuestros servicios de una manera sencilla teniendo además herramientas objetivas para saber si nuestros servicios se están portando correctamente o, por el contrario, es necesario trabajar en hacerlos más estables. Esperamos que os haya gustado el post y que lo pongáis en práctica dentro de vuestros proyectos.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.