Modelagem de saúde e observabilidade de cargas de trabalho críticas para a missão no Azure

Modelagem de saúde operacional e observabilidade são conceitos fundamentais para maximizar a confiabilidade, concentrando-se em instrumentação e monitoramento robustos e contextualizados. Esses conceitos fornecem insights críticos sobre a integridade do aplicativo, promovendo a rápida identificação e resolução de problemas.

A maioria dos aplicativos críticos é significativa em termos de escala e complexidade e, portanto, gera grandes volumes de dados operacionais, o que torna desafiador avaliar e determinar a ação operacional ideal. A modelagem de saúde, em última instância, se esforça para maximizar a observabilidade, aumentando os logs e métricas de monitoramento crus com os principais requisitos de negócios para quantificar a saúde do aplicativo, conduzindo a avaliação automatizada dos estados de saúde para alcançar operações consistentes e aceleradas.

Essa área de design se concentra no processo para definir um modelo de integridade robusto, mapeando estados quantificados de integridade do aplicativo por meio de construções operacionais e de observabilidade para atingir a maturidade operacional.

Importante

Este artigo faz parte da série de cargas de trabalho de missão crítica do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos começar com o que é uma carga de trabalho crítica?

Há três níveis principais de maturidade operacional ao se esforçar para maximizar a confiabilidade.

1. Detecte e responda a problemas à medida que eles acontecem.
2. Diagnosticar problemas que estão ocorrendo ou já ocorreram.
3. Prever e evitar problemas antes que eles ocorram.

Vídeo: Defina um modelo de saúde para sua carga de trabalho essencial para a missão

Saúde da aplicação em camadas

Para criar um modelo de integridade, primeiro defina a integridade do aplicativo no contexto dos principais requisitos de negócios quantificando estados "íntegros" e "não íntegros" em um formato em camadas e mensurável. Em seguida, para cada componente do aplicativo, refina a definição no contexto de um estado de execução estável e agregado de acordo com os fluxos do usuário do aplicativo. Sobreponha os principais requisitos de negócios não funcionais de desempenho e disponibilidade. Por fim, agregar os estados de integridade para cada fluxo de usuário individual para formar uma representação aceitável da integridade geral do aplicativo. Depois de estabelecidas, essas definições de integridade em camadas devem ser usadas para informar métricas críticas de monitoramento em todos os componentes do sistema e validar a composição do subsistema operacional.

Importante

Ao definir o que são estados 'não saudáveis', aplique essa representação a todos os níveis do aplicativo. É importante distinguir entre estados de falha transitória e não transitória para qualificar a degradação do serviço em relação à indisponibilidade.

Considerações sobre o design

• O processo de modelagem de integridade é uma atividade de design de cima para baixo que começa com um exercício de arquitetura para definir todos os fluxos de usuário e mapear dependências entre componentes funcionais e lógicos, mapeando implicitamente as dependências entre os recursos do Azure.

• Um modelo de saúde depende inteiramente do contexto da solução que ele representa e, portanto, não pode ser aplicado 'pronto para uso' porque 'um tamanho não serve para todos'.

  • Os aplicativos serão diferentes em composição e dependências
  • As métricas e os limites de métrica para recursos computacionais também devem ser ajustados em termos de quais valores representam estados saudáveis e não saudáveis, que são fortemente influenciados pela funcionalidade da aplicação e pelos requisitos não funcionais de destino.

• Um modelo de saúde em camadas permite que a saúde do aplicativo seja rastreada até dependências de nível inferior, o que ajuda a identificar rapidamente a causa raiz da degradação do serviço.

• Para capturar estados de integridade de um componente individual, as características operacionais distintas desse componente devem ser compreendidas em um estado estável que reflita a carga de produção. O teste de desempenho é, portanto, um recurso fundamental para definir e avaliar continuamente a integridade do aplicativo.

• Falhas em uma solução de nuvem podem não acontecer isoladamente. Uma interrupção em um único componente pode levar a vários recursos ou componentes adicionais a ficarem indisponíveis.

  • Esses erros podem não ser imediatamente observáveis.

Recomendações de design

• Defina um modelo de integridade mensurável como prioridade para garantir uma compreensão operacional clara de todo o aplicativo.

  • O modelo de saúde deve ser em camadas e refletir a estrutura do aplicativo.
  • A camada fundamental deve considerar componentes de aplicativo individuais, como recursos do Azure.
  • Os componentes fundamentais devem ser agregados juntamente com os principais requisitos não funcionais para criar uma perspectiva contextualizada para os negócios na saúde dos fluxos do sistema.
  • Os fluxos do sistema devem ser agregados com os pesos apropriados com base na criticidade dos negócios para criar uma definição significativa da integridade geral do aplicativo. Fluxos de usuário financeiramente significativos ou voltados para o cliente devem ser priorizados.
  • Cada camada do modelo de integridade deve capturar o que os estados 'íntegros' e 'não íntegros' representam.
  • Verifique se o modelo de integridade pode distinguir entre condições não saudáveis temporárias e permanentes para isolar a degradação do serviço da indisponibilidade total.

