Observabilidad del modo de error

Para mitigar un modo de error, primero debe detectar si este afecta o está a punto de afectar a la carga de trabajo. Las mitigaciones solo son eficaces si hay una señal de que se debe tomar una medida. Esto significa que parte de la creación de cualquier mitigación incluye, como mínimo, verificar que se tiene la observabilidad necesaria para detectar el impacto del error o que se está creando.

Debe tener en cuenta los síntomas observables del modo de error en dos dimensiones:

Por ejemplo, un error de carga excesiva que se aplica a un elemento de la base de datos podría tener un recuento de conexiones como indicador previo. Puede ver el aumento constante del número de conexiones como un indicador previo de que pronto la base de datos podría superar el límite de conexiones, por lo que puede tomar medidas (como cancelar las conexiones utilizadas menos recientemente) para reducir el recuento de conexiones. El indicador posterior indica cuándo se ha superado el límite de conexión a la base de datos y si los errores de conexión a la base de datos aumentan. Además de recopilar métricas de aplicaciones e infraestructuras, considere la posibilidad de recopilar indicadores clave de rendimiento (KPI) para detectar cuándo los errores afectan a la experiencia del cliente.

Siempre que sea posible, le recomendamos que incluya los dos tipos de indicadores en la estrategia de observabilidad. En algunos casos, es posible que no pueda crear indicadores previos, pero siempre debe tener un indicador posterior para cada error que desee mitigar. Para elegir la mitigación adecuada, también debe considerar si el error lo detectó un indicador previo o posterior. Por ejemplo, piense en un aumento repentino del tráfico a su sitio web. Es probable que solo vea un indicador posterior. En este caso, el escalado automático por sí solo puede no ser la mejor forma de mitigar el problema, ya que la implementación de nuevos recursos lleva tiempo, mientras que la limitación podría evitar la sobrecarga casi de inmediato y dar tiempo a la aplicación para escalar o reducir la carga. Por el contrario, si se tratara de un aumento gradual del tráfico, aparecería un indicador previo. En este caso, la limitación no sería adecuada porque tiene tiempo para responder escalando el sistema automáticamente.