Práticas recomendadas para monitoramento e diagnóstico

Aplicativos e serviços distribuídos executados na nuvem são peças complexas de software que compreendem muitas partes móveis. Em um ambiente de produção, é importante acompanhar como os clientes usam seu sistema, rastrear a utilização de recursos e monitorar a integridade e o desempenho do seu sistema. Você pode usar essas informações para detectar e corrigir problemas e capturar possíveis problemas antes que eles ocorram.

Cenários de monitoramento e diagnóstico

Você pode usar o monitoramento para obter informações sobre como um sistema funciona bem. O monitoramento é uma parte crucial da manutenção de metas de QoS (qualidade do serviço). Colete dados de monitoramento para os seguintes cenários comuns:

• Verifique se o sistema permanece íntegro.

• Acompanhe a disponibilidade do sistema e seus componentes.

• Mantenha o desempenho para garantir que a taxa de transferência do sistema não degrade inesperadamente à medida que o volume de trabalho aumenta.

• Garanta que o sistema atenda aos SLAs (contratos de nível de serviço).

• Proteja a privacidade e a segurança do sistema, dos usuários e de seus dados.

• Acompanhe a auditoria ou as operações regulatórias.

• Monitore o uso diário do sistema e resolva tendências que podem levar a problemas.

• Acompanhe os problemas que ocorrem, desde o relatório inicial até a análise de possíveis causas, retificação, atualizações de software e implantação.

• Rastreie operações e depure lançamentos de software.

As seções a seguir descrevem esses cenários com mais detalhes.

Monitoramento de saúde

Um sistema saudável está em execução e pode processar solicitações. Use o monitoramento de integridade para gerar um instantâneo da integridade atual do sistema para que você possa verificar se todos os componentes funcionam conforme o esperado.

Configurar alertas

O sistema deve emitir um alerta em poucos segundos se qualquer componente apresentar falha. Os alertas podem realçar a integridade do sistema por meio de sinais de semáforo:

• Vermelho para não íntegro (o sistema parou)
• Amarelo para parcialmente saudável (o sistema opera com funcionalidade reduzida)
• Verde para saudável

Um sistema abrangente de monitoramento de integridade mostra o status de integridade de cada subsistema e componente para que você possa determinar quais partes estão funcionando normalmente e quais partes estão enfrentando problemas.

Coletar dados de saúde

As seguintes fontes podem gerar os dados brutos necessários para dar suporte ao monitoramento da integridade:

• Rastreie a execução de solicitações de usuário. Você pode usar essas informações para determinar quais solicitações têm êxito ou falha e medir quanto tempo cada solicitação leva.

• Monitore usuários sintéticos. Esse processo simula as ações executadas por um usuário e segue uma série predefinida de etapas. Capture os resultados de cada etapa.

• Registrar exceções, falhas e avisos. Você pode capturar essas informações de instruções de rastreamento inseridas no código do aplicativo e nos logs de eventos de serviços que o sistema faz referência.

• Monitore a saúde dos serviços que não são da Microsoft usados pelo sistema. Talvez seja necessário recuperar e analisar os dados de saúde fornecidos por esses serviços.

• Monitore terminais.

• Colete informações de desempenho ambiente, como utilização de CPU em segundo plano ou operações de E/S (entrada/saída), incluindo atividade de rede.

Analisar dados de saúde

O foco principal do monitoramento de saúde é indicar rapidamente se o sistema está operacional. A análise em tempo real dos dados pode acionar um alerta se um componente crítico estiver em mau funcionamento.

Um sistema mais avançado pode incluir um elemento preditivo que executa uma análise a frio em cargas de trabalho recentes e atuais. Uma análise a frio pode identificar tendências e determinar se o sistema provavelmente permanecerá íntegro ou precisa de mais recursos. Baseie esse elemento preditivo nas seguintes métricas críticas de desempenho:

• A taxa de solicitações direcionadas a cada serviço ou subsistema
• Os tempos de resposta dessas solicitações
• O volume de dados que flui para dentro e para fora de cada serviço

Se o valor de qualquer métrica exceder um limite definido, o sistema poderá gerar um alerta para escalar verticalmente. Você também pode adicionar recursos, reiniciar serviços com falha ou limitar solicitações de prioridade mais baixa para manter a integridade do sistema.

Monitoramento de disponibilidade

Em um sistema íntegro, todos os componentes e subsistemas estão disponíveis. O monitoramento de disponibilidade está intimamente relacionado ao monitoramento de saúde. O monitoramento de integridade fornece uma visão imediata da integridade atual do sistema. O monitoramento de disponibilidade controla a disponibilidade do sistema e seus componentes para gerar estatísticas sobre o tempo de atividade.

Em muitos sistemas, alguns componentes, como bancos de dados, são configurados com redundância interna para permitir failover rápido se ocorrer uma falha grave ou perda de conectividade. Reúna o máximo de informações possível sobre essas falhas para determinar a causa e executar ações corretivas para evitar a recorrência.

Os dados necessários para acompanhar a disponibilidade podem depender de vários fatores de nível inferior que podem ser específicos para o aplicativo, o sistema e o ambiente. Um sistema de monitoramento eficaz captura os dados de disponibilidade que correspondem a esses fatores de baixo nível e os agrega para fornecer uma imagem geral do sistema. Por exemplo, em um sistema de comércio eletrônico, a funcionalidade de negócios que permite que um cliente faça pedidos pode depender do repositório que armazena detalhes do pedido e do sistema de pagamento que manipula transações monetárias. A disponibilidade do recurso de posicionamento do pedido depende da disponibilidade do repositório e do subsistema de pagamento.

A solução de monitoramento de disponibilidade fornece exibições atuais e históricas do status de disponibilidade de cada subsistema. Ele alerta rapidamente quando um ou mais serviços falham ou quando os usuários não podem se conectar aos serviços. Use essas informações para identificar tendências que podem causar falha nos subsistemas. Por exemplo, você pode usar dados de disponibilidade para detectar quais serviços falham durante o horário de processamento de pico.

Coletar dados de disponibilidade

Monitore usuários sintéticos, registre exceções, falhas e avisos, e monitore os pontos de extremidade para gerar os dados brutos necessários para oferecer suporte ao monitoramento da disponibilidade. O aplicativo pode expor um ou mais pontos de extremidade de integridade em que cada um testa o acesso a uma área funcional dentro do sistema. O sistema de monitoramento segue uma programação definida para enviar pings a cada endpoint e coletar os resultados, como sucesso ou falha.

Registre todas as expirações de tempo, falhas de conectividade de rede e tentativas de reconexão, e registre a data e a hora de todos os dados.

Analisar dados de disponibilidade

Agregar e correlacionar os dados para dar suporte aos seguintes tipos de análise:

• A disponibilidade imediata do sistema e dos subsistemas.

• As taxas de falha de disponibilidade do sistema e dos subsistemas. Correlacionar falhas com atividades específicas para entender as causas da falha do sistema.

• Uma exibição histórica das taxas de falha em um período especificado e a carga no sistema, como o número de solicitações de usuário, quando ocorre uma falha.

• Os motivos para a indisponibilidade do sistema ou dos subsistemas. Esses motivos incluem o serviço não em execução, conectividade perdida, tempos limite ou respostas de código de erro.

Você pode calcular a disponibilidade percentual de um serviço durante um período de tempo usando a seguinte fórmula:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Use essa fórmula para monitoramento de SLA. A definição de tempo de inatividade depende do serviço. Por exemplo, o serviço de build Azure DevOps define o tempo de inatividade como o período, no total de minutos acumulados, durante o qual o serviço de build não está disponível. O serviço será considerado indisponível por um minuto se todas as solicitações HTTP contínuas durante esse minuto resultarem em um código de erro ou não retornarem uma resposta.

Monitoramento de desempenho

À medida que o volume de usuários aumenta, o tamanho dos conjuntos de dados que os usuários acessam aumenta e a possibilidade de falha de um ou mais componentes se torna mais provável. A degradação do desempenho geralmente ocorre antes da falha do componente. Se você puder detectar degradação, poderá tomar medidas proativas para evitar falhas.

O desempenho do sistema depende de vários fatores. Normalmente, você mede cada fator por meio de KPIs (principais indicadores de desempenho), como o número de transações de banco de dados por segundo ou o volume de solicitações de rede atendidas com êxito em um período de tempo especificado. Alguns desses KPIs podem estar disponíveis como medidas de desempenho específicas, enquanto outros KPIs podem ser derivados de uma combinação de métricas.

Requisitos para monitoramento de desempenho

Para avaliar o desempenho do sistema, você normalmente precisa das seguintes informações:

• As taxas de resposta para solicitações de usuário
• O número de solicitações de usuário simultâneas
• O volume de tráfego de rede
• As taxas nas quais o sistema conclui transações comerciais
• O tempo médio de processamento para solicitações

Use ferramentas que podem ajudá-lo a identificar as seguintes correlações:

• O número de usuários simultâneos versus tempos de latência de solicitação ou quanto tempo leva para iniciar o processamento de uma solicitação depois que o usuário a envia

• O número de usuários simultâneos versus o tempo médio de resposta ou quanto tempo leva para concluir uma solicitação após iniciar o processamento

• O volume de solicitações versus o número de erros de processamento

