Modelagem de integridade para cargas de trabalho de missão crítica

O monitoramento de aplicativos e infraestrutura é uma parte importante de qualquer implantação de infraestrutura. Para uma carga de trabalho de missão crítica, o monitoramento é uma parte crítica da implantação. Monitorar a integridade do aplicativo e as principais métricas dos recursos do Azure ajuda você a entender se o ambiente está funcionando conforme o esperado.

Para entender completamente essas métricas e avaliar a integridade geral de uma carga de trabalho, é necessária uma compreensão holística de todos os dados monitorados. Um modelo de integridade pode ajudar na avaliação do estado de integridade geral, exibindo uma indicação clara da integridade da carga de trabalho em vez de métricas brutas. O status é frequentemente apresentado como indicadores de "semáforo", como vermelho, verde ou amarelo. A representação de um modelo de integridade com indicadores claros torna intuitivo para um operador entender a integridade geral da carga de trabalho e responder rapidamente aos problemas que surgem.

A modelagem de integridade pode ser expandida para as seguintes tarefas operacionais para a implantação de missão crítica:

• Serviço de Integridade do Aplicativo - Componente do aplicativo no cluster de computação que fornece uma API para determinar a integridade de um carimbo.

• Monitoramento - Coleta de contadores de desempenho e de aplicativos que avaliam a integridade e o desempenho do aplicativo e da infraestrutura.

• Alertas - Alertas acionáveis de problemas ou paralisações na infraestrutura e no aplicativo.

• Análise de falhas - Detalhamento e análise de eventuais falhas incluindo documentação de causa raiz.

Essas tarefas compõem um modelo de integridade abrangente para a infraestrutura de missão crítica. O desenvolvimento de um modelo de integridade pode e deve ser uma parte exaustiva e integral de qualquer implantação de missão crítica.

Para obter mais informações, confira Modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure.

Serviço de integridade do aplicativo

O Serviço de Integridade do Aplicativo (Serviço de Integridade) é um componente de aplicativo que reside com o Serviço de Catálogo (CatalogService) e o Processador em Segundo Plano (BackgroundProcessor) dentro do cluster de computação. O Serviço de Integridade fornece uma API REST para o Azure Front Door chamar para determinar a integridade de um carimbo. O Serviço de Integridade é um componente complexo que reflete o estado das dependências, além do seu próprio.

Quando o cluster de computação estiver inativo, o serviço de integridade não responderá. Quando os serviços estão em funcionamento, ele executa verificações periódicas nos seguintes componentes na infraestrutura:

• Ele tenta fazer uma consulta no Azure Cosmos DB.

• Ele tenta enviar uma mensagem para os Hubs de Eventos. A mensagem é filtrada pelo trabalhador em segundo plano.

• Ele procura um arquivo de estado na conta de armazenamento. Esse arquivo pode ser usado para desativar uma região, mesmo enquanto as outras verificações ainda estão funcionando corretamente. Esse arquivo pode ser usado para se comunicar com outros processos. Por exemplo, se o carimbo for desocupado para fins de manutenção, o arquivo poderá ser excluído para forçar um estado não íntegro e redirecionar o tráfego.

• Ele consulta o modelo de integridade para determinar se todas as métricas operacionais estão dentro dos limites predeterminados. Quando o modelo de integridade indica que o carimbo não está íntegro, o tráfego não deve ser roteado para o carimbo mesmo que os outros testes que o Serviço de Integridade executa retornem com êxito. O Modelo de Integridade leva em conta uma visão mais completa do estado de saúde.

Todos os resultados da verificação de integridade são armazenados em cache na memória por um número configurável de segundos, por padrão 10. Essa operação potencialmente adiciona uma pequena latência na detecção de interrupções, mas garante que nem todas as consultas do Serviço de Integridade exijam chamadas de back-end, reduzindo assim a carga no cluster e nos serviços downstream.

Esse padrão de cache é importante, porque o número de consultas do Serviço de Integridade cresce significativamente ao usar um roteador global como o Azure Front Door: cada nó de borda em cada datacenter do Azure que atende solicitações chamará o Serviço de Integridade para determinar se ele tem uma conexão de back-end funcional. Armazenar em cache os resultados reduz a carga extra de cluster gerada por verificações de integridade.

Configuração

O Serviço de Integridade e o CatalogService têm definições de configuração comuns entre os componentes, exceto para as seguintes configurações usadas exclusivamente pelo Serviço de Integridade:

Implementação

Todas as verificações são feitas de forma assíncrona e em paralelo. Se alguma delas falhar, todo o carimbo será considerado indisponível.

Os resultados da verificação são armazenados em cache na memória, usando o padrão ASP.NET Core não distribuídoMemoryCache. A expiração do cache é controlada e SysConfig.HealthServiceCacheDurationSeconds definida como 10 segundos por padrão.

A tabela a seguir detalha as verificações de integridade dos componentes na infraestrutura:

Consultas do Azure Cosmos DB

Para a consulta somente leitura, a seguinte consulta está sendo usada, que não busca dados e não tem um grande efeito na carga geral:

SELECT GetCurrentDateTime ()

A consulta de gravação cria um manequim ItemRating com conteúdo mínimo:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Monitoramento

O Azure Log Analytics é usado como um armazenamento central para armazenar logs e métricas de todos os componentes de aplicativos e infraestrutura. O Azure Application Insights é usado para todos os dados de monitoramento de aplicativos. Cada carimbo na infraestrutura tem um workspace dedicado da Análise de Logs e uma instância do Application Insights. Um workspace separado da Análise de Logs é usado para os recursos compartilhados globalmente, como o Front Door e o Azure Cosmos DB.

