Modelação e observabilidade do estado de funcionamento de cargas de trabalho fundamentais para a missão no Azure

A modelação e a observabilidade do estado de funcionamento são conceitos essenciais para maximizar a fiabilidade, que se foca na instrumentação e monitorização robustas e contextualizadas. Estes conceitos fornecem informações críticas sobre o estado de funcionamento das aplicações, promovendo a rápida identificação e resolução de problemas.

A maioria das aplicações críticas para a missão são significativas em termos de escala e complexidade e, por conseguinte, geram grandes volumes de dados operacionais, o que torna difícil avaliar e determinar uma ação operacional ideal. Em última análise, a modelação do estado de funcionamento tenta maximizar a observabilidade ao aumentar os registos e as métricas de monitorização não processados com requisitos empresariais fundamentais para quantificar o estado de funcionamento das aplicações, impulsionando a avaliação automatizada dos estados de saúde para alcançar operações consistentes e aceleradas.

Esta área de design centra-se no processo para definir um modelo de estado de funcionamento robusto, mapeando estados quantificados do estado de funcionamento da aplicação através de observabilidade e construções operacionais para alcançar a maturidade operacional.

Importante

Este artigo faz parte da série de cargas de trabalho críticas para a missão do Azure Well-Architected . Se não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica para a missão?

Existem três níveis principais de maturidade operacional ao tentar maximizar a fiabilidade.

1. Detetar e responder a problemas à medida que acontecem.
2. Diagnosticar problemas que estão a ocorrer ou que já ocorreram.
3. Prever e evitar problemas antes de ocorrerem.

Vídeo: Definir um modelo de estado de funcionamento para a carga de trabalho crítica para a sua missão

Estado de funcionamento da aplicação em camadas

Para criar um modelo de estado de funcionamento, primeiro defina o estado de funcionamento da aplicação no contexto dos principais requisitos empresariais ao quantificar estados "em bom estado de funcionamento" e "em mau estado de funcionamento" num formato em camadas e mensurável. Em seguida, para cada componente da aplicação, refine a definição no contexto de um estado de execução constante e agregada de acordo com os fluxos de utilizador da aplicação. Sobreponha-se aos principais requisitos empresariais não funcionais para desempenho e disponibilidade. Por fim, agregue os estados de funcionamento de cada fluxo de utilizador individual para formar uma representação aceitável do estado de funcionamento geral da aplicação. Depois de estabelecidas, estas definições de estado de funcionamento em camadas devem ser utilizadas para informar as métricas de monitorização críticas em todos os componentes do sistema e validar a composição do subsistema operacional.

Importante

Ao definir os estados "em mau estado de funcionamento", represente todos os níveis da aplicação. É importante distinguir entre estados de falha transitórios e não transitórios para qualificar a degradação do serviço relativamente à indisponibilidade.

Considerações de design

• O processo de modelação do estado de funcionamento é uma atividade de design de cima para baixo que começa com um exercício de arquitetura para definir todos os fluxos de utilizador e mapear dependências entre componentes funcionais e lógicos, mapeando implicitamente dependências entre recursos do Azure.

• Um modelo de estado de funcionamento depende inteiramente do contexto da solução que representa e, portanto, não pode ser resolvido "pronto a utilizar" porque "um tamanho não cabe em todos".

  • As aplicações serão diferentes em composição e dependências
  • As métricas e os limiares de métricas dos recursos também têm de ser otimizados em termos dos valores que representam estados em bom estado de funcionamento e em mau estado de funcionamento, que são fortemente influenciados pela funcionalidade de aplicação abrangente e pelos requisitos não funcionais de destino.

• Um modelo de estado de funcionamento em camadas permite que o estado de funcionamento da aplicação seja rastreado até dependências de nível inferior, o que ajuda a causar rapidamente a degradação do serviço.

• Para capturar estados de funcionamento de um componente individual, as características operacionais distintas desse componente têm de ser compreendidas num estado estável que refleia a carga de produção. Por conseguinte, o teste de desempenho é uma capacidade fundamental para definir e avaliar continuamente o estado de funcionamento da aplicação.

• As falhas numa solução cloud podem não ocorrer isoladamente. Uma falha num único componente pode fazer com que várias capacidades ou componentes adicionais fiquem indisponíveis.

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

Recomendações de conceção

