Este documento del framework de arquitectura de Google Cloud se basa en los debates anteriores sobre los objetivos de nivel de servicio (SLO) mediante la exploración de qué y cómo medir con respecto a las cargas de trabajo de servicio comunes. Este documento se basa en los conceptos definidos en Componentes de los objetivos de nivel de servicio.
Decide qué medir
Sin importar el dominio, muchos servicios comparten funciones comunes y pueden usar SLO genéricos. En esta sección, se analizan los SLOs genéricos para diferentes tipos de servicios y se proporcionan explicaciones detalladas de los SLIs que se aplican a cada SLO.
En cada una de las siguientes subsecciones, se identifica un tipo de servicio en particular y se proporciona una breve descripción de este. Luego, en cada tipo de servicio, se enumeran los SLIs posibles, una definición del indicador y otra información relacionada con el SLI.
Servicios impulsados por solicitudes
Este tipo de servicio recibe una solicitud de un cliente (un usuario o algún otro servicio), realiza algunos cálculos, envía solicitudes de red a un backend (opcional) y, luego, muestra una respuesta al cliente.
Disponibilidad como un SLI
La disponibilidad es la proporción de solicitudes válidas que se entregan de forma correcta. En la siguiente lista, se incluye información que se debe tener en cuenta cuando se usa la disponibilidad como un SLI:
- Como propietario del servicio, decides qué es una solicitud válida. Las definiciones comunes incluyen longitud no cero o cumple con un protocolo cliente-servidor. Un método para medir la validez es revisar los códigos de respuesta HTTP (o RPC). Por ejemplo, los códigos HTTP 5xx son errores relacionados con el servidor que se consideran en el SLO, mientras que los códigos 4xx son errores de cliente que no cuentan.
- Cada código de respuesta que muestra el servicio debe examinarse para garantizar que la aplicación use esos códigos de manera correcta y coherente. ¿El código es un indicador preciso de la experiencia de los usuarios del servicio? Por ejemplo, ¿cómo responde un sitio de comercio electrónico cuando un usuario intenta pedir un artículo que está agotado? ¿La solicitud falla y muestra un mensaje de error? ¿El sitio sugiere productos similares? Los códigos de error deben estar relacionados con las expectativas del usuario.
- Los desarrolladores pueden hacer un uso inadecuado de los errores por accidente. Si usas la situación agotado de la viñeta anterior, un desarrollador podría mostrar un error por error. Sin embargo, el sistema funciona correctamente y no presenta errores. El código debe mostrar un resultado correcto, aunque el usuario no pueda comprar el elemento. Si bien a los propietarios del servicio se debe notificar sobre el inventario bajo, la imposibilidad de realizar una venta no es un error desde la perspectiva del cliente y no se considera en un SLO.
- Un ejemplo de un servicio más complejo es el que controla solicitudes asíncronas o proporciona un proceso de larga duración para los clientes. Si bien puedes exponer la disponibilidad de otra manera, recomendamos representar la disponibilidad como la proporción de solicitudes válidas que se ejecutan de forma correcta. La disponibilidad también se puede definir como la cantidad de minutos que se ejecuta la carga de trabajo de un cliente (a veces conocido como el enfoque de buenos minutos).
- Considera un servicio que ofrece máquinas virtuales (VMs). Puedes medir la disponibilidad en términos de la cantidad de minutos después de una solicitud inicial que la VM está disponible para el usuario.
Latencia como un SLI
La latencia (o velocidad) es la proporción de solicitudes válidas que se entregan más rápido que un umbral. Por lo tanto, la latencia indica la rapidez del servicio y se puede medir mediante el cálculo de la diferencia entre las horas de inicio y detención para un tipo de solicitud determinado. Recuerda que esta es la percepción de latencia del usuario y los propietarios de servicios suelen medir este valor con demasiada precisión. En realidad, los usuarios no pueden distinguir entre una actualización de 100 milisegundos (ms) y una de 300 ms, y es posible que acepten respuestas entre 300 ms y 1,000 ms con normalidad. Para obtener más información, consulta el modelo de Rail.
Desarrolla métricas céntricas en la actividad que se centren en el usuario. A continuación, se muestran algunos ejemplos de estas métricas:
- Interactivo: Un usuario espera 1,000 ms para obtener un resultado después de hacer clic en un elemento.
- Escritura: un cambio en un sistema distribuido subyacente tarda 1,500 ms. Si bien esta cantidad de tiempo se considera lenta, los usuarios tienden a aceptarla. Recomendamos que identifiques de forma explícita entre escrituras y lecturas en las métricas.
- Segundo plano: Las acciones que no son visibles para el usuario, como una actualización periódica de datos o cualquier otra solicitud asíncrona, no tardan más de 5,000 ms en completarse.
La latencia se mide, por lo general, como una distribución y se menciona en Elige tus SLI. Dada una distribución, puedes medir varios percentiles. Por ejemplo, puedes medir la cantidad de solicitudes que son más lentas que el percentil 99 histórico. Los eventos que son más rápidos que este umbral se consideran buenos; las solicitudes más lentas se consideran no tan buenas. Establece este umbral en función de los requisitos del producto. Incluso puedes configurar varios SLO de latencia, por ejemplo, la latencia típica en comparación con la latencia final.
No uses solo la latencia promedio (o mediana) como tu SLI. Si la latencia mediana es demasiado lenta, la mitad de los usuarios ya están insatisfechos. Además, tu servicio puede experimentar una latencia mala durante días antes de que descubras el problema. Por lo tanto, define el SLO para la latencia final (percentil 95) y la latencia mediana (percentil 50).
En el artículo Metrics That Matter (Métricas que importan) de ACM, Benjamin Trenyor Sloss escribe lo siguiente:
- “Una buena regla general […] es que la latencia del percentil 99 no debería ser mayor que el triple o el quíntuple de la latencia mediana”.
- “Pensamos que cada una de las medidas de latencia de los percentiles 50, 95 y 99 de un servicio son valiosas, y lo ideal sería establecer los SLO en torno a cada uno de ellos”.
Determina tus umbrales de latencia según los percentiles históricos y, luego, mide cuántas solicitudes se incluyen en cada bucket. Este enfoque es un buen modelo para seguir.
Calidad como un SLI
La calidad es la proporción de solicitudes válidas que se entregan sin degradar el servicio. Por ejemplo, la calidad es un SLI útil para servicios complejos diseñados a fin de fallar con facilidad. A modo de ejemplo, considera una página web que carga su contenido principal desde un almacén de datos y carga elementos opcionales de 100 servicios y almacenes de datos adicionales. Si uno de los elementos opcionales está fuera de servicio o es demasiado lento, la página aún se renderiza sin los elementos opcionales. En esta situación, puedes usar los SLI para hacer lo siguiente:
- Puedes informar la proporción de solicitudes incorrectas si mides la cantidad de solicitudes que reciben una respuesta degradada (una respuesta a la que le falta una respuesta de al menos un servicio de backend).
- Puedes hacer un seguimiento de la cantidad de respuestas a las que les falta una respuesta de un solo backend o de varios backends.
Servicios de procesamiento de datos
Estos servicios consumen datos de una entrada, los procesan y generan un resultado. El rendimiento del servicio en pasos intermedios no es tan importante como el resultado final. Los SLIs más eficaces son la actualidad, la cobertura, la precisión y la capacidad de procesamiento. La latencia y la disponibilidad son menos útiles.
Actualidad como un SLI
La actualidad es la proporción de datos válidos actualizados más recientemente que un límite. En la siguiente lista, se proporcionan algunos ejemplos del uso de la actualización como un SLI:
- En un sistema por lotes, la actualidad se mide como el tiempo transcurrido durante una ejecución de procesamiento completada de forma correcta para un resultado determinado.
- En el procesamiento en tiempo real o sistemas más complejos, la actualidad realiza un seguimiento de la antigüedad del registro más reciente procesado en una canalización.
- En un juego en línea que genera mosaicos de mapas en tiempo real, es posible que los usuarios no perciban la rapidez con la que se crean los mosaicos de mapas, pero puede que noten cuando faltan los datos de los mapas o no están actualizados. En este caso, la actualidad realiza un seguimiento de los datos faltantes o inactivos.
- En un servicio que lee registros desde un sistema de seguimiento para generar el mensaje “X elementos en stock” para un sitio web de comercio electrónico, se puede definir un SLI de actualización como el porcentaje de solicitudes que se usan recientemente (dentro del el último minuto).
- También puedes usar una métrica para entregar datos no actualizados para actualizar al SLI de calidad.
Cobertura como un SLI
La cobertura es la proporción de datos válidos que se procesaron de manera correcta.
Para definir la cobertura, sigue estos pasos:
- Determina si aceptas una entrada como válida o la omites. Por ejemplo, si un registro de entrada está dañado o tiene duración cero y no se puede procesar, puedes considerar que el registro no es válido como una métrica.
- Cuenta la cantidad de registros válidos. Este recuento se puede realizar con un método
*count()*simple y representa el recuento total de registros. - Por último, cuenta la cantidad de registros que se procesaron de forma correcta y compárala con el recuento total de registros válidos. Este valor es tu SLI para la cobertura.
Precisión como un SLI
La precisión es la proporción de datos válidos que generaron el resultado correcto. Ten en cuenta los siguientes puntos cuando uses la precisión como un SLI:
- En algunos casos, los métodos para determinar la precisión de un resultado se usan para validar el procesamiento de salida. Por ejemplo, un sistema que rota o colorea una imagen nunca debe producir una imagen de cero bytes, o una imagen con una longitud o un ancho de cero. Es importante separar esta lógica de validación de la lógica de procesamiento en sí misma.
- Un método para medir un SLI de precisión es usar datos de entrada de prueba conocida. Este tipo de datos son aquellos que producen un resultado correcto conocido. Recuerda que los datos de entrada deben ser representativos de los datos del usuario.
- En otros casos, es posible usar una verificación matemática o lógica en el resultado, como en el ejemplo anterior de rotación de una imagen.
- Por último, considera un sistema de facturación que determine la validez de la transacción mediante la verificación de la diferencia entre el saldo antes y después de una transacción. Si esto coincide con el valor de la transacción, es una transacción válida.
Capacidad de procesamiento como un SLI
La capacidad de procesamiento es la proporción de tiempo en la que la tasa de procesamiento de datos fue más rápida que el umbral. Estos son algunos puntos que se deben tener en cuenta cuando se usa la capacidad de procesamiento como un SLI:
- La capacidad de procesamiento en un sistema de procesamiento de datos suele ser más representativa de la satisfacción del usuario que una medición de latencia única para una operación determinada. Si el tamaño de cada entrada varía de manera considerable, puede que no tenga sentido comparar el tiempo que tarda cada elemento en completarse (si todos los trabajos avanzan a una tasa aceptable).
- La cantidad de bytes por segundo es una forma común de medir la cantidad de trabajo que se requiere para procesar datos sin importar el tamaño de un conjunto de datos. Pero cualquier métrica que se escale de forma lineal en relación con el costo de procesamiento puede funcionar.
- Puede ser útil particionar los sistemas de procesamiento de datos según las tasas de capacidad de procesamiento esperadas. También puedes implementar un sistema de calidad de servicio que garantice que se manejen las entradas de prioridad alta y que se pongan en cola las entradas de prioridad baja. De cualquier manera, medir la capacidad de procesamiento como se define en esta sección ayuda a determinar si el sistema funciona como dentro del SLO.
Servicios de ejecución programada
Para los servicios que necesitan realizar una acción en intervalos regulares, como trabajos cron de Kubernetes, puedes medir el sesgo y la duración de la ejecución. El siguiente es un trabajo cron de Kubernetes programado de muestra:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec:
schedule: "0 * * * *"
Sesgo como un SLI
Desviación: la proporción de ejecuciones que comienzan en un período aceptable en torno a la hora de inicio prevista. Cuando uses el sesgo, ten en cuenta lo siguiente:
- El sesgo mide la diferencia de tiempo entre el momento en el que un trabajo debería comenzar y la hora de inicio real. Considera el ejemplo anterior de trabajo cron de Kubernetes. Si está configurada para comenzar en el minuto cero de cada hora, pero comienza tres minutos después de la hora, el sesgo es de tres minutos. Cuando un trabajo se ejecuta antes, tienes un sesgo negativo.
- Puedes medir el sesgo como una distribución a lo largo del tiempo, con los rangos aceptables adecuados que definen un buen sesgo. Para determinar el SLI, compara la cantidad de ejecuciones que estaban dentro de un rango adecuado.
Duración de la ejecución como un SLI
La duración de la ejecución es la proporción de ejecuciones que se completan dentro del período de duración aceptable. A continuación, se abordan conceptos importantes relacionados con el uso de la duración de la ejecución:
- La duración de la ejecución es el tiempo que tarda un trabajo en completarse. Para una ejecución determinada, un modo de falla común es cuando la duración real supera la duración programada.
- Un caso interesante es aplicar este SLI a un trabajo interminable. Debido a que estos trabajos no se completan, registra el tiempo que se emplea en un trabajo determinado en lugar de esperar a que se complete un trabajo. Este enfoque proporciona una distribución precisa del tiempo que lleva completar el trabajo, incluso en los peores casos.
- Al igual que con el sesgo, puedes hacer un seguimiento de la duración de la ejecución como una distribución y definir límites inferiores y superiores aceptables para buenos eventos.
Métricas para otros tipos de sistemas
Muchas otras cargas de trabajo tienen sus propias métricas para generar SLI y SLO. Considera los siguientes ejemplos:
- Sistemas de almacenamiento: durabilidad, capacidad de procesamiento, tiempo hasta el primer byte, disponibilidad de BLOB
- Multimedia/video: continuidad de reproducción del cliente, tiempo hasta el inicio de la reproducción, finalización de la ejecución por grafos de la transcodificación
- Videojuegos: tiempo para emparejar a los jugadores activos, tiempo para generar un mapa
Decide cómo medir
En la sección anterior, se explicó lo que se mide. Una vez que hayas determinado qué medir, puedes decidir cómo medir. Puedes recopilar métricas de SLI de varias maneras. En las siguientes secciones, se identifican varios métodos de medición, se proporciona una descripción breve del método, se enumeran sus ventajas y desventajas, y se identifican las herramientas de implementación adecuadas para el método.
Registro del servidor
El método de registro del lado del servidor implica el procesamiento de registros del lado del servidor de solicitudes o datos procesados.
| Registro del servidor | Detalles |
|---|---|
| Ventajas |
|
| Desventajas |
|
| Método de implementación y herramientas |
Métricas del servidor de aplicaciones
El método de métricas del servidor de aplicaciones implica exportar métricas de SLI desde el código que entrega las solicitudes del usuario o procesa sus datos.
| Métricas del servidor de aplicaciones | Detalles |
|---|---|
| Ventajas |
|
| Desventajas |
|
| Método de implementación y herramientas |
|
Métricas de infraestructura de frontend
El método de métricas de infraestructura de frontend usa métricas de la infraestructura de balanceo de cargas (como un balanceador de cargas de capa 7 global en Google Cloud).
| Métricas de infraestructura de frontend | Detalles |
|---|---|
| Ventajas |
|
| Desventajas |
|
| Método de implementación y herramientas |
|
Datos o clientes sintéticos
El método de clientes o datos sintéticos implica el uso de clientes que envían solicitudes falsificadas a intervalos regulares y valida las respuestas.
| Datos o clientes sintéticos | Detalles |
|---|---|
| Ventajas |
|
| Desventajas |
|
| Método de implementación y herramientas |
|
Instrumentación de clientes
El método de instrumentación de cliente implica agregar funciones de observabilidad al cliente con las que el usuario interactúa y, luego, registrar eventos en la infraestructura de entrega que hagan un seguimiento de los SLI.
| Instrumentación de clientes | Detalles |
|---|---|
| Ventajas |
|
| Desventajas |
|
| Método de implementación y herramientas |
|
Elige un método de medición
Después de decidir qué y cómo medir tu SLO, el siguiente paso es elegir un método de medición que se ajuste lo más posible a la experiencia del cliente de tu servicio y exige el menor esfuerzo de tu parte. Para lograr esto, es posible que debas usar una combinación de los métodos en las tablas anteriores. A continuación, se sugieren enfoques que puedes implementar a lo largo del tiempo, enumerados en orden creciente de esfuerzo:
- Usa exportaciones de servidores de aplicaciones y métricas de infraestructura. Por lo general, puedes acceder a estas métricas de inmediato, y proporcionan valor con rapidez. Algunas herramientas de APM incluyen las herramientas integradas de SLO.
- Usa instrumentación de cliente. Debido a que, en general, los sistemas heredados no tienen instrumentación de cliente del usuario final integrada, configurar la instrumentación puede requerir una inversión significativa. Sin embargo, si usas un paquete de APM o framework de frontend que proporcione instrumentación de cliente, puedes obtener estadísticas sobre la satisfacción del cliente con rapidez.
- Usa procesamiento de registros. Si no puedes implementar exportaciones de servidor o instrumentación de cliente (viñetas anteriores), pero los registros existen, el procesamiento de registros podría ser el mejor enfoque. Otro método es combinar las exportaciones y el procesamiento de registros. Usa las exportaciones como fuente inmediata para algunos SLIs (como la disponibilidad inmediata) y el procesamiento de registros para indicadores a largo plazo (como las alertas de consumo lento que se analizan en la guía de SLOs y las alertas).
- Implementa pruebas sintéticas. Una vez que comprendas cómo tus clientes usan el servicio, debes probar tu servicio. Por ejemplo, puedes generar cuentas de prueba con datos identificados como buenos y realizar consultas para obtenerlos. Este enfoque puede ayudar a destacar los modos de falla que no se ven con facilidad, como los servicios con poco tráfico.
Próximos pasos
- Lee SLOs y alertas.
- Lee El arte de los SLO, un taller que desarrolló el equipo de Ingeniería de confiabilidad de clientes de Google.
- Prueba Ingeniería de confiabilidad de sitios: cómo medir y manejar la confiabilidad, un curso en línea sobre la compilación de SLO.
- Lee Ingeniería de confiabilidad de sitios: implementa SLOs.
- Lee Conceptos en la supervisión de servicios.
- Lee Implementa objetivos de nivel de servicio de Alex Neo llama.
- Obtén información para desarrollar SLO con Cloud Monitoring.
- Prueba el generador de SLO flexible de Professional Services Organization (PSO) de Google.
- Lee nuestros recursos sobre DevOps.
Obtén más información sobre las funciones de DevOps relacionadas con esta serie:
Realiza la verificación rápida de DevOps para comprender cuál es tu posición en comparación con el resto de la industria.
Explora otras categorías en el framework de arquitectura.
Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.