Melhores práticas para monitorização e diagnóstico

Aplicações e serviços distribuídos que correm na cloud são peças complexas de software que compreendem muitas partes móveis. Num ambiente de produção, é importante acompanhar como os clientes utilizam o seu sistema, rastrear a utilização de recursos e monitorizar a saúde e o desempenho do seu sistema. Pode usar esta informação para detetar e corrigir problemas e detetar potenciais problemas antes que ocorram.

Cenários de monitorização e diagnóstico

Pode usar a monitorização para obter informações sobre o funcionamento de um sistema. A monitorização é uma parte crucial da manutenção das metas de qualidade de serviço (QoS). Recolha dados de monitorização para os seguintes cenários comuns:

• Garantir que o sistema se mantém saudável.

• Acompanhe a disponibilidade do sistema e dos seus componentes.

• Mantenha o desempenho para garantir que o rendimento do sistema não se degrada inesperadamente à medida que o volume de trabalho aumenta.

• Garantir que o sistema cumpre os acordos de nível de serviço (SLAs).

• Proteger a privacidade e segurança do sistema, dos utilizadores e dos seus dados.

• Monitorizar auditorias ou operações regulamentares.

• Monitorize o uso diário do sistema e aborde tendências que possam causar problemas.

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

• Monitorize operações e depure versões de software.

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

Monitorização de saúde

Um sistema saudável funciona e pode processar pedidos. Use a monitorização da saúde para gerar um instantâneo do estado atual do sistema, de modo a verificar se todos os componentes funcionam como esperado.

Configurar alertas

O sistema deverá emitir um alerta em segundos se alguma parte estiver insalubre. Os alertas podem destacar o estado do sistema através de sinais tipo semáforo:

• Vermelho para doente (o sistema parou)
• Amarelo para parcialmente saudável (o sistema corre com funcionalidades reduzidas)
• Verde para saudável

Um sistema abrangente de monitorização da saúde mostra-lhe o estado de saúde de cada subsistema e componente, para que possa determinar quais as partes que funcionam normalmente e quais estão a apresentar problemas.

Recolha de dados de saúde

As seguintes fontes podem gerar os dados brutos necessários para apoiar a monitorização da saúde:

• Rastreie a execução dos pedidos dos utilizadores. Pode usar esta informação para determinar quais os pedidos bem-sucedidos ou falhados e para medir quanto tempo cada pedido demora.

• Monitorize utilizadores sintéticos. Este processo simula as ações que o utilizador realiza e segue uma série pré-definida de passos. Regista os resultados de cada etapa.

• Registo exceções, falhas e avisos. Pode captar esta informação a partir de instruções trace embutidas no código da aplicação e dos registos de eventos dos serviços que o sistema referencia.

• Monitorize o estado dos serviços não serviços Microsoft que o sistema utiliza. Pode precisar de recuperar e analisar dados de saúde que estes serviços fornecem.

• Monitorizar os endpoints.

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

Analisar dados de saúde

O foco principal da monitorização de saúde é indicar rapidamente se o sistema está a funcionar. Uma análise rápida de dados imediatos pode desencadear um alerta se um componente crítico estiver insalubre.

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

• A taxa de pedidos dirigidos a cada serviço ou subsistema
• Os tempos de resposta destes pedidos
• O volume de dados que entra e sai de cada serviço

Se o valor de qualquer métrica ultrapassar um limiar definido, o sistema pode emitir um alerta para aumentar a escala. Também poderá adicionar recursos, reiniciar serviços que estejam a falhar ou limitar os pedidos de prioridade inferior para manter o bom funcionamento do sistema.

Monitoramento de disponibilidade

Num sistema saudável, todos os componentes e subsistemas estão disponíveis. A monitorização de disponibilidade está intimamente relacionada com a monitorização de saúde. A monitorização da saúde proporciona uma visão imediata do estado atual do sistema. A monitorização da disponibilidade acompanha a disponibilidade do sistema e dos seus componentes para gerar estatísticas sobre o tempo de atividade.

Em muitos sistemas, alguns componentes, como bases de dados, estão configurados com redundância incorporada para permitir um failover rápido caso ocorra uma falha grave ou perda de conectividade. Recolha o máximo de informação possível sobre estas falhas para determinar a causa e tomar medidas 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 da aplicação, sistema e ambiente. Um sistema de monitorização eficaz recolhe os dados de disponibilidade correspondentes a estes fatores de baixo nível e depois agrega-os para fornecer uma imagem global do sistema. Por exemplo, num sistema de comércio eletrónico, a funcionalidade empresarial que permite a um cliente fazer encomendas pode depender do repositório que armazena os detalhes das encomendas e do sistema de pagamentos que gere as transações monetárias. A disponibilidade da funcionalidade de colocação de encomendas depende da disponibilidade do repositório e do subsistema de pagamento.

A solução de monitorização da disponibilidade fornece vistas atuais e históricas do estado de disponibilidade de cada subsistema. Alerta rapidamente quando um ou mais serviços falham ou quando os utilizadores não conseguem ligar-se aos serviços. Use esta informação para identificar tendências que possam causar falhas em subsistemas. Por exemplo, pode usar dados de disponibilidade para detetar quais os serviços que falham durante as horas de maior ponta de processamento.

Recolha de dados de disponibilidade

Monitorizar utilizadores sintéticos, registar exceções, falhas e avisos, e monitorizar os endpoints para gerar os dados brutos necessários para suportar a monitorização da disponibilidade. A aplicação pode expor um ou mais endpoints de saúde que testam o acesso a uma área funcional dentro do sistema. O sistema de monitorização segue um cronograma definido para fazer ping a cada endpoint e recolher os resultados, como sucesso ou falha.

Regista todos os tempos limite, as falhas de conectividade de rede e as tentativas de repetição da ligação, e regista a data e hora de todos os dados.

Analisar dados de disponibilidade

Agregue e correlacione os dados para apoiar os seguintes tipos de análise:

• A disponibilidade imediata do sistema e dos subsistemas.

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

• Uma visão histórica das taxas de falha ao longo de um período especificado e da carga no sistema, como o número de pedidos dos utilizadores, quando ocorre uma falha.

• As razões para a indisponibilidade do sistema ou subsistemas. Essas razões incluem o serviço não estar em execução, perda de ligação, expiração do tempo limite ou respostas com códigos de erro.

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

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

Use esta fórmula para monitorização de SLA. A definição de tempo de inatividade depende do serviço. Por exemplo, o serviço de compilação Azure DevOps define o tempo de inatividade como o período, em minutos acumulados totais, durante o qual o serviço de compilação está indisponível. O serviço é considerado indisponível durante um minuto se todos os pedidos HTTP contínuos durante esse minuto resultarem num código de erro ou não responderem.

Monitorização do desempenho

À medida que o volume de utilizadores aumenta, o tamanho dos conjuntos de dados a que acede cresce e a possibilidade de falha de um ou mais componentes torna-se mais provável. A degradação do desempenho ocorre frequentemente antes da falha dos componentes. Se conseguir detetar degradação, pode tomar medidas proativas para evitar falhas.

O desempenho do sistema depende de múltiplos fatores. Normalmente, mede cada fator através de indicadores-chave de desempenho (KPIs), como o número de transações de base de dados por segundo ou o volume de pedidos de rede bem atendidos num período de tempo especificado. Alguns destes KPIs podem estar disponíveis como medidas de desempenho específicas, enquanto outros podem ser derivados de uma combinação de métricas.

Requisitos para a monitorização do desempenho

Para avaliar o desempenho do sistema, normalmente precisa da seguinte informação:

• As taxas de resposta aos pedidos dos utilizadores
• O número de solicitações simultâneas de utilizadores
• O volume do tráfego de rede
• As taxas a que o sistema conclui transações comerciais
• O tempo médio de processamento dos pedidos

Use ferramentas que o possam ajudar a identificar as seguintes correlações:

• O número de utilizadores concorrentes versus tempos de latência dos pedidos, ou quanto tempo demora a começar a processar um pedido depois de o utilizador o enviar

• O número de utilizadores em simultâneo versus o tempo médio de resposta, ou quanto tempo demora a concluir um pedido depois de este começar a ser processado

• O volume de pedidos versus o número de erros de processamento