• Represente estados de integridade usando uma pontuação de integridade granular para cada componente de aplicativo distinto e cada fluxo de usuário agregando pontuações de integridade para componentes dependentes mapeados, considerando os principais requisitos não funcionais como coeficientes.

  • A pontuação de integridade de um fluxo de usuário deve ser representada pela pontuação mais baixa em todos os componentes mapeados, considerando a obtenção relativa em relação aos requisitos não funcionais para o fluxo do usuário.
  • O modelo usado para calcular pontuações de integridade deve refletir consistentemente a integridade operacional e, caso contrário, o modelo deve ser ajustado e reimplantado para refletir novos aprendizados.
  • Defina os limites de pontuação de saúde para refletir o status de saúde.

• A pontuação de saúde deve ser calculada automaticamente com base em métricas subjacentes, que podem ser visualizadas por meio de modelos de observabilidade e utilizadas em procedimentos operacionais automatizados.

  • A pontuação de integridade deve se tornar fundamental para a solução de monitoramento, para que as equipes operacionais não precisem mais interpretar e mapear dados operacionais para a integridade do aplicativo.

• Use o modelo de saúde para calcular a obtenção do Objetivo de Nível de Serviço (SLO) de disponibilidade em vez de disponibilidade bruta, garantindo que a demarcação entre degradação do serviço e indisponibilidade seja refletida como SLOs distintos.

• Use o modelo de integridade em pipelines de CI/CD e os ciclos de teste para validar se a integridade do aplicativo é mantida após atualizações de código e configuração.

  • O modelo de saúde deve ser usado para observar e validar a saúde durante o teste de carga e o teste de caos como parte dos processos de CI/CD.

• Criar e manter um modelo de saúde é um processo iterativo, e o investimento em engenharia deve estar alinhado para promover melhorias contínuas.

  • Defina um processo para avaliar e ajustar continuamente a precisão do modelo e considere investir em modelos de machine learning para treinar ainda mais o modelo.

Exemplo – Modelo de saúde em camadas

Essa é uma representação simplificada de um modelo de integridade de aplicativo em camadas para fins ilustrativos. Um modelo de saúde abrangente e contextualizado é fornecido nas implementações de referência Mission Critical.

• Mission-Critical Online
• Missão Crítica Conectada

Ao implementar um modelo de integridade, é importante definir a integridade de componentes individuais por meio da agregação e interpretação das principais métricas de nível de recurso. Um exemplo de como as métricas de recurso podem ser usadas é a imagem abaixo:

Essa definição de saúde pode posteriormente ser representada por uma consulta KQL, como demonstrado pelo exemplo de consulta abaixo que agrega InsightsMetrics (insights de contêiner) e AzureMetrics (configuração de diagnóstico para cluster do AKS) e compara (junção interna) com os limites de saúde modelados.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

O resultado da tabela resultante pode posteriormente ser transformado em uma pontuação de saúde para facilitar a agregação em níveis mais altos do modelo de saúde.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Essas pontuações agregadas podem ser representadas posteriormente como um diagrama de dependência usando ferramentas de visualização, como o Grafana, para ilustrar o modelo de saúde.

Esta imagem mostra um exemplo de modelo de integridade em camadas da implementação de referência online Mission-Critical do Azure e demonstra como uma alteração no estado de integridade de um componente fundamental pode ter um impacto em cascata nos fluxos do usuário e na integridade geral do aplicativo (os valores de exemplo correspondem à tabela na imagem anterior).

Vídeo de demonstração: Demonstração de monitoramento e modelagem de saúde

Coletor de dados unificado para análise correlacionada

Muitos conjuntos de dados operacionais devem ser coletados de todos os componentes do sistema para representar com precisão um modelo de integridade definido, considerando logs e métricas de componentes do aplicativo e recursos subjacentes do Azure. Essa grande quantidade de dados, em última análise, precisa ser armazenada em um formato que permita uma interpretação quase em tempo real para facilitar uma ação operacional rápida. Além disso, a correlação entre todos os conjuntos de dados abrangidos é necessária para garantir que a análise efetiva não seja limitada, permitindo a representação em camadas da saúde.

Um coletor de dados unificado é necessário para garantir que todos os dados operacionais sejam armazenados rapidamente e disponibilizados para análise correlacionada para criar uma representação de "painel único" da integridade do aplicativo. O Azure fornece várias tecnologias operacionais diferentes sob o guarda-chuva do Azure Monitor e o workspace do Log Analytics serve como o coletor de dados nativo do Azure principal para armazenar e analisar dados operacionais.

Considerações sobre o design

Azure Monitor

• O Azure Monitor está habilitado por padrão para todas as assinaturas do Azure, mas os logs do Azure Monitor (workspace do Log Analytics) e os recursos do Application Insights devem ser implantados e configurados para incorporar recursos de coleta e consulta de dados.

