Exercício - Criar um modelo de integridade do aplicativo
A Contoso Shoes precisa de uma maneira de detetar, diagnosticar e prever problemas nessa arquitetura. Você deseja criar um modelo de integridade mensurável por meio de um status de integridade aplicado aos fluxos do usuário e do sistema. O objetivo é identificar possíveis pontos de falha antes que eles possam causar uma interrupção.
Estado atual e problema
Até agora, você adicionou uma API de verificação de integridade e criou recursos de várias regiões em sua arquitetura. No entanto, não há uma maneira de obter informações sobre a topologia complexa que inclui fluxos de usuário e sistema. Essa lacuna precisa ser preenchida para que a equipe SRE possa identificar e resolver problemas rapidamente.
Em um incidente recente, a equipe não conseguiu ver o impacto em cascata de um problema resultante de um componente de API que afeta suas dependências de plataforma. Houve um tempo significativo gasto na solução de problemas porque o componente não íntegro não pôde ser detetado imediatamente. Em última análise, essa ineficiência levou a tempos de inatividade mais longos, causando perdas financeiras para a empresa.
Especificação
Projete um modelo de integridade que mostre a relação entre todos os componentes da arquitetura, incluindo os componentes do aplicativo e as dependências da plataforma. Considere os itens que existem dentro do fluxo de solicitação, incluindo o gateway, computação, bancos de dados, armazenamento, caches e assim por diante. Inclua também componentes que normalmente existem fora do fluxo de solicitação. Por exemplo, artefatos Open Container Initiative (OCI), armazenamentos secretos, serviços de configuração e outros. Todos os serviços do Azure devem ser configurados para enviar dados de diagnóstico.
Adicione um coletor de dados unificado na arquitetura para coletar dados de várias fontes.
Defina um status geral de integridade com base em logs e métricas históricas agregadas. Representar o status em um dos três estados de saúde: insalubre, degradado e saudável.
Visualize o status de integridade de todos os componentes em uma hierarquia que representa todos os fluxos.
Abordagem recomendada
Para começar a desenvolver o seu design, recomendamos que siga estes passos:
Importante
A modelagem em saúde é um exercício abrangente. A abordagem nesta secção destina-se a ajudá-lo a começar. Seja extensivo na aplicação do modelo a todos os fluxos funcionais e não funcionais em seu projeto de missão crítica para obter uma visão holística do sistema.
1–Inicie a modelagem de integridade
Este exercício é teórico. Modelagem de integridade em uma atividade de design de cima para baixo na qual você precisará de uma lista abrangente de componentes usados na arquitetura. Essa lista deve incluir todos os componentes do aplicativo e os serviços do Azure.
Coloque esses componentes em um gráfico de dependência que mostre uma exibição hierárquica da solução. A camada superior tem os fluxos de usuário que rastreiam a solicitação do usuário final para o site e fluxos no nível da API do aplicativo. A camada inferior contém os fluxos do sistema dos serviços do Azure. Também mapeie dependências entre os recursos do Azure.
Seu gráfico deve ter esta aparência:
Verifique seu progresso: integridade do aplicativo em camadas
2–Definir os escores de saúde
Para cada componente, colete métricas e limites métricos e, em seguida, decida o valor no qual o componente deve ser considerado íntegro, degradado e não íntegro. Essa decisão deve ser influenciada pelo desempenho esperado e pelos requisitos comerciais não funcionais. Categorize suas métricas como:
Métricas do aplicativo: pontos de dados do código do aplicativo, como a contagem de exceções.
Métricas de serviço: pontos de dados dos serviços do Azure, como unidades de transação de banco de dados (DTUs) em uso.
Métricas da solução: pontos de dados no nível da solução, como o tempo de processamento de ponta a ponta de uma solicitação.
Aqui está um exemplo para os Serviços de Aplicativo do Azure:
| Serviços Aplicacionais | Estado de funcionamento |
|---|---|
| Tempo < de resposta 200ms Erros < do servidor HTTP 2 |
 |
| Tempo < de resposta 500ms Erros < do servidor HTTP 2 |
 |
