El Cloud y la monitorización de servicios.

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.

Google Cloud's operations suite (antes stackdriver)

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.

• Logging: sistemas de registro de logs, nos permite realizar consultas sobre los logs de nuestras aplicaciones de manera centralizada, sencilla y potente: podemos elegir si buscar en los logs a nivel de aplicación, filtrando por servicios, localizaciones, texto en concreto, severidad… Podemos elegir qué logs guardamos y cuáles descartamos, cuanto tiempo lo almacenamos… incluso, podemos enviarlos a sistemas de almacenamiento y consulta. Para los servicios más cloud native el envío de logs al sistema es transparente, pero para tener los logs de las MV necesitaremos instalar los agentes que nos ofrece Google o tirar de API.
• Monitoring: era el punto fuerte de Stackdriver, nos permite crear cuadros de mandos donde ver nuestras métricas, crear alarmas, controles de disponibilidad, métricas personalizadas o basadas en logs…. Una de las últimas novedades del servicio consiste en la monitorización de servicios mediante SLIs y SLOs, que veremos en detalle en este post.
• Trace: Cloud trace nos ayuda a detectar problemas de rendimiento en entornos productivos. Nos ofrece un sistema distribuido que obtiene datos sobre las peticiones en casi-tiempo-real de aplicaciones dentro y fuera de Google Cloud. Nos informa si detecta una pérdida significativa de rendimiento y podemos usarla mediante sus SDKs disponibles para los principales frameworks de desarrollo o incluso llamando directamente a su API.
• Profiler: nos permite hacer profiling de nuestras aplicaciones para poder conocer qué partes de la aplicación consumen más recursos de CPU y de memoria. Los profilings son de gran utilidad a la hora de optimizar nuestras aplicaciones.

Una de acrónimos: SLI, SLO, SLA y SRE

Para poder entender la propuesta de Google sobre monitorización de servicios es imprescindible conocer el significado de algunos acrónimos.

• SRE - Site Reliability Engineering. Es tanto un rol especializado en mejorar el mantenimiento y robustez de grandes sistemas como el conjunto de prácticas para lograrlo. Se puede decir que los SREs usan prácticas SRE para mantener sus sistemas siendo estables y fiables. Para saber más sobre SRE recomendamos leer este libro gratuito. Dentro del conjunto de prácticas recomendadas nos encontramos la definición de service level indicators y service level objectives.
• SLI - Service Level Indicators. Nos permite medir cuantitativamente algún aspecto clave del servicio. Es importante que lo que mida sea realmente importante para el usuario del servicio. Dos ejemplos: la disponibilidad de un servicio y la latencia en la respuesta.
• SLO - Service Level Objectives. Una vez definido un indicador el siguiente paso es poner un objetivo que nos marcará cuando un servicio se está comportando correctamente. Un SLO consta de 3 partes: El SLI, el objetivo y un plazo de tiempo.
• SLA - Service Level Agreements. Acuerdo a nivel de servicio. Define los niveles de servicio a los que se compromete un vendedor de servicios y cómo es medido. En caso de no cumplirlo se establecen unas compensaciones.

Definición de servicios a nivel monitorización

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:

• Descubiertos automáticamente: si usamos servicios de App Engine o Anthos Service Mesh los servicios se reflejarán automáticamente en esta pantalla sin tener nosotros que hacer nada.
• Sugeridos: a la hora de crear un servicio manualmente el sistema nos ofrecerá los servicios de Cloud Run, GKE namespaces, workloads y services para que podamos nosotros crearlos fácilmente.
• Customs: para el resto de servicios (Functions, VMs, workflows) tendremos que crear este tipo de servicios indicando solo un nombre. Actuará solo de referencia a la hora de crear sus SLIs y SLOs.

Generación de SLI y SLO

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
      }
    }
  }
}

Cuidando nuestros SLOs - Configuración de alertas

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.

Conclusiones

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.