Exercício - Definir estado de integridade, métricas e limites
Neste exercício, continuamos com a estrutura do modelo de saúde que você criou anteriormente. Sua tarefa é quantificar estados de integridade de componentes individuais para o aplicativo de exemplo.
Na estrutura do modelo de integridade, comece avaliando as camadas começando na parte superior com os fluxos do usuário e prossiga para as camadas inferiores.
Estado de integridade do fluxo do usuário
Até agora, identificamos dois fluxos de usuários: Listar itens de catálogo e Adicionar comentário. Para determinar os estados de integridade de cada fluxo, faça perguntas como:
- Quando o fluxo de usuários é considerado saudável?
- Pode operar em estado degradado?
Com base na implementação e nos requisitos funcionais, identifique os componentes do aplicativo que participam do fluxo do usuário. Os componentes são descritos em Exemplos de componentes de arquitetura.
| Fluxo de utilizador | Componentes |
|---|---|
| Listar itens do catálogo | Aplicação Web interna front-end, API de catálogo |
| Adicionar comentário | Aplicação Web interna front-end, API de catálogo, processador em segundo plano |
Se algum desses componentes se tornar não íntegro, espera-se que o fluxo do usuário se torne não íntegro.
Nota
Algumas aplicações podem operar em um modo degradado especial. Por exemplo, se a Contoso Shoes implementar o cache do navegador local, os funcionários que estão usando o aplicativo Web poderão criar comentários, mas os comentários não poderão ser enviados e a exibição do cliente não será atualizada até que a API do Catálogo fique íntegra, o que o navegador pode verificar continuamente.
Estado de integridade do componente do aplicativo
Determine métricas que contribuem para o estado de integridade do componente. Para esta etapa, você precisa conhecer a funcionalidade do componente. Faça perguntas como:
- Qual tempo de processamento na API é aceitável para manter uma boa experiência do usuário?
- Existem erros esperados? Qual é a taxa de erro "normal"?
- Qual é o tempo de processamento "normal"? O que significa se o tempo de processamento for maior do que o normal?
- O que acontece para gravar operações se o Azure Cosmos DB estiver inacessível?
Essas perguntas devem levá-lo a limites específicos e mensuráveis para métricas-chave. Por exemplo, você pode considerar esses valores de limite para o componente API de catálogo.
| Métricas e limite | Estado de integridade |
|---|---|
| Tempo < de resposta 150 ms Contagem < de pedidos falhados 10 | Bom estado de funcionamento |
| Tempo < de resposta 300 ms Contagem < de pedidos falhados 50 | Degradado |
| Tempo > de resposta 300 ms Contagem > de pedidos falhados 50 | Mau estado de funcionamento |
Você pode obter os valores de uma solução de monitoramento de aplicativos, como o Application Insights.
Estado de integridade do recurso do Azure
Os estados de integridade do serviço do Azure são baseados em recursos específicos. Por exemplo, o Azure Cosmos DB relata a utilização da unidade de transação de banco de dados (DTU) e os Serviços de Aplicativo do Azure fornecem informações sobre a utilização da CPU.
Para obter informações sobre métricas por tipo de recurso, consulte Métricas suportadas com o Azure Monitor.
Estados de saúde e limiares
Depois de avaliar todas as camadas do aplicativo, você deve ter uma lista de componentes e suas definições de estado de integridade semelhantes a este exemplo.
| Componente | Indicador/métrica | Bom estado de funcionamento | Degradado | Mau estado de funcionamento |
|---|---|---|---|---|
| Listar fluxo de usuário de itens de catálogo | Estado de saúde subjacente | Front-end íntegro e API de catálogo íntegro | ||
| Adicionar fluxo de usuário de comentário | Estado de saúde subjacente | Front-end íntegro, API de catálogo íntegro e processador em segundo plano íntegro | ||
| Aplicação Web front-end | # de respostas HTTP não-20x/min | 0 | 1-10 | > 10 |
| API do Catálogo | # de exceções/seg | < 10 | 10-50 | > 10 |
| Tempo médio de processamento (ms) | < 150 | 150-500 | > 500 | |
| Processador em segundo plano | Tempo médio na fila (ms) | < 200 | 200-1,000 | > 1,000 |
| Tempo médio de processamento (ms) | < 100 | 100-200 | > 200 | |
| Contagem de falhas | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Utilização da DTU | < 70% | 70%-90% | > 90% |
| Azure Key Vault | Contagem de falhas | < 3 | 3-10 | > 10 |
| Hubs de Eventos do Azure | Processamento do comprimento da lista de pendências (mensagens de saída/entrada) | < 3 | 3-20 | > 20 |
| Armazenamento de Blobs do Azure | Latência média (ms) | < 100 | 100-200 | > 200 |
Neste exemplo, a tolerância a erros para o aplicativo Web front-end e a API de catálogo é diferente. Esta diferença está relacionada com a compreensão técnica da aplicação. Todos os erros de front-end devem ser tratados do lado do cliente, portanto, há um limite zero. No entanto, na camada de API, 10 exceções são permitidas para contabilizar erros causados pelo usuário. Por exemplo, erros como 404 - Não encontrado não indicam necessariamente um problema de saúde.