Modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure

A modelagem e a observabilidade de integridade são conceitos essenciais para maximizar a confiabilidade, que se concentra em instrumentação e monitoramento robustos e contextualizados. Esses conceitos fornecem insights críticos sobre a integridade do aplicativo, promovendo a identificação rápida e a 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 integridade, em última análise, se esforça para maximizar a observabilidade aumentando logs e métricas de monitoramento brutos com os principais requisitos de negócios para quantificar a integridade do aplicativo, impulsionando a avaliação automatizada dos estados de integridade 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 alcançar a maturidade operacional.

Há três níveis main 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: Definir um modelo de integridade para sua carga de trabalho crítica

Integridade do aplicativo 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 constante e agregado de acordo com os fluxos do usuário do aplicativo. Sobreponha-se aos principais requisitos de negócios não funcionais para desempenho e disponibilidade. Por fim, agregue 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.

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 integridade depende inteiramente do contexto da solução que ele representa e, portanto, não pode ser resolvido 'pronto para uso' porque 'um tamanho não se encaixa em todos'.

  • Os aplicativos serão diferentes em composição e dependências
  • As métricas e os limites de métrica para recursos também devem ser ajustados em termos de quais valores representam estados íntegros e não íntegros, que são fortemente influenciados pela funcionalidade englobada do aplicativo e se destinam a requisitos não funcionais.

• Um modelo de integridade em camadas permite que a integridade do aplicativo seja rastreada de volta para dependências de nível inferior, o que ajuda a causar rapidamente a 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, uma funcionalidade fundamental para definir e avaliar continuamente a integridade do aplicativo.

• Falhas em uma solução de nuvem podem não ocorrer 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 sobre design

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

  • O modelo de integridade 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 junto com os principais requisitos não funcionais para criar uma lente contextualizada pelos negócios na integridade dos fluxos do sistema.
  • Os fluxos do sistema devem ser agregados com pesos apropriados com base na criticalidade 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 'íntegro' e 'não íntegro' representam.
  • Verifique se o modelo de integridade pode distinguir entre estados não íntegros transitórios e não transitórios para isolar a degradação do serviço da indisponibilidade.

• 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 limites de pontuação de integridade para refletir status de integridade.

• A pontuação de integridade deve ser calculada automaticamente com base em métricas subjacentes, que podem ser visualizadas por meio de padrões de observabilidade e executadas por meio de 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 integridade para calcular a obtenção do SLO (Objetivo de Nível de Serviço) de disponibilidade em vez da disponibilidade bruta, garantindo que a demarcação entre degradação do serviço e indisponibilidade seja refletida como SLOs separados.

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

  • O modelo de integridade deve ser usado para observar e validar a integridade 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 ser alinhado para impulsionar 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 integridade em camadas

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

• Missão crítica 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 integridade pode ser representada posteriormente por uma consulta KQL, conforme demonstrado pela consulta de exemplo 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 limites de integridade 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

A saída da tabela resultante pode posteriormente ser transformada em uma pontuação de integridade para facilitar a agregação em níveis mais altos do modelo de integridade.

// 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 gráfico de dependência usando ferramentas de visualização como o Grafana para ilustrar o modelo de integridade.

Esta imagem mostra um exemplo de modelo de integridade em camadas do Azure Mission-Critical implementação de referência online 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).

de

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

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 integridade.

Um coletor de dados unificado é necessário para garantir que todos os dados operacionais sejam armazenados rapidamente e disponibilizados para análise correlacionada a fim de 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.

de

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 em workspaces do Log Analytics, que se baseia no Azure Data Explorer. As consultas de log são armazenadas em pacotes de consulta 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 workspace do Log Analytics usando uma configuração de diagnóstico 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.