• Defina um modelo de estado de funcionamento mensurável como uma prioridade para garantir uma compreensão operacional clara de toda a aplicação.

  • O modelo de estado de funcionamento deve ser colocado em camadas e refletir a estrutura da aplicação.
  • A camada fundamental deve considerar os componentes individuais da aplicação, como os recursos do Azure.
  • Os componentes fundamentais devem ser agregados juntamente com os principais requisitos não funcionais para criar uma lente contextualizada para a empresa no estado de funcionamento dos fluxos do sistema.
  • Os fluxos de sistema devem ser agregados com pesos adequados com base na importância empresarial para criar uma definição significativa do estado de funcionamento geral da aplicação. Os fluxos de utilizadores financeiramente significativos ou destinados ao cliente devem ser priorizados.
  • Cada camada do modelo de estado de funcionamento deve capturar os estados "em bom estado de funcionamento" e "em mau estado de funcionamento".
  • Certifique-se de que o modelo de estado de funcionamento consegue distinguir entre estados de mau estado de funcionamento transitórios e não transitórios para isolar a degradação do serviço da indisponibilidade.

• Represente estados de funcionamento com uma classificação de estado de funcionamento granular para cada componente de aplicação distinto e cada fluxo de utilizador ao agregar classificações de estado de funcionamento para componentes dependentes mapeados, considerando os principais requisitos não funcionais como coeficientes.

  • A classificação de estado de funcionamento de um fluxo de utilizador deve ser representada pela classificação mais baixa em todos os componentes mapeados, tendo em conta a obtenção relativa de requisitos não funcionais para o fluxo de utilizador.
  • O modelo utilizado para calcular as classificações de estado de funcionamento tem de refletir consistentemente o estado de funcionamento operacional e, se não for o caso, o modelo deve ser ajustado e reimplementado para refletir novas aprendizagens.
  • Defina limiares de classificação de estado de funcionamento para refletir o estado de funcionamento.

• A classificação de estado de funcionamento tem de ser calculada automaticamente com base em métricas subjacentes, que podem ser visualizadas através de padrões de observabilidade e atuadas através de procedimentos operacionais automatizados.

  • A classificação de estado de funcionamento deve tornar-se fundamental para a solução de monitorização, para que as equipas operacionais já não tenham de interpretar e mapear dados operacionais para o estado de funcionamento da aplicação.

• Utilize o modelo de estado de funcionamento para calcular a disponibilidade do Objetivo de Nível de Serviço (SLO) em vez da disponibilidade não processada, garantindo que a demarcação entre a degradação do serviço e a indisponibilidade se reflete como SLOs separados.

• Utilize o modelo de estado de funcionamento nos pipelines de CI/CD e os ciclos de teste para validar a manutenção do estado de funcionamento da aplicação após as atualizações de código e configuração.

  • O modelo de estado de funcionamento deve ser utilizado para observar e validar o estado de funcionamento durante o teste de carga e os testes de caos como parte dos processos de CI/CD.

• Criar e manter um modelo de estado de funcionamento é 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 continuar a preparar o modelo.

Exemplo - Modelo de estado de funcionamento em camadas

Esta é uma representação simplificada de um modelo de estado de funcionamento da aplicação em camadas para fins ilustrativos. É fornecido um modelo de estado de funcionamento abrangente e contextualizado nas implementações de referência de Mission-Critical:

• Missão Crítica Online
• Missão-Crítica Ligada

Ao implementar um modelo de estado de funcionamento, é importante definir o estado de funcionamento dos componentes individuais através da agregação e interpretação das principais métricas ao nível dos recursos. Um exemplo de como as métricas de recursos podem ser utilizadas é a imagem abaixo:

para a missão

Posteriormente, esta definição de estado de funcionamento pode ser representada por uma consulta KQL, conforme demonstrado pela consulta de exemplo abaixo que agrega InsightsMetrics (Container Insights) e AzureMetrics (definição de diagnóstico para o cluster do AKS) e compara (associação interna) com limiares de estado de funcionamento 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

Posteriormente, a saída da tabela resultante pode ser transformada numa classificação de estado de funcionamento para facilitar a agregação em níveis mais elevados do modelo de estado de funcionamento.

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

Posteriormente, estas classificações agregadas podem ser representadas como um gráfico de dependências através de ferramentas de visualização, como o Grafana, para ilustrar o modelo de estado de funcionamento.

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

Visualização do de Funcionamento

Vídeo de demonstração: Demonstração da monitorização e modelação do estado de funcionamento

Sink de dados unificados para análise correlacionada

Muitos conjuntos de dados operacionais têm de ser recolhidos de todos os componentes do sistema para representar com precisão um modelo de estado de funcionamento definido, tendo em conta os registos e as métricas dos componentes da aplicação e dos recursos subjacentes do Azure. Em última análise, esta grande quantidade de dados tem de ser armazenada num formato que permita uma interpretação quase em tempo real para facilitar uma ação operacional rápida. Além disso, a correlação em todos os conjuntos de dados englobados é necessária para garantir que a análise eficaz não está vinculada, permitindo a representação em camadas do estado de funcionamento.