Juntamente com essas informações funcionais de alto nível, obtenha uma exibição detalhada do desempenho de cada componente no sistema. Os contadores de desempenho de baixo nível normalmente fornecem esses dados. Eles acompanham as seguintes informações:

• Utilização da memória
• Número de threads
• Tempo de processamento da CPU
• Comprimento da fila de solicitação
• Taxas e erros de E/S de rede ou de disco
• Número de bytes gravados ou lidos
• Indicadores de middleware, como comprimento da fila

Todas as visualizações devem permitir que você especifique um período de tempo. Os dados exibidos podem ser um instantâneo da situação atual ou uma exibição histórica do desempenho. O sistema deve gerar alertas com base em qualquer medida de desempenho para qualquer valor especificado durante qualquer intervalo de tempo especificado.

Coletar dados de desempenho

Colete dados de alto desempenho, como taxa de transferência, o número de usuários simultâneos, o número de transações comerciais e as taxas de erro, monitorando o progresso das solicitações dos usuários. Incorpore instruções de rastreamento e informações de tempo em pontos-chave no código do aplicativo. Capture todas as falhas, exceções e avisos com dados suficientes e as correlacione com as solicitações que as causaram.

Se possível, capture dados de desempenho para todos os sistemas externos que o aplicativo usa. Esses sistemas externos podem fornecer seus próprios contadores de desempenho ou outros recursos para solicitar dados de desempenho. Se esse método não for possível, registre informações como a hora de início e a hora de término de cada solicitação para um sistema externo e o êxito, falha ou status de aviso da operação.

Dados de desempenho de baixo nível para componentes individuais em um sistema podem estar disponíveis por meio de recursos e serviços, como contadores de desempenho Windows coletados pelo agente Azure Monitor.

Analisar dados de desempenho

A maioria das análises agrega dados de desempenho por tipo de solicitação de usuário ou pelo subsistema ou serviço ao qual cada solicitação é enviada. Um exemplo de uma solicitação de usuário é adicionar um item a um carrinho de compras ou ao processo de check-out em um sistema de comércio eletrônico.

Outro requisito comum é resumir dados de desempenho em percentis. Por exemplo, você pode determinar os tempos de resposta para 99% de solicitações, 95% de solicitações e 70% de solicitações. Você pode definir metas de SLA ou outras metas para cada percentil. Relatar resultados contínuos quase em tempo real para ajudar a detectar problemas imediatamente. Agregar resultados ao longo do tempo para fins estatísticos.

Problemas de latência também podem afetar o desempenho. Para identificar rapidamente a causa dos gargalos, avalie a latência de cada etapa executada por cada solicitação. Os dados de desempenho devem fornecer uma maneira de correlacionar as métricas de desempenho para cada etapa para associá-las a uma solicitação específica.

Dependendo dos requisitos de visualização, pode ser útil gerar e armazenar um cubo de dados que contenha exibições dos dados brutos. Esse cubo de dados pode permitir consultas complexas e não planejadas e análise de informações de desempenho.

Monitoramento de segurança

Todos os sistemas comerciais que incluem dados confidenciais devem implementar uma estrutura de segurança. A confidencialidade dos dados normalmente determina o quão complexo é o mecanismo de segurança. Em um sistema que exige que os usuários sejam autenticados, registre as seguintes informações:

• Todas as tentativas de entrada e se elas falham ou têm êxito

• Todas as operações executadas por um usuário autenticado e os detalhes de todos os recursos que eles acessam

• Quando um usuário termina uma sessão e sai

O monitoramento pode ajudar a detectar ataques ao sistema. Por exemplo, várias tentativas de login malsucedidas podem indicar um ataque de força bruta. Um aumento inesperado nas solicitações pode ser o resultado de um ataque de DDoS. Esteja preparado para monitorar todas as solicitações para todos os recursos, independentemente de sua origem. Um sistema que tem uma vulnerabilidade de entrada pode acidentalmente expor recursos sem exigir que um usuário entre.

Requisitos para monitoramento de segurança

Os dados que o monitoramento de segurança captura podem ajudá-lo:

• Detectar tentativas de invasões por uma entidade não autenticada.

• Identifique as tentativas das entidades de executar operações em dados aos quais elas não têm acesso.

• Determine se um usuário não autenticado ou um usuário autenticado mal-intencionado está tentando atacar o sistema.

Para dar suporte a essas tarefas, o sistema deverá enviar alertas se:

• Uma conta faz repetidas tentativas de entrada com falha em um período especificado.

• Uma conta autenticada tenta acessar repetidamente um recurso proibido durante um período especificado.

• Um grande número de solicitações não autenticadas ou não autorizadas ocorre durante um período especificado.

Configure alertas para incluir o endereço de host da origem para cada solicitação. Se as violações de segurança ocorrerem regularmente de um intervalo específico de endereços, você poderá bloquear esses hosts.

Uma parte fundamental da manutenção da segurança de um sistema é a capacidade de detectar rapidamente ações que se desviam do padrão habitual. Você pode exibir visualmente informações, como o número de solicitações de logon com falha ou bem-sucedidas, para ajudar a detectar picos de atividade em horários incomuns. Você também pode usar essas informações para configurar o dimensionamento automático baseado em tempo. Por exemplo, se você vir que muitos usuários se inscrevem regularmente em um momento específico, você poderá iniciar serviços de autenticação extra para lidar com o volume de trabalho. Desligue esses serviços depois que o pico passar.

Coletar dados de segurança

A segurança é um aspecto abrangente da maioria dos sistemas distribuídos e o monitoramento gera dados pertinentes em vários pontos em todo o sistema. Adote uma abordagem siem (Gerenciamento de Eventos e Informações de Segurança) para coletar informações resultantes de eventos gerados pelo aplicativo, equipamentos de rede, servidores, firewalls, software antivírus e outros elementos de prevenção de intrusão.

O monitoramento de segurança pode incorporar dados de ferramentas fora do aplicativo. Essas ferramentas incluem utilitários que identificam atividades de verificação de porta por agências externas e filtros de rede que detectam tentativas de obter acesso não autenticado ao seu aplicativo e dados. Em alguns casos, a integração contínua e as ferramentas de implantação de CI/CD (entrega contínua) compõem uma parte importante do ciclo de vida do aplicativo. Essas ferramentas também devem sinalizar o comportamento anômalo.

Analisar dados de segurança

Um dos principais recursos de monitoramento de segurança é que ele coleta dados de várias fontes. Os diferentes formatos e níveis de detalhes geralmente exigem uma análise complexa para compilar os dados em um thread coerente de informações. Você pode detectar entradas com falha ou tentativas repetidas de obter acesso não autorizado aos recursos, mas o processamento automatizado complexo de dados de segurança pode não ser viável. Nesse cenário, você precisa aplicar um carimbo de data/hora aos dados e gravá-los em um repositório seguro em sua forma original para análise manual por especialistas.

Monitoramento de SLA

Sistemas comerciais que dão suporte a clientes pagantes fazem compromissos sobre o desempenho do sistema na forma de SLAs. As SLAs afirmam que o sistema pode lidar com um volume de trabalho definido dentro de um período acordado e sem perder informações críticas. O monitoramento de SLA garante que o sistema atenda a SLAs mensuráveis.

As seguintes métricas definem SLAs:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode comprometer-se a manter o sistema disponível 99,9% do tempo todo. Esse percentual equivale a no máximo nove horas de inatividade por ano ou aproximadamente 10 minutos por semana.

• Capacidade operacional. Esse aspecto geralmente é expresso como um ou mais limites máximos, como o compromisso de que o sistema pode dar suporte a até 100.000 solicitações simultâneas de usuários ou processar 10.000 transações de negócio simultâneas.

• Tempo de resposta operacional. O sistema também pode precisar processar solicitações a uma taxa definida. Por exemplo, 99% de todas as transações comerciais devem ser concluídas dentro de 2 segundos e nenhuma transação única leva mais de 10 segundos.

Requisitos para monitoramento de SLA

Você deve ser capaz de determinar rapidamente se o sistema atende a um SLA. Se ele não atender ao SLA, você precisará avaliar os fatores subjacentes para encontrar a causa do desempenho abaixo do padrão.

Você pode descrever os seguintes indicadores de alto nível visualmente:

• O percentual de tempo de atividade do serviço

• A taxa de transferência do aplicativo, medida em termos de transações ou operações bem-sucedidas por segundo

• O número de solicitações de aplicativo bem-sucedidas ou com falha

• O número de falhas de aplicativo e do sistema, exceções e avisos

Certifique-se de que você pode filtrar todos esses indicadores por um período de tempo especificado.

Seu aplicativo de nuvem provavelmente inclui vários subsistemas e componentes. Você deve ser capaz de selecionar um indicador de alto nível, como o tempo de atividade geral do sistema, e determinar quais componentes subjacentes afetam seu estado de integridade.

Para fins de alerta, o sistema deve gerar um evento se qualquer um dos indicadores de alto nível exceder um limite especificado. Disponibilize os detalhes de nível inferior para o sistema de alertas como dados contextuais.

Coletar dados SLA

Execute as seguintes ações para capturar os dados brutos necessários para o monitoramento do SLA:

• Faça o monitoramento de endpoints.
• Registrar exceções, falhas e avisos.
• Rastreie a execução de solicitações de usuário.
• Monitore a disponibilidade de quaisquer serviços que não sejam da Microsoft usados pelo sistema.
• Use contadores e métricas de desempenho.

Todos os dados devem ser registrados e carimbados com data e hora.

Analisar dados do SLA

Agregar os dados SLA para gerar uma imagem do desempenho geral do sistema. Você também deve ser capaz de analisar em detalhe os dados agregados para avaliar os subsistemas subjacentes. Por exemplo, você deve ser capaz de realizar as seguintes tarefas:

• Calcule o número total de solicitações de usuário durante um período especificado e determine a taxa de êxito e falha dessas solicitações.

• Combine os tempos de resposta das solicitações do usuário para gerar uma exibição geral dos tempos de resposta do sistema.

• Analise o progresso das solicitações do usuário para dividir o tempo de resposta geral nos tempos de resposta de itens de trabalho individuais na solicitação.

• Determinar a disponibilidade geral do sistema como um percentual de tempo de atividade para um período específico.

• Analise a disponibilidade de tempo percentual dos componentes e serviços individuais no sistema. Talvez seja necessário analisar logs gerados por serviços que não são da Microsoft.

Os sistemas comerciais devem relatar números reais de desempenho em relação aos SLAs por um período especificado. Você pode usar essas informações para calcular créditos ou outras formas de reembolsos para os clientes se você não atender a SLAs durante esse período. Você pode calcular a disponibilidade de um serviço usando a técnica descrita em Analisar dados de disponibilidade.

Para fins internos, uma organização também pode acompanhar o número e a natureza dos incidentes que causam falha nos serviços. Saiba como resolver esses problemas rapidamente ou eliminá-los para que você possa reduzir o tempo de inatividade e atender a SLAs.

Auditing

Dependendo da natureza do aplicativo, as regulamentações legais podem especificar requisitos para auditar as operações dos usuários e registrar todo o acesso a dados. A auditoria pode fornecer evidências que vinculam os clientes a solicitações específicas. O não repúdio é um fator importante nos sistemas de negócios eletrônicos para ajudar a manter a confiança entre o cliente e a organização responsável pelo aplicativo ou serviço.

Requisitos para auditoria

Você deve ser capaz de rastrear a sequência de operações de negócios que os usuários realizam para que você possa reconstruir as ações dos usuários. Esse registro pode ser necessário para fins de documentação ou como parte de uma investigação forense.

As informações de auditoria são altamente confidenciais. Ele provavelmente inclui dados que identificam os usuários do sistema e as tarefas que eles executam. Por esse motivo, as informações de auditoria provavelmente só estão disponíveis para analistas confiáveis, em vez de como parte de um sistema interativo. O analista gera uma variedade de relatórios, como os seguintes exemplos:

• Relatórios que listam as atividades de todos os usuários durante um período de tempo especificado

• Relatórios que detalham a cronologia da atividade para um único usuário

• Relatórios que listam a sequência de operações executadas em um ou mais recursos

Coletar dados de auditoria

As principais fontes de informações para auditoria incluem:

• O sistema de segurança que gerencia a autenticação do usuário.
• Rastreie logs que registram as atividades do usuário.
• Logs de segurança que rastreiam todas as solicitações de rede identificáveis e não identificáveis.

Os requisitos regulatórios podem determinar o formato dos dados de auditoria e como armazená-los. Se os regulamentos exigirem que você registre os dados em seu formato original, talvez não seja possível limpar os dados. Como resultado, o acesso ao repositório que o armazena deve ser protegido de perto para evitar adulterações.

Analisar dados de auditoria

Você deve ser capaz de acessar dados brutos em sua totalidade e em sua forma original. Além do requisito para gerar relatórios de auditoria comuns, as ferramentas para analisar esses dados provavelmente são especializadas e mantidas externas para o sistema.

Monitoramento do uso

O monitoramento de uso controla como os clientes usam os recursos e componentes de um aplicativo. Você pode usar os dados para:

• Identifique recursos populares e possíveis hotspots no sistema. Elementos de alto tráfego podem se beneficiar de particionamento funcional ou replicação para espalhar a carga de forma mais uniforme. Você também pode usar essas informações para determinar quais recursos são usados com pouca frequência e são possíveis candidatos à aposentadoria ou substituição em uma versão futura do sistema.

• Obtenha informações sobre os eventos operacionais do sistema em uso normal. Por exemplo, em um site de comércio eletrônico, você pode registrar informações estatísticas sobre o número de transações e o volume de clientes responsáveis por elas. Você pode usar essas informações para planejamento de capacidade à medida que o número de clientes aumenta.

• Detecte a satisfação do usuário com o desempenho e a funcionalidade do sistema. Por exemplo, se muitos clientes em um sistema de comércio eletrônico abandonarem regularmente seus carrinhos de compras, pode haver um problema com a funcionalidade de check-out.

• Gerar informações de cobrança. Um aplicativo comercial ou serviço multilocatário pode cobrar dos clientes pelos recursos que eles usam.

• Aplicar cotas. Se um usuário em um sistema multitenant exceder sua cota paga de tempo de processamento ou de uso de recursos durante um período especificado, você poderá limitar seu acesso ou reduzir a velocidade do processamento.

• Detecte problemas de vizinhos barulhentos. Para ajudar a conduzir investigações de erros ou decisões de produto, determine se o tráfego é distribuído uniformemente ou se um pequeno conjunto de usuários gera a maior parte do tráfego. Se um único usuário gerar tráfego significativo, o recurso poderá precisar de ajuste de desempenho. Como alternativa, você pode decidir impor cotas extras para reduzir o tráfego.

Requisitos para monitoramento de uso

Para avaliar o uso do sistema, você normalmente precisa das seguintes informações:

• O número de solicitações que cada subsistema processa e direciona para cada recurso

• O trabalho que cada usuário executa

• O volume de armazenamento de dados que cada usuário ocupa

• Os recursos que cada usuário acessa

Você também deve ser capaz de gerar grafos. Exemplos comuns incluem grafos de usuários que consomem a maioria dos recursos e os recursos ou recursos do sistema acessados com mais frequência.

Coletar dados de uso

Você pode executar o acompanhamento de uso de alto nível observando os horários de início e término de cada solicitação e a natureza de cada solicitação, como leitura ou gravação. Para capturar essas informações, execute as seguintes tarefas:

• Rastrear a atividade do usuário.
• Capture contadores de desempenho que medem a utilização de cada recurso.
• Monitore o consumo de recursos de cada usuário.

Para fins de medição, você também precisa identificar quais usuários executam quais operações e os recursos que essas operações usam. Verifique se as informações coletadas são detalhadas o suficiente para dar suporte à cobrança precisa.

Acompanhamento de problemas

Clientes e outros usuários poderão relatar problemas se ocorrerem eventos ou comportamentos inesperados no sistema. O controle de problemas gerencia esses problemas, associa problemas aos esforços para corrigi-los e informa os clientes sobre resoluções.

Requisitos para acompanhamento de problemas

Para controlar problemas, use um sistema separado que permite que você registre e relate os detalhes dos problemas relatados pelos usuários. Esses detalhes incluem as tentativas de tarefas, os sintomas do problema, a sequência de eventos e mensagens de erro ou aviso.

Coletar dados de acompanhamento de problemas

A fonte de dados inicial para dados de acompanhamento de problemas é o usuário que relata o problema. Esse usuário pode fornecer os seguintes detalhes:

• Um despejo de memória, se o aplicativo incluir um componente executado no desktop do usuário

• Uma captura de tela

• A data e a hora em que o erro ocorreu e outras informações ambientais, como a localização do usuário

Use essas informações para ajudá-lo a depurar o sistema e construir uma lista de pendências para versões futuras de software.

Analisar dados de acompanhamento de problemas

Usuários diferentes podem relatar o mesmo problema e o sistema de acompanhamento de problemas deve associar relatórios comuns.

Registre o avanço do esforço de depuração para cada relatório. Ao resolver o problema, informe o cliente sobre a solução.

Se um usuário relatar um problema que tenha uma solução conhecida no sistema de acompanhamento de problemas, você poderá informar o usuário da solução imediatamente.

Rastreamento de operações e depuração das versões de software

Quando um usuário relata um problema, ele normalmente só está ciente do efeito imediato que tem em suas operações. O usuário só pode relatar os resultados de sua própria experiência. Essas experiências geralmente são um sintoma visível de um ou mais problemas fundamentais. Em muitos casos, um analista precisa analisar a cronologia das operações subjacentes para estabelecer a causa raiz do problema. Esse processo é chamado análise da causa raiz (RCA).

Requisitos para rastreamento e depuração

Para rastrear eventos inesperados e outros problemas, os dados de monitoramento devem fornecer informações suficientes para permitir que um analista localize a origem do problema e reconstrua a sequência de eventos. Em seguida, um desenvolvedor pode fazer modificações para evitar que o problema se repita.

Coletar dados de rastreamento e depuração

Para solucionar problemas, rastreie todos os métodos e seus parâmetros invocados como parte de uma operação. Em seguida, crie uma árvore que ilustra o fluxo lógico por meio do sistema quando um cliente faz uma solicitação específica. Capturar e registrar exceções e avisos que o sistema gera como resultado desse fluxo.