• Não é incomum que os controles regulatórios exijam que os dados operacionais permaneçam dentro de regiões ou 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 banco regulamentado, os dados de auditoria devem ser retidos 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. Os 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 perda de dados contra indisponibilidade de um workspace do Log Analytics, os recursos podem ser configurados com várias configurações de diagnóstico. Cada configuração de diagnóstico pode enviar métricas e logs para um workspace 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.
  • Confira Práticas recomendadas para logs do Azure Monitor 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 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 arquivos .json.
  • Os destinos de exportação de dados devem estar na mesma região do Azure que o workspace do Log Analytics. Um destino de exportação de dados do hub de eventos para estar na mesma região que o workspace do Log Analytics. Hubs de Eventos do Azure recuperação de desastre geográfico não é aplicável a esse cenário.
  • Há várias limitações de exportação de dados. Somente tabelas específicas no workspace têm suporte 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 limitação de consulta de usuário, que podem aparecer 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 consulta são recursos de Resource Manager do Azure, 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, o pacote de consultas poderá ser reimplantado de uma definição armazenada externamente.

• O Application Insights pode ser implantado em um modelo de implantação baseado em workspace, apoiado por um workspace do Log Analytics em que 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 retidos 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ços 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 pelo mesmo preço que a camada atual.

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

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

Recomendações sobre design

• Use o workspace do Log Analytics como um coletor de dados unificado para fornecer um "painel único" em todos os conjuntos de dados operacionais.

  • Descentralizar workspaces do Log Analytics em todas as regiões de implantação usadas. 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 do Log Analytics separado, 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 consistente de Monitoramento de Desempenho de Aplicativos (APM) em todos os componentes do aplicativo para coletar logs, métricas e rastreamentos do aplicativo.

  • 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 ambos os componentes do aplicativo e recursos subjacentes do Azure.

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

• Use pacotes de consulta para proteger consultas de log em caso 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 selo de implantação regional.

• Exporte dados operacionais críticos do workspace do Log Analytics para retenção e análise de longo prazo para facilitar o AIOps e a análise avançada para refinar o modelo de integridade subjacente e informar a ação preditiva.

• 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 consultável.

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

• Selecione 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 Azure Policy para garantir que todos os recursos regionais roteiem dados operacionais para o workspace correto do Log Analytics.

• Configure apenas a amostragem no Application Insights se for necessário otimizar o desempenho ou se a amostragem não se tornar proibitiva de custo.

  • 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 determinada solicitação.

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

• Verifique se o código do aplicativo incorpora a instrumentação e o 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 investigações de integridade significativas a todos os componentes do aplicativo.

  • Ao usar o AKS, configure os pontos de extremidade de integridade para cada implantação (pod) para que o Kubernetes possa determinar corretamente quando um pod está íntegro ou não íntegro.
  • Ao usar 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 garantindo que instâncias não íntegras sejam recicladas rapidamente.

Se o aplicativo estiver inscrito no Suporte do Microsoft Mission-Critical, considere expor as principais investigações de integridade a Suporte da Microsoft, para que a integridade do aplicativo possa ser modelada com mais precisão por Suporte da Microsoft.

• Registre solicitações de marcar 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 do Log Analytics de produção 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 economia de custos.

• Os volumes de ingestão de dados operacionais fornecidos atendem ao limite mínimo de camada, configure 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ços "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 workspace do Log Analytics.

Visualização

A representação visual do modelo de integridade com os 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 as equipes de DevOps, facilitando o diagnóstico rápido de desvios do 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 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 do posicionamento dos Painéis do Azure como uma plataforma de observabilidade holística e, como resultado, deve-se considerar o uso suplementar 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 de dashboard robusta capaz de fornecer lentes técnicas e de negócios para a integridade do aplicativo, habilitando equipes de DevOps e operação eficaz. Dashboards robustos são essenciais para diagnosticar problemas que já ocorreram e dar suporte às equipes operacionais na detecção e resposta a problemas à medida que ocorrem.

Considerações sobre o design

• Ao visualizar o modelo de integridade usando consultas de log, observe que há limites do Log Analytics em consultas simultâneas e enfileiradas, bem como a taxa de consulta geral, 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 ao criar 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 status de integridade e isso pode ser desafiador durante um incidente ativo.

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

  • Atingir o limite de consulta simultânea no Log Analytics enfileirará consultas subsequentes, fazendo com que a experiência de dashboard se sinta 'lenta'.