É necessário um sink de dados unificado para garantir que todos os dados operacionais são rapidamente armazenados e disponibilizados para análise correlacionada para criar uma representação do "único painel" do estado de funcionamento da aplicação. O Azure fornece várias tecnologias operacionais diferentes sob a alçada do Azure Monitor e a área de trabalho do Log Analytics serve como o principal sink de dados nativos do Azure para armazenar e analisar dados operacionais.

Considerações de design

Azure Monitor

• O Azure Monitor está ativado por predefinição para todas as subscrições do Azure, mas os registos do Azure Monitor (área de trabalho do Log Analytics) e os recursos do Application Insights têm de ser implementados e configurados para incorporar capacidades de recolha e consulta de dados.

• O Azure Monitor suporta três tipos de dados de observabilidade: registos, métricas e rastreios distribuídos.

  • Os registos são armazenados em áreas de trabalho do Log Analytics, que se baseiam no Azure Data Explorer. As consultas de registo são armazenadas em pacotes de consultas que podem ser partilhados entre subscrições e são utilizadas para impulsionar componentes de observabilidade, como dashboards, livros ou outras ferramentas de relatórios e visualização.
  • As métricas são armazenadas numa base de dados de série temporal interna. Para a maioria dos recursos do Azure, as métricas são recolhidas e retidas automaticamente durante 93 dias. Os dados de métricas também podem ser enviados para a área de trabalho do Log Analytics através de uma definição de diagnóstico para o recurso.

• Todos os recursos do Azure expõem registos e métricas, mas os recursos têm de estar devidamente configurados para encaminhar dados de diagnóstico para o sink de dados pretendido.

Dica

O Azure fornece várias Políticas Incorporadas que podem ser aplicadas para garantir que os recursos implementados estão configurados para enviar registos e métricas para uma área de trabalho do Log Analytics.

• Não é incomum que os controlos regulamentares exijam que os dados operacionais permaneçam em regiões geográficas ou países/regiões de origem. Os requisitos regulamentares podem estipular a retenção de tipos de dados críticos durante um longo período de tempo. Por exemplo, na banca regulamentada, os dados de auditoria têm de ser mantidos durante, pelo menos, sete anos.

• Diferentes tipos de dados operacionais podem exigir períodos de retenção diferentes. Por exemplo, os registos de segurança podem ter de ser mantidos durante um longo período, enquanto os dados de desempenho não necessitam de retenção de longo prazo fora do contexto do AIOps.

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

• Os Clusters Dedicados fornecem uma opção de implementação que permite Zonas de Disponibilidade para proteção contra falhas zonais em regiões do Azure suportadas. Os Clusters Dedicados requerem uma alocação mínima diária de ingestão de dados.

• As áreas de trabalho do Log Analytics são implementadas numa região especificada do Azure.

• Para proteger contra a perda de dados contra a indisponibilidade de uma área de trabalho do Log Analytics, os recursos podem ser configurados com várias definições de diagnóstico. Cada definição de diagnóstico pode enviar métricas e registos para uma área de trabalho do Log Analytics separada.

  • Os dados enviados para cada área de trabalho adicional do Log Analytics irão incorrer em custos adicionais.
  • A área de trabalho redundante do Log Analytics pode ser implementada na mesma região do Azure ou em regiões separadas do Azure para redundância regional adicional.
  • O envio de registos e métricas de um recurso do Azure para uma área de trabalho do Log Analytics numa região diferente irá incorrer em custos de saída de dados entre regiões.
  • Alguns recursos do Azure requerem uma área de trabalho do Log Analytics na mesma região que o próprio recurso.
  • Veja Melhores práticas dos Registos do Azure Monitor para obter mais opções de disponibilidade para a área de trabalho do Log Analytics.

• Os dados da área de trabalho 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 arquivo de dados a longo prazo e protege contra possíveis perdas 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 ficheiros .json.
  • Os destinos de exportação de dados têm de estar na mesma região do Azure que a área de trabalho do Log Analytics. Um destino de exportação de dados do hub de eventos para estar na mesma região que a área de trabalho do Log Analytics. Hubs de Eventos do Azure recuperação após desastre geográfico não é aplicável a este cenário.
  • Existem várias limitações de exportação de dados. Apenas as tabelas específicas na área de trabalho são suportadas para exportação de dados.
  • O arquivo pode ser utilizado para armazenar dados numa área de trabalho do Log Analytics para retenção de longo prazo a um custo reduzido sem os exportar.