• O Azure Monitor dá suporte a três tipos de dados de observabilidade: logs, métricas e rastreamentos distribuídos.

  • Os logs são armazenados nos workspaces do Log Analytics, que se baseiam no Azure Data Explorer. As consultas de log são armazenadas em pacotes de consultas que podem ser compartilhados entre assinaturas e são usadas para impulsionar componentes de observabilidade, como painéis, pastas de trabalho ou outras ferramentas de relatório e visualização.
  • As métricas são armazenadas em um banco de dados de série temporal interno. Para a maioria dos recursos do Azure, as métricas são coletadas e retidas automaticamente por 93 dias. Os dados de métrica também podem ser enviados para o espaço de trabalho do Log Analytics usando uma configuração de diagnósticos para o recurso.

• Todos os recursos do Azure expõem logs e métricas, mas os recursos devem ser configurados adequadamente para rotear dados de diagnóstico para o coletor de dados desejado.

Dica

Azure fornece várias políticas integradas que podem ser aplicadas para garantir que os recursos implantados sejam configurados para enviar logs e métricas para uma área de trabalho do Log Analytics.

• Não é incomum que os controles regulatórios exijam que os dados operacionais permaneçam dentro das geografias ou países/regiões de origem. Os requisitos regulatórios podem estipular a retenção de tipos de dados críticos por um longo período de tempo. Por exemplo, no setor bancário regulamentado, os dados de auditoria devem ser mantidos por pelo menos sete anos.

• Diferentes tipos de dados operacionais podem exigir períodos de retenção diferentes. Por exemplo, os logs de segurança podem precisar ser retidos por um longo período, enquanto é improvável que os dados de desempenho exijam retenção de longo prazo fora do contexto do AIOps.

• Os dados podem ser arquivados ou exportados de workspaces do Log Analytics para fins de retenção e/ou auditoria de longo prazo.

• Os Clusters Dedicados fornecem uma opção de implantação que permite zonas de disponibilidade para proteção contra falhas zonais em regiões do Azure com suporte. Clusters dedicados exigem um compromisso mínimo diário de ingestão de dados.

• Os workspaces do Log Analytics são implantados em uma região do Azure especificada.

• Para proteger contra a perda de dados por indisponibilidade de um workspace do Log Analytics, os recursos podem ser configurados com múltiplas definições de diagnóstico. Cada configuração de diagnóstico pode enviar métricas e logs para um “espaço de trabalho” separado do Log Analytics.

  • Os dados enviados para cada workspace adicional do Log Analytics incorrerão em custos extras.
  • O workspace redundante do Log Analytics pode ser implantado na mesma região do Azure ou em regiões separadas do Azure para redundância regional adicional.
  • O envio de logs e métricas de um recurso do Azure para um workspace do Log Analytics em uma região diferente incorrerá em custos de saída de dados entre regiões.
  • Alguns recursos do Azure exigem um workspace do Log Analytics na mesma região que o próprio recurso.
  • Consulte as práticas recomendadas para Azure Monitor Logs para obter mais opções de disponibilidade para o workspace do Log Analytics.

• Os dados do workspace do Log Analytics podem ser exportados para o Armazenamento do Azure ou hubs de eventos do Azure de forma contínua, agendada ou única.

  • A exportação de dados permite o arquivamento de dados de longo prazo e protege contra uma possível perda de dados operacionais devido à indisponibilidade.
  • Os destinos de exportação disponíveis são o Armazenamento do Azure ou os Hubs de Eventos do Azure. O Armazenamento do Azure pode ser configurado para diferentes níveis de redundância , incluindo zonal ou regional. A exportação de dados para o Armazenamento do Azure armazena os dados em .json arquivos.
  • Os destinos de exportação de dados devem estar na mesma região do Azure que o workspace do Log Analytics. O destino de exportação de dados do hub de eventos deve estar na mesma região que o workspace do Log Analytics. A recuperação de desastre geográfico dos Hubs de Eventos do Azure não é aplicável a esse cenário.
  • Há várias limitações de exportação de dados. Há suporte apenas para tabelas específicas no workspace para exportação de dados.
  • O arquivamento pode ser usado para armazenar dados em um workspace do Log Analytics para retenção de longo prazo a um custo reduzido sem exportá-los.

• Os Logs do Azure Monitor têm limites de consultas de usuários, que podem se manifestar como disponibilidade reduzida para clientes, como painéis de observabilidade.

  • Cinco consultas simultâneas por usuário: se cinco consultas já estiverem em execução, consultas adicionais serão colocadas em uma fila de simultaneidade por usuário até que uma consulta em execução termine.
  • Tempo na fila de simultaneidade: se uma consulta ficar na fila de simultaneidade por mais de três minutos, ela será encerrada e um código de erro 429 será retornado.
  • Limite de profundidade da fila de simultaneidade: a fila de simultaneidade é limitada a 200 consultas e consultas adicionais serão rejeitadas com um código de erro 429.
  • Limite de taxa de consulta: há um limite por usuário de 200 consultas por 30 segundos em todos os workspaces.