Para dar suporte à depuração, o sistema fornece ganchos que você pode usar para capturar informações de estado em pontos cruciais no sistema. Ou o sistema pode fornecer informações detalhadas passo a passo à medida que as operações selecionadas avançam. Capturar dados nesse nível de detalhes pode aumentar a carga no sistema e deve ser um processo temporário. Use esse processo quando eventos incomuns e difíceis de replicar ocorrerem ou quando uma nova versão exigir um monitoramento cuidadoso para garantir que os elementos funcionem conforme o esperado.

O fluxo de monitoramento e diagnóstico

O monitoramento de um sistema distribuído em larga escala representa um desafio significativo. Você não deve necessariamente considerar cada um dos cenários descritos nas seções anteriores isoladamente. Os dados de monitoramento e diagnóstico necessários para cada situação se sobrepõem, mas talvez seja necessário processar e apresentar esses dados de maneiras diferentes. Por esses motivos, use uma visão holística do monitoramento e do diagnóstico.

Você pode imaginar todo o processo de monitoramento e diagnóstico como um pipeline que compreende os estágios mostrados no diagrama a seguir.

O diagrama mostra como os dados de monitoramento e diagnóstico vêm de várias fontes. Os estágios de instrumentação e coleta ajudam a identificar os dados que você precisa capturar, onde e como capturá-los e como formatar os dados para que você possa analisá-los facilmente. O estágio de análise e diagnóstico usa os dados brutos e os usa para gerar informações significativas que podem ser usadas para determinar o estado do sistema. Você pode usar essas informações para determinar quais ações possíveis devem ser tomadas e, em seguida, reincorporar os resultados às etapas de instrumentação e coleta. A etapa de visualização e alertas apresenta uma visão de fácil compreensão do estado do sistema. Ele pode exibir informações quase em tempo real usando uma série de painéis. Ele pode gerar relatórios, gráficos e gráficos para fornecer uma exibição histórica dos dados que podem ajudá-lo a identificar tendências de longo prazo. Se as informações indicarem que um KPI provavelmente excederá os limites aceitáveis, esse estágio também poderá disparar um alerta. Em alguns casos, um alerta também pode disparar um processo automatizado que tenta executar ações corretivas, como dimensionamento automático.

Essas etapas formam um processo de fluxo contínuo no qual os estágios são executados em paralelo. O ideal é que todas as fases sejam configuráveis dinamicamente. Em alguns pontos, especialmente quando um sistema é implantado recentemente ou está enfrentando problemas, talvez seja necessário coletar dados estendidos com mais frequência. Em outras ocasiões, você pode continuar capturando informações essenciais de alto nível para verificar se o sistema está funcionando corretamente.

Trate todo o processo de monitoramento como uma solução dinâmica e contínua que precisa de ajustes finos e melhorias com base em comentários. Por exemplo, você pode começar medindo muitos fatores para determinar a integridade do sistema e refinar sua análise ao longo do tempo para descartar medidas que não são relevantes.

Fontes de dados de monitoramento e diagnóstico

As informações que o processo de monitoramento usa podem vir de várias fontes. No nível do aplicativo, as informações são provenientes de logs de rastreamento que você incorpora ao código do sistema. Os desenvolvedores devem seguir uma abordagem padrão para acompanhar o fluxo de controle por meio de seu código. Por exemplo, uma entrada para um método pode emitir uma mensagem de rastreamento que especifica o nome do método, a hora atual, o valor de cada parâmetro e outras informações pertinentes. Talvez você também queira gravar os horários de entrada e saída.

Registre todas as exceções e avisos e não se esqueça de manter um rastreamento completo de todos os avisos e exceções aninhadas. Capture informações que identificam o usuário que executa as informações de correlação de código e atividade para acompanhar solicitações à medida que passam pelo sistema. O log tenta acessar todos os recursos, como filas de mensagens, bancos de dados, arquivos e outros serviços dependentes. Você pode usar essas informações para fins de medição e auditoria.

Muitos aplicativos usam bibliotecas e estruturas para executar tarefas comuns, como acessar um armazenamento de dados ou se comunicar por uma rede. Você pode configurar essas estruturas para fornecer suas próprias mensagens de rastreamento e informações de diagnóstico brutas, como taxas de transação e êxitos e falhas de transmissão de dados.

O sistema operacional no qual o aplicativo é executado pode ser uma fonte de informações de baixo nível em todo o sistema, como contadores de desempenho que indicam taxas de E/S, utilização de memória e uso da CPU. Ele também pode relatar erros do sistema operacional, como a falha ao abrir um arquivo corretamente.

Considere também a infraestrutura subjacente e os componentes nos quais o sistema é executado. Máquinas virtuais (VMs), redes virtuais e serviços de armazenamento podem ser fontes de contadores de desempenho importantes no nível da infraestrutura e outros dados de diagnóstico.

Se o aplicativo usar outros serviços externos, como um servidor Web ou um DBMS (sistema de gerenciamento de banco de dados), esses serviços poderão publicar suas próprias informações de rastreamento, logs e contadores de desempenho. Por exemplo, as DMVs (exibições de gerenciamento dinâmico) no SQL Server acompanham as operações realizadas em um banco de dados do SQL Server. O Application Insights rastreia logs para registrar solicitações feitas para Serviço de Aplicativo do Azure.

À medida que você modifica os componentes do sistema e implanta novas versões, é importante que você possa atribuir problemas, eventos e métricas a cada versão. Associe essas informações ao pipeline de lançamento para que você possa acompanhar e corrigir problemas com uma versão específica de um componente rapidamente.

Use as seguintes estratégias para coletar dados de monitoramento e diagnóstico:

• O monitoramento do aplicativo e do sistema usa fontes internas no aplicativo, estruturas de aplicativos, sistema operacional e infraestrutura. O código do aplicativo pode gerar seus próprios dados de monitoramento em pontos notáveis durante o ciclo de vida de uma solicitação de cliente. O aplicativo pode incluir instruções de rastreamento que podem ser ativadas e desativadas conforme necessário. Você também pode injetar diagnóstico dinamicamente usando uma estrutura de diagnóstico. Esses frameworks normalmente fornecem plug-ins que se conectam a vários pontos de instrumentação no seu código e coletam dados de rastreamento nesses pontos.

  Seu código ou a infraestrutura subjacente também podem gerar eventos em pontos críticos. Os agentes de monitoramento configurados para escutar esses eventos podem gravar as informações do evento.

• O monitoramento real do usuário registra as interações entre um usuário e o aplicativo e observa o fluxo de cada solicitação e resposta. Use essas informações para medir o uso por cada usuário e determinar se os usuários recebem um QoS adequado, incluindo tempos de resposta rápidos, baixa latência e erros mínimos. Você pode usar os dados para identificar áreas em que as falhas ocorrem com mais frequência. Você também pode usar os dados para identificar pontos em que o sistema fica mais lento devido a pontos críticos na aplicação ou a outros gargalos. Se você implementar essa abordagem com cuidado, poderá reconstruir os fluxos dos usuários por meio do aplicativo para fins de depuração e teste.

  Importante

  Trate os dados capturados pelo monitoramento real do usuário como altamente confidenciais porque podem incluir material confidencial. Se você salvar os dados capturados, armazene-os com segurança. Se você quiser usar os dados para fins de monitoramento de desempenho ou depuração, remova todos os dados pessoais primeiro.

• O monitoramento de usuário sintético exige que você escreva seu próprio cliente de teste que simula um usuário e execute uma série configurável, mas típica de operações. Você pode acompanhar o desempenho do cliente de teste para ajudar a determinar o estado do sistema. Você também pode usar várias instâncias do cliente de teste como parte de uma operação de teste de carga para estabelecer como o sistema responde sob estresse e a saída de monitoramento gerada por essas condições.

  Note

  Você pode implementar o monitoramento de usuário real e sintético incluindo código que rastreia e mede a execução de chamadas de método e outras partes críticas do aplicativo.

• A criação de perfil ajuda a monitorar e melhorar o desempenho do aplicativo. Ao contrário do monitoramento real do usuário e do monitoramento de usuário sintético, que operam no nível funcional, a criação de perfil captura informações de nível inferior à medida que o aplicativo é executado. Implemente a criação de perfil amostrando periodicamente o estado de execução de um aplicativo ou determinando qual parte do código o aplicativo executa em um momento específico. Você também pode usar instrumentação que insere sondas no código em pontos importantes, como no início e no fim de uma chamada de método. As investigações registram quais métodos a chamada invocou, em que momento e quanto tempo cada chamada leva. Em seguida, você pode analisar esses dados para determinar quais partes do aplicativo podem causar problemas de desempenho.

• Monitoramento do ponto de extremidade usa um ou mais pontos de extremidade de diagnóstico que o aplicativo expõe especificamente para habilitar o monitoramento. Um ponto de extremidade fornece um caminho para o código do aplicativo e pode retornar informações sobre a integridade do sistema. Pontos de extremidade diferentes podem se concentrar em vários aspectos da funcionalidade. Você pode escrever seu próprio cliente de diagnóstico que envia solicitações periódicas para esses endpoints e processa as respostas. Para obter mais informações, consulte o padrão de Monitoramento de Ponto de Extremidade de Saúde.