| Tempo > de resposta 500ms Erros > do servidor HTTP 2 |
 |
3–Definir um estado geral de saúde
Para cada fluxo de usuário e sistema, defina um status geral. Você precisará agregar o status de integridade de componentes individuais que participam desse fluxo.
Suponha que um fluxo do sistema seja composto por um componente de aplicativo, plano do Serviço de Aplicativo do Azure e Serviços de Aplicativo.
| API | Plano do Serviço de Aplicações | Serviços Aplicacionais | Estado de funcionamento |
|---|---|---|---|
| Latência < máxima 30ms | <% da CPU 70% Comprimento < da fila HTTP 5 |
Tempo < de resposta 200ms Erros < do servidor HTTP 2 |
|
| Latência < máxima 30ms | <% da CPU 90% Comprimento < da fila HTTP 5 |
Tempo < de resposta 500ms Erros < do servidor HTTP 2 |
|
| Latência > máxima 30ms | >% da CPU 90% Comprimento > da fila HTTP 5 |
Tempo > de resposta 500ms Erros > do servidor HTTP 2 |
|
A pontuação de integridade para um fluxo de usuário deve ser representada pela pontuação mais baixa em todos os componentes mapeados. Para fluxos do sistema, aplique pesos apropriados com base na criticidade do negócio. Entre os dois fluxos, devem ser priorizados fluxos de usuários financeiramente significativos ou voltados para o cliente.
Verifique o seu progresso: Exemplo - Modelo de estado de funcionamento em camadas
4–Recolha de dados de monitorização
Você precisará de um coletor de dados unificado em cada região que colete logs e métricas para todos os serviços de aplicativos e plataformas implantados como parte do selo regional. Você precisará de outro coletor para armazenar métricas emitidas por recursos globais, como o Azure Front Door e o Cosmos DB.
Opções de tecnologia
- Azure Application Insights: usado para coletar toda a telemetria de aplicativos.
- Azure Monitor Logs: Coleta dados enviados por insights de aplicativos e métricas de plataforma para serviços do Azure.
- Azure Log Analytics: usado como a ferramenta central para analisar logs e métricas de todos os componentes de aplicativo e infraestrutura.
Verifique seu progresso: Coletor de dados unificado para análise correlacionada
5–Configurar consultas para dados de monitoramento
A Kusto Query Language (KQL) está bem integrada com o Log Analytics. Implemente consultas KQL personalizadas como funções para recuperar dados do Azure Monitor.
Armazene consultas personalizadas no repositório de código para que sejam importadas e aplicadas automaticamente como parte de seus pipelines de integração contínua/entrega contínua (CI/CD).
6–Visualize o estado de saúde
Você pode visualizar o gráfico de dependência com pontuações de integridade com uma representação de semáforo. Use ferramentas como Painéis do Azure, Pastas de Trabalho de Monitor ou Grafana. Eis um exemplo:
Verifique o seu progresso: Visualização
7–Configurar alertas sobre alterações de status
Você deve usar painéis com alertas para chamar a atenção imediata para os problemas.
Se o estado de integridade de um componente mudar para Degradado ou Não íntegro, o operador deve ser imediatamente notificado. Defina alertas no nó raiz, porque qualquer alteração nesse nó indica um estado não íntegro nos fluxos ou recursos de usuário subjacentes.
Verifique o seu progresso: Alertas
Verifique o seu trabalho
Assista a esta demonstração sobre monitoramento e modelagem de integridade. Cobriu todos os aspetos do seu projeto?
- Você tem um coletor de dados unificado para análise correlacionada?
- Você incluiu logs de aplicativos, métricas de plataforma e pontos de dados de solução?
- Você configurou painéis para visualizar o status de integridade de todos os componentes?
- Você considerou pontos de falha em cada serviço (ou parte dele) que poderiam causar uma interrupção ou impedi-lo de escalar, implantar e monitorar?
- Você considerou os Pacotes de Consultas para capturar consultas importantes que ajudariam a triar problemas mais rapidamente?
- Sua API de verificação de integridade foi útil nesse modelo? Precisou alterar essa API para se adequar melhor ao modelo de saúde?