• Os pacotes de consultas são recursos do Azure Resource Manager, que podem ser usados para proteger e recuperar consultas de log se o workspace do Log Analytics não estiver disponível.

  • Os pacotes de consulta contêm consultas como JSON e podem ser armazenados externos ao Azure semelhantes a outros ativos de infraestrutura como código.
    • Implantável por meio da API REST do Microsoft.Insights.
    • Se um workspace do Log Analytics precisar ser recriado, será possível reimplantar o pacote de consultas a partir de uma definição armazenada externamente.

• O Application Insights pode ser implantado em um modelo de implantação baseado em espaço de trabalho, apoiado por um espaço de trabalho do Log Analytics onde todos os dados são armazenados.

• A amostragem pode ser habilitada no Application Insights para reduzir a quantidade de telemetria enviada e otimizar os custos de ingestão de dados.

• Todos os dados coletados pelo Azure Monitor, incluindo o Application Insights, são cobrados com base no volume de dados ingeridos e na duração em que os dados são mantidos.

  • Os dados ingeridos em um workspace do Log Analytics podem ser mantidos sem custo adicional até os primeiros 31 dias (90 dias se o Sentinel estiver habilitado)
  • Os dados ingeridos em um Application Insights baseado em workspace são mantidos pelos primeiros 90 dias sem custo adicional.

• O modelo de preço do tipo de compromisso do Log Analytics fornece um custo reduzido e uma abordagem previsível para os encargos de ingestão de dados.

  • Qualquer uso acima do nível de reserva é cobrado ao mesmo preço da camada atual.

• O Log Analytics, o Application Insights e o Azure Data Explorer usam a KQL (Linguagem de Consulta Kusto).

• As consultas do Log Analytics são salvas como funções no workspace do Log Analytics (savedSearches).

Recomendações de design

• Use o Log Analytics workspace como um coletor de dados unificado para fornecer uma "visão única" em todos os conjuntos de dados operacionais.

  • Descentralizar os workspaces do Log Analytics em todas as regiões de implantação utilizadas. Cada região do Azure com uma implantação de aplicativo deve considerar um workspace do Log Analytics para coletar todos os dados operacionais provenientes dessa região. Todos os recursos globais devem usar um workspace dedicado separado do Log Analytics, que deve ser implantado em uma região de implantação primária.
    • Enviar todos os dados operacionais para um único workspace do Log Analytics criaria um único ponto de falha.
    • Os requisitos de residência de dados podem proibir a saída de dados da região de origem e os workspaces federados resolvem esse requisito por padrão.
    • Há um custo substancial de saída associado à transferência de logs e métricas entre regiões.
  • Todos os selos de implantação na mesma região podem usar o mesmo workspace regional do Log Analytics.

• Considere configurar recursos com várias configurações de diagnóstico apontando para diferentes workspaces do Log Analytics para proteger contra a indisponibilidade do Azure Monitor para aplicativos com menos selos de implantação regionais.

• Use o Application Insights como uma ferramenta de APM (Monitoramento de Desempenho de Aplicativo) consistente em todos os componentes do aplicativo para coletar logs de aplicativos, métricas e rastreamentos.

  • Implante o Application Insights em uma configuração baseada em workspace para garantir que cada workspace regional do Log Analytics contenha logs e métricas de componentes do aplicativo e recursos subjacentes do Azure.

• Use consultas entre workspaces para manter um "único painel" unificado entre os diferentes workspaces.

• Emplegue pacotes de consulta para proteger consultas de log na eventualidade de indisponibilidade do workspace.

  • Armazene pacotes de consulta no repositório git do aplicativo como ativos de infraestrutura como código.

• Todos os workspaces do Log Analytics devem ser tratados como recursos de execução prolongada com um ciclo de vida diferente para recursos de aplicativo dentro de um carimbo de implantação regional.

• Exporte dados operacionais críticos do workspace do Log Analytics para retenção e análise a longo prazo, facilitando o uso de AIOps e análises avançadas para refinar o modelo de integridade subjacente e informar ações preditivas.

• Avalie cuidadosamente qual armazenamento de dados deve ser usado para retenção de longo prazo; nem todos os dados precisam ser armazenados em um armazenamento de dados frequente e que pode ser consultado.

  • É altamente recomendável usar o armazenamento do Azure em uma configuração GRS para o armazenamento de dados operacionais a longo prazo.
    • Use o recurso de exportação do workspace do Log Analytics para exportar todas as fontes de dados disponíveis para o Armazenamento do Azure.

• Selecione os períodos de retenção apropriados para tipos de dados operacionais no log analytics, configurando períodos de retenção mais longos dentro do workspace em que existem requisitos de observabilidade 'frequentes'.

• Use a Azure Policy para garantir que todos os recursos regionais enviem dados operacionais para o workspace correto do Log Analytics.

Observação