Juntamente com esta informação funcional de alto nível, obtenha uma visão detalhada do desempenho de cada componente do sistema. Contadores de desempenho de baixo nível normalmente fornecem estes dados. Eles acompanham as seguintes informações:

• Utilização da memória
• Número de threads
• Tempo de processamento da CPU
• Tamanho da fila de espera
• Taxas e erros de I/O em disco ou rede
• Número de bytes escritos ou lidos
• Indicadores de middleware, como o comprimento da fila

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

Coletar dados de desempenho

Recolha dados de desempenho de alto nível, como a taxa de transferência, o número de utilizadores concorrentes, o número de transações de negócio e as taxas de erro, monitorizando o progresso dos pedidos dos utilizadores. Incorpore instruções de rastreamento e informações de temporização em pontos-chave do código da aplicação. Capturar todas as falhas, exceções e avisos com dados suficientes e correlacioná-los com os pedidos que os causaram.

Se possível, recolha dados de desempenho de quaisquer sistemas externos que a aplicação utilize. Esses sistemas externos podem fornecer seus próprios contadores de desempenho ou outros recursos para solicitar dados de desempenho. Se este método não for possível, regista informações como a hora de início e o fim de cada pedido a um sistema externo e o estado de sucesso, falha ou aviso da operação.

Dados de desempenho de baixo nível para componentes individuais num sistema podem estar disponíveis através de funcionalidades e serviços como contadores de desempenho do Windows que o Azure Monitor Agent recolhe.

Analisar dados de desempenho

A maioria das análises agrega dados de desempenho por tipo de pedido do utilizador ou pelo subsistema ou serviço para o qual cada pedido é enviado. Um exemplo de pedido de utilizador é adicionar um artigo a um carrinho de compras ou ao processo de compra num sistema de comércio eletrónico.

Outro requisito comum é resumir os dados de desempenho em percentis. Por exemplo, pode determinar os tempos de resposta para 99% de pedidos, 95% de pedidos e 70% de pedidos. Podes definir metas de SLA ou outras metas para cada percentil. Reporte resultados em curso quase em tempo real para ajudar a detetar problemas imediatamente. Agrega 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 passo que cada pedido realiza. Os dados de desempenho devem fornecer uma forma de correlacionar métricas de desempenho para cada etapa, associando-as a um pedido específico.

Dependendo das suas necessidades de visualização, pode ser útil gerar e armazenar um cubo de dados que contenha vistas dos dados brutos. Este cubo de dados pode permitir consultas e análises complexas e não planeadas da informação de desempenho.

Monitorização de segurança

Todos os sistemas comerciais que incluam dados sensíveis devem implementar uma estrutura de segurança. A sensibilidade dos dados determina tipicamente a complexidade do mecanismo de segurança. Num sistema que exija autenticação dos utilizadores, regista a seguinte informação:

• Todas as tentativas de registo e se falham ou têm sucesso

• Todas as operações realizadas por um utilizador autenticado e os detalhes de todos os recursos a que acede

• Quando um utilizador termina uma sessão e sai

A monitorização pode ajudar a detetar ataques ao sistema. Por exemplo, várias tentativas de início de sessão falhadas podem indicar um ataque de força bruta. Um aumento inesperado de pedidos pode ser resultado de um ataque DDoS. Esteja preparado para monitorizar todos os pedidos a todos os recursos, independentemente da sua origem. Um sistema com uma vulnerabilidade de início de sessão pode expor acidentalmente recursos sem que o utilizador precise de iniciar sessão.

Requisitos para o controlo de segurança

Os dados que a monitorização de segurança recolhe podem ajudá-lo a:

• Detetar tentativas de intrusão por uma entidade não autenticada.

• Identificar tentativas de entidades de realizar operações sobre dados a que não têm acesso.

• Determine se um utilizador não autenticado ou um utilizador autenticado malicioso está a tentar atacar o sistema.

Para suportar estas tarefas, o sistema deve enviar alertas se:

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

• Uma conta autenticada tenta repetidamente acessar 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 do host da fonte para cada pedido. Se violações de segurança ocorrerem regularmente a partir de um intervalo específico de endereços, pode bloquear esses hosts.

Uma parte fundamental para manter a segurança de um sistema é a capacidade de detetar rapidamente ações que se desviem do padrão habitual. Pode apresentar visualmente informações, como o número de tentativas de início de sessão sem êxito ou bem-sucedidas, para ajudar a detetar picos de atividade em horas invulgares. Também pode usar esta informação para configurar o autoescalonamento baseado no tempo. Por exemplo, se vir que muitos utilizadores iniciam sessão regularmente numa hora específica, pode iniciar serviços de autenticação extra para gerir o volume de trabalho. Encerre estes serviços após a passagem do período de pico.

Recolha de dados de segurança

A segurança é um aspeto abrangente da maioria dos sistemas distribuídos, e a monitorização gera dados pertinentes em múltiplos pontos do sistema. Adote uma abordagem de Gestão de Informação e Eventos de Segurança (SIEM) para recolher informações resultantes de eventos gerados pela aplicação, equipamentos de rede, servidores, firewalls, software antivírus e outros elementos de prevenção de intrusões.

A monitorização de segurança pode incorporar dados de ferramentas fora da sua aplicação. Estas ferramentas incluem utilitários que identificam atividades de varredura de portas por agências externas e filtros de rede que detetam tentativas de acesso não autenticado à sua aplicação e dados. Em alguns casos, as ferramentas de integração contínua e entrega contínua (CI/CD) constituem uma parte importante do ciclo de vida da aplicação. Estas ferramentas também devem sinalizar comportamentos anómalos.

Analisar dados de segurança

Uma característica fundamental da monitorização de segurança é que recolhe dados de várias fontes. Os diferentes formatos e níveis de detalhe frequentemente exigem uma análise complexa para compilar os dados num fio coerente de informação. Pode detetar falhas em iniciar sessão ou tentativas repetidas de obter acesso não autorizado a recursos, mas o processamento automatizado e complexo dos dados de segurança pode não ser viável. Neste cenário, é necessário marcar o horário dos dados e escrevê-los num repositório seguro na sua forma original para análise manual de especialistas.

Monitoramento de SLA

Os sistemas comerciais que suportam clientes pagantes assumem compromissos sobre o desempenho do sistema sob a forma de SLAs. Os SLAs afirmam que o sistema pode gerir um volume definido de trabalho dentro de um prazo acordado e sem perder informação crítica. A monitorização de SLA assegura que o sistema cumpre SLAs mensuráveis.

As seguintes métricas definem SLAs:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode comprometer-se com a disponibilidade do sistema 99,9% do tempo. Esta percentagem equivale a não mais do que nove horas de inatividade por ano, ou aproximadamente 10 minutos por semana.

• Rendimento operacional. Este aspeto é frequentemente expresso como um ou mais marcos altos, como o compromisso de que o sistema pode suportar até 100.000 pedidos simultâneos de utilizadores ou gerir 10.000 transações comerciais simultâneas.

• Tempo de resposta operacional. O sistema pode também precisar de processar pedidos a uma taxa definida. Por exemplo, 99% de todas as transações empresariais devem ser concluídas em 2 segundos, e nenhuma transação individual demora mais de 10 segundos.

Requisitos para monitoramento de SLA

Deverá conseguir rapidamente determinar se o sistema cumpre um SLA. Se não cumprir o SLA, é necessário avaliar os fatores subjacentes para encontrar a causa do desempenho abaixo do padrão.

Pode representar visualmente os seguintes indicadores de alto nível:

• A percentagem de tempo de atividade do serviço

• A taxa de processamento da aplicação, medida em termos de transações bem-sucedidas ou de operações bem-sucedidas por segundo

• O número de pedidos de candidatura bem-sucedidos ou falhados

• O número de falhas de aplicação e sistema, exceções e avisos

Certifique-se de que consegue filtrar todos estes indicadores por um período de tempo especificado.

A sua aplicação cloud provavelmente compreende múltiplos subsistemas e componentes. Deverá ser capaz de selecionar um indicador de alto nível, como o tempo de funcionamento total do sistema, e determinar quais os elementos subjacentes que afetam o seu estado de saúde.

Para efeitos de alerta, o sistema deve gerar um evento se algum dos indicadores de alto nível ultrapassar um limiar especificado. Disponibilize os detalhes de nível inferior ao sistema de alertas como dados contextuais.

Recolha de dados de SLA