• Os despejos de erro do usuário dependem do aplicativo para oferecer uma maneira de coletar um instantâneo do estado do aplicativo caso ele não consiga se recuperar. Os usuários também precisam compartilhar voluntariamente esse instantâneo. Você não pode garantir que um despejo de erro seja executado, mas você pode usar os dados de baixo nível fornecidos para determinar a causa principal de erros. Esse cenário é comum se os erros ocorrem com pouca frequência ou se os erros ocorrem apenas em um recurso de aplicativo usado com pouca frequência.

Para cobertura máxima, você deve usar uma combinação dessas técnicas.

Instrument an application (Instrumentar um aplicativo)

A instrumentação é uma parte crítica do processo de monitoramento. Você deve capturar dados que ajudam você a tomar decisões significativas sobre o desempenho e a integridade do sistema. Use a instrumentação para coletar informações suficientes para avaliar o desempenho, diagnosticar problemas e tomar decisões sem entrar em um servidor de produção remoto para rastrear e depurar manualmente. Os dados de instrumentação normalmente são compostos por métricas e informações gravadas em logs de rastreamento.

Um log de rastreamento pode conter dados textuais que o aplicativo grava ou dados binários que um evento de rastreamento cria, se o aplicativo usa o ETW (Rastreamento de Eventos para Windows). Os logs de sistema que registram eventos ocorridos de partes da infraestrutura, como um servidor Web, também podem gerar conteúdo do log de rastreamento. Mensagens de log textuais geralmente são legíveis por humanos, mas as gravam em um formato que um sistema automatizado também pode analisar facilmente.

Também classifique os logs. Não escreva todos os dados de rastreamento em um único log. Use logs à parte para registrar a saída de rastreamento de aspectos operacionais diferentes do sistema. Em seguida, você pode filtrar rapidamente as mensagens de log consultando o log apropriado, em vez de processar um único arquivo extenso. Nunca grave informações que tenham requisitos de segurança diferentes, como informações de auditoria e dados de depuração, no mesmo log.

As métricas geralmente são uma medida ou contagem de algum aspecto ou recurso no sistema em um momento específico, com uma ou mais marcas ou dimensões associadas, também chamadas de exemplo. Uma única instância de uma métrica não é útil isoladamente. Em vez disso, capture métricas ao longo do tempo. Considere quais métricas registrar e com que frequência. Gerar dados para métricas com muita frequência pode colocar muita carga no sistema. Mas não capturar dados suficientes pode fazer com que você perca as circunstâncias que levam a um evento significativo. As considerações variam de métrica para métrica. Por exemplo, a utilização da CPU em um servidor pode flutuar de segundo para segundo, mas a alta utilização só se tornará uma preocupação se persistir por vários minutos.

Informações para correlacionar dados

Você pode monitorar facilmente contadores de desempenho individuais no nível do sistema, capturar métricas para recursos e obter informações de rastreamento de aplicativos de vários arquivos de log. Mas algumas formas de monitoramento exigem a fase de análise e diagnóstico no pipeline de monitoramento para correlacionar os dados recuperados de várias fontes. Esses dados brutos podem tomar várias formas e o processo de análise deve ter dados de instrumentação suficientes para mapear essas formas diferentes. Por exemplo, no nível da estrutura do aplicativo, uma ID de thread pode identificar uma tarefa. Em um aplicativo, o mesmo trabalho pode estar associado à ID do usuário para o usuário que executa essa tarefa.

Um mapeamento um-para-um provavelmente não existe entre threads e solicitações de usuário porque operações assíncronas podem reutilizar os mesmos threads para executar operações para mais de um usuário. Mais de um thread também pode lidar com uma única solicitação à medida que a execução flui pelo sistema. Se possível, associe cada solicitação a uma ID de atividade exclusiva propagada por meio do sistema como parte do contexto de solicitação. A técnica para gerar e incluir IDs de atividade em informações de rastreamento depende da tecnologia que você usa para capturar os dados de rastreamento.

Carimbo de data/hora de todos os dados de monitoramento da mesma maneira. Para consistência, registre todas as datas e horas usando UTC. Esse método ajuda você a rastrear mais facilmente sequências de eventos.

Informações a serem incluídas nos dados de instrumentação

Considere os seguintes pontos ao decidir quais dados de instrumentação coletar:

• Verifique se as informações capturadas por eventos de rastreamento são legíveis por máquina e legíveis por humanos. Adote esquemas bem definidos para essas informações para facilitar o processamento automatizado de dados de log entre sistemas e fornecer consistência à equipe de operações e engenharia que lêem os logs. Inclua informações ambientais, como o ambiente de implantação, o computador no qual o processo é executado, os detalhes do processo e a pilha de chamadas.

• Habilite a criação de perfil somente quando necessário, pois ela pode adicionar sobrecarga significativa ao sistema. A criação de perfil usando a instrumentação registra um evento, como uma chamada de método, sempre que ele ocorre, e a amostragem só registra eventos selecionados. A seleção pode ser baseada em tempo, uma vez a cada n segundos ou baseada em frequência, uma vez a cada n solicitações. Se os eventos ocorrerem com frequência, a análise de desempenho com instrumentação poderá gerar uma sobrecarga excessiva e afetar o desempenho geral. Neste caso, a abordagem de amostragem é preferível. No entanto, se a frequência dos eventos for baixa, a amostragem poderá não registrá-los. Nesse caso, a instrumentação pode ser a melhor abordagem.

• Forneça contexto suficiente para que um desenvolvedor ou administrador possa determinar a origem de cada solicitação. Esse contexto pode incluir uma ID de atividade que identifica uma instância específica de uma solicitação ou informações que correlaciona uma atividade com o trabalho computacional executado e os recursos usados. Esse trabalho pode cruzar os limites do processo e do computador. Para fins de medição, o contexto também deve incluir, diretamente ou indiretamente, por meio de outras informações correlacionadas, uma referência ao cliente que faz a solicitação. Esse contexto fornece informações valiosas sobre o estado do aplicativo ao capturar dados de monitoramento.

• Registre todas as solicitações e os locais ou regiões das quais essas solicitações são feitas. Essas informações podem ajudá-lo a determinar se existem hotspots específicos ao local. Ele também pode ajudá-lo a determinar se deseja reparticionar um aplicativo ou os dados que ele usa.

• Registre e capture cuidadosamente os detalhes das exceções. Muitas vezes, as informações críticas de depuração são perdidas como resultado da má manipulação de exceções. Capture os detalhes completos das exceções geradas pelo aplicativo, incluindo quaisquer exceções internas e outras informações de contexto. Inclua a pilha de chamadas, se possível.

• Seja consistente nos dados que os diferentes elementos do aplicativo capturam. A consistência pode ajudá-lo a analisar eventos e correlacioná-los com solicitações de usuário. Considere usar um pacote de log abrangente e configurável para coletar informações, em vez de depender dos desenvolvedores para adotar a mesma abordagem que implementam diferentes partes do sistema. Colete dados dos principais contadores de desempenho, como volume de E/S, utilização de rede, número de solicitações, uso de memória e utilização da CPU. Alguns serviços de infraestrutura podem fornecer seus próprios contadores de desempenho, como o número de conexões com um banco de dados, a taxa na qual o sistema executa transações e o número de transações que são bem-sucedidas ou falham. Os aplicativos também podem definir seus próprios contadores de desempenho específicos.

• Registre todas as chamadas feitas em serviços externos, como sistemas de banco de dados, serviços Web ou outros serviços no nível do sistema que fazem parte da infraestrutura. Registre informações sobre o tempo necessário para executar cada chamada e se a chamada é bem-sucedida ou falha. Se possível, capture informações sobre todas as tentativas de repetição e falhas para quaisquer erros transitórios que ocorram.

Garantir a compatibilidade com sistemas de telemetria

Em muitos casos, as informações que a instrumentação produz são geradas como uma série de eventos e passadas para um sistema de telemetria separado para processamento e análise. Um sistema de telemetria normalmente é independente de aplicativos ou tecnologias específicas, mas espera que as informações sigam um formato específico definido por um esquema. O esquema especifica um contrato que define os campos e tipos de dados que o sistema de telemetria pode ingerir. Generalize o esquema para permitir dados de uma variedade de plataformas e dispositivos. Um exemplo de uma estrutura e um esquema amplamente usados é OpenTelemetry.

Um esquema comum deve incluir campos que todos os eventos de instrumentação têm em comum, como o nome do evento, a hora do evento, o endereço IP do remetente. Ele também deve incluir os detalhes necessários para correlacionar com outros eventos, como uma ID de usuário, uma ID do dispositivo e uma ID do aplicativo. Lembre-se de que qualquer número de dispositivos pode gerar eventos, portanto, o esquema não deve depender do tipo de dispositivo. Além disso, vários dispositivos podem gerar eventos para o mesmo aplicativo, e o aplicativo pode dar suporte a roaming ou a alguma outra forma de distribuição entre dispositivos.

O esquema também pode incluir campos de domínio relevantes para um cenário específico que é comum em diferentes aplicativos. Esses cenários incluem informações sobre exceções, eventos de início e término do aplicativo e êxito ou falha de chamadas à API do serviço Web. Todos os aplicativos que usam o mesmo conjunto de campos de domínio devem emitir o mesmo conjunto de eventos para criar um conjunto de relatórios e análises comuns.

