En este documento de la sección Framework de arquitectura de Google Cloud: confiabilidad, se proporcionan detalles sobre las alertas relacionadas con los SLO.
Un enfoque equivocado para presentar un nuevo sistema de observabilidad como SLO es usar el sistema para reemplazar por completo un sistema anterior. En cambio, deberías usar los SLO como un sistema complementario. Por ejemplo, en lugar de borrar las alertas existentes, te recomendamos que las ejecutes en paralelo con las alertas de SLO que se presentan aquí. Este enfoque te permite descubrir qué alertas heredadas predicen las alertas de SLO, cuáles se activan en paralelo con las alertas de SLO y cuáles no se activan nunca.
Un principio de SRE es alertar en función de los síntomas, no de las causas. Los SLO son, por naturaleza, mediciones de síntomas. A medida que adoptas las alertas de SLO, es posible que la alerta de síntoma se active junto con otras alertas. Si descubres que las alertas heredadas basadas en causas se activan sin SLO o síntomas, estas son buenas candidatas para desactivarlas por completo, convertirlas en alertas de creación de tickets o registrarlas para consultarlas más adelante.
Para obtener más información, consulta SRE Workbook, capítulo 5.
Ritmo de consumo de SLO
La tasa de gasto de un SLO es una medición de la rapidez con la que una interrupción expone a los usuarios a los errores y agota el porcentaje de error aceptable. Cuando mides la tasa de gasto, puedes determinar el tiempo que transcurre hasta que un servicio infrinja el SLO. Las alertas basadas en la tasa de gasto de SLO son un enfoque valioso. Recuerda que el SLO se basa en una duración, que puede ser bastante larga (semanas o incluso meses). Sin embargo, el objetivo es detectar con rapidez una condición que genere una infracción del SLO antes de que esta ocurra.
En la siguiente tabla, se muestra el tiempo que lleva superar un objetivo si el 100% de las solicitudes fallan por un intervalo determinado, siempre que las consultas por segundo (QPS) sean constantes. Por ejemplo, si tienes un SLO del 99.9% medido en un período de 30 días, puedes soportar 43.2 minutos de tiempo de inactividad completo durante ese período. Por ejemplo, ese tiempo de inactividad puede ocurrir de una sola vez o a lo largo de varios incidentes.
| Objetivo | 90 días | 30 días | 7 días | 1 día |
|---|---|---|---|---|
| 90% | 9 días | 3 días | 16.8 horas | 2.4 horas |
| 99% | 21.6 horas | 7.2 horas | 1.7 horas | 14.4 minutos |
| 99.9% | 2.2 horas | 43.2 minutos | 10.1 minutos | 1.4 minutos |
| 99.99% | 13 minutos | 4.3 minutos | 1 minuto | 8.6 segundos |
| 99.999% | 1.3 minutos | 25.9 segundos | 6 segundos | 0.9 segundos |
En la práctica, no puedes permitir incidentes de inactividad del 100% si quieres alcanzar porcentajes de éxito alto. Sin embargo, muchos sistemas distribuidos pueden fallar o degradar de forma parcial y controlada. Incluso en esos casos, necesitas saber si se necesita una intervención humana, aun en esas fallas parciales, y las alertas de SLO te permiten determinar eso.
Cuándo alertar
Una pregunta importante es cuándo actuar según la tasa de gasto de SLO. Como regla general, si agotas el porcentaje de error aceptable en 24 horas, el momento para llamar a alguien para solucionar un problema es ahora.
Medir la tasa de fallas no siempre es sencillo. Una serie de errores pequeños puede parecer aterradora en el momento, pero puede que se trate de errores de corta duración que tengan un impacto irrelevante en el SLO. Del mismo modo, si un sistema tiene problemas durante mucho tiempo, estos errores pueden generar una infracción del SLO.
Lo ideal es que el equipo reaccione a estas señales para que inviertas casi todo tu porcentaje de error aceptable (pero no lo excedas) durante un período determinado. Si gastas demasiado, infringirás el SLO. Si gastas muy poco, significa que no estás asumiendo los riesgos suficientes o, tal vez, estás desgastando al equipo de guardia.
Necesitas una forma de determinar cuándo un sistema está lo suficientemente dañado como para que una persona deba intervenir. En las siguientes secciones, se analizan algunos enfoques para contestar esa pregunta.
Consumo rápido
En el consumo rápido de SLO, se agota el porcentaje de error aceptable con rapidez y requiere que intervengas para evitar una infracción del SLO.
Supongamos que el servicio funciona con normalidad en 1,000 consultas por segundo (QPS) y quieres mantener una disponibilidad del 99%, medido en un período de siete días. El porcentaje de error aceptable es aproximadamente 6 millones de errores permitidos (a partir de alrededor de 600 millones de solicitudes). Si tienes 24 horas antes de que se agote el porcentaje de error aceptable, por ejemplo, esto te da un límite de 70 errores por segundo, o 252,000 errores en una hora. Estos parámetros se basan en la regla general que establece que los incidentes paginables deben consumir al menos el 1% del porcentaje de error aceptable por trimestre.
Puedes optar por detectar esta tasa de errores antes de que transcurra una hora. Por ejemplo, después de observar 15 minutos de una tasa de 70 errores por segundo, es posible que decidas hablar con el ingeniero de guardia, como se muestra en el siguiente diagrama.
Lo ideal es que el problema se resuelva antes de agotar una hora del presupuesto de 24 horas. Elegir que se detecte esta tasa en un período menor (por ejemplo, un minuto) puede ser muy propenso a errores. Si el tiempo objetivo para detectar es inferior a 15 minutos, se puede ajustar este número.
Consumo lento
Otro tipo de la tasa de gasto es un consumo lento. Supongamos que se presenta un error que agota tu porcentaje de error aceptable semanal en el día cinco o seis, o el presupuesto mensual en la segunda semana. ¿Cuál es la mejor respuesta?
En este caso, puedes establecer una alerta de consumo de SLO lento que te indique que estás por consumir todo el porcentaje de error aceptable antes de que finalice el período de alerta. Desde luego, esa alerta podría mostrar muchos falsos positivos. Por ejemplo, puede que haya una condición en la que los errores se produzcan de forma breve, pero a una velocidad que consumirían con rapidez el porcentaje de error aceptable. En estos casos, la condición es un falso positivo porque solo dura un tiempo breve y no afecta el porcentaje de error aceptable a largo plazo. Recuerda, el objetivo no es eliminar todas las fuentes de error, sino, permanecer dentro del rango aceptable para no exceder el porcentaje de error aceptable. Debes evitar alertar a una persona para que intervenga en eventos que no constituyen una amenaza real al porcentaje de error aceptable.
Te recomendamos notificar una cola de tickets (en lugar de llamar a alguien o enviar un correo electrónico) para eventos de consumo lento. Los eventos de consumo lento no son emergencias, pero requieren atención humana antes de que caduque el presupuesto. Estas alertas no deben ser correos electrónicos para una lista de equipos, ya que rápidamente se convierten en una molestia. Los tickets deben poder rastrearse, asignarse y transferirse. Los equipos deben desarrollar informes para la carga de tickets, los porcentajes de cierres, la capacidad de acción y los duplicados. Los tickets no prácticos excesivos son un excelente ejemplo de trabajo repetitivo.
Usar alertas de SLO con destreza puede llevar tiempo y depende de la cultura y las expectativas de tu equipo. Recuerda que puedes ajustar las alertas de SLO con el tiempo. También puedes tener varios métodos de alerta, con períodos de alerta variables según tus necesidades.
Alertas de latencia
Además de las alertas de disponibilidad, también puedes recibir alertas de latencia. Con los SLO de latencia, mides el porcentaje de solicitudes que no cumplen con un objetivo de latencia. Con este modelo, puedes usar el mismo modelo de alertas que usas para detectar consumos rápidos o lentos del porcentaje de error aceptable.
Como se mencionó antes sobre los SLO de latencia mediana, la mitad del total de tus solicitudes pueden estar fuera de SLO. En otras palabras, los usuarios pueden notar una latencia baja durante días antes de que puedas detectar el impacto en tu porcentaje de error aceptable a largo plazo. En cambio, los servicios deben definir los objetivos de latencia final y los objetivos de latencia típica. Te sugerimos usar el percentil 90 histórico para definir la típica, y el percentil 99 para la final. Después de establecer estos objetivos, puedes definir los SLO según la cantidad de solicitudes que esperas que lleguen en cada categoría de latencia y cuántas son demasiado lentas. Este enfoque usa el mismo concepto que un porcentaje de error aceptable y se debe tratar de la misma manera. Por lo tanto, podrías terminar con una declaración como “el 90% de las solicitudes se manejará con la latencia típica y un 99.9% con los objetivos de latencia final”. Estos objetivos garantizan que la mayoría de los usuarios experimenten la latencia típica y, también, te permitan hacer un seguimiento de cuántas solicitudes son más lentas que los objetivos de latencia final.
Algunos servicios pueden tener tiempos de ejecución esperados muy variables. Por ejemplo, puede que tengas expectativas de rendimiento muy diferentes para leer desde un sistema de almacén de datos, frente a escribir en él. En lugar de enumerar todas las expectativas posibles, puedes usar depósitos de rendimiento del tiempo de ejecución, como se muestra en las siguientes tablas. Este enfoque revela que estos tipos de solicitudes se identifican y clasifican de forma previa en cada bucket. No debes esperar que se clasifiquen solicitudes en el momento.
| Sitio web para el usuario | |
|---|---|
| Bucket | Tiempo de ejecución máximo esperado |
| Lectura | 1 segundo |
| Escritura / actualización | 3 segundos |
| Sistemas de procesamiento de datos | |
|---|---|
| Bucket | Tiempo de ejecución máximo esperado |
| Pequeño | 10 segundos |
| Medio | 1 minuto |
| Grande | 5 minutos |
| Gigante | 1 hora |
| Enorme | 8 horas |
Si mides el sistema tal como está en la actualidad, podrás comprender cuánto tiempo suelen tardar estas solicitudes en ejecutarse. A modo de ejemplo, considera un sistema para procesar cargas de video. Si el video es demasiado largo, el tiempo de procesamiento debería demorar más tiempo. Podemos usar la duración del video en segundos para categorizar este trabajo en un bucket, como se muestra en la siguiente tabla. En la tabla, se registra la cantidad de solicitudes por bucket y varios percentiles por la distribución del tiempo de ejecución durante el transcurso de una semana.
| Duración del video | Cantidad de solicitudes medidas en un período de una semana | 10% | 90% | 99.95% |
|---|---|---|---|---|
| Pequeño | 0 | - | - | - |
| Medio | 1.9 millones | 864 milisegundos | 17 segundos | 86 segundos |
| Grande | 25 millones | 1.8 segundos | 52 segundos | 9.6 minutos |
| Gigante | 4.3 millones | 2 segundos | 43 segundos | 23.8 minutos |
| Enorme | 81,000 | 36 segundos | 1.2 minutos | 41 minutos |
A partir de ese análisis, puedes obtener algunos parámetros para las alertas:
- fast_typical: Como máximo, el 10% de las solicitudes son más rápidas que esta vez. Si hay demasiadas solicitudes más rápidas que este tiempo, los objetivos podrían ser incorrectos o puede que haya cambiado algo en tu sistema.
- slow_typical: Como mínimo, el 90% de las solicitudes son más rápidas que esta vez. Este límite impulsa el SLO de latencia principal. Este parámetro indica si la mayoría de las solicitudes son lo suficientemente rápidas.
- slow_tail: Como mínimo, el 99.95% de las solicitudes son más rápidas que esta vez. Este límite garantiza que no haya demasiadas solicitudes lentas.
- deadline: El punto en el que se agota el tiempo de espera de una RPC o un procesamiento en segundo plano de usuario y falla (un límite que ya suele estar hard-coded en el sistema) Estas solicitudes no serán lentas, pero fallarán con un error y, en su lugar, se considerarán en el SLO de disponibilidad.
Un lineamiento sobre la definición de depósitos es mantener los valores fast_typical, slow_typical y slow_tail a un orden de magnitud de distancia uno de otro. Este lineamiento garantiza que no tengas un bucket demasiado amplio. Te recomendamos que no intentes evitar la superposición o la brecha entre los depósitos.
| Bucket | fast_typical | slow_typical | slow_tail | deadline |
|---|---|---|---|---|
| Pequeño | 100 milisegundos | 1 segundo | 10 segundos | 30 segundos |
| Medio | 600 milisegundos | 6 segundos | 60 segundos (1 minuto) | 300 segundos |
| Grande | 3 segundos | 30 segundos | 300 segundos (5 minutos) | 10 minutos |
| Gigante | 30 segundos | 6 minutos | 60 minutos (1 hora) | 3 horas |
| Enorme | 5 minutos | 50 minutos | 500 minutos (8 horas) | 12 horas |
Esto da como resultado una regla como api.method: SMALL => [1s, 10s].
En este caso, el sistema de seguimiento de SLO ve una solicitud, determina su bucket (podría analizar el nombre del método o URI y comparar el nombre con una tabla de consulta) y, luego, actualiza las estadísticas según el tiempo de ejecución de esa solicitud. Si esto demora 700 milisegundos, se encuentra dentro del objetivo slow_typical. Si es 3 segundos, está dentro de slow_tail. Si es 22 segundos, supera el valor de slow_tail, pero aún no es un error.
En términos de la satisfacción del usuario, puedes considerar la falta de latencia final como una falta de disponibilidad. (Es decir, la respuesta es tan lenta que debería considerarse como un error). Debido a esto, te sugerimos que uses el mismo porcentaje que usas para la disponibilidad, por ejemplo:
Tú decides qué considerarás como latencia típica. Algunos equipos de Google consideran que el 90% es un buen objetivo. Esto se relaciona con tu análisis y la forma en la que eliges las duraciones de slow_typical. Por ejemplo:
Alertas sugeridas
Dados estos lineamientos, en la siguiente tabla, se incluye un modelo de referencia recomendado de alertas de SLO.
| SLO | Período de mediciones | Tasa de consumo | Acción |
|---|---|---|---|
|
Disponibilidad, consumo rápido Latencia típica Latencia final |
Período de 1 hora | Menos de 24 horas para la infracción del SLO | Llama a alguien |
|
Disponibilidad, consumo lento Latencia típica, consumo lento Latencia final, consumo lento |
Período de 7 días | Más de 24 horas para la infracción del SLO | Crea un ticket |
Las alertas de SLO son una habilidad que pueden demorar en desarrollarse. Las duraciones en esta sección son sugerencias; puedes ajustarlas según tus propias necesidades y el nivel de precisión. Usar tus alertas para el gasto de porcentaje de error aceptable o el período de medición puede ser útil, o puedes agregar otra capa de alertas entre el consumo rápido y el lento.