• Os Registos do Azure Monitor têm limites de limitação de consultas do utilizador, que podem aparecer como uma disponibilidade reduzida para os clientes, como dashboards de observabilidade.

  • Cinco consultas simultâneas por utilizador: se cinco consultas já estiverem em execução, as consultas adicionais são colocadas numa fila de simultaneidade por utilizador até terminar uma consulta em execução.
  • Tempo na fila de simultaneidade: se uma consulta estiver na fila de simultaneidade durante mais de três minutos, será terminada e será devolvido um código de erro 429.
  • Limite de profundidade da fila de simultaneidade: a fila de simultaneidade está limitada a 200 consultas e as consultas adicionais serão rejeitadas com um código de erro 429.
  • Limite de taxa de consulta: existe um limite por utilizador de 200 consultas por 30 segundos em todas as áreas de trabalho.

• Os pacotes de consultas são recursos do Azure Resource Manager, que podem ser utilizados para proteger e recuperar consultas de registo se a área de trabalho do Log Analytics não estiver disponível.

  • Os pacotes de consultas contêm consultas como JSON e podem ser armazenados externos ao Azure de forma semelhante a outros recursos de infraestrutura como código.
    • Implementável através da API REST Microsoft.Insights.
    • Se uma área de trabalho do Log Analytics tiver de ser recriada, o pacote de consultas pode ser reimplementado a partir de uma definição armazenada externamente.

• O Application Insights pode ser implementado num modelo de implementação baseado na área de trabalho, suportado por uma área de trabalho do Log Analytics onde todos os dados são armazenados.

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

• Todos os dados recolhidos pelo Azure Monitor, incluindo o Application Insights, são cobrados com base no volume de dados ingeridos e na duração da retenção dos dados.

  • Os dados ingeridos numa área de trabalho do Log Analytics podem ser retidos sem custos adicionais até aos primeiros 31 dias (90 dias se o Sentinel estiver ativado)
  • Os dados ingeridos num Application Insights baseado numa área de trabalho são retidos durante os primeiros 90 dias sem custos adicionais.

• O modelo de preços do escalão de alocação do Log Analytics fornece um custo reduzido e uma abordagem previsível aos custos de ingestão de dados.

  • Qualquer utilização acima do nível de reserva é faturada pelo mesmo preço que o escalão atual.

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

• As consultas do Log Analytics são guardadas como funções na área de trabalho do Log Analytics (savedSearches).

Recomendações de conceção

• Utilize a área de trabalho do Log Analytics como um sink de dados unificado para fornecer um "único painel" em todos os conjuntos de dados operacionais.

  • Descentralizar áreas de trabalho do Log Analytics em todas as regiões de implementação utilizadas. Cada região do Azure com uma implementação de aplicação deve considerar uma área de trabalho do Log Analytics para recolher todos os dados operacionais provenientes dessa região. Todos os recursos globais devem utilizar uma área de trabalho do Log Analytics dedicada separada, que deve ser implementada numa região de implementação primária.
    • Enviar todos os dados operacionais para uma única área de trabalho do Log Analytics criaria um único ponto de falha.
    • Os requisitos de residência dos dados podem proibir os dados que saem da região de origem e as áreas de trabalho federadas resolvem este requisito por predefinição.
    • Existe um custo de saída substancial associado à transferência de registos e métricas entre regiões.
  • Todos os selos de implementação na mesma região podem utilizar a mesma área de trabalho regional do Log Analytics.

• Considere configurar recursos com várias definições de diagnóstico que apontam para diferentes áreas de trabalho do Log Analytics para proteger contra a indisponibilidade do Azure Monitor para aplicações com menos carimbos de implementação regionais.

• Utilize o Application Insights como uma ferramenta consistente de Monitorização do Desempenho de Aplicações (APM) em todos os componentes da aplicação para recolher registos de aplicações, métricas e rastreios.

  • Implemente o Application Insights numa configuração baseada na área de trabalho para garantir que cada área de trabalho regional do Log Analytics contém registos e métricas de componentes da aplicação e recursos subjacentes do Azure.

• Utilize consultas entre áreas de trabalho para manter um "painel único" unificado nas diferentes áreas de trabalho.

• Utilize pacotes de consultas para proteger as consultas de registo em caso de indisponibilidade da área de trabalho.

  • Armazene pacotes de consultas no repositório git da aplicação como recursos de infraestrutura como código.

• Todas as áreas de trabalho do Log Analytics devem ser tratadas como recursos de execução prolongada com um ciclo de vida diferente para os recursos da aplicação num carimbo de implementação regional.

• Exporte dados operacionais críticos da área de trabalho 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 estado de funcionamento subjacente e informar a ação preditiva.