Por fim, um esquema pode conter campos personalizados para capturar os detalhes de eventos específicos do aplicativo.

Práticas recomendadas para instrumentar aplicativos

A lista a seguir resume as práticas recomendadas para instrumentar um aplicativo distribuído executado na nuvem:

• Torne os logs fáceis de ler e analisar. Use o registro em log estruturado sempre que possível. Seja conciso e descritivo em mensagens de log.

• Em todos os logs, identifique a origem e forneça informações de contexto e tempo à medida que cada registro de log é gravado.

• Use o mesmo fuso horário e formato para todos os carimbos de data/hora. Essa prática ajuda a correlacionar eventos para operações que abrangem hardware e serviços executados em diferentes regiões geográficas.

• Categorize logs e escreva mensagens no arquivo de log apropriado.

• Não divulgue informações confidenciais sobre o sistema ou informações pessoais sobre usuários. Limpe essas informações antes de registrá-la, mas certifique-se de manter os detalhes relevantes. Por exemplo, remova a ID e a senha das cadeias de conexão de banco de dados. Escreva as informações restantes no log para que você possa determinar se o sistema acessa o banco de dados correto. Registre todas as exceções críticas, mas permita que o administrador ative e desative o log para níveis mais baixos de exceções e avisos. Além disso, capture e registre todas as informações da lógica de nova tentativa. Você pode usar esses dados para monitorar a integridade transitória do sistema.

• Rastrear chamadas fora do processo, como solicitações para serviços Web externos ou bancos de dados.

• Não misture mensagens de log com diferentes requisitos de segurança no mesmo arquivo de log. Por exemplo, não escreva informações de depuração e auditoria no mesmo log.

• Inicie chamadas de log que continuam funcionando de forma autônoma. Esses tipos de operações não bloqueiam o progresso das operações de negócios. Os eventos de auditoria são uma exceção porque são essenciais para a empresa. Classifique-os como uma parte fundamental das operações de negócios.

• Verifique se o registro seja extensível e não tenha dependências diretas de um alvo concreto. Por exemplo, em vez de escrever informações usando System.Diagnostics.Trace, defina uma interface abstrata, como ILogger, que expõe métodos de log e que você pode implementar por meio de quaisquer meios adequados.

• Certifique-se de que todo o registro de logs seja seguro contra falhas e nunca provoque erros em cascata. O registro em log não deve lançar nenhuma exceção.

• Trate a instrumentação como um processo iterativo contínuo e revise os logs regularmente, não apenas quando ocorre um problema.

Coletar e armazenar dados

O estágio de coleta recupera as informações geradas pela instrumentação, formata esses dados para facilitar o consumo durante o estágio de análise e diagnóstico e salva os dados transformados no armazenamento confiável. Você pode armazenar os dados de instrumentação coletados de diferentes partes de um sistema distribuído em vários locais e formatos. Por exemplo, o código do aplicativo pode gerar arquivos de log de rastreamento e dados de log de eventos do aplicativo. Outras tecnologias podem capturar contadores de desempenho que monitoram os principais aspectos da infraestrutura que seu aplicativo usa. Todos os componentes e serviços não Microsoft que seu aplicativo usa podem fornecer informações de instrumentação em formatos diferentes usando arquivos de rastreamento separados, armazenamento de blobs ou até mesmo um armazenamento de dados personalizado.

Um serviço de coleta executado de forma autônoma do aplicativo que gera os dados de instrumentação normalmente coleta os dados. O diagrama a seguir mostra um exemplo dessa arquitetura e realça o subsistema de coleta de dados de instrumentação.

Este diagrama mostra uma exibição simplificada da coleta de dados. O serviço de coleção normalmente compreende muitas partes que são executadas em computadores diferentes. Se você precisar analisar dados de telemetria rapidamente, use componentes locais que operam fora do serviço de coleta. Após o processamento analítico, os componentes enviam os resultados diretamente para o subsistema de visualização e alerta. Os dados sujeitos à análise morna ou fria são mantidos no armazenamento enquanto aguardam o processamento. Para obter mais informações, consulte Dar suporte à análise quente, morna e fria.

Para Azure aplicativos e serviços executados em máquinas virtuais, o agente Azure Monitor fornece uma solução para capturar dados. Você define regras de coleta de dados (DCRs) que especificam os dados que devem ser coletados de cada nó de computação e o workspace do Log Analytics no Azure Monitor para o qual eles devem ser enviados. O agente pode coletar dados das seguintes fontes:

• Logs do IIS (Serviços de Informações da Internet)
• Logs de eventos do Windows
• Contadores de desempenho
• Syslog de nós Linux
• Logs de texto e JSON gravados por aplicativos

Estratégias para coletar dados de instrumentação

Devido à natureza elástica da nuvem e para evitar a recuperação manual de dados de telemetria de cada nó do sistema, providencie a consolidação dos dados e sua transferência para um local central. Em um sistema que abrange vários datacenters, convém coletar, consolidar e armazenar dados em uma base região por região primeiro e, em seguida, agregar os dados regionais em um único sistema central.

Para otimizar o uso de largura de banda, você pode transferir dados menos urgentes como lotes. Não adie a transferência indefinidamente, especialmente se os dados contiverem informações sensíveis ao tempo.

Transferir e enviar por push dos dados de instrumentação

O subsistema de coleta de dados de instrumentação pode recuperar ativamente os dados de instrumentação dos vários logs e de outras fontes para cada instância do aplicativo. Esse método é chamado de modelo de extração. Ou pode atuar como um receptor passivo que aguarda os componentes que constituem cada instância do aplicativo para enviar os dados. Esse método é chamado de modelo de push.

Uma abordagem para o modelo de pull é usar agentes de monitoramento que são executados localmente com cada instância do aplicativo. Um agente de monitoramento é um processo separado que recupera periodicamente os dados de telemetria coletados no nó local e grava essas informações no armazenamento centralizado que todas as instâncias do aplicativo compartilham. O agente Azure Monitor implementa esse mecanismo. Você configura os dados a serem coletados de cada instância de computação por meio de uma regra de coleta de dados. O agente de monitoramento executado junto com cada instância coleta os dados especificados, como logs do IIS, logs de Windows de eventos e contadores de desempenho, e os envia para um workspace Log Analytics no Azure Monitor, onde você pode consultá-los e analisá-los. O diagrama a seguir mostra um exemplo dessa arquitetura.

Você pode usar os modelos de pull e push para armazenar dados de telemetria para um aplicativo de pequena escala que é executado em um número limitado de nós em um único local. Um aplicativo de nuvem global complexo e altamente escalonável pode gerar grandes volumes de dados de centenas de instâncias de computação, fragmentos de banco de dados e outros serviços. Essa inundação de dados pode facilmente sobrecarregar a largura de banda de E/S disponível com um único local central. Como resultado, você deve ser capaz de dimensionar sua solução de telemetria para evitar um gargalo à medida que o sistema se expande. Idealmente, sua solução deve incorporar um grau de redundância para reduzir os riscos de perda de informações importantes de monitoramento, como dados de auditoria ou cobrança, se parte do sistema falhar.

Para resolver esses problemas, implemente o enfileiramento. Na arquitetura de exemplo a seguir, o agente de monitoramento local ou o serviço de coleta de dados personalizado postam dados em uma fila. O serviço de gravação de armazenamento, um processo assíncrono à parte, utiliza os dados nessa fila e os grava no armazenamento compartilhado. Uma fila de mensagens é indicada para esse cenário porque oferece semântica pelo menos uma vez que ajuda a garantir que os dados na fila não serão perdidos depois que ele for lançado. Você pode implementar o serviço de gravação em armazenamento usando um processo em segundo plano à parte.

O serviço de coleta de dados local pode adicionar dados a uma fila imediatamente após recebê-los. A fila atua como um buffer e o serviço de gravação em armazenamento pode recuperar e gravar os dados em seu próprio ritmo. Por padrão, uma fila opera no modo primeiro a entrar, primeiro a sair. Mas você pode priorizar as mensagens para fazê-las avançar mais rapidamente na fila, caso contenham dados que você precise processar rapidamente. Para obter mais informações, consulte o padrão de Fila de Prioridade. Como alternativa, você pode usar canais diferentes, como tópicos do Barramento de Serviço, para direcionar dados para diferentes destinos, dependendo do tipo de processamento analítico necessário.

Para ter dimensionalidade, você pode executar várias instâncias do serviço de gravação em armazenamento. Para grandes volumes de eventos, você pode usar um hub de eventos para expedir os dados para diferentes recursos de computação para processamento e armazenamento.

Consolidar dados de instrumentação

Os dados de instrumentação que o serviço de coleta de dados recupera de uma única instância de um aplicativo dão uma exibição localizada da integridade e do desempenho dessa instância. Para avaliar o estado geral do sistema, consolide aspectos dos dados nas visualizações locais. Você pode executar essa etapa depois que os dados são armazenados, mas em alguns casos você também pode fazê-lo à medida que os dados são coletados. Em vez de gravar diretamente no armazenamento compartilhado, os dados de instrumentação passam por um serviço separado que consolida, filtra e limpa dados. Por exemplo, os dados de instrumentação que incluem as mesmas informações de correlação, como uma ID de atividade, podem ser amalgamados. Um usuário pode iniciar uma operação de negócios em um nó e, em seguida, ser transferido para outro nó se o nó falhar ou devido ao balanceamento de carga. Esse processo também pode detectar e remover dados duplicados, o que é possível se o serviço de telemetria usar filas de mensagens para encaminhar dados de instrumentação para o armazenamento. O diagrama a seguir mostra um exemplo dessa estrutura.