Tomar as seguintes ações para recolher os dados brutos necessários para a monitorização do SLA:

• Efetue a monitorização de endpoints.
• Registo exceções, falhas e avisos.
• Rastreie a execução dos pedidos dos utilizadores.
• Monitorize a disponibilidade de quaisquer serviços não serviços Microsoft que o sistema utilize.
• Use métricas de desempenho e contadores.

Todos os dados devem ser cronometrados e com carimbo de data/hora.

Analisar dados de SLA

Agrega os dados de SLA para gerar uma imagem do desempenho global do sistema. Também deves ser capaz de aprofundar os dados agregados para avaliar subsistemas subjacentes. Por exemplo, deverá ser capaz de realizar as seguintes tarefas:

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

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

• Analise o progresso dos pedidos dos utilizadores para decompor o tempo total de resposta nos tempos de resposta dos itens individuais do pedido.

• Determine a disponibilidade global do sistema como percentagem do tempo de funcionamento para um período específico.

• Analisar a disponibilidade de tempo percentual dos componentes e serviços individuais no sistema. Pode ser necessário analisar registos gerados por serviços que não são da Microsoft.

Os sistemas comerciais devem reportar números reais de desempenho em relação aos SLAs durante um período especificado. Pode usar esta informação para calcular créditos ou outras formas de reembolso para clientes caso não cumpra os SLAs durante esse período. Pode calcular a disponibilidade de um serviço utilizando a técnica descrita em Analisar dados de disponibilidade.

Para fins internos, uma organização pode também monitorizar o número e a natureza dos incidentes que causam a falha dos serviços. Aprenda a resolver estes problemas rapidamente ou a eliminá-los para reduzir o tempo de inatividade e cumprir os SLAs.

Auditing

Dependendo da natureza da aplicação, os regulamentos legais podem especificar requisitos para auditar as operações dos utilizadores e registar todo o acesso aos dados. A auditoria pode fornecer evidências que vinculam os clientes a solicitações específicas. A não repudiação é 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 pela aplicação ou serviço.

Requisitos para auditoria

Deve ser capaz de rastrear a sequência das operações empresariais que os utilizadores realizam para poder reconstruir as ações dos utilizadores. Este registo 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 sensíveis. Provavelmente inclui dados que identificam os utilizadores do sistema e as tarefas que realizam. Por esta razão, a informação de auditoria está provavelmente disponível apenas para analistas de confiança, 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 todas as atividades dos utilizadores durante um período de tempo especificado

• Relatórios que detalham a cronologia de atividade de um único utilizador

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

Recolha de dados de auditoria

As principais fontes de informação para auditoria incluem:

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

Os requisitos regulamentares podem determinar o formato dos dados de auditoria e como os armazena. Se as regulamentações exigirem que grave os dados no seu formato original, pode não conseguir limpá-los. Como resultado, o acesso ao repositório que o armazena deve estar cuidadosamente protegido para evitar adulterações.

Analisar dados de auditoria

Deve ser capaz de aceder aos dados brutos na sua totalidade e na sua forma original. Para além da necessidade de gerar relatórios de auditoria comuns, as ferramentas para analisar estes dados são provavelmente especializadas e mantidas externas ao sistema.

Monitorização da utilização

A monitorização de utilização acompanha como os clientes utilizam as funcionalidades e componentes de uma aplicação. Pode usar os dados para:

• Identifique funcionalidades populares e potenciais pontos críticos no sistema. Elementos de alto tráfego podem beneficiar de particionamento funcional ou replicação para distribuir a carga de forma mais uniforme. Também pode usar esta informação para determinar quais as funcionalidades que são usadas com pouca frequência e que são possíveis candidatas à reforma ou substituição numa versão futura do sistema.

• Obter informações sobre os eventos operacionais do sistema em uso normal. Por exemplo, num site de comércio eletrónico, pode registar informação estatística sobre o número de transações e o volume de clientes responsáveis por elas. Pode usar esta informação para planear a capacidade à medida que o número de clientes cresce.

• Detetar a satisfação do utilizador com o desempenho e a funcionalidade do sistema. Por exemplo, se muitos clientes num sistema de comércio eletrónico abandonam regularmente os seus carrinhos de compras, pode haver um problema com a funcionalidade de pagamento.

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

• Fazer cumprir as quotas. Se um utilizador num sistema multitenant exceder a quota paga de tempo de processamento ou utilização de recursos durante um período especificado, pode limitar o seu acesso ou limitar o processamento.

• Detetar problemas barulhentos de vizinhos. Para ajudar a conduzir investigações de erros ou decisões de produto, determine se o tráfego está distribuído de forma uniforme ou se um pequeno grupo de utilizadores gera a maior parte do tráfego. Se um único utilizador gerar tráfego significativo, a funcionalidade pode precisar de ajustes de desempenho. Em alternativa, pode decidir impor quotas extra para reduzir o tráfego.

Requisitos para monitoramento de uso

Para avaliar o uso do sistema, normalmente precisa da seguinte informação:

• O número de pedidos que cada subsistema processa e direciona para cada recurso

• O trabalho que cada utilizador realiza

• O volume de armazenamento de dados que cada utilizador ocupa

• Os recursos a que cada utilizador acede

Também deves conseguir gerar gráficos. Exemplos comuns incluem grafos de utilizadores que consomem mais recursos e os recursos ou funcionalidades do sistema mais frequentemente acedidas.

Recolha de dados de utilização

Pode realizar um acompanhamento de uso de alto nível anotando as horas de início e fim de cada pedido e a natureza de cada pedido, como leitura ou escrita. Para captar esta informação, execute as seguintes tarefas:

• Rastrear a atividade dos utilizadores.
• Capturar contadores de desempenho que medem a utilização de cada recurso.
• Monitorize o consumo de recursos de cada utilizador.

Para efeitos de medição, também é necessário identificar quais os utilizadores que realizam que operações e os recursos que essas operações utilizam. Certifique-se de que a informação que recolhe é suficientemente detalhada para apoiar uma faturação precisa.

Acompanhamento de problemas

Clientes e outros utilizadores podem reportar problemas se ocorrerem eventos ou comportamentos inesperados no sistema. O acompanhamento de problemas gere estes problemas, associa-os aos esforços para os resolver e informa os clientes sobre as soluções.

Requisitos para o acompanhamento de problemas

Para acompanhar problemas, utilize um sistema separado que lhe permita registar e reportar os detalhes dos problemas reportados pelos utilizadores. Estes detalhes incluem as tarefas tentadas, sintomas do problema, a sequência de eventos e mensagens de erro ou aviso.

Recolha de dados de acompanhamento de questões

A fonte inicial de dados para o acompanhamento de problemas é o utilizador que reporta o problema. Este utilizador poderá fornecer os seguintes detalhes:

• Um crash dump, se a aplicação incluir um componente que corre no ambiente de trabalho do utilizador

• Um instantâneo de ecrã

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

Utilize esta informação para o ajudar a depurar o sistema e criar uma lista de pendências para futuras versões do software.

Analisar dados de acompanhamento de problemas

Utilizadores diferentes podem reportar o mesmo problema, e o sistema de monitorização de problemas deve associar relatórios comuns.

Registe o progresso do esforço de depuração relativamente a cada relatório. Quando resolver o problema, informe o cliente da solução.

Se um utilizador reportar um problema que tenha uma solução conhecida no sistema de monitorização, pode informar imediatamente o utilizador da solução.

Monitorização de operações e depuração de versões de software

Quando um utilizador reporta um problema, normalmente só tem consciência do efeito imediato que tem nas suas operações. O utilizador só pode reportar os resultados da sua própria experiência. Estas experiências são geralmente um sintoma visível de um ou mais problemas fundamentais. Em muitos casos, um analista precisa de analisar a cronologia das operações subjacentes para estabelecer a causa raiz do problema. Este processo chama-se análise da causa raiz (RCA).

Requisitos para rastreio e depuração

Para rastrear eventos inesperados e outros problemas, os dados de monitorização devem fornecer informação suficiente para permitir que um analista encontre a origem do problema e reconstrua a sequência de eventos. Depois, um programador pode fazer modificações para evitar que o problema volte a acontecer.

Recolha de dados de rastreio e depuração