Ao implantar em uma zona de destino do Azure, se houver um requisito para o armazenamento centralizado de dados operacionais, você poderá bifurcar dados durante a instanciação para que eles sejam ingeridos em ferramentas centralizadas e espaços de trabalho do Log Analytics dedicados ao aplicativo. Como alternativa, exponha o acesso aos workspaces do Log Analytics de aplicativos para que as equipes centrais possam consultar os dados dos aplicativos. Em última análise, é essencial que os dados operacionais provenientes da solução estão disponíveis nos workspaces do Log Analytics dedicados ao aplicativo.

Se a integração do SIEM for necessária, não envie entradas de log brutas, mas envie alertas críticos.

• Somente configure a amostragem no Application Insights se for necessário otimizar o desempenho, ou se a ausência de amostragem se tornar proibitiva de custos.

  • A amostragem excessiva pode levar a sinais operacionais incorretos ou imprecisos.

• Use IDs de correlação para todos os eventos de rastreamento e mensagens de log para vinculá-los a uma determinada solicitação.

  • Retornar IDs de correlação ao chamador para todas as chamadas, não apenas para solicitações com falha.

• Verifique se o código do aplicativo incorpora instrumentação e registro em log adequados para informar o modelo de integridade e facilitar a solução de problemas subsequente ou a análise de causa raiz quando necessário.

  • O código do aplicativo deve usar o Application Insights para facilitar o Rastreamento Distribuído, fornecendo ao chamador uma mensagem de erro abrangente que inclui uma ID de correlação quando ocorre uma falha.

• Use o log estruturado para todas as mensagens de log.

• Adicione sondas de saúde significativas a todos os componentes da aplicação.

  • Ao usar o AKS, configure os endpoints de saúde para cada implantação (pod) para o Kubernetes determinar corretamente se um pod está saudável ou não.
  • Ao usar o Serviço de Aplicativo do Azure, configure as Verificações de Integridade para que as operações de expansão não causem erros enviando tráfego para instâncias que ainda não estão prontas e certificando-se de que as instâncias não íntegras sejam recicladas rapidamente.

Se o aplicativo estiver inscrito no Suporte Crítico à Missão da Microsoft, considere expor as principais sondas de integridade ao Suporte da Microsoft, para que a integridade do aplicativo possa ser modelada com mais precisão pelo Suporte da Microsoft.

• Registre solicitações de verificação de integridade bem-sucedidas, a menos que volumes de dados aumentados não possam ser tolerados no contexto do desempenho do aplicativo, pois fornecem insights adicionais para modelagem analítica.

• Não configure workspaces de produção do Log Analytics para aplicar um limite diário, que limita a ingestão diária de dados operacionais, pois isso pode levar à perda de dados operacionais críticos.

  • Em ambientes mais baixos, como Desenvolvimento e Teste, um limite diário pode ser considerado como um mecanismo opcional de redução de custos.

• Desde que os volumes de ingestão de dados operacionais atendam ao limite mínimo de camada, configure os workspaces do Log Analytics para usar preços baseados em camada de compromisso para gerar eficiências de custo em relação ao modelo de preço "pago conforme o uso".

• É altamente recomendável armazenar consultas do Log Analytics usando o controle do código-fonte e usar a automação de CI/CD para implantá-las em instâncias relevantes do espaço de trabalho do Log Analytics.

Visualização

Representar visualmente o modelo de integridade com dados operacionais críticos é essencial para alcançar operações eficazes e maximizar a confiabilidade. Em última análise, os painéis devem ser utilizados para fornecer insights quase em tempo real sobre a integridade do aplicativo para equipes de DevOps, facilitando o diagnóstico rápido de desvios de estado estável.

A Microsoft fornece várias tecnologias de visualização de dados, incluindo Painéis do Azure, Power BI e Grafana Gerenciado do Azure (atualmente em versão prévia). Os Painéis do Azure estão posicionados para fornecer uma solução de visualização pronta para uso e integrada para dados operacionais no Azure Monitor. Portanto, ele tem um papel fundamental a desempenhar na representação visual dos dados operacionais e da integridade do aplicativo para uma carga de trabalho crítica. No entanto, há várias limitações em termos de posicionamento dos Painéis do Azure como uma plataforma de observabilidade holística e, como resultado, deve-se considerar o uso complementar de soluções de observabilidade líderes de mercado, como o Grafana, que também é fornecido como uma solução gerenciada no Azure.

Esta seção se concentra no uso dos Painéis do Azure e do Grafana para criar uma experiência robusta de dashboarding capaz de fornecer perspectivas técnicas e de negócios para a integridade do aplicativo, habilitando as equipes de DevOps e a operação eficaz. O dashboard robusto é essencial para diagnosticar problemas que já ocorreram e dar suporte a equipes operacionais na detecção e resposta a problemas à medida que eles ocorrem.

Considerações sobre o design

• Ao visualizar o modelo de saúde usando consultas de log, observe que há limites do Log Analytics em consultas simultâneas e enfileiradas, bem como a taxa geral de consultas, com consultas subsequentes enfileiradas e limitadas.