Todos os selos são de curta duração e continuamente substituídos a cada nova versão. Os workspaces da Análise de Logs por carimbo são implantados como um recurso global em um grupo de recursos de monitoramento separado como os recursos da Análise de Logs de carimbo. Esses recursos não compartilham o ciclo de vida de um carimbo.

Para obter mais informações, consulte Coletor de dados unificado para análise correlacionada.

Monitorando: fontes de dados

• Configurações de diagnóstico: todos os serviços do Azure usados para a Missão Crítica do Azure são configurados para enviar todos os seus dados de diagnóstico, incluindo logs e métricas, para o Workspace de Análise de Log específico da implantação (global ou carimbo). Esse processo acontece automaticamente como parte da implantação do Terraform. Novas opções serão identificadas automaticamente e adicionadas como parte do terraform apply.

• Monitoramento do Kubernetes: as configurações de diagnóstico são usadas para enviar logs e métricas do Serviço de Kubernetes do Azure (AKS) para a Análise de Logs. O AKS está configurado para usar o Container Insights. O Container Insights implanta o OMSAgentForLinus por meio de um Kubernetes DaemonSet em cada nó nos clusters AKS. O OMSAgentForLinux é capaz de coletar logs e métricas extras de dentro do cluster do Kubernetes e enviá-los para seu espaço de trabalho correspondente da Análise de Logs. Esses logs e métricas extras contêm dados mais granulares sobre pods, implantações, serviços e a integridade geral do cluster. Para obter mais insights dos vários componentes, como ingress-nginx, cert-manager e outros componentes implantados no Kubernetes ao lado da carga de trabalho de missão crítica, é possível usar a extração do Prometheus. A extração do Prometheus configura o OMSAgentForLinux para raspar as métricas do Prometheus de vários pontos de extremidade dentro do cluster.

• Telemetria do Application Insights: o Application Insights é usado para coletar dados de telemetria do aplicativo. O código foi instrumentado para coletar dados sobre o desempenho do aplicativo com o SDK do Application Insights. Informações críticas, como o código de status resultante e a duração das chamadas de dependência e contadores para exceções não tratadas, são coletadas. Essas informações são usadas no Modelo de Integridade e estão disponíveis para alertas e solução de problemas.

Monitoramento: testes de disponibilidade do Application Insights

Para monitorar a disponibilidade dos carimbos individuais e da solução geral de um ponto de vista externo, os Testes de Disponibilidade do Application Insights são configurados em dois locais:

• Testes de disponibilidade regional: esses testes são configurados nas instâncias regionais do Application Insights e usados para monitorar a disponibilidade dos carimbos. Esses testes visam diretamente os clusters e as contas de armazenamento estático dos carimbos. Para chamar os pontos de entrada dos clusters diretamente, as solicitações precisam carregar o cabeçalho correto do Front Door ID, caso contrário, elas serão rejeitadas pelo controlador de entrada.

• Teste de disponibilidade global: esses testes são configurados na instância global do Application Insights e usados para monitorar a disponibilidade da solução geral executando ping no Front Door. Dois testes são usados: um para testar uma chamada de API em relação ao CatalogService e outro para testar a home page do site.

Monitoramento: Consultas

O Azure Mission-Critical usa diferentes consultas KQL (Linguagem de Consulta Kusto) para implementar consultas personalizadas como funções para recuperar dados da Análise de Logs. Essas consultas são armazenadas como arquivos individuais em nosso repositório de código, separados para implantações globais e de carimbo. Eles são importados e aplicados automaticamente via Terraform como parte de cada pipeline de infraestrutura executado.

Essa abordagem separa a lógica de consulta da camada de visualização. As consultas da Análise de Logs são chamadas diretamente do código, por exemplo, da API Serviço de Integridade. Outro exemplo é de uma ferramenta de visualização, como Painéis do Azure, Pastas de Trabalho do Monitor ou Grafana.

Monitoramento: Visualização

Para visualizar os resultados de nossas consultas de integridade da Análise de Logs, usamos o Grafana em nossa implementação de referência. O Grafana é usado para mostrar os resultados das consultas da Análise de Logs e não contém nenhuma lógica em si. A pilha Grafana não faz parte do ciclo de vida de implantação da solução, mas é lançada separadamente.

Para saber mais, confira Visualização.

Alertas

Os alertas são uma parte importante da estratégia geral de operações. O monitoramento proativo, como o uso de painéis, deve ser usado com alertas que chamem a atenção imediata para os problemas.

Esses alertas formam uma extensão do modelo de integridade, alertando o operador sobre uma mudança no estado de integridade, seja para o estado degradado/amarelo ou para o estado não íntegro/vermelho. Ao definir o alerta para o nó raiz do Modelo de Integridade, o operador fica imediatamente ciente de qualquer efeito no nível de negócios para o estado da solução: afinal, esse nó raiz ficará amarelo ou vermelho se qualquer um dos fluxos ou recursos de usuário subjacentes relatar métricas amarelas ou vermelhas. O operador pode direcionar sua atenção para a visualização do Modelo de Integridade para solução de problemas.

Para obter mais informações, confira Resposta automatizada a incidentes.

Análise de falha

Compor a análise de falhas é, em sua maioria, um exercício teórico de planejamento. Este exercício teórico deve ser usado como entrada para as injeções automáticas de falha que fazem parte do processo de validação contínua. Ao simular os modos de falha definidos aqui, podemos validar a resiliência da solução contra essas falhas para garantir que elas não levem a interrupções.

A tabela a seguir lista exemplos de casos de falha dos vários componentes da implementação de referência de Missão Crítica do Azure.

Próximas etapas

Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usados nessa arquitetura.