• Avalie cuidadosamente que arquivo de dados deve ser utilizado para retenção de longo prazo; nem todos os dados têm de ser armazenados num arquivo de dados frequente e queificável.

  • Recomenda-se vivamente que utilize o Armazenamento do Azure numa configuração GRS para armazenamento de dados operacional a longo prazo.
    • Utilize a capacidade de exportação da área de trabalho do Log Analytics para exportar todas as origens de dados disponíveis para o Armazenamento do Azure.

• Selecione períodos de retenção adequados para tipos de dados operacionais na análise de registos, configurando períodos de retenção mais longos na área de trabalho onde existem requisitos de observabilidade "frequentes".

• Utilize Azure Policy para garantir que todos os recursos regionais encaminham dados operacionais para a área de trabalho correta do Log Analytics.

Nota

Ao implementar numa zona de destino do Azure, se existir um requisito para o armazenamento centralizado de dados operacionais, pode criar forks de dados em instâncias para que sejam ingeridos em ferramentas centralizadas e áreas de trabalho do Log Analytics dedicadas à aplicação. Em alternativa, exponha o acesso às áreas de trabalho do Log Analytics da aplicação para que as equipas centrais possam consultar os dados da aplicação. Em última análise, é fundamental que os dados operacionais provenientes da solução estejam disponíveis nas áreas de trabalho do Log Analytics dedicadas à aplicação.

Se for necessária integração SIEM, não envie entradas de registo não processadas, mas envie alertas críticos.

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

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

• Utilize IDs de correlação para todos os eventos de rastreio e mensagens de registo para as associar a um determinado pedido.

  • Devolver IDs de correlação ao autor da chamada para todas as chamadas e não apenas pedidos falhados.

• Certifique-se de que o código da aplicação incorpora instrumentação e registo adequados para informar o modelo de estado de funcionamento e facilitar a resolução de problemas subsequente ou a análise da causa raiz, quando necessário.

  • O código da aplicação deve utilizar o Application Insights para facilitar o Rastreio Distribuído, ao fornecer ao autor da chamada uma mensagem de erro abrangente que inclui um ID de correlação quando ocorre uma falha.

• Utilize o registo estruturado para todas as mensagens de registo.

• Adicione sondas de estado de funcionamento significativas a todos os componentes da aplicação.

  • Ao utilizar o AKS, configure os pontos finais de estado de funcionamento para cada implementação (pod) para que o Kubernetes possa determinar corretamente quando um pod está em bom estado de funcionamento ou em mau estado de funcionamento.
  • Ao utilizar Serviço de Aplicações do Azure, configure as Verificações de Estado de Funcionamento para que as operações de aumento horizontal não causem erros ao enviar tráfego para instâncias que ainda não estão prontas e garantir que as instâncias em mau estado de funcionamento são recicladas rapidamente.

Se a aplicação estiver subscrita no Suporte do Microsoft Mission-Critical, considere expor as principais pesquisas de estado de funcionamento a Suporte da Microsoft, para que o estado de funcionamento da aplicação possa ser modelado com mais precisão Suporte da Microsoft.

• Registe pedidos de verificação de estado de funcionamento bem-sucedidos, a menos que não seja possível tolerar o aumento dos volumes de dados no contexto do desempenho da aplicação, uma vez que fornecem informações adicionais para a modelação analítica.

• Não configure áreas de trabalho do Log Analytics de produção para aplicar um limite diário, o que limita a ingestão diária de dados operacionais, uma vez que tal 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 poupança de custos.

• Os volumes de ingestão de dados operacionais fornecidos cumprem o limiar de escalão mínimo, configure as áreas de trabalho do Log Analytics para utilizar os preços baseados no escalão de alocação para impulsionar as eficiências de custos relativamente ao modelo de preços "pay as you go".

• Recomenda-se vivamente armazenar consultas do Log Analytics com o controlo de origem e utilizar a automatização CI/CD para implementá-las em instâncias relevantes da área de trabalho do Log Analytics.

Visualização

Representar visualmente o modelo de estado de funcionamento com dados operacionais críticos é essencial para alcançar operações eficazes e maximizar a fiabilidade. Os dashboards devem, em última análise, ser utilizados para fornecer informações quase em tempo real sobre o estado de funcionamento da aplicação para as equipas de DevOps, facilitando o rápido diagnóstico de desvios do estado estável.