Para resolver problemas, rastreie todos os métodos e os seus parâmetros invocados como parte de uma operação. Depois, crie uma árvore que represente o fluxo lógico através do sistema quando um cliente faz um pedido específico. Capturar e registar exceções e avisos que o sistema gera como resultado deste fluxo.

Para suportar a depuração, o sistema fornece ganchos que pode usar para captar informação de estado em pontos cruciais do sistema. Ou o sistema pode fornecer informações detalhadas passo a passo à medida que as operações selecionadas avançam. Capturar dados a este nível de detalhe pode aumentar a carga sobre o sistema e deve ser um processo temporário. Use este processo quando ocorrem eventos invulgares e difíceis de replicar ou quando uma nova versão exige uma monitorização cuidadosa para garantir que os elementos funcionam como esperado.

O pipeline de monitorização e diagnóstico

A monitorização de um sistema distribuído em grande escala coloca um desafio significativo. Não deve necessariamente considerar cada um dos cenários descritos nas secções anteriores isoladamente. Os dados de monitorização e diagnóstico necessários para cada situação sobrepõem-se, mas pode ser necessário processar e apresentar esses dados de formas diferentes. Por estas razões, adote uma visão holística da monitorização e diagnóstico.

Pode imaginar todo o processo de monitorização e diagnóstico como um pipeline que compreende as etapas mostradas no diagrama seguinte.

O diagrama mostra como os dados de monitorização e diagnóstico provêm de várias fontes. As fases de instrumentação e recolha ajudam-no a identificar os dados que precisa de recolher, onde e como os recolher, e como formatar os dados para que os possa analisar facilmente. A fase de análise e diagnóstico pega nos dados brutos e utiliza-os para gerar informação significativa que pode usar para determinar o estado do sistema. Pode usar esta informação para determinar quais as possíveis ações a tomar e depois alimentar os resultados para as fases de instrumentação e recolha. A fase de visualização e emissão de alertas apresenta uma visão de fácil interpretação do estado do sistema. Ele pode exibir informações quase em tempo real usando uma série de painéis. Pode gerar relatórios, gráficos e gráficos para fornecer uma visão histórica dos dados que o ajudam a identificar tendências de longo prazo. Se a informação indicar que um KPI provavelmente ultrapassa limites aceitáveis, esta fase também pode desencadear um alerta. Em alguns casos, um alerta pode também desencadear um processo automatizado que tenta tomar ações corretivas, como o autoescalonamento.

Estes passos formam um processo de fluxo contínuo em que os estágios correm em paralelo. Idealmente, todas as fases devem ser configuradas dinamicamente. Em alguns momentos, especialmente quando um sistema é recém-implementado ou está a enfrentar problemas, pode ser necessário recolher dados extensos com mais frequência. Noutras ocasiões, pode continuar a recolher informações essenciais e de alto nível para verificar se o sistema está a funcionar corretamente.

Trate todo o processo de monitorização como uma solução contínua e em tempo real que precisa de ajustes finos e melhorias com base no feedback. Por exemplo, pode começar por medir muitos fatores para determinar a saúde do sistema e refinar a sua análise ao longo do tempo para descartar medidas que não são relevantes.

Fontes de dados de monitorização e diagnóstico

A informação utilizada pelo processo de monitorização pode provir de várias fontes. Ao nível da aplicação, a informação provém de registos de rastreio que integra no código do sistema. Os desenvolvedores devem seguir uma abordagem padrão para rastrear o fluxo de controle através de seu código. Por exemplo, uma entrada de um método pode emitir uma mensagem de traço que especifica o nome do método, a hora atual, o valor de cada parâmetro e outras informações pertinentes. Também pode querer registar os horários de entrada e saída.

Registe todas as exceções e avisos, e certifique-se de que mantém um registo completo de quaisquer exceções e avisos aninhados. Recolha informação que identifica o utilizador que executa o código e a informação de correlação de atividade para acompanhar pedidos à medida que passam pelo sistema. Registe as tentativas de acesso a todos os recursos, como filas de mensagens, bases de dados, ficheiros e outros serviços dependentes. Pode usar esta informação 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. Pode ser possível configurar estes frameworks para fornecerem as suas próprias mensagens de rastreio e informação diagnóstica bruta, como taxas de transação e sucessos e falhas na transmissão de dados.

O sistema operativo em que a aplicação corre pode ser uma fonte de informação de baixo nível, a nível de todo o sistema, como contadores de desempenho que indicam taxas de E/S, utilização de memória e utilização da CPU. Também pode reportar erros do sistema operativo, como a falha em abrir corretamente um ficheiro.

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

Se a sua aplicação utilizar outros serviços externos, como um servidor web ou um sistema de gestão de bases de dados (SGBD), estes serviços podem publicar as suas próprias informações de rastreio, registos e contadores de desempenho. Por exemplo, as vistas de gestão dinâmicas (DMVs) no SQL Server monitorizam as operações efetuadas numa base de dados do SQL Server. O Application Insights utiliza registos de rastreio para registar pedidos efetuados ao Serviço de Aplicações do Azure.

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

Use as seguintes estratégias para recolher dados de monitorização e diagnóstico:

• A monitorização de aplicações e sistemas utiliza fontes internas dentro da aplicação, frameworks de aplicação, sistema operativo e infraestrutura. O código da aplicação pode gerar os seus próprios dados de monitorização em pontos notáveis durante o ciclo de vida de um pedido de cliente. A aplicação pode incluir instruções de rastreamento que pode ativar ou desligar conforme necessário. Também podes injetar diagnósticos dinamicamente usando um framework de diagnóstico. Estes frameworks normalmente fornecem plugins que se ligam a vários pontos de instrumentação no seu código e capturam dados de rastreio nesses pontos.

  O seu código ou a infraestrutura subjacente também podem gerar eventos em pontos críticos. Agentes de monitorização configurados para ouvir estes eventos podem registar a informação do evento.

• A monitorização real do utilizador regista as interações entre um utilizador e a aplicação e observa o fluxo de cada pedido e resposta. Use esta informação para medir a utilização por cada utilizador e determinar se os utilizadores recebem um QoS adequado, incluindo tempos de resposta rápidos, baixa latência e erros mínimos. Pode usar os dados para identificar áreas onde as falhas ocorrem com mais frequência. Também pode usar os dados para identificar zonas em que o sistema fica mais lento devido a pontos críticos na aplicação ou noutros gargalos. Se implementar esta abordagem com cuidado, poderá conseguir reconstruir os fluxos dos utilizadores através da aplicação para fins de depuração e teste.

  Importante

  Trate os dados capturados pela monitorização de utilizadores reais como altamente sensíveis, pois podem incluir material confidencial. Se você salvar os dados capturados, armazene-os com segurança. Se quiser usar os dados para monitorização de desempenho ou depuração, remova primeiro todos os dados pessoais.

• A monitorização sintética do utilizador exige que escreva o seu próprio cliente de teste que simule um utilizador e execute uma série de operações configurável, mas típica. Você pode acompanhar o desempenho do cliente de teste para ajudar a determinar o estado do sistema. Também pode usar várias instâncias do cliente de teste como parte de uma operação de testes de carga para determinar como o sistema responde sob stress e os dados de monitorização gerados por estas condições.

  Note

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

• O perfilamento ajuda-o a monitorizar e melhorar o desempenho da aplicação. Ao contrário da monitorização real do utilizador e da monitorização sintética do utilizador, que operam ao nível funcional, o perfil capta informação de nível inferior à medida que a aplicação é executada. Implemente a perfis amostrando periodicamente o estado de execução de uma aplicação ou determinando que pedaço de código a aplicação corre num momento específico. Também pode usar instrumentação que insere sondas no código em momentos importantes, como o início e o fim de uma chamada de método. As sondas registam quais os métodos invocados pela chamada, a que hora e quanto tempo demora cada chamada. Em seguida, você pode analisar esses dados para determinar quais partes do aplicativo podem causar problemas de desempenho.

• A monitorização de endpoints utiliza um ou mais endpoints de diagnóstico que a aplicação expõe especificamente para permitir a monitorização. Um ponto de extremidade fornece um caminho para o código do aplicativo e pode retornar informações sobre a integridade do sistema. Diferentes pontos finais podem concentrar-se em diversos aspetos da funcionalidade. Pode escrever o seu próprio cliente de diagnóstico que envie pedidos periódicos para estes endpoints e assimile as respostas. Para obter mais informações, consulte o modelo de Monitorização do Ponto de Extremo de Saúde.