• Consultas para recuperar dados operacionais usados para calcular e representar pontuações de integridade podem ser gravadas e executadas no Log Analytics ou no Azure Data Explorer.

  • As consultas de exemplo estão disponíveis aqui.

• O Log Analytics impõe vários limites de consulta, que devem ser projetados para a criação de painéis operacionais.

• A visualização de métricas de recursos brutos, como utilização da CPU ou taxa de transferência de rede, requer avaliação manual por equipes de operações para determinar impactos no status de integridade e isso pode ser desafiador durante um incidente ativo.

• Se vários usuários usarem dashboards em uma ferramenta como o Grafana, o número de consultas enviadas ao Log Analytics multiplica rapidamente.

  • Atingir o limite de consultas simultâneas no Log Analytics colocará na fila as consultas subsequentes, fazendo com que a experiência do painel pareça 'lenta'.

Recomendações de design

• Colete e apresente resultados de consultas de todos os workspaces regionais do Log Analytics e do workspace global do Log Analytics para criar uma visão unificada da saúde do aplicativo.

Observação

Se estiver implantando em uma zona de destino do Azure, considere consultar o workspace do Log Analytics da plataforma central caso existam dependências chave em recursos da plataforma, como o ExpressRoute para comunicação no local.

• Um modelo de "semáforo" (traffic light) deve ser usado para indicar visualmente estados "saudáveis" e "não saudáveis", com verde ilustrando quando os principais requisitos não funcionais são totalmente atendidos e os recursos são utilizados de maneira ideal. Use "Verde", "Âmbar" e "Vermelho" para representar os estados "Saudável", "Degradado" e "Indisponível".

• Use os Painéis do Azure para criar lentes operacionais para recursos globais e selos de implantação regionais, representando métricas importantes, como contagem de solicitações para o Azure Front Door, latência do lado do servidor para o Azure Cosmos DB, mensagens de entrada/saída para Hubs de Eventos e utilização de CPU ou status de implantação para AKS. Os painéis devem ser adaptados para impulsionar a eficácia operacional, infundindo aprendizados de cenários de falha para garantir que as equipes do DevOps tenham visibilidade direta das principais métricas.

• Se os Painéis do Azure não puderem ser usados para representar com precisão o modelo de integridade e os requisitos de negócios necessários, é altamente recomendável considerar o Grafana como uma solução de visualização alternativa, fornecendo recursos líderes de mercado e um extenso ecossistema de plug-ins de código aberto. Avalie a versão prévia gerenciada do Grafana para evitar as complexidades operacionais do gerenciamento da infraestrutura do Grafana.

• Ao implantar o Grafana auto-hospedado, empregue um design altamente disponível e distribuído geograficamente para garantir que os painéis operacionais críticos possam ser resilientes a falhas de plataforma regionais e cenários de erro em cascata.

  • Separe o estado de configuração em um armazenamento de dados externo, como o banco de dados do Azure para Postgres ou o MySQL, para garantir que os nós de aplicativo do Grafana permaneçam sem estado.

    • Configure a replicação de banco de dados entre regiões de implantação.

  • Implante nós do Grafana nos Serviços de Aplicativos em uma configuração altamente disponível dentro de uma região, usando implantações baseadas em contêineres.

    • Implantar instâncias do Serviço de Aplicativo em regiões de implantação consideradas.

    Os Serviços de Aplicativo fornecem uma plataforma de contêiner de baixo atrito, ideal para cenários de baixa escala, como painéis operacionais, e isolar o Grafana do AKS fornece uma clara separação de preocupação entre a plataforma de aplicativo principal e representações operacionais dessa plataforma. Consulte a área de design da Plataforma de Aplicação para obter mais recomendações de configuração.

  • Use o Armazenamento do Azure em uma configuração GRS para hospedar e gerenciar visuais e plug-ins personalizados.

  • Implante o serviço de aplicação e componentes do Grafana para réplica de leitura do banco de dados em um mínimo de duas regiões de implantação, e considere empregar um modelo onde o Grafana seja implantado em todas as regiões de implantação consideradas.

Para cenários destinados a um >SLO de = 99,99%, o Grafana deve ser implantado em um mínimo de três regiões de implantação para maximizar a confiabilidade geral dos principais painéis operacionais.

• Reduza os limites de consulta do Log Analytics agregando consultas em um único ou pequeno número de consultas, como usando o operador KQL 'union' e defina uma taxa de atualização apropriada no painel.

  • Uma taxa de atualização máxima apropriada dependerá do número e da complexidade das consultas do painel; a análise de consultas implementadas é necessária.

• Se o limite de consulta simultâneo do Log Analytics estiver sendo atingido, considere otimizar o padrão de recuperação armazenando (temporariamente) os dados necessários para o painel em um armazenamento de dados de alto desempenho, como o SQL do Azure.

Resposta automatizada a incidentes

Embora as representações visuais da integridade do aplicativo forneçam insights operacionais e de negócios inestimáveis para dar suporte à detecção e ao diagnóstico de problemas, elas se baseiam na prontidão e nas interpretações das equipes operacionais, bem como na eficácia das respostas subsequentes disparadas pelo homem. Portanto, para maximizar a confiabilidade, é necessário implementar alertas extensivos para detectar proativamente e responder a problemas quase em tempo real.