A Microsoft fornece várias tecnologias de visualização de dados, incluindo Dashboards do Azure, Power BI e Azure Managed Grafana (atualmente em pré-visualização). Os Dashboards do Azure estão posicionados para fornecer uma solução de visualização integrada totalmente integrada para dados operacionais no Azure Monitor. Por conseguinte, tem um papel fundamental a desempenhar na representação visual dos dados operacionais e do estado de funcionamento da aplicação para uma carga de trabalho crítica para a missão. No entanto, existem várias limitações em termos do posicionamento dos Dashboards do Azure como uma plataforma holística de observabilidade e, como resultado, deve ser considerada a utilização suplementar de soluções de observabilidade líderes no mercado, como o Grafana, que também é fornecido como uma solução gerida no Azure.

Esta secção centra-se na utilização dos Dashboards do Azure e do Grafana para criar uma experiência de dashboard robusta capaz de fornecer lentes técnicas e empresariais para o estado de funcionamento da aplicação, permitindo equipas de DevOps e funcionamento eficaz. O dashboarding robusto é essencial para diagnosticar problemas que já ocorreram e suportar as equipas operacionais na deteção e resposta a problemas à medida que acontecem.

Considerações de design

• Ao visualizar o modelo de estado de funcionamento através de consultas de registo, tenha em atenção que existem limites do Log Analytics em consultas simultâneas e em fila, bem como a taxa de consulta geral, com consultas subsequentes colocadas em fila e limitadas.

• As consultas para obter dados operacionais utilizados para calcular e representar classificações de estado de funcionamento podem ser escritas 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 têm de ser concebidos para quando conceber dashboards operacionais.

• A visualização de métricas de recursos não processados, como a utilização da CPU ou o débito de rede, requer uma avaliação manual por parte das equipas de operações para determinar os impactos no estado de funcionamento, o que pode ser desafiante durante um incidente ativo.

• Se vários utilizadores utilizarem dashboards numa ferramenta como o Grafana, o número de consultas enviadas para o Log Analytics multiplica-se rapidamente.

  • Atingir o limite de consultas simultâneas no Log Analytics colocará em fila as consultas subsequentes, fazendo com que a experiência do dashboard se sinta "lenta".

Recomendações de Estrutura

• Recolha e apresente saídas consultadas de todas as Áreas de Trabalho regionais do Log Analytics e da Área de Trabalho do Log Analytics global para criar uma vista unificada do estado de funcionamento da aplicação.

Nota

Se implementar numa zona de destino do Azure, considere consultar a área de trabalho do Log Analytics da plataforma central se existirem dependências chave nos recursos da plataforma, como o ExpressRoute para comunicação no local.

• Um modelo de "semáforo" deve ser utilizado para representar visualmente estados "em bom estado de funcionamento" e "em mau estado de funcionamento", com verde utilizado para ilustrar quando os principais requisitos não funcionais estão totalmente satisfeitos e os recursos são utilizados de forma ideal. Utilize os estados "Verde", "Âmbar e "Vermelho" para representar os estados "Saudável", "Degradado" e "Indisponível".

• Utilize os Dashboards do Azure para criar lentes operacionais para recursos globais e selos de implementação regionais, representando métricas-chave, como a contagem de pedidos para o Azure Front Door, a latência do lado do servidor para o Azure Cosmos DB, mensagens de entrada/saída para Hubs de Eventos e a utilização da CPU ou os estados de implementação do AKS. Os dashboards devem ser adaptados para impulsionar a eficácia operacional, infundindo aprendizagens de cenários de falha para garantir que as equipas do DevOps têm visibilidade direta sobre as principais métricas.

• Se os Dashboards do Azure não puderem ser utilizados para representar com precisão o modelo de estado de funcionamento e os requisitos de negócio necessários, recomenda-se vivamente que considere o Grafana como uma solução de visualização alternativa, fornecendo capacidades líderes de mercado e um extenso ecossistema de plug-in open source. Avalie a oferta de pré-visualização gerida do Grafana para evitar as complexidades operacionais da gestão da infraestrutura do Grafana.

• Ao implementar o Grafana autoalojado, utilize um design altamente disponível e geográfico para garantir que dashboards operacionais críticos podem ser resilientes a falhas na plataforma regional e cenários de erro em cascata.

  • Separe o estado de configuração num arquivo de dados externo, como a Base de Dados do Azure para Postgres ou MySQL, para garantir que os nós da aplicação Grafana permanecem sem estado.

    • Configurar a replicação de base de dados entre regiões de implementação.

  • Implemente nós do Grafana nos Serviços de Aplicações numa configuração de elevada disponibilidade numa região, através de implementações baseadas em contentores.

    • Implementar Serviço de Aplicações instâncias em regiões de implementação consideradas.

    Os Serviços de Aplicações fornecem uma plataforma de contentores de baixa fricção, ideal para cenários de baixa escala, como dashboards operacionais, e isolar o Grafana do AKS proporciona uma clara separação de preocupação entre a plataforma de aplicações primária e as representações operacionais para essa plataforma. Consulte a área Deign da Plataforma de Aplicações para obter mais recomendações de configuração.

  • Utilize o Armazenamento do Azure numa configuração GRS para alojar e gerir elementos visuais e plug-ins personalizados.

  • Implemente componentes do Grafana do serviço de aplicações e da réplica de base de dados num mínimo de duas regiões de implementação e considere utilizar um modelo em que o Grafana é implementado em todas as regiões de implementação consideradas.