Recomendações de design

• Colete e apresente saídas consultadas de todos os workspaces regionais do Log Analytics e do workspace global do Log Analytics para criar uma exibição unificada da integridade do aplicativo.

• Um modelo de ‘semáforo’ deve ser usado para representar visualmente os estados 'íntegro' e 'não íntegro', com o verde usado para ilustrar 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 "Íntegro", "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 dos cenários de falha para garantir que as equipes de 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 amplo ecossistema de plug-in de software livre. Avalie a oferta de visualização 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 painéis operacionais críticos possam ser resilientes a falhas de plataforma regional 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 do aplicativo Grafana permaneçam sem estado.

    • Configurar 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 entre os de uma região, usando implantações baseadas em contêiner.

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

    Os Serviços de Aplicativo fornecem uma plataforma de contêiner de baixo atrito, que é 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 primária e as representações operacionais dessa plataforma. Consulte a área Deign da Plataforma de Aplicativos 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 aplicativo e o banco de dados réplica componentes do Grafana em um mínimo de duas regiões de implantação e considere empregar um modelo em que o Grafana seja implantado em todas as regiões de implantação consideradas.

Para cenários direcionados a um >SLO = 99,99%, o Grafana deve ser implantado dentro de 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 número único ou pequeno de consultas, como usando o operador KQL 'union' e defina uma taxa de atualização apropriada no dashboard.

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

• Se o limite de consulta simultânea do Log Analytics estiver sendo atingido, considere otimizar o padrão de recuperação armazenando (temporariamente) os dados necessários para o dashboard em um armazenamento de dados de alto desempenho, como 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 dependem da preparação e das interpretações das equipes operacionais, bem como da eficácia das respostas posteriores disparadas por pessoas. Portanto, para maximizar a confiabilidade, é necessário implementar alertas abrangentes 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. Portanto, esta seção se concentrará 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.

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ó podem ser interrogadas 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, que devem ser projetadas para.
    • 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 integridade em camadas criando uma Regra de Alerta para uma consulta de pesquisa de log salva da função de pontuação "raiz" do modelo. Por exemplo, usando 'WebsiteHealthScore' e alertas sobre um valor numérico que representa um estado 'Não íntegro'.

Recomendações sobre 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 da regra de alerta.

• Consolide as 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 funcionalidades de dimensionamento automático nativas do Azure sempre que possível. Quando a funcionalidade interna de dimensionamento automático não for aplicável, use a pontuação de integridade do componente para modelar sinais e determine quando responder a eles com operações de escala automatizadas. Verifique se as operações de escala automatizada são definidas de acordo com um modelo de capacidade, que quantifica as relações de escala entre os componentes, de modo que as respostas de escala englobem componentes que precisam ser escalados 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 a serem incorporados 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á in-loco 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 nos alertas 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 alertas 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 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 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 as principais métricas de negócios, 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 infundidas no sistema por meio de um loop de comentários que treina ainda mais o modelo subjacente para gerar eficiências adicionais.

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

O AIOps é usado para conduzir ações preditivas, interpretar e correlacionar 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

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

  • Os modelos de ML podem ser treinados e executados em pools do Synapse Spark com bibliotecas incluindo MLLib, SparkML e MMLSpark, bem como bibliotecas de software livre populares, 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.

• O 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 o ML automatizado.

• 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 em Azure Synapse, no Azure Databricks e por meio de SDKs e APIs REST em aplicativos cliente.

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

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

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

• 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, no qual eles podem ser transformados e preparados 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 ML treinados, operacionalizados e implantados podem ser usados para pontuação em lote no Synapse.

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

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

• Para incorporar totalmente o AIOps, é necessário alimentar dados de observabilidade quase em tempo real em modelos de inferência de ML em tempo real continuamente.

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

Recomendações sobre 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.

• Ingerir dados operacionais do Log Analytics das Contas de Armazenamento do Azure globais e regionais em 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 novamente 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 lote 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 iterativo de CI/CD para modelos de 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.