Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a esta recomendação de lista de verificação de confiabilidade do Azure Well-Architected Framework:
| RE:10 | Medir e acompanhar continuamente a integridade do sistema usando indicadores de tempo de atividade e confiabilidade entre componentes e fluxos críticos. Certifique-se de que esses dados sejam mantidos e acessíveis para dar suporte à detecção, resposta e análise pós-incidente oportuna. |
|---|
O monitoramento de confiabilidade é a prática de medir o quão bem um sistema atende aos seus requisitos de negócios ao longo do tempo, em relação à resiliência e à capacidade de recuperação. Um sistema de monitoramento bem projetado fornece exibição em tempo real e tendências de comportamento do sistema estabelecendo visibilidade entre camadas de plataforma, infraestrutura e carga de trabalho.
Ao correlacionar esses sinais entre componentes e ao longo do tempo, o monitoramento permite uma análise rápida e confiante de incidentes e interrupções. Crie uma abordagem estruturada para que os insights sejam significativos, os alertas conduzam as ações certas e os aprendizados retroalimentem a arquitetura e as operações.
As principais estratégias neste artigo baseiam-se na prática operacional fundamental da observabilidade, descrita nas estratégias de arquitetura do OE:07 para a criação de um sistema de monitoramento. As diretrizes sobre como implementar a prática de monitoramento estão disponíveis no Guia de Design de Monitoramento. Recomendamos revisar esses recursos primeiro.
Definições
| Term | Definição |
|---|---|
| SLA (contrato de nível de serviço) | Compromissos externos que você recebe de fornecedores ou que você faz aos seus clientes. Não atender a SLAs pode levar a penalidades financeiras, danos à reputação ou experiência degradada do usuário. |
| SLO (objetivos de nível de serviço) | Metas internas de desempenho e confiabilidade usadas para definir limites que disparam alertas e medem a integridade do sistema em relação aos objetivos de negócios. |
| Modelo de saúde | Uma representação hierárquica da condição do sistema usando estados de integridade claros (íntegros, degradados, não íntegros) com sinais em tempo real e capacidade de detalhamento do sistema geral para componentes individuais. |
| Carimbo | Uma unidade de implantação com limites de capacidade definidos, como limite máximo de usuários simultâneos, taxa de transferência ou utilização de recursos. Vários carimbos habilitam a distribuição regional e em escala horizontal. |
| FMA (análise do modo de falha) | Uma análise sistemática para identificar possíveis pontos de falha em um sistema, usada para orientar a estratégia de monitoramento e melhorias de confiabilidade. |
| RTO (objetivo de tempo de recuperação) | O tempo máximo aceitável para detectar, responder e se recuperar de uma falha ou incidente. |
| RPO (objetivo de ponto de recuperação) | A quantidade máxima aceitável de perda de dados medida no tempo, representando a quantidade de dados que podem ser perdidas durante um cenário de falha. |
| Transações sintéticas | Testes automatizados que simulam ações reais do usuário e interações de ponta a ponta para validar a integridade do sistema e detectar problemas da perspectiva do cliente, fornecendo validação externa da disponibilidade do sistema. |
| IDs de correlação | Identificadores exclusivos usados para rastrear transações e solicitações em vários serviços e componentes, permitindo identificação e análise de problemas em sistemas distribuídos. |
| Falhas transitórias | Falhas temporárias em dependências do sistema que normalmente se resolvem em um curto período de tempo, como tempos limite de rede ou indisponibilidade de serviço temporário. |
| Latência da cauda | O tempo de resposta experimentado pelas requisições mais lentas, normalmente medido em percentis altos (p95, p99), onde os problemas de desempenho geralmente aparecem primeiro. |
Monitorar a funcionalidade da carga de trabalho
Monitore o que seu sistema realmente fornece. Comece acompanhando se os fluxos de trabalho críticos são concluídos com êxito e produzem resultados válidos. Um sistema pode parecer íntegro enquanto ainda produz saídas incorretas ou incompletas, portanto, a execução por si só não é suficiente.
Por exemplo, se uma carga de trabalho gerar relatórios a cada seis horas, o monitoramento deverá confirmar duas coisas: que o trabalho foi executado como agendado e que produziu um resultado válido, como um relatório não vazio com conteúdo e tamanho esperados. Esse tipo de validação ajuda a garantir que o sistema não esteja apenas em execução, mas também fornecendo a funcionalidade para a qual ele foi projetado.
Monitorar a experiência do usuário
Monitore a confiabilidade de uma perspectiva comercial e do usuário. Como parte da FMA (análise do modo de falha), você já deve ter identificado os principais fluxos de usuário. Para cada fluxo, acompanhe como falhas em qualquer componente ou dependência afetam a experiência do usuário e o que o resultado esperado se torna. Por exemplo, em um fluxo de check-out de comércio eletrônico, uma interrupção ou sobrecarga de serviço em sistemas de pagamento ou inventário pode impedir que os clientes concatenem compras.
A confiabilidade também reflete a qualidade do serviço. Em um fluxo de check-out, os usuários devem ser capazes de concluir compras de ponta a ponta sem interrupção. Use métricas de latência baseadas em percentil, como p50, p95 e p99, para entender a experiência real do usuário, com atenção especial à latência final em que os problemas de desempenho geralmente aparecem primeiro.
Importante
O monitoramento de desempenho fornece uma visão de como seu sistema se comporta sob carga real, dividindo a latência de ponta a ponta entre as camadas do sistema. Ele conecta alterações de desempenho para que você possa entender o que influenciou uma mudança de comportamento. Isso pode ser devido a implantações, atualizações de configuração e eventos de dimensionamento. Juntos, a confiabilidade e o monitoramento de desempenho fornecem uma visão completa do comportamento do sistema e realçam onde a atenção focada terá o maior impacto. Para obter informações sobre o monitoramento de desempenho, consulte Monitor Performance.
Rastrear alvos de disponibilidade
Acompanhe o quão bem seu sistema atende às suas metas definidas para disponibilidade, taxa de transferência e tempos de resposta. Essas metas geralmente são formalizadas como SLAs (contratos de nível de serviço) e SLOs (objetivos de nível de serviço) e refletem as expectativas que você definiu com seus usuários. O monitoramento deles mantém a confiabilidade alinhada com os resultados reais dos negócios. Para obter mais informações, consulte destinos de confiabilidade e contratos de nível de serviço.
Concentre-se nos principais indicadores que contribuem para esses destinos e os acompanhem ao longo do tempo. Quando algo se desvia, você deve ser capaz de aprofundar nos componentes ou subsistemas específicos envolvidos. Capture todos os sinais relevantes, incluindo problemas mascarados por redundância ou failover, para que você possa entender o que realmente aconteceu e evitar ocorrências de repetição.
Combine a consciência em tempo real com o contexto histórico. Sinais em tempo real ajudam você a responder rapidamente quando os destinos estão em risco, enquanto tendências ao longo do tempo revelam padrões e problemas recorrentes. Classificar as causas das falhas em atingir metas e agregar essas métricas também suporta relatórios de SLA claros e auxilia na orientação de melhorias contínuas.
Monitore os principais SLAs fornecidos por seus fornecedores e serviços de plataforma (da Microsoft e de outros). Você deve:
- Acompanhar indicadores de possíveis violações de SLA em tempo real
- Capturar e reter as evidências necessárias para dar suporte à reclamação de SLA se ocorrer uma violação
Rastrear metas de recuperabilidade
Acompanhe a capacidade de recuperação tratando cada teste e incidente real como um evento mensurável. Use dados de monitoramento para validar que seu sistema e sua equipe podem atender aos objetivos de recuperação definidos em condições reais.
Medir sinais importantes, como tempo para detectar, responder e recuperar (RTO), juntamente com a exposição à perda de dados (RPO). Inclua indicadores como preparação e capacidade de failover, taxas de sucesso de failover e tempo de execução, sucesso de backup e restauração, retardo de replicação e quanta intervenção manual é necessária.
Essas métricas também destacam lacunas operacionais, como procedimentos não claros, atrasos de decisão ou documentação difícil de acessar, o que pode afetar o desempenho da recuperação. Use esses insights para fortalecer o design do sistema e as práticas de resposta a incidentes.
Note
Tenha cuidado para que as políticas de limpeza ou retenção não sejam tão agressivas que deletem logs ou dados de telemetria justamente quando você mais precisar deles. Para cada cenário, pergunte: Quais dados precisaríamos para entender o que aconteceu antes e durante o incidente? Uma abordagem útil é pensar com antecedência em diferentes tipos de investigações pós-incidente, como:
- Interrupções de plataforma ou infraestrutura
- Problemas de disponibilidade do aplicativo (por exemplo, após uma implantação ou alteração de configuração)
- Bugs de aplicativo que causam perda ou corrupção de dados
- Incidentes de segurança
Tornar alertas acionáveis com um modelo de saúde
Projete alertas para que eles claramente apontem para algo que mereça uma ação e os baseie em um modelo de saúde que represente o sistema usando estados simples como saudável, degradado e não saudável.
Estruture o modelo de integridade hierarquicamente, desde componentes individuais até o sistema completo, para que você possa rastrear rapidamente os problemas até a origem. Defina limites usando SLOs (objetivos de nível de serviço) e combine sinais como métricas, logs, rastreamentos e verificações sintéticas para criar uma imagem confiável da integridade do sistema. Isso fornece aos operadores uma visão clara do que está funcionando, do que não está e de onde agir sem pesquisar dados brutos. Para obter mais informações, consulte o guia de design sobre modelagem de saúde.
Ajuste alertas para condições reais concentrando-se na experiência de ponta a ponta e em transações críticas, para que reflitam o impacto real do usuário. Reduza o ruído ao considerar flutuações transitórias e acionar em alterações significativas de estado de saúde, em vez de picos ou oscilações isoladas. Combine alertas em tempo real com insights de tendência para capturar problemas imediatos e degradação gradual, ajudando as equipes a responder rapidamente e manter o foco.
Risco: a modelagem de integridade do sistema requer coletar sinais significativos em todo o sistema. Depender apenas de métricas simples, como CPU ou memória, pode perder o que realmente importa. Inclua dados de experiência do usuário e verificações sintéticas para obter uma exibição completa. Definir "saudável" necessita de alinhamento, e limites mal ajustados podem criar ruído e reduzir a eficácia.
Monitorar todas as camadas do sistema
Monitore cada camada do sistema, aplicativo, dados/armazenamento e rede para manter uma visão completa dos sinais de confiabilidade.
Na camada do aplicativo, acompanhe o êxito, a falha e a latência usando logs, métricas e investigações de integridade. Use IDs de correlação para seguir solicitações entre serviços e facilitar a solução de problemas. Colete logs de forma assíncrona para que eles não afetem o desempenho da solicitação e mantenham os logs de diagnóstico e auditoria separados para maior clareza. Adicione transações sintéticas e sondas de endpoint para confirmação do que os clientes realmente experimentam.
Troca. Escolher entre o log assíncrono e síncrono envolve um equilíbrio entre o desempenho e a confiabilidade da telemetria.
O registro de log assíncrono mantém o processo de registro fora do caminho crítico, reduzindo a latência e melhorando o desempenho do sistema. No entanto, ele introduz um risco de perda de telemetria, especialmente se ocorrer uma falha antes que os logs sejam liberados ou persistidos.
O registro em log síncrono garante que os logs sejam gravados antes de continuar o processamento, o que melhora a durabilidade e a auditabilidade dos dados. A compensação é uma latência maior e um acoplamento mais apertado entre o desempenho do aplicativo e o sistema de registro em log.
Na maioria dos cenários, o registro em log assíncrono é a abordagem preferencial devido ao seu impacto mínimo no desempenho. No entanto, em ambientes fortemente regulamentados ou sensíveis à auditoria, o registro em log síncrono pode ser necessário para garantir que eventos críticos sejam capturados de forma confiável.
Na camada de dados e armazenamento, concentre-se na disponibilidade, nas taxas de sucesso de gravação, na latência da consulta, nos tempos limite, nos bloqueios e na pressão do recurso. Examine as tendências ao longo do tempo para identificar gargalos crescentes e distinguir questões de curta duração da degradação sustentada.
Na camada de rede, monitore a conectividade, a latência, a perda de pacotes, a largura de banda e os padrões de tráfego. Combine logs de fluxo, verificações de ponto de extremidade e testes sintéticos para identificar problemas de roteamento, anomalias ou comportamentos relacionados à segurança. Conecte esses sinais de volta aos dados do aplicativo e da plataforma para entender a origem dos problemas.
Os logs operacionais ajudam a diagnosticar problemas, acompanhar o desempenho e entender o comportamento do sistema. Eles não foram projetados para servir como uma fonte de verdade para eventos de negócios, auditoria ou relatórios regulatórios, que normalmente exigem uma rastreabilidade mais forte.
O que monitorar em detalhes para cada camada é abordado no Guia de Design de Monitoramento.
Definir e monitorar a capacidade do carimbo
Defina limites de capacidade claros para cada unidade de implantação ou carimbo e monitore-os de perto. Cada selo opera dentro de um teto finito, seja máximos usuários simultâneos, largura de banda ou limite de utilização de recursos. Portanto, tornar esses limites explícitos lhe dará uma linha de base confiável para a tomada de decisões.
Essa visibilidade ajuda você a identificar quando um selo está se aproximando da saturação, bem antes de afetar a confiabilidade. Ele também dá suporte a decisões de expansão em tempo hábil, como adicionar novos selos ou redistribuir carga, e confirma que o tráfego está fluindo de acordo com seu design.
Definir esses limites nem sempre é simples. A capacidade pode ser difícil de medir, especialmente quando depende de vários serviços subjacentes com diferentes características de dimensionamento. Você deve usar as diretrizes da plataforma, como cotas e limites do Microsoft Azure, como ponto de partida. Na prática, a capacidade geralmente é determinada por meio de teste de carga, observação e ajuste iterativo em vez de modelagem inicial precisa.
Monitorar a distribuição de carga entre instâncias redundantes
Quando você executa a carga de trabalho em várias instâncias redundantes, incluindo quando distribui instâncias em diferentes regiões ou zonas, o tráfego e o uso de recursos devem permanecer equilibrados entre essas instâncias.
Você deseja detectar desequilíbrios que geralmente apontam para problemas de roteamento, problemas de configuração ou restrições de dependência. Ele também garante que os destinos de failover tenham capacidade suficiente para absorver o tráfego quando necessário e confirma que os mecanismos de redundância se comportam conforme o esperado durante cenários de operação normal e de falha.
Detectar modos de falha
Como parte do exercício de FMA (análise de modo de falha), você deve ter identificado os possíveis pontos de falha.
Na prática de monitoramento de confiabilidade, mantenha a vigilância contínua nesses pontos. Comece focando em sinais mais simples, como falhas transitórias. Monitore o comportamento de repetição e as taxas de falha transitórias para entender como suas dependências e serviços subjacentes se comportam em condições operacionais reais. Esses sinais fornecem uma visão inicial da instabilidade emergente. Eles ajudam você a reconhecer quando os padrões de repetição se afastam da norma esperada, mantêm uma noção de se o sistema está se mantendo íntegro sob carga e identificam quando uma dependência ou serviço externo começa a se degradar antes que isso afete a experiência do usuário.
Inclua também falhas de impacto maiores, como interrupções de zona de disponibilidade que afetam um subconjunto de infraestrutura, interrupções de serviço ou interrupções regionais que coloquem toda uma região do Azure offline. Observe até mesmo cenários de segurança, como DDoS ou outra atividade mal-intencionada, configuração incorreta do componente e problemas de desempenho, pois cada um deles pode afetar a confiabilidade geral da solução.
Para obter informações sobre o FMA, consulte estratégias de arquitetura para análise de modo de falha.
Ser informado sobre o status de confiabilidade da plataforma
Você precisa de uma visão clara sobre a integridade da plataforma para gerenciar a confiabilidade com eficiência. Esse reconhecimento ajuda você a determinar rapidamente se um problema se origina em sua carga de trabalho ou na plataforma de nuvem subjacente.
Azure Service Health fornece visibilidade do estado do Azure. Configure alertas no Service Health para que você receba notificações quando houver alterações nas condições da plataforma. Você recebe atualizações sobre interrupções ativas que afetam seus recursos, eventos de manutenção planejada que podem introduzir interrupções e degradações regionais ou específicas do serviço.
Suporte ao Azure
Incorpore serviços de monitoramento e alerta de plataforma de nuvem, incluindo:
Integridade no nível da plataforma, como Azure Service Health.
Integridade no nível do recurso, como Azure Resource Health.
O Azure Monitor é uma solução de monitoramento abrangente usada para coletar, analisar e responder a dados de monitoramento de seus ambientes locais e de nuvem.
O Log Analytics é uma ferramenta no portal do Azure usada para editar e executar consultas de log em dados no workspace do Log Analytics.
Application Insights é uma extensão de Azure Monitor. Ele fornece recursos de monitoramento de desempenho de aplicativos (APM).
Os insights do Azure Monitor são ferramentas de análise avançada que ajudam a monitorar os serviços do Azure, como máquinas virtuais, serviços de aplicativos e contêineres. Os insights são criados com base no Azure Monitor e no Log Analytics.
Azure Monitor para Soluções SAP é um produto de monitoramento nativo do Azure para cenários SAP executados no Azure.
O monitor de conexão é uma ferramenta para acompanhar continuamente a conectividade de rede e o desempenho entre os recursos do Azure. Ele executa testes sintéticos e fornece alertas e diagnósticos em tempo real para detectar falhas antecipadamente. Você pode criar pastas de trabalho personalizadas para visualizar a integridade da conectividade e as métricas de desempenho agregadas.
Os logs de fluxo de rede virtual podem ser habilitados entre cargas de trabalho para monitorar o tráfego de rede. A análise de tráfego pode ser usada para analisar e enriquecer esses logs de fluxo para obter informações de superfície, como tráfego bloqueado, fluxos mal-intencionados e portas ativas expostas à Internet. A criação de pastas de trabalho permite que as equipes monitorem o comportamento de tráfego ao vivo e recebam alertas. Use exibições de linha do tempo e visualizações de topologia para monitorar facilmente padrões de tráfego que podem indicar degradação de desempenho ou ameaças à segurança.
Para obter várias práticas recomendadas de workspace, consulte Projetar uma arquitetura de workspace do Log Analytics.
Example
Para obter exemplos de soluções de monitoramento do mundo real, consulte Monitoramento de aplicativos Web no Azure e Arquitetura de linha de base para um cluster do Serviço de Kubernetes do Azure.
Links da comunidade
- Os Alertas de Linha de Base do Azure Monitor (AMBA) são um repositório central de definições de alerta que clientes e parceiros podem usar para melhorar sua experiência de observabilidade por meio da adoção do Azure Monitor.
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.