Para cenários direcionados para um >SLO = 99,99%, o Grafana deve ser implementado num mínimo de 3 regiões de implementação para maximizar a fiabilidade geral dos principais dashboards operacionais.

• Mitigar os limites de consultas do Log Analytics ao agregar consultas num único ou pequeno número de consultas, como utilizar o operador "union" do KQL e definir uma taxa de atualização adequada no dashboard.

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

• Se o limite de consultas simultâneo do Log Analytics estiver a ser atingido, considere otimizar o padrão de obtenção ao armazenar (temporariamente) os dados necessários para o dashboard num arquivo de dados de elevado desempenho, como SQL do Azure.

Resposta automatizada a incidentes

Embora as representações visuais do estado de funcionamento da aplicação forneçam informações operacionais e empresariais inestimáveis para suportar a deteção e diagnóstico de problemas, baseia-se na preparação e interpretações das equipas operacionais, bem como na eficácia das respostas subsequentes acionadas pelo homem. Por conseguinte, para maximizar a fiabilidade, é necessário implementar alertas extensivos para detetar proativamente e responder a problemas quase em tempo real.

O Azure Monitor fornece uma arquitetura de alerta extensiva para detetar, categorizar e responder a sinais operacionais através de Grupos de Ações. Por conseguinte, esta secção irá focar-se na utilização de alertas do Azure Monitor para impulsionar ações automatizadas em resposta a desvios atuais ou potenciais de um estado de aplicação em bom estado de funcionamento.

Importante

Os alertas e as ações automatizadas são fundamentais para detetar e responder rapidamente aos problemas à medida que ocorrem, antes que possa ocorrer um maior impacto negativo. Os alertas também fornecem um mecanismo para interpretar os sinais recebidos e responder para evitar problemas antes de ocorrerem.

Considerações de design

• As regras de alerta são definidas para serem acionadas quando são cumpridos critérios condicionais para sinais de entrada, que podem incluir várias origens de dados, como métricas, consultas de registo 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, uma vez que nem todos os pontos de dados de diagnóstico são disponibilizados no Log Analytics.

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

• Existem limites de subscrição relacionados com alertas e grupos de ações, que têm de ser concebidos 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 utilização extrema.
  • Os Grupos de Ações têm vários limites rígidos para o número de respostas configuráveis, que têm de ser concebidas para.
    • Cada tipo de resposta tem um limite de 10 ações, para além do e-mail, que tem um limite de 1000 ações.

• Os alertas podem ser integrados num modelo de estado de funcionamento em camadas ao criar uma Regra de Alerta para uma consulta de pesquisa de registos guardada a partir da função de classificação "raiz" do modelo. Por exemplo, utilizar "WebsiteHealthScore" e alertar sobre um valor numérico que representa um estado "Em mau estado de funcionamento".

Recomendações de conceção

• 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 ações automatizadas num número mínimo de Grupos de Ações, alinhadas com as equipas de serviço para suportar uma abordagem de DevOps.

• Responda a sinais de utilização excessiva de recursos através de operações de dimensionamento automatizado, utilizando capacidades de dimensionamento automático nativo do Azure sempre que possível. Quando a funcionalidade de dimensionamento automático incorporada não for aplicável, utilize a classificação de estado de funcionamento do componente para modelar sinais e determinar quando responder com operações de dimensionamento automatizadas. Certifique-se de que as operações de dimensionamento automatizado são definidas de acordo com um modelo de capacidade, que quantifica as relações de dimensionamento entre componentes, para que as respostas de dimensionamento abranjam componentes que precisam de ser dimensionados em relação a outros componentes.

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

• Utilize a API de Alertas do Azure Monitor para recolher 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 recebidos com uma resposta automatizada, certifique-se de que a "automatização do runbook" operacional está no local para impulsionar uma ação rápida e consistente assim que a interpretação manual e o fim de sessão forem fornecidos. Utilizar notificações de alerta para impulsionar a identificação rápida de problemas que requerem interpretação manual