Armazenar dados de instrumentação

As seções anteriores mostram uma exibição simplificada de como armazenar dados de instrumentação. Na prática, você deve armazenar diferentes tipos de informações usando as tecnologias que se adequam a como você planeja usá-la.

Por exemplo, Armazenamento de Blobs do Azure e Armazenamento de Tabelas do Azure têm padrões de acesso semelhantes, mas as operações que podem ser executadas são limitadas e a granularidade dos dados armazenados varia. Se você precisar executar operações analíticas ou exigir recursos de pesquisa de texto completo, talvez seja necessário usar o armazenamento de dados que fornece as seguintes funcionalidades de consulta e acesso a dados:

• Armazene dados do contador de desempenho em um banco de dados SQL para habilitar a análise não planejada.
• Armazene logs de rastreamento no Azure Cosmos DB.
• Escreva informações de segurança no HDFS (Sistema de Arquivos Distribuído do Hadoop).
• Armazene informações que exigem pesquisa de texto completo usando o Elasticsearch, que usa a indexação avançada para acelerar pesquisas.

O diagrama a seguir mostra como você pode implementar um serviço extra que recupera periodicamente os dados do armazenamento compartilhado, particiona e filtra os dados de acordo com sua finalidade e grava-os em um conjunto apropriado de armazenamentos de dados. Uma abordagem alternativa é incluir essa funcionalidade no processo de consolidação e limpeza e gravar os dados diretamente nesses repositórios conforme eles são recuperados, em vez de salvá-los em uma área de armazenamento compartilhado intermediária. Cada abordagem tem vantagens e desvantagens. Implementar um serviço de particionamento separado reduz a carga no serviço de consolidação e limpeza. Ele também permite regenerar pelo menos alguns dos dados particionados, se necessário, dependendo da quantidade de dados que o armazenamento compartilhado retém. No entanto, essa abordagem consome mais recursos. Também pode atrasar o recebimento de dados de instrumentação de cada instância de aplicativo e a conversão desses dados em informações acionáveis.

Talvez você precise dos mesmos dados de instrumentação para mais de uma finalidade. Por exemplo, os contadores de desempenho podem fornecer uma exibição histórica do desempenho do sistema ao longo do tempo. Você pode combinar essas informações com outros dados de uso para gerar informações de cobrança do cliente. Nesses cenários, envie os mesmos dados para mais de um destino, como um banco de dados de documento que armazena informações de cobrança e um repositório multidimensional que manipula análises de desempenho complexas.

Considere a urgência de precisar dos dados. Os dados que fornecem informações para alertas devem ser acessados rapidamente, portanto, você deve armazená-los no armazenamento de dados rápido e indexá-los ou estruturá-los para otimizar as consultas do sistema de alertas. Em alguns casos, o serviço de telemetria que coleta os dados em cada nó pode precisar formatar e salvar dados localmente para que uma instância local do sistema de alertas possa notificá-lo rapidamente sobre problemas. Você pode expedir os mesmos dados para o serviço de gravação de armazenamento que os diagramas anteriores mostram e armazená-los de maneira centralizada se precisar dele para outras finalidades.

As informações que você usa para uma análise mais complexa, para relatórios e para identificar tendências históricas são menos urgentes. Armazene-o de forma que dê suporte à mineração de dados e consultas não planejadas. Para obter mais informações, consulte Dar suporte à análise quente, morna e fria.

Rotação de logs e retenção de dados

A instrumentação gera muitos dados. Em alguns casos, depois que os dados são processados e transferidos, você pode remover os dados de origem bruta originais de cada nó. Ou talvez seja necessário salvar as informações brutas.

Os dados de desempenho normalmente têm uma vida útil mais longa para que você possa usá-los para identificar as tendências de desempenho e a capacidade do plano. Mantenha a exibição consolidada desses dados online por um período finito para que você possa acessá-los rapidamente. Talvez seja necessário salvar os dados coletados para medição e cobrança indefinidamente. Além disso, os requisitos regulatórios podem exigir que você arquive e salve as informações coletadas para fins de auditoria e segurança. Criptografe ou proteja esses dados confidenciais para evitar adulteração. Nunca registre senhas de usuários ou outras informações pessoais. Limpe esses detalhes dos dados antes de armazená-los.

Subamostragem de dados

Armazene dados históricos para identificar tendências de longo prazo. Em vez de salvar todos os dados antigos, você pode reduzir os dados para reduzir sua resolução e economizar custos de armazenamento. Por exemplo, em vez de salvar indicadores de desempenho minuto a minuto, você pode consolidar dados com mais de um mês de idade para formar uma exibição hora a hora.

Práticas recomendadas para coletar e armazenar informações de log

A lista a seguir resume as práticas recomendadas para capturar e armazenar informações de log:

• O agente de monitoramento ou o serviço de coleta de dados deve ser executado como um serviço fora de processo e ser simples de implantar.

• Toda a saída do agente de monitoramento ou do serviço de coleta de dados deve ser um formato independente do computador, do sistema operacional ou do protocolo de rede. Por exemplo, emita informações em um formato autodescrevendo, como JSON, MessagePack ou Protobuf, em vez de arquivos ETL (Log de Rastreamento de Eventos) no Linux ou ETW. Use um formato padrão para que o sistema possa construir fluxos de processamento. Você pode integrar facilmente componentes que leem, transformam e enviam dados no formato acordado.

• O processo de monitoramento e coleta de dados deve ser à prova de falhas e não deve disparar erros em cascata.

• Se uma falha transitória enviar informações a um coletor de dados, o agente de monitoramento ou serviço de coleta de dados deverá estar preparado para reordenar dados de telemetria para que as informações mais recentes sejam enviadas primeiro. O agente de monitoramento ou o serviço de coleta de dados pode optar por remover os dados mais antigos ou salvá-los localmente e transmiti-los mais tarde para acompanhar, a seu próprio critério.

Analisar dados e diagnosticar problemas

Uma parte importante do monitoramento e do diagnóstico é analisar os dados coletados para obter uma imagem da integridade geral do sistema. Defina seus próprios KPIs e métricas de desempenho e aprenda a estruturar os dados para atender aos seus requisitos de análise. Entenda como os dados capturados em diferentes métricas e arquivos de log se correlacionam porque essas informações são fundamentais para acompanhar uma sequência de eventos e diagnosticar problemas.

Os dados de cada parte do sistema normalmente são capturados localmente, mas você precisa combiná-los com os dados gerados em outros sites que participam do sistema. Correlacione essas informações cuidadosamente para garantir que os dados sejam combinados com precisão. Por exemplo, os dados de uso de uma operação podem abranger os seguintes nós:

• Um nó que hospeda um site ao qual um usuário se conecta
• Um nó que executa um serviço à parte, acessado como parte dessa operação
• Um nó que armazena o armazenamento de dados

Você precisa unir essas informações para fornecer uma exibição geral do recurso e do uso de processamento para a operação. O nó que captura os dados pode pré-processá-los e filtrá-los, mas os nós centrais normalmente agregam e formatam os dados. Para obter mais informações, consulte Consolidar dados de instrumentação.

Compatível com análise quente, morna e fria

Analisar e reformatar dados para fins de visualização, relatórios e alertas pode ser um processo complexo que consome seu próprio conjunto de recursos. Algumas formas de monitoramento exigem que a análise imediata de dados seja eficaz, também conhecida como análise frequente. Exemplos incluem análise para alertas e monitoramento de segurança. Para análise em tempo real, disponibilize os dados e estruture-os para um processamento eficiente. Em alguns casos, talvez seja necessário mover o processamento de análise para os nós individuais que contêm os dados.

Outras formas de análise são menos sensíveis ao tempo e podem exigir computação e agregação depois que os dados brutos são recebidos. Esse método é chamado de análise calorosa. A análise de desempenho geralmente se enquadra nessa categoria. Nesse caso, um pico repentino ou uma falha pode causar um evento de desempenho único isolado que não é estatisticamente significativo. Os dados de uma série de eventos fornecem uma imagem mais confiável do desempenho do sistema.

Você também pode usar a análise térmica para ajudar a diagnosticar problemas de saúde. Use a análise hot para processar um evento de integridade e emitir imediatamente um alerta. Em seguida, use a análise warm para analisar os dados e encontrar a causa do evento de integridade.

Alguns tipos de monitoramento geram mais dados de longo prazo. Você pode executar essa análise posteriormente, possivelmente de acordo com um agendamento predefinido. Em alguns casos, a análise pode precisar filtrar grandes volumes de dados capturados ao longo do tempo. Esse método é chamado de análise a frio. O principal requisito é que você armazene os dados com segurança depois de capturá-los. Por exemplo, o monitoramento e a auditoria de uso exigem uma imagem precisa do estado do sistema em intervalos regulares, mas essas informações de estado não precisam estar disponíveis imediatamente para processamento.