• Os despejos de erro do utilizador dependem de a aplicação disponibilizar uma forma de recolher uma captura do estado da aplicação caso esta não consiga recuperar. Os utilizadores também precisam de partilhar voluntariamente esse instantâneo. Não podes garantir que um dump de erro seja executado, mas podes usar os dados de baixo nível que ele fornece para determinar a causa raiz dos erros. Este cenário é comum se os erros ocorrerem raramente ou se os erros ocorrerem apenas numa funcionalidade de aplicação pouco utilizada.

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

Instrumentar uma aplicação

A instrumentação é uma parte crítica do processo de monitorização. Deve recolher dados que o ajudem a tomar decisões significativas sobre o desempenho e a saúde do seu sistema. Use instrumentação para recolher informação suficiente para avaliar desempenho, diagnosticar problemas e tomar decisões sem ter de iniciar sessão num servidor de produção remoto para rastrear e depurar manualmente. Os dados de instrumentação normalmente compreendem métricas e informações escritas para registos de rastreamento.

Um registo de traços pode conter dados textuais que a aplicação escreve ou dados binários criados por um evento de traço, se a aplicação utilizar Rastreamento de Eventos para Windows (ETW). Os registos do sistema que registam eventos que ocorrem em partes da infraestrutura, como um servidor web, também podem gerar conteúdo de registos de rastreamento. As mensagens de registo textuais são frequentemente legíveis por humanos, mas escrevem-nas num formato que um sistema automatizado também consegue analisar facilmente.

Também categoriza os registos. Não escrevas todos os dados de rastreio num único registo. Utilize registos separados para registar a saída de rastreio de diferentes aspetos operacionais do sistema. Pode então filtrar rapidamente as mensagens do log lendo do log apropriado em vez de processar um único ficheiro longo. Nunca escreva informações com requisitos de segurança diferentes, como informações de auditoria e dados de depuração, no mesmo log.

Métricas são geralmente uma medida ou contagem de algum aspeto ou recurso no sistema num momento específico, com uma ou mais etiquetas ou dimensões associadas, também chamadas de amostra. Uma única instância de uma métrica não é útil isoladamente. Em vez disso, capte métricas ao longo do tempo. Considere que métricas registar e com que frequência. Gerar dados para métricas com demasiada frequência pode sobrecarregar demasiado o sistema. Mas não recolher dados suficientes pode levá-lo a perder as circunstâncias que levam a um evento significativo. As considerações variam de métrica para métrica. Por exemplo, a utilização do CPU num servidor pode oscilar de segundo para segundo, mas a elevada utilização só se torna preocupante se persistir durante 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 monitorização requerem a fase de análise e diagnóstico no pipeline de monitorização para correlacionar dados recolhidos de várias fontes. Estes dados brutos podem assumir várias formas, e o processo de análise deve ter dados de instrumentação suficientes para mapear estas diferentes formas. Por exemplo, no nível da estrutura do aplicativo, um ID de thread pode identificar uma tarefa. Dentro de uma aplicação, o mesmo trabalho pode estar associado ao ID de utilizador do utilizador que realiza essa tarefa.

Um mapeamento um-para-um provavelmente não existe entre threads e pedidos de utilizador porque operações assíncronas podem reutilizar as mesmas threads para realizar operações para mais do que um utilizador. Mais de uma thread pode também processar um único pedido à medida que o fluxo de execução percorre o sistema. Se possível, associe cada pedido a um ID de atividade único propagado pelo sistema como parte do contexto do pedido. A técnica para gerar e incluir IDs de atividade na informação de rastreio depende da tecnologia que utiliza para capturar os dados de rastreio.

Aplique a mesma marca temporal a todos os dados de monitorização. Para maior consistência, regista todas as datas e horas usando o UTC. Este método ajuda-te a traçar mais facilmente sequências de eventos.

Informações a incluir nos dados da instrumentação

Considere os seguintes pontos ao decidir que dados de instrumentação recolher:

• Garantir que a informação capturada por eventos de rastreio é legível por máquinas e legível por humanos. Adotar esquemas bem definidos para esta informação, facilitando o processamento automatizado dos dados dos registos entre sistemas e para garantir consistência à equipa de operações e engenharia que lê os registos. Inclua informação ambiental, como o ambiente de implementação, a máquina onde o processo corre, os detalhes do processo e a pilha de chamadas.

• Ative o perfilamento apenas quando necessário, pois pode adicionar uma sobrecarga significativa ao sistema. O perfilamento através da utilização de instrumentação regista um evento, como uma chamada de método, sempre que ocorre, enquanto a amostragem regista apenas eventos selecionados. A seleção pode ser baseada no tempo, uma vez a cada n segundos, ou com base na frequência, uma vez a cada n pedidos. Se os eventos ocorrerem frequentemente, o perfilamento por instrumentação pode causar um fardo demasiado grande e afetar o desempenho global. Neste caso, é preferível a abordagem por amostragem. No entanto, se a frequência dos eventos for baixa, a amostragem pode não os atingir. Neste caso, a instrumentação pode ser a melhor abordagem.

• Forneça contexto suficiente para que um programador ou administrador possa determinar a origem de cada pedido. Este contexto pode incluir um ID de atividade que identifica uma instância específica de um pedido ou informação que correlaciona uma atividade com o trabalho computacional realizado e os recursos utilizados. Este trabalho pode ultrapassar os limites do processo e da máquina. Para a medição, o contexto deve também incluir, direta ou indiretamente através de outra informação correlacionada, uma referência ao cliente que faz o pedido. Este contexto fornece informações valiosas sobre o estado da aplicação quando recolhe dados de monitorização.

• Registre todas as solicitações e os locais ou regiões a partir dos quais essas solicitações são feitas. Esta informação pode ajudá-lo a determinar se existem pontos críticos específicos de localização. Também pode ajudar a determinar se deve reparticionar uma aplicação ou os dados que ela utiliza.

• Registre e capture os detalhes das exceções com cuidado. Muitas vezes, as informações críticas de depuração são perdidas como resultado do mau tratamento de exceções. Capture todos os detalhes das exceções que o aplicativo lança, incluindo quaisquer exceções internas e outras informações de contexto. Inclua o stack de chamadas, se possível.

• Seja consistente nos dados que os diferentes elementos da sua aplicação capturam. A consistência pode ajudar a analisar eventos e correlacioná-los com pedidos dos utilizadores. Considere o uso de um pacote de log abrangente e configurável para coletar informações, em vez de depender dos desenvolvedores para adotar a mesma abordagem ao implementar diferentes partes do sistema. Recolha dados de contadores de desempenho chave, como volume de I/O, utilização da rede, número de pedidos, uso de memória e utilização da CPU. Alguns serviços de infraestrutura podem fornecer os seus próprios contadores de desempenho, como o número de ligações a uma base de dados, a taxa a que o sistema realiza transações e o número de transações que têm sucesso ou falham. Os aplicativos também podem definir seus próprios contadores de desempenho específicos.

• Registre todas as chamadas feitas para 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. Registe informações sobre o tempo que demora a realizar cada chamada e se a chamada tem sucesso 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 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 é tipicamente independente de aplicações ou tecnologias específicas, mas espera que a informação siga um formato específico definido por um esquema. O esquema especifica um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. Generalize o esquema para permitir dados de várias plataformas e dispositivos. Um exemplo de framework e esquema amplamente utilizado é o 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. Deve também incluir os detalhes necessários para correlacionar com outros eventos, como um ID de utilizador, um ID de dispositivo e um ID de aplicação. Lembra-te que qualquer número de dispositivos pode gerar eventos, por isso o esquema não deve depender do tipo de dispositivo. Além disso, vários dispositivos podem gerar eventos para a mesma aplicação, e a aplicação pode suportar roaming ou alguma outra forma de distribuição entre dispositivos.

O esquema também pode incluir campos de domínio que são relevantes para um cenário específico que é comum em diferentes aplicativos. Estes cenários incluem informações sobre exceções, eventos de início e fim de aplicações, e sucesso ou falha de chamadas à API de serviços web. Todas as aplicações que utilizam o mesmo conjunto de campos de domínio devem emitir o mesmo conjunto de eventos para construir um conjunto de relatórios e análises comuns.

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

Práticas recomendadas para instrumentação de aplicações