• Crie licenças em sprints de engenharia para impulsionar melhorias incrementais em alertas para garantir que novos cenários de falha que não tenham sido considerados anteriormente podem 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 implementaçã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 recolher informações críticas relacionadas com a filtragem de alertas excessivos de "ruído" e a previsão de problemas antes de causarem impacto, bem como acelerar a resposta a incidentes quando o fazem.

Mais especificamente, uma metodologia do AIOps pode ser aplicada a informações críticas sobre o comportamento dos processos de sistema, utilizadores e DevOps. Estas informações podem incluir a identificação de um problema que está a ocorrer agora (detetar), quantificar o motivo pelo qual o problema está a acontecer (diagnosticar) ou sinalizar o que vai acontecer no futuro (prever). Estas informações podem ser utilizadas para impulsionar ações que ajustam e otimizam a aplicação para mitigar problemas ativos ou potenciais, utilizando as principais métricas empresariais, as métricas de qualidade do sistema e as métricas de produtividade do DevOps, para priorizar de acordo com o impacto empresarial. As ações realizadas podem ser infundidas no sistema através de um ciclo de comentários que prepara ainda mais o modelo subjacente para impulsionar eficiências adicionais.

Existem várias tecnologias analíticas no Azure, como o Azure Synapse e o Azure Databricks, que podem ser utilizadas para criar e preparar modelos analíticos para o AIOps. Por conseguinte, esta secção irá focar-se na forma como estas tecnologias podem ser posicionadas numa estrutura de aplicação para acomodar o AIOps e impulsionar a ação preditiva, focando-se em Azure Synapse que reduz o atrito ao reunir o melhor dos serviços de dados do Azure, juntamente com novas funcionalidades avançadas.

O AIOps é utilizado para impulsionar ações preditivas, interpretando e correlacionando sinais operacionais complexos observados durante um período sustentado, de modo a responder melhor e evitar problemas antes de ocorrerem.

Considerações de design

• Azure Synapse Analytics oferece várias capacidades de Machine Learning (ML).

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

• O Synapse Analytics está integrado no Azure ML através do Azure Synapse Notebooks, o que permite que os modelos de ML sejam preparados numa Área de Trabalho do Azure ML através do ML Automatizado.

• O Synapse Analytics também permite capacidades de ML com os Serviços Cognitivos do Azure para resolver problemas gerais em vários domínios, como a Deteção de Anomalias. Os Serviços Cognitivos podem ser utilizados em Azure Synapse, no Azure Databricks e através de SDKs e APIs REST em aplicações cliente.

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

• Azure Synapse permite o registo de conjuntos de dados externos para dados armazenados no armazenamento de Blobs do Azure ou Azure Data Lake Storage.

  • Os conjuntos de dados registados podem ser utilizados em tarefas de análise de dados do conjunto do Synapse Spark.

• O Azure Databricks pode ser integrado em pipelines do Azure Synapse Analytics para funcionalidades adicionais do Spark.

  • O Synapse orquestra a leitura de dados e o envio para um cluster do Databricks, onde podem ser transformados e preparados para a preparação de modelos de ML.

• Normalmente, os dados de origem têm de ser preparados para análise e ML.

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

• Os modelos de ML preparados, operacionalizados e implementados podem ser utilizados para classificação em lotes no Synapse.

  • Os cenários do AIOps, como a execução de predições de regressão ou degradação no pipeline ci/CD, podem exigir classificação em tempo real .

• Existem limites de subscrição para Azure Synapse, que devem ser totalmente compreendidos no contexto de uma metodologia do 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 de forma contínua.

  • As capacidades, como a deteção de anomalias, devem ser avaliadas no fluxo de dados de observabilidade.

Recomendações de conceção

• Certifique-se de que todos os recursos do Azure e componentes da aplicação estão totalmente instrumentados para que esteja disponível um conjunto de dados operacional completo para a preparação do modelo do AIOps.

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

• Utilize a API de Alertas do Azure Monitor para obter alertas históricos e armazená-lo no armazenamento a frio para que os dados operacionais sejam posteriormente utilizados nos modelos de ML. Se for utilizada a exportação de dados do Log Analytics, armazene dados de alertas históricos nas mesmas contas de Armazenamento do Azure que os dados exportados do Log Analytics.

• Depois de os dados ingeridos estarem preparados para a preparação de ML, escreva-os novamente no Armazenamento do Azure para que estejam disponíveis para preparação de modelos de ML sem que sejam necessários recursos de computação de preparação de dados do Synapse para serem executados.

• Certifique-se de que a operacionalização do modelo de ML suporta a classificação em lote e em tempo real.

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

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

Passo seguinte

Reveja as considerações de implementação e teste.

Implementação e teste