Você também pode usar análise cold a fim de fornecer dados para análise da previsão de integridade. Reúna informações históricas ao longo de um período específico e combine-as com os dados de saúde atuais para identificar tendências que possam causar problemas de saúde. Nesses casos, talvez seja necessário gerar um alerta para corrigir a tendência.

Correlacionar dados

Os dados que a instrumentação captura podem fornecer um instantâneo do estado do sistema, mas a finalidade da análise é tornar esses dados acionáveis. Por exemplo, você pode determinar a causa do carregamento intenso de E/S no nível do sistema em um momento específico e garantir que os tempos de resposta do banco de dados, o número de transações por segundo e os tempos de resposta do aplicativo na mesma conjuntura confirmem suas descobertas.

Uma maneira de reduzir a carga é fragmentar os dados em mais servidores. Exceções podem ocorrer devido a uma falha em qualquer nível do sistema. Uma exceção em um nível geralmente dispara outra falha no nível acima dela.

Por esses motivos, você precisa correlacionar os diferentes tipos de dados de monitoramento em cada nível para produzir uma exibição geral do estado do sistema e dos aplicativos executados nele. Use essas informações para decidir se o sistema está funcionando de forma aceita e determinar o que você pode fazer para melhorar a qualidade.

Verifique se os dados brutos de instrumentação incluem informações suficientes de ID de contexto e atividade para dar suporte às agregações necessárias para correlacionar eventos. Esses dados podem ser mantidos em formatos diferentes, portanto, talvez seja necessário analisar e convertê-los em um formato padronizado para análise. Para obter mais informações, consulte Informações para correlacionar dados.

Solucionar problemas e diagnosticar problemas

Para diagnosticar problemas, você precisa realizar uma análise de causa raiz (RCA) para determinar a causa de falhas ou comportamentos inesperados. Normalmente, você precisa das seguintes informações para todo o sistema ou para um subsistema específico durante uma janela de tempo especificada:

• Informações detalhadas dos registros de eventos e rastros
• Concluir rastreamentos de pilha de exceções e falhas de qualquer nível especificado
• Despejos de falha para eventuais processos com falha
• Logs de atividades que registram as operações que todos os usuários ou usuários selecionados executam

Para analisar dados para fins de solução de problemas, você precisa de uma compreensão técnica profunda da arquitetura do sistema e de seus componentes. Você deve interpretar os dados, estabelecer a causa dos problemas e recomendar uma estratégia para corrigi-los. Outra estratégia é armazenar uma cópia dessas informações em seu formato original e disponibilizá-la para análise a frio por um especialista.

Visualizar dados e gerar alertas

Os sistemas de monitoramento devem apresentar dados para que você possa identificar rapidamente tendências ou problemas. Eles também devem notificá-lo imediatamente quando ocorrer um evento que exija atenção.

A apresentação de dados pode usar várias formas, incluindo visualização usando dashboards, alertas e relatórios.

Visualização usando dashboards

A maneira mais comum de visualizar dados é usar painéis que exibem informações como uma série de gráficos, gráficos ou outras ilustrações. Você pode parametrizar esses itens e selecionar os parâmetros importantes, como o período de tempo, para uma situação específica.

Você pode organizar dashboards hierarquicamente. Os painéis de nível superior fornecem uma visão geral de cada aspecto do sistema e permitem que você faça uma busca detalhada nos detalhes. Por exemplo, em um painel que ilustra a E/S geral do disco para o sistema, você pode exibir as taxas de E/S para cada disco individual para determinar se um ou mais dispositivos específicos representam um volume desproporcional de tráfego. O painel também deve exibir informações relacionadas, como o usuário ou a atividade que gera essa E/S. Essas informações podem ajudá-lo a espalhar a carga de forma mais uniforme entre os dispositivos.

Um painel também pode usar codificação de cores ou outras indicações visuais para indicar valores que aparecem anômalos ou que estão fora de um intervalo esperado. Considere os seguintes exemplos de codificação de cores:

• Vermelho para um disco com uma taxa de E/S se aproximando de sua capacidade máxima durante um longo período ou um disco quente

• Amarelo para um disco cuja taxa de E/S atinge periodicamente seu limite máximo por curtos períodos, ou para um disco morno

• Verde para um disco com uso normal

Os sistemas de dashboard devem ter os dados brutos para funcionar efetivamente. Se você criar seu próprio sistema de dashboard ou usar um painel desenvolvido por outra organização, deverá entender quais dados de instrumentação você precisa coletar, em quais níveis de granularidade e como formatá-los para o painel consumir.

Um painel eficaz também permite que você faça perguntas sobre informações. Alguns sistemas fornecem ferramentas de gerenciamento que você pode usar para executar essas tarefas e explorar os dados subjacentes. Dependendo do repositório que contém as informações, você poderá consultar dados diretamente ou importá-los em ferramentas como Excel para análise e relatórios adicionais.

Emitir alertas

O alerta analisa os dados de monitoramento e instrumentação e gera uma notificação se ele detecta um evento significativo.

O alerta ajuda a garantir que o sistema permaneça íntegro, responsivo e seguro. É uma parte importante de qualquer sistema que oferece garantias de desempenho, disponibilidade e privacidade aos usuários. O alerta também pode notificar você sobre eventos que disparam alertas. Use alertas para invocar funções do sistema, como dimensionamento automático.

O alerta depende dos seguintes dados de instrumentação:

• Eventos de segurança: Se os logs de eventos indicarem que ocorrem falhas repetidas de autenticação ou autorização. Nesse cenário, um alerta deve informá-lo de que o sistema pode estar sob ataque.

• Métricas de desempenho: O sistema deve responder rapidamente se uma métrica de desempenho exceder um limite especificado.

• Informações de disponibilidade: Se uma falha for detectada, talvez seja necessário reiniciar rapidamente um ou mais subsistemas ou fazer failover em um recurso de backup. Falhas repetidas em um subsistema podem indicar problemas mais graves.

Você pode receber informações de alerta por meio de muitos canais, como email, pager ou mensagem de texto SMS. Um alerta também pode incluir uma indicação de quão crítica é uma situação. Muitos sistemas de alerta dão suporte a grupos de assinantes e todos os operadores que são membros do mesmo grupo recebem o mesmo conjunto de alertas.

Torne o sistema de alertas personalizável e forneça os valores apropriados dos dados de instrumentação subjacentes como parâmetros. Usando essa abordagem, você pode filtrar dados para limites específicos ou combinações de valores. Em alguns casos, você pode fornecer os dados brutos de instrumentação para o sistema de alertas. Ou pode ser mais apropriado fornecer dados agregados. Por exemplo, um alerta é acionado quando a utilização da CPU de um nó excede 90% durante os últimos 10 minutos. Forneça ao sistema de alerta informações resumidas e de contexto adequadas para reduzir a possibilidade de que eventos falsos positivos acionem um alerta.

Reportagem

Use relatórios para gerar uma exibição geral do sistema. Pode incorporar dados históricos e informações atuais. Os requisitos de relatório se enquadram em categorias operacionais e de segurança.

O relatório operacional normalmente inclui os seguintes aspectos para o sistema geral ou subsistemas específicos durante uma janela de tempo especificada:

• Estatísticas agregadas que você pode usar para entender a utilização de recursos

• Tendências no uso de recursos

• Monitoramento de exceções

• Eficiência do aplicativo em termos de recursos implantados e se você pode reduzir o volume de recursos sem afetar o desempenho

Os relatórios de segurança rastreiam como os clientes usam o sistema. Normalmente, ele inclui os seguintes aspectos:

• Auditar operações do usuário. Registre solicitações individuais que cada usuário executa junto com datas e horas. Estruturar os dados para que você possa reconstruir rapidamente a sequência de operações que um usuário executa durante um período especificado.

• Acompanhe o uso de recursos para cada usuário. Registre como cada solicitação de um usuário acessa os recursos do sistema e por quanto tempo. Use esses dados para gerar um relatório de utilização para cada usuário durante um período especificado, possivelmente para fins de cobrança.

Em muitos casos, os processos em lotes podem gerar relatórios de acordo com um agendamento definido. A geração de relatórios normalmente não aumenta a latência, portanto, você pode gerar relatórios sob demanda, se necessário. Se você armazenar dados em um banco de dados relacional, como Banco de Dados SQL do Azure, poderá usar uma ferramenta como SQL Server Reporting Services para extrair e formatar dados e apresentá-los como um conjunto de relatórios.

Próximas Etapas 

• Visão geral do Azure Monitor
• Monitorar, diagnosticar e solucionar problemas de armazenamento
• Visão geral de alertas no Azure
• Visão geral do Application Insights
• Diagnóstico de desempenho para VMs do Azure

Recursos relacionados

• As diretrizes de dimensionamento automático descrevem como diminuir a sobrecarga de gerenciamento reduzindo a necessidade de monitorar continuamente o desempenho do sistema e tomar decisões para adicionar ou remover recursos.

• Padrão de monitoramento de ponto de extremidade de integridade descreve como implementar verificações funcionais dentro de um aplicativo que ferramentas externas podem acessar por meio de pontos de extremidade expostos em intervalos regulares.

• O padrão fila de prioridade descreve como priorizar mensagens enfileiradas para que os sistemas recebam e processem solicitações urgentes antes de mensagens menos urgentes.