A lista seguinte resume as melhores práticas para instrumentar uma aplicação distribuída que corre na cloud:

• Torna os registos fáceis de ler e analisar. Use o log estruturado sempre que possível. Seja conciso e descritivo nas 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.

• Utilize o mesmo fuso horário e formato para todos os marcadores temporais. Esta prática ajuda a correlacionar eventos em operações que abrangem hardware e serviços que correm em diferentes regiões geográficas.

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

• Não divulgue informações sensíveis sobre o sistema nem informações pessoais dos utilizadores. Apague esta informação antes de a registar, mas certifique-se de que mantém os dados relevantes. Por exemplo, remover o ID e a palavra-passe das cadeias de ligação à base de dados. Escreva a informação restante no registo para que possa determinar se o sistema acede à base de dados correta. Registe todas as exceções críticas, mas permita ao administrador ativar e desligar o login para níveis inferiores de exceções e avisos. Além disso, capture e registre todas as informações de lógica de tentativas. Pode usar estes dados para monitorizar a saúde transitória do sistema.

• Rastreie chamadas fora de processo, como pedidos para serviços web externos ou bases 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 registo de eventos que continuem a funcionar autonomamente. Este tipo de operações não bloqueia o progresso das operações empresariais. Os eventos de auditoria são uma exceção porque são críticos para o negócio. Classifique-os como parte fundamental das operações empresariais.

• Certifique-se de que o registo de eventos seja extensível e não tenha quaisquer dependências diretas de um destino concreto. Por exemplo, em vez de escrever informação usando System.Diagnostics.Trace, defina uma interface abstrata, como o ILogger, que expõe métodos de registo e que pode implementar por qualquer meio adequado.

• Certifique-se de que todo o registo é à prova de falhas e nunca desencadeia erros em cascata. A exploração florestal não deve levantar exceções.

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

Recolha e armazenamento de dados

A fase de recolha recupera a informação gerada pela instrumentação, formata esses dados para facilitar o seu consumo durante a fase de análise e diagnóstico, e guarda os dados transformados num armazenamento fiável. Pode armazenar os dados de instrumentação que recolhe de diferentes partes de um sistema distribuído em vários locais e formatos. Por exemplo, o código da sua aplicação pode gerar ficheiros de registo de traços e dados do registo de eventos da aplicação. Outras tecnologias podem captar contadores de desempenho que monitorizam aspetos-chave da infraestrutura que a sua aplicação utiliza. Quaisquer componentes e serviços que não sejam da Microsoft que a sua aplicação utilize podem fornecer informação de instrumentação em diferentes formatos, utilizando ficheiros de rastreamento separados, armazenamento de blobs ou até um armazenamento de dados personalizado.

Um serviço de recolha que funciona de forma autónoma em relação à aplicação que gera os dados de instrumentação normalmente recolhe os dados. O diagrama seguinte mostra um exemplo desta arquitetura e destaca o subsistema de recolha de dados de instrumentação.

Este diagrama mostra uma visão simplificada da recolha de dados. O serviço de recolha normalmente compreende várias peças que funcionam em diferentes máquinas. Se precisar de analisar dados de telemetria rapidamente, utilize componentes locais que operem fora do serviço de recolha. Após o processamento analítico, os componentes enviam os resultados diretamente para o subsistema de visualização e alerta. Dados sujeitos a análise a quente ou frio são armazenados enquanto aguardam o processamento. Para mais informações, consulte Suporte análise de quente, quente e frio.

Para aplicações e serviços Azure que correm em máquinas virtuais, o Azure Monitor Agent fornece uma solução para capturar dados. Defines regras de recolha de dados (DCRs) que especificam os dados a recolher de cada nó de computação e do espaço de trabalho Log Analytics no Azure Monitor para onde os enviar. O agente pode recolher dados das seguintes fontes:

• Logs do IIS (Serviços de Informações da Internet)
• Registos de eventos do Windows
• Contadores de desempenho
• Syslog a partir de nós Linux
• Registos de texto e JSON que as aplicações escrevem

Estratégias para a recolha de dados de instrumentação

Devido à natureza elástica da cloud, e para evitar a recuperação manual de dados de telemetria de todos os nós do sistema, organize a consolidação dos dados e a sua transferência para um local central. Num sistema que abrange vários centros de dados, pode querer recolher, consolidar e armazenar dados região a região primeiro, e depois agregar os dados regionais num único sistema central.

Para otimizar o uso da largura de banda, pode transferir dados menos urgentes em lotes. Não atrase a transferência indefinidamente, especialmente se os dados contiverem informação sensível ao tempo.

Dados de instrumentação de puxar e empurrar

O subsistema de recolha de dados de instrumentação pode recuperar ativamente dados de instrumentação dos vários registos e outras fontes para cada instância da aplicação. Este método chama-se modelo de puxada. Ou pode atuar como um recetor passivo que espera que os componentes que constituem cada instância da aplicação enviem os dados. Este método chama-se modelo push.

Uma abordagem ao modelo de pull é usar agentes de monitorização que correm localmente com cada instância da aplicação. Um agente de monitorização é um processo separado que periodicamente recolhe dados de telemetria recolhidos no nó local e escreve essa informação num armazenamento centralizado que todas as instâncias da aplicação partilham. O Azure Monitor Agent implementa este mecanismo. Configura os dados para recolher de cada instância de computação através de uma regra de recolha de dados. O agente de monitorização que corre em conjunto com cada instância recolhe os dados especificados, como logs IIS, logs de eventos do Windows e contadores de desempenho, e envia-os para um espaço de trabalho de Log Analytics no Azure Monitor, onde pode consultá-los e analisá-los. O diagrama seguinte mostra um exemplo desta arquitetura.

Pode usar os modelos pull e push para armazenar dados de telemetria numa aplicação de pequena escala que corre num número limitado de nós numa única localização. Uma aplicação global de cloud complexa, altamente escalável pode gerar enormes volumes de dados a partir de centenas de instâncias de computação, fragmentos de bases de dados e outros serviços. Essa enxurrada de dados pode facilmente sobrecarregar a largura de banda de E/S disponível com um único local central. Como resultado, deve ser capaz de escalar a sua solução de telemetria para evitar um gargalo à medida que o sistema se expande. Idealmente, a sua solução deve incorporar um grau de redundância para reduzir os riscos de perder informações importantes de monitorização, como dados de auditoria ou faturação, caso parte do sistema falhe.

Para resolver estes problemas, implemente filas. No exemplo de arquitetura seguinte, o agente local de monitorização ou o serviço personalizado de recolha de dados coloca os dados numa fila. O serviço de escrita no armazenamento, um processo assíncrono separado, obtém os dados desta fila e grava-os no armazenamento partilhado. Uma fila de mensagens é adequada para este cenário porque fornece semântica de at-least-once, o que ajuda a garantir que os dados colocados na fila não se percam depois de publicados. Pode implementar o serviço de escrita de armazenamento usando um processo separado em segundo plano.

O serviço local de recolha de dados pode adicionar dados a uma fila imediatamente após os receber. A fila funciona como um buffer, e o serviço de escrita de armazenamento pode recuperar e escrever os dados ao seu próprio ritmo. Por padrão, uma fila opera em uma base de primeiro a entrar, primeiro a sair. Mas podes priorizar mensagens para as acelerar na fila se contiverem dados que tens de tratar rapidamente. Para obter mais informações, consulte o padrão de fila de prioridade. Em alternativa, pode usar diferentes canais, como tópicos do Service Bus, para direcionar dados para diferentes destinos, dependendo da forma de processamento analítico necessária.

Para garantir a escalabilidade, pode executar várias instâncias do serviço de escrita no armazenamento. Para volumes elevados de eventos, pode usar um hub de eventos para despachar os dados para diferentes recursos computacionais 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 fornecem uma visão localizada da integridade e do desempenho dessa instância. Para avaliar a saúde geral do sistema, consolide alguns aspetos dos dados nas vistas locais. Pode realizar este passo depois de os dados estarem armazenados, mas em alguns casos também pode fazê-lo à medida que os dados são recolhidos. Em vez de escrever diretamente para armazenamento partilhado, os dados da instrumentação passam por um serviço separado que consolida, filtra e limpa os dados. Por exemplo, dados de instrumentação que incluem a mesma informação de correlação, como um ID de atividade, podem ser amalgamados. Um utilizador pode iniciar uma operação empresarial num nó e depois ser transferido para outro nó se este falhar ou devido ao balanceamento de carga. Este processo também pode detetar e remover dados duplicados, o que é possível se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação para o armazenamento. O diagrama seguinte mostra um exemplo desta estrutura.

