Ejercicio: Definir un estado de mantenimiento, métricas y umbrales
En este ejercicio, continuamos con la estructura del modelo de mantenimiento que creamos anteriormente. Su tarea consiste en cuantificar los estados de mantenimiento de los componentes individuales de la aplicación de ejemplo.
En la estructura del modelo de mantenimiento, comience evaluando las capas empezando por el principio con flujos de usuario y avanzando hacia las capas inferiores.
Estado de mantenimiento de flujo de usuario
Hasta ahora, hemos identificado dos flujos de usuario: Lista de elementos de catálogo y Adición de comentarios. Para conocer los estados de mantenimiento de cada flujo, haga preguntas como las siguientes:
- ¿Cuándo se considera que el flujo de usuario es correcto?
- ¿Puede funcionar en un estado degradado?
Dependiendo de los requisitos funcionales y de implementación, identifique los componentes de la aplicación que participan en el flujo de usuario. Los componentes se describen en Componentes de la arquitectura de ejemplo.
| Flujo de usuario | Componentes |
|---|---|
| Enumeración de elementos del catálogo | Aplicación web interna front-end, API de catálogo |
| Agregar comentario | Aplicación web interna front-end, API de catálogo, procesador en segundo plano |
Si alguno de estos componentes pasa a un estado incorrecto, se espera que el flujo de usuario sea incorrecto también.
Nota
Algunas aplicaciones pueden funcionar en un modo degradado especial. Por ejemplo, si Contoso Shoes implementa el almacenamiento en caché del explorador local, los empleados que usan la aplicación web pueden crear comentarios, pero los comentarios no se pueden enviar y la vista del cliente no se actualiza hasta que la API de catálogo esté en un estado correcto, algo que el explorador puede comprobar continuamente.
Estado de mantenimiento de componente de la aplicación
Determine las métricas que contribuyen al estado de mantenimiento del componente. En este paso debe conocer la funcionalidad del componente. Formule preguntas como estas:
- ¿Qué tiempo de procesamiento en la API es aceptable para mantener una buena experiencia de usuario?
- ¿Hay errores esperados? ¿Cuál es la tasa de errores "normal"?
- ¿Cuál es el tiempo de procesamiento "normal"? ¿Qué ocurre si el tiempo de procesamiento es mayor de lo normal?
- ¿Qué ocurre con las operaciones de escritura si Azure Cosmos DB no está accesible?
Estas preguntas deben llevarle a unos umbrales específicos y mensurables de las métricas clave. Por ejemplo, puede considerar estos valores de umbral para el componente de API de catálogo.
| Métricas y umbral | Estado de mantenimiento |
|---|---|
| Tiempo de respuesta < 150-ms Número de solicitudes erróneas < 10 | Healthy |
| Tiempo de respuesta < 300-ms Número de solicitudes erróneas < 50 | Degradado |
| Tiempo de respuesta > 300-ms Número de solicitudes erróneas > 50 | Unhealthy (Incorrecto) |
Puede obtener los valores de una solución de supervisión de aplicaciones, como Application Insights.
Estado de mantenimiento de recursos de Azure
Los estados de mantenimiento del servicio de Azure se basan en recursos específicos. Por ejemplo, Azure Cosmos DB informa del uso de la unidad de procesamiento de base de datos (DTU), mientras que Azure App Services proporciona información sobre el uso de la CPU.
Para obtener información sobre las métricas por tipo de recurso, vea Métricas admitidas con Azure Monitor.
Estados de mantenimiento y umbrales
Después de evaluar todas las capas de la aplicación, debería tener una lista de los componentes y sus definiciones de estado de mantenimiento parecida a la de este ejemplo.
| Componente | Indicador/métrica | Healthy | Degradado | Unhealthy (Incorrecto) |
|---|---|---|---|---|
| Flujo de usuario Mostrar elementos de catálogo | Estado de mantenimiento subyacente | Estado de front-end correcto y estado de la API de catálogo correcto | ||
| Flujo de usuario Agregar comentario | Estado de mantenimiento subyacente | Estado de front-end correcto, estado de la API de catálogo correcto y estado del procesador en segundo plano correcto | ||
| Aplicación web front-end | N.º de respuestas HTTP/min que no son 20x | 0 | 1-10 | > 10 |
| API de catálogo | N.º de excepciones/s | < 10 | 10-50 | > 10 |
| Promedio de tiempo de procesamiento (ms) | < 150 | 150-500 | > 500 | |
| Procesador en segundo plano | Promedio de tiempo en cola (ms) | < 200 | 200-1000 | > 1000 |
| Promedio de tiempo de procesamiento (ms) | < 100 | 100-200 | > 200 | |
| Recuento de errores | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Uso de DTU | < 70 % | 70-90 % | > 90 % |
| Azure Key Vault | Recuento de errores | < 3 | 3-10 | > 10 |
| Azure Event Hubs | Longitud de trabajos pendientes de procesamiento (mensajes salientes o entrantes) | < 3 | 3-20 | > 20 |
| Azure Blob Storage | Latencia media (ms) | < 100 | 100-200 | > 200 |
En este ejemplo, la tolerancia a errores de la aplicación web front-end y de la API de catálogo es diferente. Esta diferencia tiene que ver con el conocimiento técnico de la aplicación. Todos los errores de front-end deben controlarse en el lado cliente, por lo que no existe ningún umbral. Sin embargo, en la capa de API, se permiten 10 excepciones para tener en cuenta los errores causados por el usuario. Por ejemplo, errores como 404 - No encontrado no indican necesariamente un problema de mantenimiento.