O Azure Monitor fornece uma ampla estrutura de alertas para detectar, categorizar e responder a sinais operacionais por meio de Grupos de Ações. Esta seção se concentrará, portanto, no uso de alertas do Azure Monitor para conduzir ações automatizadas em resposta a desvios atuais ou potenciais de um estado de aplicativo íntegro.

Importante

O alerta e a ação automatizada são fundamentais para detectar e responder rapidamente a problemas conforme eles acontecem, antes que um impacto negativo maior possa ocorrer. O alerta também fornece um mecanismo para interpretar sinais de entrada e responder para evitar problemas antes que eles ocorram.

Considerações sobre o design

• As regras de alerta são definidas para disparar quando um critério condicional é atendido para sinais de entrada, que podem incluir várias fontes de dados, como métricas, consultas de log ou testes de disponibilidade.

• Os alertas podem ser definidos no Log Analytics ou no Azure Monitor no recurso específico.

• Algumas métricas só são interrogáveis no Azure Monitor, pois nem todos os pontos de dados de diagnóstico são disponibilizados no Log Analytics.

• A API de Alertas do Azure Monitor pode ser usada para recuperar alertas ativos e históricos.

• Há limites de assinatura relacionados a alertas e grupos de ações, que devem ser projetados para:

  • Existem limites para o número de regras de alerta configuráveis.
  • A API de Alertas tem limites de limitação, que devem ser considerados para cenários de uso extremo.
  • Os Grupos de Ações têm vários limites rígidos para o número de respostas configuráveis, para as quais deve ser projetado.
    • Cada tipo de resposta tem um limite de 10 ações, além do email, que tem um limite de 1.000 ações.

• Os alertas podem ser integrados em um modelo de saúde em camadas criando uma Regra de Alerta para uma consulta de pesquisa de log salva da função de avaliação 'root' do modelo. Por exemplo, usando 'WebsiteHealthScore' e alertando sobre um valor numérico que representa um estado 'Não Saudável'.

Recomendações de design

• Para alertas centrados em recursos, crie regras de alerta no Azure Monitor para garantir que todos os dados de diagnóstico estão disponíveis para os critérios de regra de alerta.

• Consolide ações automatizadas em um número mínimo de Grupos de Ações, alinhados com as equipes de serviço para dar suporte a uma abordagem de DevOps.

• Responda a sinais de utilização excessiva de recursos por meio de operações de escala automatizadas, usando recursos de dimensionamento automático nativo do Azure sempre que possível. Quando a funcionalidade de escala automática interna não for aplicável, use a pontuação de integridade do componente para modelar sinais e determinar quando responder com operações de escala automatizadas. Verifique se as operações de escala automatizadas são definidas de acordo com um modelo de capacidade, que quantifica as relações de escala entre componentes, de modo que as respostas de escala englobam componentes que precisam ser dimensionados em relação a outros componentes.

• Ações de modelo para acomodar uma ordenação priorizada, que deve ser determinada pelo impacto nos negócios.

• Use a API de Alertas do Azure Monitor para coletar alertas históricos para incorporar no armazenamento operacional 'frio' para análise avançada.

• Para cenários críticos de falha, que não podem ser atendidos com uma resposta automatizada, verifique se a "automação de runbook" operacional está no local para conduzir uma ação rápida e consistente depois que a interpretação manual e a saída forem fornecidas. Usar notificações de alerta para orientar a identificação rápida de problemas que exigem interpretação manual

• Crie subsídios em sprints de engenharia para promover melhorias incrementais no alerta para garantir que novos cenários de falha que não foram considerados anteriormente possam ser totalmente acomodados em novas ações automatizadas.

• Realize testes de preparação operacional como parte dos processos de CI/CD para validar as principais regras de alerta para atualizações de implantação.

Ação preditiva e operações de IA (AIOps)

Os modelos de machine learning podem ser aplicados para correlacionar e priorizar dados operacionais, ajudando a coletar insights críticos relacionados à filtragem de "ruído" de alerta excessivo e à previsão de problemas antes que eles causem impacto, bem como acelerar a resposta a incidentes quando o fizerem.

Mais especificamente, uma metodologia do AIOps pode ser aplicada a insights críticos sobre o comportamento do sistema, dos usuários e dos processos de DevOps. Esses insights podem incluir a identificação de um problema que está acontecendo agora (detectar), quantificar por que o problema está acontecendo (diagnosticar) ou sinalizar o que acontecerá no futuro (prever). Esses insights podem ser usados para impulsionar ações que ajustam e otimizam o aplicativo para atenuar problemas ativos ou potenciais, usando métricas de negócios importantes, métricas de qualidade do sistema e métricas de produtividade do DevOps, para priorizar de acordo com o impacto nos negócios. As ações realizadas podem ser integradas no sistema por meio de um ciclo de feedback que treina ainda mais o modelo subjacente para impulsionar eficiências adicionais.