Armazenar dados de instrumentação

As secções anteriores mostram uma visão simplificada de como armazenar dados de instrumentação. Na prática, deve armazenar diferentes tipos de informação utilizando as tecnologias que se adequem à forma como planeia utilizá-la.

Por exemplo, o Armazenamento de Blobs do Azure e o Armazenamento de Tabelas do Azure têm padrões de acesso semelhantes, mas as operações que podem realizar são limitadas e a granularidade dos dados que armazenam varia. Se precisar de realizar operações analíticas ou necessitar de capacidades de pesquisa em texto integral, poderá precisar de usar armazenamento de dados que forneça as seguintes capacidades de consulta e acesso a dados:

• Armazene os dados dos contadores de desempenho numa base de dados SQL para permitir análises não planeadas.
• Armazenar registos de rastreio no Azure Cosmos DB.
• Escreva informações de segurança no Hadoop Distributed File System (HDFS).
• Armazene informação que requer pesquisa em texto completo usando o Elasticsearch, que utiliza indexação rica para acelerar as pesquisas.

O diagrama seguinte mostra como pode implementar um serviço extra que periodicamente recupera os dados do armazenamento partilhado, particiona e filtra os dados de acordo com o seu propósito, e depois os escreve num conjunto apropriado de armazenamentos. Uma abordagem alternativa é incluir esta funcionalidade no processo de consolidação e limpeza e escrever os dados diretamente nesses armazenamentos à medida que são recuperados, em vez de os guardar numa área de armazenamento partilhada intermédia. Cada abordagem tem vantagens e desvantagens. Implementar um serviço de particionamento separado reduz a carga sobre o serviço de consolidação e limpeza. Permite também regenerar pelo menos parte dos dados particionados, se necessário, dependendo da quantidade de dados que o armazenamento partilhado retém. No entanto, esta abordagem consome mais recursos. Pode também atrasar a receção de dados de instrumentação de cada instância de aplicação e a conversão desses dados em informação acionável.

Podes precisar dos mesmos dados de instrumentação para mais do que um propósito. Por exemplo, contadores de desempenho podem fornecer uma visão histórica do desempenho do sistema ao longo do tempo. Pode combinar esta informação com outros dados de utilização para gerar dados de faturação do cliente. Nestes cenários, envia os mesmos dados para mais do que um destino, como uma base de dados de documentos que armazena informação de faturação e um armazenamento multidimensional que gere análises complexas de desempenho.

Considere a urgência com que precisa dos dados. Os dados que fornecem informação para alertas devem ser acedidos rapidamente, por isso deve armazená-los num armazenamento rápido de dados e indexá-los ou estruturar para otimizar as consultas do sistema de alertas. Em alguns casos, o serviço de telemetria que recolhe os dados de cada nó pode precisar de formatar e guardar os dados localmente para que uma instância local do sistema de alertas possa notificá-lo rapidamente sobre problemas. Pode enviar os mesmos dados para o serviço de escrita de armazenamento que os diagramas anteriores mostram e armazená-los centralmente se precisar para outros fins.

A informação que se utiliza para análises mais complexas, para relatórios e para identificar tendências históricas é menos urgente. Armazene-o de forma a suportar mineração de dados e consultas não planeadas. Para mais informações, consulte Suporte análise de quente, quente e frio.

Rotação logarítmica e retenção de dados

A instrumentação gera muitos dados. Em alguns casos, depois de os dados serem processados e transferidos, pode remover os dados originais de origem bruta de cada nó. Ou talvez precises de guardar a informação bruta.

Os dados de desempenho normalmente têm uma vida útil mais longa, permitindo que os utilize para identificar tendências de desempenho e planear a capacidade. Mantenha a visão consolidada destes dados online durante um período finito para que possa aceder rapidamente a eles. Pode ser necessário guardar os dados recolhidos para medição e faturação indefinidamente. Além disso, os requisitos regulamentares podem exigir que arquives e guardes a informação recolhida para fins de auditoria e segurança. Encripte ou proteja de outra forma estes dados sensíveis para evitar adulterações. Nunca registe as palavras-passe ou outras informações pessoais dos utilizadores. Apague estes detalhes dos dados antes de os armazenar.

Redução de amostragem de dados

Armazene dados históricos para identificar tendências de longo prazo. Em vez de guardar todos os dados antigos, pode reduzir a amostragem dos dados para reduzir a sua resolução e poupar 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 para formar uma exibição hora a hora.

Práticas recomendadas para recolher e armazenar informação de registo

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

• O agente de monitorização ou serviço de recolha de dados deve funcionar como um serviço fora de processo e ser simples de implementar.

• Toda a saída do agente de monitoramento ou do serviço de coleta de dados deve ser um formato agnóstico que seja independente da máquina, do sistema operacional ou do protocolo de rede. Por exemplo, emitir informação num formato auto-descritivo como JSON, MessagePack ou Protobuf em vez de ficheiros Event Trace Log (ETL) no Linux ou ETW. Utilize um formato padrão para que o sistema possa construir cadeias de processamento. Pode facilmente integrar componentes que leem, transformam e enviam dados no formato acordado.

• O processo de monitorização e recolha de dados deve ser à prova de falhas e não pode desencadear erros em cascata.

• Se uma falha transitória enviar informação para um sumidouro de dados, o agente de monitorização ou o serviço de recolha de dados deve estar preparado para reordenar os dados de telemetria para que a informação mais recente seja enviada primeiro. O agente de monitorização ou o serviço de recolha de dados pode optar por largar os dados mais antigos ou guardá-los localmente e transmiti-los mais tarde para se atualizar, a sua própria discrição.

Analisar dados e diagnosticar problemas

Uma parte importante da monitorização e diagnóstico é analisar os dados recolhidos para obter uma imagem da saúde geral do sistema. Defina os seus próprios KPIs e métricas de desempenho, e aprenda a estruturar os dados para satisfazer os seus requisitos de análise. Compreenda como os dados capturados em diferentes métricas e ficheiros de registo se correlacionam, pois esta informação é fundamental para acompanhar uma sequência de eventos e diagnosticar problemas.

Os dados de cada parte do sistema são normalmente recolhidos localmente, mas depois é necessário combiná-los com dados gerados noutros locais que participam no sistema. Correlacione cuidadosamente esta informação para garantir que os dados são combinados com precisão. Por exemplo, os dados de utilização de uma operação podem abranger os seguintes nós:

• Um nó que aloja um sítio Web ao qual um utilizador acede
• Um nó que executa um serviço em separado, acedido no âmbito desta operação
• Um nó que armazena dados

É necessário ligar esta informação para fornecer uma visão geral do uso de recursos e 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 mais informações, consulte Consolidar dados de instrumentação.

Suporta análise a quente, morna e a frio

Analisar e reformatar dados para fins de visualização, relatório e alerta pode ser um processo complexo que consome seu próprio conjunto de recursos. Algumas formas de monitorização requerem uma análise imediata de dados para serem eficazes, também conhecida como análise em quente. Exemplos incluem análise para alertas e monitorização de segurança. Para análise a quente, disponibilize e estruture os dados para processamento eficiente. Em alguns casos, pode ser necessário mover o processamento da 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 cálculo e agregação após a receção dos dados brutos. Este método chama-se análise a quente. A análise de desempenho geralmente se enquadra nessa categoria. Neste caso, um pico ou falha repentina pode causar um evento isolado e único de desempenho que não é estatisticamente significativo. Os dados de uma série de eventos fornecem uma imagem mais fiável do desempenho do sistema.

Também pode utilizar a análise térmica para ajudar a diagnosticar problemas de saúde. Utilize a análise quente para processar um evento de saúde e acione imediatamente um alerta. Depois, utilize a análise quente para analisar os dados e encontrar a causa do evento de saúde.