Há várias tecnologias analíticas no Azure, como o Azure Synapse e o Azure Databricks, que podem ser usadas para criar e treinar modelos analíticos para a AIOps. Esta seção, portanto, se concentrará em como essas tecnologias podem ser posicionadas em um design de aplicativo para acomodar o AIOps e impulsionar a ação preditiva, focando no Azure Synapse que reduz o atrito reunindo o melhor dos serviços de dados do Azure, juntamente com novos recursos avançados.

O AIOps é usado para conduzir a ação preditiva, interpretando e correlacionando sinais operacionais complexos observados durante um período sustentado, a fim de responder melhor e evitar problemas antes que eles ocorram.

Considerações sobre o design

• O Azure Synapse Analytics oferece vários recursos de ML (Machine Learning).

  • Os modelos de ML podem ser treinados e executados em Pools do Spark do Synapse com bibliotecas incluindo MLLib, SparkML e MMLSpark, bem como bibliotecas populares de software livre, como o Scikit Learn.
  • Os modelos de ML podem ser treinados com ferramentas comuns de ciência de dados, como PySpark/Python, Scala ou .NET.

• Synapse Analytics é integrado ao Azure ML por meio do Azure Synapse Notebooks, que permite que os modelos de ML sejam treinados em um Workspace do Azure ML usando Automated ML.

• O Synapse Analytics também permite que os recursos de ML usando os Serviços Cognitivos do Azure resolvam problemas gerais em vários domínios, como Detecção de Anomalias. Os Serviços Cognitivos podem ser usados no Azure Synapse, no Azure Databricks e por meio de SDKs e APIs REST em aplicativos cliente.

• O Azure Synapse integra-se nativamente às ferramentas do Azure Data Factory para extrair, transformar e carregar (ETL) ou ingerir dados em pipelines de orquestração.

• O Azure Synapse permite o registro de conjunto de dados externo para dados armazenados no Armazenamento de Blobs do Azure ou no Azure Data Lake Storage.

  • Conjuntos de dados registrados podem ser usados em tarefas de análise de dados do pool do Synapse Spark.

• O Azure Databricks pode ser integrado aos pipelines do Azure Synapse Analytics para recursos adicionais do Spark.

  • O Synapse orquestra a leitura de dados e o envio para um cluster do Databricks, onde ele pode ser transformado e preparado para treinamento de modelo de ML.

• Os dados de origem normalmente precisam estar preparados para análise e ML.

  • O Synapse oferece várias ferramentas para ajudar na preparação de dados, incluindo Apache Spark, Synapse Notebooks e pools de SQL sem servidor com visualizações internas e T-SQL.

• Modelos de Machine Learning que foram treinados, operacionalizados e implantados podem ser usados para pontuação em lote no Synapse.

  • Cenários de AIOps, como a realização de previsões de regressão ou degradação no pipeline de CI/CD, podem exigir avaliação em tempo real.

• Há limites de assinatura para o Azure Synapse, que devem ser totalmente compreendidos no contexto de uma metodologia do AIOps.

• Para integrar plenamente o AIOps, é necessário fornecer continuamente dados de observabilidade quase em tempo real a modelos de inferência de ML em tempo real.

  • Recursos como a detecção de anomalias devem ser avaliados dentro do fluxo de dados de observabilidade.

Recomendações de design

• Verifique se todos os recursos do Azure e os componentes do aplicativo estão totalmente instrumentados para que um conjunto de dados operacional completo esteja disponível para treinamento de modelo do AIOps.

• Importar dados operacionais do Log Analytics das Contas de Armazenamento globais e regionais do Azure para o Azure Synapse para análise.

• Use a API de Alertas do Azure Monitor para recuperar alertas históricos e armazená-los no armazenamento frio para que os dados operacionais sejam usados posteriormente em modelos de ML. Se a exportação de dados do Log Analytics for usada, armazene dados de alertas históricos nas mesmas contas do Armazenamento do Azure que os dados exportados do Log Analytics.

• Depois que os dados ingeridos forem preparados para treinamento de ML, escreva-os de volta no Armazenamento do Azure para que estejam disponíveis para treinamento de modelo de ML sem exigir que os recursos de computação de preparação de dados do Synapse estejam em execução.

• Verifique se a operacionalização do modelo de ML dá suporte à pontuação em lotes e em tempo real.

• À medida que os modelos AIOps são criados, implemente MLOps e aplique práticas de DevOps para automatizar o ciclo de vida de ML para treinamento, operacionalização, pontuação e melhoria contínua. Crie um processo de CI/CD iterativo para modelos do AIOps ML.

• Avalie os Serviços Cognitivos do Azure para cenários preditivos específicos devido à baixa sobrecarga administrativa e de integração. Considere a Detecção de Anomalias para sinalizar rapidamente variações inesperadas em fluxos de dados de observabilidade.

Próxima etapa

Examine as considerações de implantação e teste.

Implantação e teste