Alguns tipos de monitorização geram dados a mais longo prazo. Pode realizar esta análise numa data posterior, possivelmente de acordo com um calendário pré-definido. Em alguns casos, a análise pode precisar de filtrar grandes volumes de dados capturados ao longo do tempo. Este método chama-se análise a frio. O requisito fundamental é armazenar os dados em segurança depois de os capturar. Por exemplo, a monitorização e auditoria de utilização exigem uma imagem precisa do estado do sistema a intervalos regulares, mas esta informação de estado não tem de estar imediatamente disponível para processamento.

Também pode usar análise a frio para fornecer os dados para análise preditiva de saúde. Recolha informações históricas ao longo de um período específico e combine-a com os dados atuais de saúde para identificar tendências que possam causar problemas de saúde. Nestes casos, pode ser necessário alertar para corrigir a tendência.

Correlacionar dados

Os dados que a instrumentação captura podem fornecer um instantâneo do estado do sistema, mas o objetivo da análise é tornar esses dados acionáveis. Por exemplo, pode determinar a causa do carregamento intenso de I/O ao nível do sistema num momento específico e garantir que os tempos de resposta da base de dados, o número de transações por segundo e os tempos de resposta da aplicação ao mesmo tempo confirmam as suas conclusões.

Uma forma 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 num nível frequentemente desencadeia outra falha no nível superior.

Por estas razões, é necessário correlacionar os diferentes tipos de dados de monitorização em cada nível para produzir uma visão global do estado do sistema e das aplicações que nele correm. Use esta informação para decidir se o sistema está a funcionar de forma aceitável e determinar o que pode fazer para melhorar a qualidade.

Garantir que os dados brutos da instrumentação incluem contexto suficiente e informação de identificação de atividade para apoiar as agregações necessárias para correlacionar eventos. Estes dados podem estar armazenados em formatos diferentes, por isso pode ser necessário analisá-los e convertê-los para um formato padronizado. Para mais informações, consulte Informações sobre dados correlacionados.

Resolução de problemas e diagnóstico

Para diagnosticar problemas, é necessário fazer RCA para determinar a causa de falhas ou comportamentos inesperados. Normalmente, precisa da seguinte informação para todo o sistema ou para um subsistema específico durante uma janela de tempo especificada:

• Informação detalhada dos registos e vestígios de eventos
• Rastreios completos da pilha de exceções e falhas de qualquer nível especificado
• Despejos de falha para processos falhados
• Registos de atividade que registam as operações que todos os utilizadores ou utilizadores selecionados realizam

Para analisar dados para fins de resolução de problemas, é necessário um conhecimento técnico profundo da arquitetura do sistema e dos seus componentes. Deve interpretar os dados, estabelecer a causa dos problemas e recomendar uma estratégia para os corrigir. Outra estratégia é armazenar uma cópia desta informação no seu formato original e disponibilizá-la para análise a frio por um especialista.

Visualizar dados e levantar alertas

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

A apresentação de dados pode assumir várias formas, incluindo visualização usando painéis, alertas e relatórios.

Visualização usando painéis

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

Podes organizar dashboards hierarquicamente. Dashboards de topo oferecem uma visão geral de cada aspeto do sistema e permitem-lhe aprofundar os detalhes. Por exemplo, num painel que representa a I/O global do disco para o sistema, pode visualizar as taxas de I/O de cada disco individual para determinar se um ou mais dispositivos específicos representam um volume desproporcional de tráfego. O painel de instrumentos deve também mostrar informação relacionada, como o utilizador ou a atividade que gera esta E/S. Esta informação pode ajudar a distribuir a carga de forma mais equilibrada entre dispositivos.

Um painel pode também usar codificação por cores ou outros sinais visuais para indicar valores que parecem anómalos ou que estão fora do intervalo esperado. Considere os seguintes exemplos de codificação por cores:

• Vermelho para um disco com uma taxa de I/O próxima da sua capacidade máxima durante um período prolongado, ou para um disco quente

• Amarelo para um disco com uma taxa de I/O que periodicamente atinge o seu limite máximo durante curtos períodos, ou um disco quente

• Verde para um disco que apresenta uso normal

Os sistemas de dashboard devem ter os dados brutos para funcionar eficazmente. Se construir o seu próprio sistema de dashboards ou usar um dashboard desenvolvido por outra organização, deve compreender que dados de instrumentação precisa de recolher, em que níveis de granularidade e como os formatar para que o dashboard possa consumir.

Um painel eficaz também lhe permite colocar questões sobre informação. Alguns sistemas fornecem ferramentas de gestão que pode usar para realizar estas tarefas e explorar os dados subjacentes. Dependendo do repositório que guarda a informação, pode ser possível consultar dados diretamente ou importá-los para ferramentas como o Excel para análise e relatórios adicionais.

Levantar alertas

O alerta analisa os dados de monitorização e instrumentação e gera uma notificação se detetar um evento significativo.

Os alertas ajudam a garantir que o sistema permaneça íntegro, responsivo e seguro. É uma parte importante de qualquer sistema que garanta desempenho, disponibilidade e privacidade aos utilizadores. O alerta também pode notificá-lo de eventos que desencadeiam alertas. Use alertas para invocar funções do sistema como o autoscaling.

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

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

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

• Informação sobre disponibilidade: Se for detetada uma falha, pode ser necessário reiniciar rapidamente um ou mais subsistemas ou fazer failover para um recurso de backup. Falhas repetidas num subsistema podem indicar problemas mais graves.

Pode receber informações de alerta através de vários canais, como email, pager ou SMS SMS. Um alerta também pode incluir uma indicação de quão crítica é uma situação. Muitos sistemas de alerta suportam grupos de assinantes, e todos os operadores que pertencem ao mesmo grupo recebem o mesmo conjunto de alertas.

Tornar o sistema de alertas personalizável e fornecer os valores apropriados dos dados da instrumentação subjacente como parâmetros. Ao usar esta abordagem, pode filtrar dados por limiares específicos ou combinações de valores. Em alguns casos, pode fornecer os dados brutos da instrumentação ao sistema de alerta. Ou pode ser mais apropriado fornecer dados agregados. Por exemplo, um alerta é ativado quando a utilização da CPU para um nó ultrapassa 90% nos últimos 10 minutos. Forneça ao sistema de alertas informações adequadas de resumo e contexto para reduzir a possibilidade de eventos falsos positivos desencadearem um alerta.

Relatórios

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

O relatório operacional inclui tipicamente os seguintes aspetos para o sistema global ou subsistemas específicos durante uma janela de tempo especificada:

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

• Tendências na utilização de recursos

• Monitorização de exceções

• Eficiência da aplicação em termos dos recursos implementados e se é possível reduzir o volume de recursos sem afetar o desempenho

Os relatórios de segurança acompanham como os clientes utilizam o sistema. Normalmente inclui os seguintes aspetos:

• Auditar as operações dos utilizadores. Registar pedidos individuais que cada utilizador realiza, juntamente com datas e horas. Estrutura os dados de forma a que possas reconstruir rapidamente a sequência de operações que um utilizador realiza durante um período especificado.

• Acompanhe o uso de recursos para cada utilizador. Registe como cada pedido de um utilizador acede aos recursos do sistema e durante quanto tempo. Use estes dados para gerar um relatório de utilização para cada utilizador durante um período especificado, possivelmente para fins de faturação.

Em muitos casos, os processos em lote podem gerar relatórios de acordo com uma agenda definida. A geração de relatórios normalmente não aumenta a latência, por isso pode gerar relatórios sob demanda se necessário. Se armazenar dados numa base de dados relacional como o Base de Dados SQL do Azure, pode usar uma ferramenta como o SQL Server Reporting Services para extrair e formatar dados e apresentá-los como um conjunto de relatórios.

Passos seguintes

• Visão geral do Azure Monitor
• Monitorizar, diagnosticar e resolver problemas Armazenamento
• Visão geral dos alertas em Azure
• Visão Geral dos Insights de Aplicação
• Diagnóstico de desempenho para Azure VMs

Recursos relacionados

• As orientações de autoescalabilidade descrevem como diminuir a sobrecarga de gestão, reduzindo a necessidade de monitorizar continuamente o desempenho do sistema e tomar decisões para adicionar ou remover recursos.

• O padrão Health Endpoint Monitoring descreve como implementar verificações funcionais em um aplicativo que ferramentas externas podem acessar por meio de pontos de extremidade expostos em intervalos regulares.

• O padrão de Priority Queue descreve como priorizar mensagens em fila para que os sistemas recebam e processem pedidos urgentes antes das menos urgentes.