Orientações em matéria de monitorização e diagnóstico

Azure Monitor

As aplicações e serviços distribuídos executados na nuvem são, pela sua natureza, peças complexas de software que compreendem muitas partes móveis. Em um ambiente de produção, é importante ser capaz de rastrear a maneira como os usuários usam seu sistema, rastrear a utilização de recursos e, geralmente, monitorar a integridade e o desempenho do sistema. Pode utilizar estas informações como uma ajuda de diagnóstico para detetar e corrigir problemas, bem como ajudar a detetar potenciais problemas e evitá-los.

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

Você pode usar o monitoramento para obter uma visão de como um sistema está funcionando. A monitorização é uma parte crucial da manutenção dos objetivos de qualidade do serviço. Os cenários comuns para a recolha de dados de monitorização incluem:

• Garantir que o sistema permanece saudável.
• Acompanhamento da disponibilidade do sistema e seus elementos componentes.
• Manter o desempenho para garantir que a taxa de transferência do sistema não se degrade inesperadamente à medida que o volume de trabalho aumenta.
• Garantir que o sistema atenda a quaisquer acordos de nível de serviço (SLAs) estabelecidos com os clientes.
• Proteger a privacidade e a segurança do sistema, dos utilizadores e dos seus dados.
• Acompanhamento das operações realizadas para fins de auditoria ou regulamentação.
• Monitorar o uso diário do sistema e detetar tendências que podem levar a problemas se não forem abordadas.
• Rastreando problemas que ocorrem, desde o relatório inicial até a análise de possíveis causas, retificação, consequentes atualizações de software e implantação.
• Operações de rastreamento e depuração de versões de software.

Observação

Esta lista não pretende ser exaustiva. Este documento se concentra nesses cenários como as situações mais comuns para realizar monitoramento. Pode haver outros que são menos comuns ou são específicos para o seu ambiente.

As seções a seguir descrevem esses cenários com mais detalhes. As informações para cada cenário são discutidas no seguinte formato:

1. Uma breve visão geral do cenário.
2. Os requisitos típicos deste cenário.
3. Os dados brutos de instrumentação necessários para dar suporte ao cenário e possíveis fontes dessas informações.
4. Como esses dados brutos podem ser analisados e combinados para gerar informações de diagnóstico significativas.

Monitorização de saúde

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

Requisitos para a monitorização da saúde

Um operador deve ser alertado rapidamente (em questão de segundos) se qualquer parte do sistema for considerada não íntegra. O operador deve poder verificar quais as partes do sistema que estão a funcionar normalmente e quais as que estão a ter problemas. A integridade do sistema pode ser destacada através de um sistema de semáforos:

• Vermelho para insalubridade (o sistema parou)
• Amarelo para parcialmente saudável (o sistema está funcionando com funcionalidade reduzida)
• Verde para completamente saudável

Um sistema abrangente de monitoramento de integridade permite que um operador analise detalhadamente o sistema para visualizar o status de integridade de subsistemas e componentes. Por exemplo, se o sistema geral for descrito como parcialmente íntegro, o operador deve ser capaz de ampliar e determinar qual funcionalidade está indisponível no momento.

Fontes de dados, instrumentação e requisitos de coleta de dados

Os dados brutos necessários para dar suporte ao monitoramento de integridade podem ser gerados como resultado de:

• Rastreando a execução das solicitações do usuário. Essas informações podem ser usadas para determinar quais solicitações foram bem-sucedidas, quais falharam e quanto tempo cada solicitação leva.
• Monitoramento sintético do usuário. Este processo simula as etapas executadas por um usuário e segue uma série predefinida de etapas. Os resultados de cada etapa devem ser capturados.
• Registro de exceções, falhas e avisos. Essas informações podem ser capturadas como resultado de instruções de rastreamento incorporadas no código do aplicativo, bem como recuperar informações dos logs de eventos de quaisquer serviços que o sistema referencia.
• Monitorizar o estado de funcionamento de quaisquer serviços de terceiros que o sistema utilize. Esse monitoramento pode exigir a recuperação e a análise de dados de integridade fornecidos por esses serviços. Essas informações podem ter vários formatos.
• Monitorização de pontos finais. Esse mecanismo é descrito com mais detalhes na seção "Monitoramento de disponibilidade".
• Coleta de informações de desempenho ambiente, como utilização da CPU em segundo plano ou atividade de E/S (incluindo rede).

Analisando dados de saúde

O foco principal do monitoramento de integridade é indicar rapidamente se o sistema está em execução. A análise a quente dos dados imediatos pode disparar um alerta se um componente crítico for detetado como não íntegro. (Ele não responde a uma série consecutiva de pings, por exemplo.) O operador pode então tomar as medidas corretivas adequadas.

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 fria pode identificar tendências e determinar se é provável que o sistema permaneça íntegro ou se precisará de recursos adicionais. Este elemento preditivo deve basear-se em métricas críticas de desempenho, tais como:

• A taxa de solicitações direcionadas a cada serviço ou subsistema.
• Os tempos de resposta destes pedidos.
• O volume de dados que entram e saem de cada serviço.

Se o valor de qualquer métrica exceder um limite definido, o sistema pode emitir um alerta para permitir que um operador ou dimensionamento automático (se disponível) tome as ações preventivas necessárias para manter a integridade do sistema. Essas ações podem envolver a adição de recursos, a reinicialização de um ou mais serviços que estão falhando ou a aplicação de limitação a solicitações de prioridade mais baixa.

Monitoramento de disponibilidade

Um sistema verdadeiramente saudável requer que os componentes e subsistemas que compõem o sistema estejam disponíveis. O monitoramento de disponibilidade está intimamente relacionado ao monitoramento de integridade. Mas enquanto o monitoramento de integridade fornece uma visão imediata da integridade atual do sistema, o monitoramento de disponibilidade está preocupado em rastrear a disponibilidade do sistema e seus componentes para gerar estatísticas sobre o tempo de atividade do sistema.

Em muitos sistemas, alguns componentes (como um banco de dados) são configurados com redundância interna para permitir um failover rápido no caso de uma falha grave ou perda de conectividade. Idealmente, os usuários não devem estar cientes de que tal falha ocorreu. Mas, do ponto de vista do monitoramento de disponibilidade, é necessário reunir o máximo de informações possível sobre essas falhas para determinar a causa e tomar ações corretivas para evitar que elas se repitam.

Os dados necessários para controlar a disponibilidade podem depender de vários fatores de nível inferior. Muitos desses fatores podem ser específicos do aplicativo, do sistema e do ambiente. Um sistema de monitorização eficaz capta os dados de disponibilidade que correspondem a estes fatores de baixo nível e, em seguida, agrega-os para dar uma imagem global do sistema. Por exemplo, em um sistema de comércio eletrônico, a funcionalidade comercial que permite que um cliente faça pedidos pode depender do repositório onde os detalhes do pedido são armazenados e do sistema de pagamento que lida com as transações monetárias para pagar por esses pedidos. A disponibilidade da parte do sistema relativa à colocação de ordens depende, por conseguinte, da disponibilidade do repositório e do subsistema de pagamento.

Requisitos para monitoramento de disponibilidade

O operador deverá também poder visualizar a disponibilidade histórica de cada sistema e subsistema e utilizar essas informações para detetar quaisquer tendências suscetíveis de provocar falhas periódicas de um ou mais subsistemas. (Os serviços começam a falhar em um determinado horário do dia que corresponde às horas de pico de processamento?)

Uma solução de monitorização deve fornecer uma visão imediata e histórica da disponibilidade ou indisponibilidade de cada subsistema. Também deve ser capaz de alertar rapidamente um operador quando um ou mais serviços falham ou quando os utilizadores não conseguem ligar-se aos serviços. Esta é uma questão não só de monitorar cada serviço, mas também examinar as ações que cada usuário executa se essas ações falharem quando eles tentam se comunicar com um serviço. Até certo ponto, um grau de falha de conectividade é normal e pode ser devido a erros transitórios. Mas pode ser útil permitir que o sistema emita um alerta para o número de falhas de conectividade com um subsistema especificado que ocorrem durante um período específico.

Fontes de dados, instrumentação e requisitos de coleta de dados

Assim como no monitoramento de integridade, os dados brutos necessários para dar suporte ao monitoramento de disponibilidade podem ser gerados como resultado do monitoramento sintético do usuário e do registro de quaisquer exceções, falhas e avisos que possam ocorrer. Além disso, os dados de disponibilidade podem ser obtidos a partir da execução do monitoramento de endpoint. O aplicativo pode expor um ou mais pontos de extremidade de integridade, cada um testando o acesso a uma área funcional dentro do sistema. O sistema de monitoramento pode executar ping em cada ponto final seguindo um cronograma definido e coletar os resultados (sucesso ou falha).

Todos os tempos limites, falhas de conectividade de rede e tentativas de repetição de conexão devem ser registrados. Todos os dados devem ter carimbo de data/hora.

Analisando dados de disponibilidade

Os dados de instrumentação devem ser agregados e correlacionados 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. Idealmente, um operador deve ser capaz de correlacionar falhas com atividades específicas: o que estava acontecendo quando o sistema falhou?
• Uma visão histórica das taxas de falha do sistema ou de quaisquer subsistemas em qualquer período especificado e a carga no sistema (número de solicitações do usuário, por exemplo) quando ocorreu uma falha.
• As razões para a indisponibilidade do sistema ou de quaisquer subsistemas. Por exemplo, os motivos podem ser serviço não em execução, conectividade perdida, conectado mas com tempo limite limite e conectado mas retornando erros.

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

Isso é útil para fins de SLA. (O monitoramento de SLA é descrito mais detalhadamente mais adiante nesta orientação.) A definição de tempo de inatividade depende do serviço. Por exemplo, o Visual Studio Team Services Build Service define o tempo de inatividade como o período (total de minutos acumulados) durante o qual o Serviço de Criação não está disponível. Um minuto é considerado indisponível se todas as solicitações HTTP contínuas ao Serviço de Criação para executar operações iniciadas pelo cliente ao longo do minuto resultarem em um código de erro ou não retornarem uma resposta.

Monitorização do desempenho

À medida que o sistema é colocado sob cada vez mais estresse (aumentando o volume de usuários), o tamanho dos conjuntos de dados que esses usuários acessam cresce e a possibilidade de falha de um ou mais componentes torna-se mais provável. Frequentemente, a falha do componente é precedida por uma diminuição no desempenho. Se você for capaz de detetar essa diminuição, poderá tomar medidas proativas para remediar a situação.

O desempenho do sistema depende de uma série de fatores. Cada fator é normalmente medido por meio de indicadores-chave de desempenho (KPIs), 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 podem ser derivados de uma combinação de métricas.

Observação

Determinar um desempenho ruim ou bom requer que você entenda o nível de desempenho no qual o sistema deve ser capaz de funcionar. Isso requer observar o sistema enquanto ele está funcionando sob uma carga típica e capturar os dados para cada KPI durante um período de tempo. Isso pode envolver a execução do sistema sob uma carga simulada em um ambiente de teste e a coleta dos dados apropriados antes de implantar o sistema em um ambiente de produção.

Deve também assegurar que a monitorização para efeitos de desempenho não se torne um fardo para o sistema. Talvez seja possível ajustar dinamicamente o nível de detalhes dos dados que o processo de monitoramento de desempenho coleta.

Requisitos para a monitorização do desempenho

Para examinar o desempenho do sistema, um operador normalmente precisa ver informações que incluem:

• As taxas de resposta para solicitações de usuários.
• O número de solicitações de usuários simultâneos.
• O volume de tráfego de rede.
• As taxas às quais as transações comerciais estão sendo concluídas.
• O tempo médio de processamento dos pedidos.

Também pode ser útil fornecer ferramentas que permitam a um operador ajudar a identificar correlações, tais como:

• O número de usuários simultâneos versus tempos de latência de solicitação (quanto tempo leva para começar a processar uma solicitação depois que o usuário a enviou).
• O número de usuários simultâneos versus o tempo médio de resposta (quanto tempo leva para concluir uma solicitação depois que ela começou a ser processada).
• O volume de solicitações versus o número de erros de processamento.

Juntamente com essas informações funcionais de alto nível, um operador deve ser capaz de obter uma visão detalhada do desempenho de cada componente do sistema. Esses dados geralmente são fornecidos por meio de contadores de desempenho de baixo nível que rastreiam informações como:

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

Todas as visualizações devem permitir que um operador especifique 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 operador deverá poder emitir um alerta com base em qualquer medida de desempenho para qualquer valor especificado durante qualquer intervalo de tempo especificado.

Fontes de dados, instrumentação e requisitos de coleta de dados

Você pode coletar dados de desempenho de alto nível (taxa de transferência, número de usuários simultâneos, número de transações comerciais, taxas de erro e assim por diante) monitorando o progresso das solicitações dos usuários à medida que chegam e passam pelo sistema. Isso envolve a incorporação de instruções de rastreamento em pontos-chave no código do aplicativo, juntamente com informações de tempo. Todas as falhas, exceções e avisos devem ser capturados com dados suficientes para correlacioná-los com as solicitações que os causaram. O log do IIS (Serviços de Informações da Internet) é outra fonte útil.

Se possível, você também deve capturar dados de desempenho para quaisquer 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 isso não for possível, registre informações como a hora de início e a hora de término de cada solicitação feita a um sistema externo, juntamente com o status (sucesso, falha ou aviso) da operação. Por exemplo, você pode usar uma abordagem de cronômetro para solicitações de tempo: inicie um temporizador quando a solicitação for iniciada e, em seguida, pare o temporizador quando a solicitação terminar.

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 do Windows e Diagnóstico do Azure.

Analisando dados de desempenho

Grande parte do trabalho de análise consiste em agregar dados de desempenho por tipo de solicitação do usuário ou pelo subsistema ou serviço para o qual cada solicitação é enviada. Um exemplo de uma solicitação do usuário é adicionar um item a um carrinho de compras ou realizar o processo de checkout em um sistema de comércio eletrônico.

Outro requisito comum é resumir os dados de desempenho em percentis selecionados. Por exemplo, um operador pode determinar os tempos de resposta para 99% das solicitações, 95% das solicitações e 70% das solicitações. Pode haver metas de SLA ou outras metas definidas para cada percentil. Os resultados em curso devem ser comunicados quase em tempo real para ajudar a detetar problemas imediatos. Os resultados devem também ser agregados ao longo de mais tempo para fins estatísticos.

No caso de problemas de latência que afetem o desempenho, um operador deve ser capaz de identificar rapidamente a causa do gargalo, examinando a latência de cada etapa executada por cada solicitação. Os dados de desempenho devem, portanto, fornecer um meio de correlacionar as medidas de desempenho para cada etapa, a fim de vinculá-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 e análises ad hoc complexas das informações de desempenho.

Monitorização de segurança

Todos os sistemas comerciais que incluam dados sensíveis devem implementar uma estrutura de segurança. A complexidade do mecanismo de segurança é geralmente uma função da sensibilidade dos dados. Em um sistema que exija que os usuários sejam autenticados, você deve registrar:

• Todas as tentativas de início de sessão, independentemente de falharem ou serem bem-sucedidas.
• Todas as operações realizadas por um usuário autenticado e os detalhes de todos os recursos acessados.
• Quando um usuário termina uma sessão e termina sessão.

O monitoramento pode ajudar a detetar ataques ao sistema. Por exemplo, um grande número de tentativas de entrada com falha pode indicar um ataque de força bruta. Um aumento inesperado nas solicitações pode ser o resultado de um ataque distribuído de negação de serviço (DDoS). Você deve estar preparado para monitorar todas as solicitações para todos os recursos, independentemente da origem dessas solicitações. Um sistema que tenha uma vulnerabilidade de início de sessão pode expor acidentalmente recursos ao mundo exterior sem exigir que um utilizador inicie sessão.

Requisitos para o controlo de segurança

Os aspetos mais críticos do controlo de segurança devem permitir ao operador acelerar a:

• Detetar tentativas de intrusão por uma entidade não autenticada.
• Identificar tentativas de entidades de realizar operações em dados para os quais não lhes foi concedido acesso.
• Determine se o sistema, ou alguma parte do sistema, está sob ataque externo ou interno. (Por exemplo, um usuário autenticado mal-intencionado pode estar tentando derrubar o sistema.)

Para satisfazer estes requisitos, o operador deve ser notificado 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.

As informações fornecidas a um operador devem incluir o endereço de host da fonte para cada solicitação. Se as violações de segurança surgirem regularmente de um determinado intervalo de endereços, esses anfitriões podem ser bloqueados.

Uma parte fundamental na manutenção da segurança de um sistema é ser capaz de detetar rapidamente ações que se desviam do padrão usual. Informações como o número de solicitações de entrada com falha ou bem-sucedidas podem ser exibidas visualmente para ajudar a detetar se há um pico de atividade em um momento incomum. (Um exemplo dessa atividade são os usuários que entram às 3:00 da manhã e realizam um grande número de operações quando seu dia de trabalho começa às 9:00 da manhã). Essas informações também podem ser usadas para ajudar a configurar o dimensionamento automático baseado em tempo. Por exemplo, se um operador observar que um grande número de utilizadores inicia sessão regularmente a uma determinada hora do dia, pode organizar o início de serviços de autenticação adicionais para lidar com o volume de trabalho e, em seguida, encerrar esses serviços adicionais quando o pico tiver passado.

Fontes de dados, instrumentação e requisitos de coleta de dados

A segurança é um aspeto abrangente da maioria dos sistemas distribuídos. É provável que os dados pertinentes sejam gerados em vários pontos de um sistema. Você deve considerar a adoção de uma abordagem de Gerenciamento de Informações e Eventos de Segurança (SIEM) para coletar as informações relacionadas à segurança resultantes de eventos gerados pelo aplicativo, equipamento de rede, servidores, firewalls, software antivírus e outros elementos de prevenção de invasões.

O monitoramento de segurança pode incorporar dados de ferramentas que não fazem parte do seu aplicativo. Essas ferramentas podem incluir utilitários que identificam atividades de varredura de portas por agências externas ou filtros de rede que detetam tentativas de obter acesso não autenticado ao seu aplicativo e dados.

Em todos os casos, os dados recolhidos devem permitir que um administrador determine a natureza de qualquer ataque e tome as contramedidas adequadas.

Análise de dados de segurança

Uma característica do monitoramento de segurança é a variedade de fontes das quais os dados surgem. Os diferentes formatos e nível de detalhe geralmente exigem uma análise complexa dos dados capturados para uni-los em um fio coerente de informações. Além dos casos mais simples (como a deteção de um grande número de entradas com falha ou tentativas repetidas de obter acesso não autorizado a recursos críticos), pode não ser possível executar qualquer processamento automatizado complexo de dados de segurança. Em vez disso, pode ser preferível gravar esses dados, com carimbo de data/hora, mas em sua forma original, em um repositório seguro para permitir a análise manual de especialistas.

Monitoramento de SLA

Muitos sistemas comerciais que suportam clientes pagantes fazem garantias sobre o desempenho do sistema na forma de SLAs. Essencialmente, os SLAs afirmam que o sistema pode lidar com um volume definido de trabalho dentro de um período de tempo acordado e sem perder informações críticas. O monitoramento de SLA está preocupado em garantir que o sistema possa atender a SLAs mensuráveis.

Observação

O monitoramento do SLA está intimamente relacionado ao monitoramento de desempenho. Mas enquanto o monitoramento de desempenho se preocupa em garantir que o sistema funcione de forma otimizada, o monitoramento de SLA é regido por uma obrigação contratual que define o que realmente significa otimamente .

Os SLAs são frequentemente definidos em termos de:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode garantir que o sistema estará disponível por 99,9% do tempo. Isso equivale a não mais do que 9 horas de inatividade por ano, ou aproximadamente 10 minutos por semana.
• Rendimento operacional. Esse aspeto é frequentemente expresso como uma ou mais marcas de água altas, como a garantia de que o sistema possa suportar até 100.000 solicitações de usuários simultâneas ou lidar com 10.000 transações comerciais simultâneas.
• Tempo de resposta operacional. O sistema pode também dar garantias quanto ao ritmo a que os pedidos são processados. Um exemplo é que 99% de todas as transações comerciais serão concluídas em 2 segundos, e nenhuma transação levará mais de 10 segundos.

Observação

Alguns contratos para sistemas comerciais também podem incluir SLAs para suporte ao cliente. Um exemplo é que todas as solicitações de help-desk obterão uma resposta em cinco minutos e que 99% de todos os problemas serão totalmente resolvidos dentro de 1 dia útil. O rastreamento eficaz de problemas (descrito mais adiante nesta seção) é fundamental para cumprir SLAs como estes.

Requisitos para monitoramento de SLA

Ao mais alto nível, um operador deve ser capaz de determinar rapidamente se o sistema está a cumprir os SLAs acordados ou não. E, caso contrário, o operador deve ser capaz de detalhar e examinar os fatores subjacentes para determinar as razões para um desempenho abaixo do padrão.

Os indicadores típicos de alto nível que podem ser representados visualmente incluem:

• A porcentagem de tempo de atividade do serviço.
• A taxa de transferência do aplicativo (medida em termos de transações bem-sucedidas ou operações por segundo).
• O número de pedidos de candidatura bem-sucedidos/reprovados.
• O número de falhas, exceções e avisos do aplicativo e do sistema.

Todos estes indicadores devem poder ser filtrados por um período de tempo especificado.

Um aplicativo em nuvem provavelmente compreenderá vários subsistemas e componentes. Um operador deve ser capaz de selecionar um indicador de alto nível e ver como ele é composto a partir da integridade dos elementos subjacentes. Por exemplo, se o tempo de atividade do sistema geral cair abaixo de um valor aceitável, um operador deve ser capaz de aumentar o zoom e determinar quais elementos estão contribuindo para essa falha.

Observação

O tempo de atividade do sistema precisa ser definido com cuidado. Em um sistema que usa redundância para garantir a disponibilidade máxima, instâncias individuais de elementos podem falhar, mas o sistema pode permanecer funcional. O tempo de atividade do sistema, conforme apresentado pelo monitoramento de integridade, deve indicar o tempo de atividade agregado de cada elemento e não necessariamente se o sistema realmente parou. Além disso, as falhas podem ser isoladas. Assim, mesmo que um sistema específico não esteja disponível, o restante do sistema pode permanecer disponível, embora com funcionalidade reduzida. (Em um sistema de comércio eletrônico, uma falha no sistema pode impedir que um cliente faça pedidos, mas o cliente ainda pode navegar no catálogo de produtos.)

Para efeitos de alerta, o sistema deve ser capaz de gerar um evento se algum dos indicadores de alto nível exceder um limiar especificado. Os detalhes de nível inferior dos vários fatores que compõem o indicador de alto nível devem estar disponíveis como dados contextuais para o sistema de alerta.

Fontes de dados, instrumentação e requisitos de coleta de dados

Os dados brutos necessários para dar suporte ao monitoramento de SLA são semelhantes aos dados brutos necessários para o monitoramento de desempenho, juntamente com alguns aspetos do monitoramento de integridade e disponibilidade. (Consulte essas seções para obter mais detalhes.) Você pode capturar esses dados da seguinte forma:

• Execução de monitoramento de endpoint.
• Registro de exceções, falhas e avisos.
• Rastreando a execução de solicitações do usuário.
• Monitorizar a disponibilidade de quaisquer serviços de terceiros que o sistema utilize.
• Usando métricas de desempenho e contadores.

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

Analisando dados de SLA

Os dados de instrumentação devem ser agregados para gerar uma imagem do desempenho geral do sistema. Os dados agregados também devem suportar a análise detalhada para permitir o exame do desempenho dos subsistemas subjacentes. Por exemplo, deve ser capaz de:

• 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 das solicitações do usuário para dividir o tempo de resposta geral de uma solicitação nos tempos de resposta dos itens de trabalho individuais nessa solicitação.
• Determine a disponibilidade geral do sistema como uma porcentagem do tempo de atividade para qualquer período específico.
• Analisar a disponibilidade de tempo percentual dos componentes e serviços individuais no sistema. Isso pode envolver a análise de logs gerados por serviços de terceiros.

Muitos sistemas comerciais são obrigados a relatar números reais de desempenho em relação aos SLAs acordados por um período especificado, normalmente um mês. Essas informações podem ser usadas para calcular créditos ou outras formas de reembolso para clientes se os SLAs não forem cumpridos durante esse período. Você pode calcular a disponibilidade de um serviço usando a técnica descrita na seção Analisando dados de disponibilidade.

Para fins internos, uma organização também pode rastrear o número e a natureza dos incidentes que causaram falhas nos serviços. Aprender a resolver esses problemas rapidamente, ou eliminá-los completamente, ajudará a reduzir o tempo de inatividade e cumprir os SLAs.

Auditoria

Dependendo da natureza do aplicativo, pode haver regulamentos legais ou outros que especifiquem requisitos para auditar as operações dos usuários e registrar todo o acesso aos dados. A auditoria pode fornecer evidências que vinculam os clientes a solicitações específicas. O não repúdio é um fator importante em muitos sistemas de e-business para ajudar a manter a confiança entre um cliente e a organização responsável pelo aplicativo ou serviço.

Requisitos para auditoria

Um analista deve ser capaz de rastrear a sequência de operações de negócios que os usuários estão executando para que você possa reconstruir as ações dos usuários. Isso pode ser necessário simplesmente como uma questão de registro ou como parte de uma investigação forense.

As informações de auditoria são altamente sensíveis. Ele provavelmente incluirá dados que identificam os usuários do sistema, juntamente com as tarefas que eles estão executando. Por esse motivo, as informações de auditoria provavelmente assumirão a forma de relatórios que estão disponíveis apenas para analistas confiáveis, em vez de como um sistema interativo que suporta detalhamento de operações gráficas. Um analista deve ser capaz de gerar uma gama de relatórios. Por exemplo, os relatórios podem listar todas as atividades dos usuários que ocorrem durante um período de tempo especificado, detalhar a cronologia da atividade de um único usuário ou listar a sequência de operações executadas em relação a um ou mais recursos.

Fontes de dados, instrumentação e requisitos de coleta de dados

As principais fontes de informação para auditoria podem incluir:

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

O formato dos dados de auditoria e a forma como são armazenados podem ser determinados por requisitos regulamentares. Por exemplo, pode não ser possível limpar os dados de forma alguma. (Deve ser gravado no seu formato original.) O acesso ao repositório onde é mantido deve ser protegido para evitar adulterações.

Análise de dados de auditoria

Um analista deve ser capaz de acessar os dados brutos em sua totalidade, em sua forma original. Além da exigência de gerar relatórios de auditoria comuns, as ferramentas para analisar esses dados provavelmente serão especializadas e mantidas externas ao sistema.

Monitorização da utilização

O monitoramento de uso rastreia como os recursos e componentes de um aplicativo são usados. Um operador pode utilizar os dados recolhidos para:

• Determine quais recursos são muito usados e determine possíveis pontos de acesso no sistema. Elementos de alto tráfego podem se beneficiar do particionamento funcional ou até mesmo da replicação para distribuir a carga de forma mais uniforme. Um operador também pode usar essas informações para verificar 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.

• Obter informações sobre os eventos operacionais do sistema em uso normal. Por exemplo, em um site de comércio eletrônico, você pode registrar as informações estatísticas sobre o número de transações e o volume de clientes que são responsáveis por elas. Essas informações podem ser usadas para o planejamento de capacidade à medida que o número de clientes cresce.

• Detetar (possivelmente indiretamente) a satisfação do usuário com o desempenho ou funcionalidade do sistema. Por exemplo, se um grande número de clientes em um sistema de comércio eletrônico abandona regularmente seus carrinhos de compras, isso pode ser devido a um problema com a funcionalidade de checkout.

• 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 usuário em um sistema multilocatário exceder sua cota paga de tempo de processamento ou uso de recursos durante um período especificado, seu acesso poderá ser limitado ou o processamento poderá ser limitado.

Requisitos para monitoramento de uso

Para examinar o uso do sistema, um operador normalmente precisa ver informações que incluem:

• O número de solicitações que são processadas por cada subsistema e direcionadas para cada recurso.
• O trabalho que cada usuário está executando.
• O volume de armazenamento de dados que cada usuário ocupa.
• Os recursos que cada usuário está acessando.

Um operador também deve ser capaz de gerar gráficos. Por exemplo, um gráfico pode exibir os usuários que consomem mais recursos ou os recursos ou recursos do sistema acessados com mais frequência.

Fontes de dados, instrumentação e requisitos de coleta de dados

O rastreamento de uso pode ser realizado em um nível relativamente alto. Ele pode anotar os horários de início e término de cada solicitação e a natureza da solicitação (leitura, gravação e assim por diante, dependendo do recurso em questão). Pode obter estas informações da seguinte forma:

• Rastreando a atividade do usuário.
• Captura de contadores de desempenho que medem a utilização de cada recurso.
• Monitorização do consumo de recursos por cada utilizador.

Para fins de medição, você também precisa ser capaz de identificar quais usuários são responsáveis por executar quais operações e os recursos que essas operações usam. As informações recolhidas devem ser suficientemente detalhadas para permitir uma faturação precisa.

Acompanhamento de problemas

Clientes e outros usuários podem relatar problemas se ocorrerem eventos ou comportamentos inesperados no sistema. O rastreamento de problemas está preocupado em gerenciar esses problemas, associá-los aos esforços para resolver quaisquer problemas subjacentes no sistema e informar os clientes sobre possíveis resoluções.

Requisitos para o acompanhamento de problemas

Os operadores geralmente realizam o rastreamento de problemas usando um sistema separado que lhes permite registrar e relatar os detalhes dos problemas relatados pelos usuários. Esses detalhes podem incluir as tarefas que o usuário estava tentando executar, os sintomas do problema, a sequência de eventos e quaisquer mensagens de erro ou aviso que foram emitidas.

Fontes de dados, instrumentação e requisitos de coleta de dados

A fonte de dados inicial para dados de rastreamento de problemas é o usuário que relatou o problema em primeiro lugar. O utilizador poderá fornecer dados adicionais, tais como:

• Um despejo de memória (se o aplicativo incluir um componente executado na área de trabalho do usuário).
• Um instantâneo da tela.
• A data e a hora em que o erro ocorreu, juntamente com quaisquer outras informações ambientais, como a localização do utilizador.

Essas informações podem ser usadas para ajudar no esforço de depuração e ajudar a construir uma lista de pendências para versões futuras do software.

Analisando dados de rastreamento de problemas

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

O progresso do esforço de depuração deve ser registrado em relação a cada relatório de problema. Quando o problema é resolvido, o cliente pode ser informado da solução.

Se um utilizador comunicar um problema que tenha uma solução conhecida no sistema de rastreio de problemas, o operador deve poder informar imediatamente o utilizador da solução.

Operações de rastreamento e depuração de versões de software

Quando um usuário relata um problema, muitas vezes ele só está ciente do efeito imediato que ele tem em suas operações. O utilizador só pode comunicar os resultados da sua própria experiência a um operador responsável pela manutenção do sistema. Estas experiências são geralmente apenas um sintoma visível de um ou mais problemas fundamentais. Em muitos casos, um analista precisará vasculhar a cronologia das operações subjacentes para estabelecer a causa raiz do problema. Esse processo é chamado de análise de causa raiz.

Observação

A análise de causa raiz pode revelar ineficiências no design de um aplicativo. Nessas situações, talvez seja possível retrabalhar os elementos afetados e implantá-los como parte de uma versão subsequente. Este processo requer um controlo cuidadoso e os componentes atualizados devem ser monitorizados de perto.

Requisitos para rastreamento e depuração

Para rastrear eventos inesperados e outros problemas, é vital que os dados de monitoramento forneçam informações suficientes para permitir que um analista rastreie as origens desses problemas e reconstrua a sequência de eventos que ocorreram. Essas informações devem ser suficientes para permitir que um analista diagnostique a causa raiz de quaisquer problemas. Um desenvolvedor pode então fazer as modificações necessárias para evitar que elas se repitam.

Fontes de dados, instrumentação e requisitos de coleta de dados

A solução de problemas pode envolver o rastreamento de todos os métodos (e seus parâmetros) invocados como parte de uma operação para criar uma árvore que retrate o fluxo lógico através do sistema quando um cliente faz uma solicitação específica. As exceções e avisos que o sistema gera como resultado desse fluxo precisam ser capturados e registrados.

Para suportar a depuração, o sistema pode fornecer ganchos que permitem que um operador capture informações de estado em pontos cruciais do sistema. Ou, o sistema pode fornecer informações detalhadas passo a passo à medida que as operações selecionadas progridem. A captura de dados neste nível de detalhe pode impor uma carga adicional ao sistema e deve ser um processo temporário. Um operador usa esse processo principalmente quando uma série altamente incomum de eventos ocorre e é difícil de replicar, ou quando uma nova liberação de um ou mais elementos em um sistema requer monitoramento cuidadoso para garantir que os elementos funcionem conforme o esperado.

O pipeline de monitoramento e diagnóstico

A monitorização de um sistema distribuído em grande escala coloca um desafio significativo. Cada um dos cenários descritos na secção anterior não deve necessariamente ser considerado isoladamente. É provável que haja uma sobreposição significativa nos dados de monitoramento e diagnóstico necessários para cada situação, embora esses dados possam precisar ser processados e apresentados de maneiras diferentes. Por estas razões, deve ter uma visão holística da monitorização e do diagnóstico.

Você pode imaginar todo o processo de monitoramento e diagnóstico como um pipeline que compreende os estágios mostrados na Figura 1.

Figura 1 - As etapas no pipeline de monitoramento e diagnóstico.

A Figura 1 destaca como os dados para monitoramento e diagnóstico podem vir de uma variedade de fontes de dados. As etapas de instrumentação e coleta estão preocupadas em identificar as fontes de onde os dados precisam ser capturados, determinar quais dados capturar, como capturá-los e como formatar esses dados para que possam ser facilmente examinados. A etapa de análise/diagnóstico pega os dados brutos e os usa para gerar informações significativas que um operador pode usar para determinar o estado do sistema. O operador pode usar essas informações para tomar decisões sobre possíveis ações a serem tomadas e, em seguida, alimentar os resultados de volta para as etapas de instrumentação e coleta. A fase de visualização/alerta apresenta uma visão consumível do estado do sistema. Ele pode exibir informações quase em tempo real usando uma série de painéis. E pode gerar relatórios, gráficos e tabelas para fornecer uma visão histórica dos dados que podem ajudar 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 para um operador. Em alguns casos, um alerta também pode ser usado para acionar um processo automatizado que tenta tomar ações corretivas, como o dimensionamento automático.

Note-se que estas etapas constituem um processo de fluxo contínuo onde as etapas estão acontecendo em paralelo. Idealmente, todas as fases devem ser configuradas dinamicamente. Em alguns pontos, especialmente quando um sistema foi implantado recentemente ou está enfrentando problemas, pode ser necessário coletar dados estendidos com mais frequência. Outras vezes, deve ser possível voltar a capturar um nível básico de informações essenciais para verificar se o sistema está funcionando corretamente.

Além disso, todo o processo de monitoramento deve ser considerado uma solução ativa e contínua que está sujeita a ajustes finos e melhorias como resultado do feedback. Por exemplo, você pode começar medindo muitos fatores para determinar a integridade do sistema. A análise ao longo do tempo pode levar a um refinamento à medida que você descarta medidas que não são relevantes, permitindo que você se concentre com mais precisão nos dados de que precisa enquanto minimiza o ruído de fundo.

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

As informações que o processo de monitorização utiliza podem provir de várias fontes, como ilustrado na Figura 1. No nível do aplicativo, as informações vêm de logs de rastreamento incorporados ao 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 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 qualquer outra informação pertinente. O registo dos horários de entrada e saída também pode revelar-se útil.

Você deve registrar todas as exceções e avisos e garantir que você mantenha um rastreamento completo de quaisquer exceções e avisos aninhados. Idealmente, você também deve capturar informações que identifiquem o usuário que está executando o código, juntamente com informações de correlação de atividade (para rastrear solicitações à medida que passam pelo sistema). E você deve registrar as tentativas de acessar todos os recursos, como filas de mensagens, bancos de dados, arquivos e outros serviços dependentes. Essas informações podem ser usadas 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. Essas estruturas podem ser configuráveis para fornecer suas próprias mensagens de rastreamento e informações brutas de diagnóstico, como taxas de transação e sucessos e falhas de transmissão de dados.

Observação

Muitas estruturas modernas publicam automaticamente eventos de desempenho e rastreamento. Capturar essas informações é simplesmente uma questão de fornecer um meio de recuperá-las e armazená-las onde possam ser processadas e analisadas.

O sistema operacional em que o aplicativo está sendo 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. Erros do sistema operacional (como a falha ao abrir um arquivo corretamente) também podem ser relatados.

Você também deve considerar a infraestrutura subjacente e os componentes nos quais o sistema é executado. Máquinas virtuais, 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 seu aplicativo usa outros serviços externos, como um servidor Web ou um sistema de gerenciamento de banco de dados, esses serviços podem publicar suas próprias informações de rastreamento, logs e contadores de desempenho. Os exemplos incluem Exibições de Gerenciamento Dinâmico do SQL Server para controlar operações executadas em um banco de dados do SQL Server e logs de rastreamento do IIS para registrar solicitações feitas a um servidor Web.

À medida que os componentes de um sistema são modificados e novas versões são implantadas, é importante poder atribuir problemas, eventos e métricas a cada versão. Essas informações devem ser vinculadas ao pipeline de liberação para que os problemas com uma versão específica de um componente possam ser rastreados rapidamente e corrigidos.

Problemas de segurança podem ocorrer em qualquer ponto do sistema. Por exemplo, um utilizador pode tentar iniciar sessão com um ID de utilizador ou palavra-passe inválidos. Um usuário autenticado pode tentar obter acesso não autorizado a um recurso. Ou um usuário pode fornecer uma chave inválida ou desatualizada para acessar informações criptografadas. As informações relacionadas à segurança para solicitações bem-sucedidas e com falha devem ser sempre registradas.

A seção Instrumentando um aplicativo contém mais orientações sobre as informações que você deve capturar. Mas você pode usar uma variedade de estratégias para reunir essas informações:

• Monitorização da aplicação/sistema. Essa estratégia usa fontes internas dentro do 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 do cliente. O aplicativo pode incluir instruções de rastreamento que podem ser seletivamente habilitadas ou desabilitadas conforme as circunstâncias ditarem. Também pode ser possível injetar diagnósticos dinamicamente usando uma estrutura de diagnóstico. Essas estruturas geralmente fornecem plug-ins que podem ser anexados a vários pontos de instrumentação em seu código e capturar dados de rastreamento nesses pontos.

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

• Monitorização real do utilizador. Essa abordagem registra as interações entre um usuário e o aplicativo e observa o fluxo de cada solicitação e resposta. Essas informações podem ter uma dupla finalidade: podem ser usadas para medir o uso por cada usuário e podem ser usadas para determinar se os usuários estão recebendo uma qualidade de serviço adequada (por exemplo, tempos de resposta rápidos, baixa latência e erros mínimos). Você pode usar os dados capturados para identificar áreas de preocupação onde as falhas ocorrem com mais frequência. Você também pode usar os dados para identificar elementos em que o sistema fica mais lento, possivelmente devido a pontos críticos no aplicativo ou alguma outra forma de gargalo. Se você implementar essa abordagem cuidadosamente, talvez seja possível reconstruir os fluxos dos usuários através do aplicativo para fins de depuração e teste.

  Importante

  Você deve considerar os dados capturados pelo monitoramento de usuários reais como altamente confidenciais, pois 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.

• Monitoramento sintético do usuário. Nessa abordagem, você escreve seu próprio cliente de teste que simula um usuário e executa 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 que tipo de saída de monitoramento é gerada nessas condições.

  Observação

  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.

• Definição de perfis. Essa abordagem visa principalmente monitorar e melhorar o desempenho do aplicativo. Em vez de operar no nível funcional de monitoramento de usuário real e sintético, ele captura informações de nível inferior à medida que o aplicativo é executado. Você pode implementar a criação de perfil usando amostragem periódica do estado de execução de um aplicativo (determinando qual parte do código o aplicativo está sendo executado em um determinado momento). Você também pode usar instrumentação que insere testes no código em momentos importantes (como o início e o fim de uma chamada de método) e registra quais métodos foram invocados, em que momento e quanto tempo cada chamada levou. Em seguida, você pode analisar esses dados para determinar quais partes do aplicativo podem causar problemas de desempenho.

• Monitorização de pontos finais. Essa técnica 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. Diferentes pontos de extremidade podem se concentrar em vários aspetos da funcionalidade. Você pode escrever seu próprio cliente de diagnóstico que envia solicitações periódicas para esses pontos de extremidade e assimilar as respostas. Para obter mais informações, consulte o padrão Health Endpoint Monitoring.

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

Instrumentando um aplicativo

A instrumentação é uma parte crítica do processo de monitorização. Você pode tomar decisões significativas sobre o desempenho e a integridade de um sistema somente se primeiro capturar os dados que permitem tomar essas decisões. As informações coletadas usando a instrumentação devem ser suficientes para permitir que você avalie o desempenho, diagnostique problemas e tome decisões sem exigir que você entre em um servidor de produção remoto para executar o rastreamento (e a depuração) manualmente. Os dados de instrumentação geralmente incluem métricas e informações gravadas em logs de rastreamento.

O conteúdo de um log de rastreamento pode ser o resultado de dados textuais gravados pelo aplicativo ou dados binários criados como resultado de um evento de rastreamento, se o aplicativo estiver usando o Rastreamento de Eventos para Windows (ETW). Eles também podem ser gerados a partir de logs do sistema que registram eventos decorrentes de partes da infraestrutura, como um servidor web. As mensagens de registo textuais são muitas vezes concebidas para serem legíveis por humanos, mas também devem ser escritas num formato que permita a um sistema automatizado analisá-las facilmente.

Você também deve categorizar logs. Não escreva todos os dados de rastreamento em um único log, mas use logs separados para registrar a saída de rastreamento de diferentes aspetos operacionais do sistema. Em seguida, você pode filtrar rapidamente as mensagens de log lendo o log apropriado em vez de ter que processar um único arquivo longo. Nunca escreva informações com requisitos de segurança diferentes (como informações de auditoria e dados de depuração) no mesmo log.

Observação

Um log pode ser implementado como um arquivo no sistema de arquivos ou pode ser mantido em algum outro formato, como um blob no armazenamento de blobs. As informações de log também podem ser mantidas em um armazenamento mais estruturado, como linhas em uma tabela.

As métricas geralmente serão uma medida ou contagem de algum aspeto ou recurso no sistema em um momento específico, com uma ou mais tags ou dimensões associadas (às vezes chamadas de amostra). Uma única instância de uma métrica geralmente não é útil isoladamente. Em vez disso, as métricas têm de ser capturadas ao longo do tempo. A questão-chave a considerar é quais métricas você deve registrar e com que frequência. A geração de dados para métricas com muita frequência pode impor uma carga adicional significativa ao sistema, enquanto a captura de métricas com pouca frequência 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 variar significativamente de segundo para segundo, mas a alta utilização se torna um problema apenas se for de longa duração 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 monitoramento exigem o estágio de análise e diagnóstico no pipeline de monitoramento para correlacionar os dados recuperados de várias fontes. Esses dados podem assumir várias formas nos dados brutos, e o processo de análise deve ser fornecido com dados de instrumentação suficientes para poder mapear essas diferentes formas. Por exemplo, no nível da estrutura do aplicativo, uma tarefa pode ser identificada por um ID de thread. Dentro de um aplicativo, o mesmo trabalho pode ser associado ao ID do usuário que está executando essa tarefa.

Além disso, é improvável que haja um mapeamento 1:1 entre threads e solicitações de usuário, porque operações assíncronas podem reutilizar os mesmos threads para executar operações em nome de mais de um usuário. Para complicar ainda mais as coisas, uma única solicitação pode ser tratada por mais de um thread à medida que a execução flui pelo sistema. Se possível, associe cada solicitação a um ID de atividade exclusivo que é propagado pelo sistema como parte do contexto da solicitação. (A técnica para gerar e incluir IDs de atividade nas informações de rastreamento depende da tecnologia usada para capturar os dados de rastreamento.)

Todos os dados de monitorização devem ter o carimbo de data/hora da mesma forma. Para consistência, registre todas as datas e horas usando o Tempo Universal Coordenado. Isto irá ajudá-lo a rastrear mais facilmente sequências de eventos.

Observação

Os computadores que operam em fusos horários e redes diferentes podem não estar sincronizados. Não dependa apenas do uso de carimbos de data/hora para correlacionar dados de instrumentação que abrangem várias máquinas.

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

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

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

• Habilite a criação de perfil somente quando necessário, pois ela pode impor uma sobrecarga significativa ao sistema. A criação de perfil usando instrumentação registra um evento (como uma chamada de método) toda vez que ele ocorre, enquanto a amostragem registra apenas eventos selecionados. A seleção pode ser baseada no tempo (uma vez a cada n segundos) ou na frequência (uma vez a cada n solicitações). Se os eventos ocorrerem com muita frequência, a criação de perfis por instrumentação pode causar muita carga e afetar o desempenho geral. Neste caso, pode ser preferível o método de 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 permitir que um desenvolvedor ou administrador determine a origem de cada solicitação. Isso pode incluir alguma forma de ID de atividade que identifique uma instância específica de uma solicitação. Também pode incluir informações que podem ser usadas para correlacionar esta atividade com o trabalho computacional realizado e os recursos utilizados. Observe que esse trabalho pode cruzar os limites do processo e da máquina. Para a medição, o contexto também deve incluir (direta ou indiretamente através de outras informações correlacionadas) uma referência ao cliente que causou o pedido. Esse contexto fornece informações valiosas sobre o estado do aplicativo no momento em que os dados de monitoramento foram capturados.

• Registre todas as solicitações e os locais ou regiões a partir dos quais essas solicitações são feitas. Estas informações podem ajudar a determinar se existem pontos de acesso específicos para cada local. Essas informações também podem ser úteis para determinar se um aplicativo deve ser reparticionado ou os dados que ele usa.

• 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 a pilha de chamadas, se possível.

• Seja consistente nos dados que os diferentes elementos do seu aplicativo capturam, pois isso pode ajudar na análise de eventos e correlacioná-los com as solicitações do usuário. 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. Reúna dados dos principais contadores de desempenho, como o volume de E/S que está sendo executado, a utilização da rede, o número de solicitações, o uso da memória e a utilização da CPU. Alguns serviços de infraestrutura podem fornecer seus próprios contadores de desempenho específicos, como o número de conexões com um banco de dados, a taxa na qual as transações estão sendo executadas e o número de transações bem-sucedidas ou com falha. 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. Registre informações sobre o tempo necessário para executar cada chamada e o sucesso ou falha da chamada. 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 qualquer aplicativo ou tecnologia específica, mas espera que as informações sigam um formato específico que geralmente é definido por um esquema. O esquema especifica efetivamente um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. O esquema deve ser generalizado para permitir que os dados cheguem de uma variedade de plataformas e dispositivos.

Um esquema comum deve incluir campos que são comuns a todos os eventos de instrumentação, como o nome do evento, a hora do evento, o endereço IP do remetente e os detalhes necessários para correlacionar com outros eventos (como um ID de usuário, um ID de dispositivo e um ID de 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; O aplicativo 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. Isso pode ser informações sobre exceções, eventos de início e término do aplicativo e sucesso ou falha de chamadas de API de serviço Web. Todos os aplicativos que usam o mesmo conjunto de campos de domínio devem emitir o mesmo conjunto de eventos, permitindo que um conjunto de relatórios e análises comuns seja criado.

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

Práticas recomendadas para instrumentação de aplicativos

A lista a seguir resume as práticas recomendadas para instrumentar um aplicativo distribuído em execução na nuvem.

• Torne os logs 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.

• Use o mesmo fuso horário e formato para todos os carimbos de data/hora. Isso ajudará 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 os usuários. Limpe essas informações antes de serem registradas, mas certifique-se de que os detalhes relevantes sejam mantidos. Por exemplo, remova o ID e a senha de qualquer cadeia de conexão de banco de dados, mas grave as informações restantes no log para que um analista possa determinar que o sistema está acessando o banco de dados correto. Registre todas as exceções críticas, mas permita que o administrador ative e desative o logon para níveis mais baixos de exceções e avisos. Além disso, capture e registre todas as informações de lógica de repetição. Esses dados podem ser úteis para monitorar a integridade transitória do sistema.

• Rastreie chamadas de 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.

• Com exceção dos eventos de auditoria, certifique-se de que todas as chamadas de registro sejam operações de disparo e esquecimento que não bloqueiem o progresso das operações de negócios. Os eventos de auditoria são excecionais porque são críticos para o negócio e podem ser classificados como uma parte fundamental das operações de negócios.

• Certifique-se de que o registro em log é extensível e não tem dependências diretas em um destino concreto. Por exemplo, em vez de gravar informações usando System.Diagnostics.Trace, defina uma interface abstrata (como ILogger) que exponha métodos de log e que possa ser implementada por qualquer meio apropriado.

• Certifique-se de que todo o registo é à prova de falhas e nunca dispara quaisquer erros em cascata. O registro em log não deve gerar exceções.

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

Recolha e armazenamento de dados

A etapa de coleta do processo de monitoramento está preocupada em recuperar as informações geradas pela instrumentação, formatar esses dados para facilitar o consumo da etapa de análise/diagnóstico e salvar os dados transformados em armazenamento confiável. Os dados de instrumentação que você coleta de diferentes partes de um sistema distribuído podem ser mantidos em uma variedade de locais e com formatos variados. Por exemplo, o código do aplicativo pode gerar arquivos de log de rastreamento e gerar dados de log de eventos do aplicativo, enquanto os contadores de desempenho que monitoram os principais aspetos da infraestrutura que seu aplicativo usa podem ser capturados por meio de outras tecnologias. Quaisquer componentes e serviços de terceiros que seu aplicativo usa podem fornecer informações de instrumentação em formatos diferentes, usando arquivos de rastreamento separados, armazenamento de blob ou até mesmo um armazenamento de dados personalizado.

A coleta de dados geralmente é realizada por meio de um serviço de coleta que pode ser executado de forma autônoma a partir do aplicativo que gera os dados de instrumentação. A Figura 2 ilustra um exemplo dessa arquitetura, destacando o subsistema de coleta de dados de instrumentação.

Figura 2 - Recolha de dados de instrumentação.

Observe que esta é uma exibição simplificada. O serviço de recolha não é necessariamente um processo único e pode incluir muitas partes constituintes que funcionam em máquinas diferentes, conforme descrito nas secções seguintes. Além disso, se a análise de alguns dados de telemetria precisar ser executada rapidamente (análise a quente, conforme descrito na seção Suporte a análise quente, quente e fria mais adiante neste documento), os componentes locais que operam fora do serviço de coleta podem executar as tarefas de análise imediatamente. A Figura 2 mostra essa situação para eventos selecionados. Após o processamento analítico, os resultados podem ser enviados diretamente para o subsistema de visualização e alerta. Os dados que são submetidos a análises quentes ou frias são mantidos em armazenamento enquanto aguardam processamento.

Para aplicativos e serviços do Azure, o Diagnóstico do Azure fornece uma solução possível para capturar dados. O Diagnóstico do Azure reúne dados das seguintes fontes para cada nó de computação, agrega-os e, em seguida, carrega-os no Armazenamento do Azure:

• Registos do IIS
• Logs de solicitação com falha do IIS
• Registos de eventos do Windows
• Contadores de desempenho
• Relatórios de falha
• Registos da infraestrutura do Diagnóstico do Azure
• Registos de erros personalizados
• Fonte de eventos do .NET
• ETW baseado no manifesto

Para obter mais informações, consulte o artigo Azure: Noções básicas de telemetria e solução de problemas.

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

Considerando a natureza elástica da nuvem e para evitar a necessidade de recuperar manualmente dados de telemetria de cada nó do sistema, você deve providenciar para que os dados sejam transferidos para um local central e consolidados. Em um sistema que abrange vários datacenters, pode ser útil primeiro coletar, consolidar e armazenar dados região a região e, em seguida, agregar os dados regionais em um único sistema central.

Para otimizar o uso da largura de banda, você pode optar por transferir dados menos urgentes em partes, como lotes. No entanto, os dados não devem ser adiados indefinidamente, especialmente se contiverem informações sensíveis em termos de tempo.

Extraindo e enviando dados de instrumentação

O subsistema de coleta de dados de instrumentação pode recuperar ativamente dados de instrumentação de vários logs e outras fontes para cada instância do aplicativo (o modelo pull). Ou, ele pode atuar como um recetor passivo que aguarda que os dados sejam enviados dos componentes que constituem cada instância do aplicativo (o modelo push).

Uma abordagem para implementar o modelo pull é usar agentes de monitoramento que são executados localmente com cada instância do aplicativo. Um agente de monitoramento é um processo separado que periodicamente recupera (extrai) dados de telemetria coletados no nó local e grava essas informações diretamente no armazenamento centralizado que todas as instâncias do aplicativo compartilham. Este é o mecanismo que o Diagnóstico do Azure implementa. Cada instância de uma função Web ou de trabalho do Azure pode ser configurada para capturar informações de diagnóstico e outras informações de rastreamento armazenadas localmente. O agente de monitoramento executado ao lado de cada instância copia os dados especificados para o Armazenamento do Azure. O artigo Habilitando diagnósticos nos Serviços de Nuvem do Azure e Máquinas Virtuais fornece mais detalhes sobre esse processo. Alguns elementos, como logs do IIS, despejos de memória e logs de erros personalizados, são gravados no armazenamento de blobs. Os dados do log de eventos do Windows, eventos ETW e contadores de desempenho são registrados no armazenamento de tabelas. A Figura 3 ilustra este mecanismo.

Figura 3 - Usando um agente de monitoramento para extrair informações e gravar no armazenamento compartilhado.

Observação

A utilização de um agente de monitorização é o processo mais adequado para capturar dados de instrumentação extraídos naturalmente de uma origem de dados. Um exemplo são as informações das Exibições de Gerenciamento Dinâmico do SQL Server ou o comprimento de uma fila do Barramento de Serviço do Azure.

É viável usar a abordagem descrita anteriormente para armazenar dados de telemetria para um aplicativo de pequena escala executado em um número limitado de nós em um único local. No entanto, um aplicativo de nuvem global complexo, altamente escalável pode gerar grandes volumes de dados de centenas de funções Web e de trabalho, fragmentos de banco 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. Portanto, sua solução de telemetria deve ser escalável para evitar que atue como 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 faturamento) se parte do sistema falhar.

Para resolver esses problemas, você pode implementar o enfileiramento, como mostra a Figura 4. Nessa arquitetura, o agente de monitoramento local (se puder ser configurado adequadamente) ou o serviço de coleta de dados personalizado (se não) posta dados em uma fila. Um processo separado executado de forma assíncrona (o serviço de gravação de armazenamento na Figura 4) pega os dados nessa fila e os grava no armazenamento compartilhado. Uma fila de mensagens é adequada para esse cenário porque fornece semântica "pelo menos uma vez" que ajuda a garantir que os dados enfileirados não sejam perdidos depois de publicados. Você pode implementar o serviço de gravação de armazenamento usando uma função de trabalho separada.

Figura 4 - Usando uma fila para armazenar dados de instrumentação em buffer.

O serviço de coleta de dados local pode adicionar dados a uma fila imediatamente após seu recebimento. A fila atua como um buffer e o serviço de gravação de armazenamento pode recuperar e gravar os dados em seu próprio ritmo. Por padrão, uma fila opera em uma base de primeiro a entrar, primeiro a sair. Mas você pode priorizar mensagens para acelerá-las na fila se elas contiverem dados que devem ser tratados mais rapidamente. Para obter mais informações, consulte o padrão de fila de prioridade. Como alternativa, você pode usar diferentes canais (como tópicos do Service Bus) para direcionar dados para destinos diferentes, dependendo da forma de processamento analítico necessária.

Para escalabilidade, você pode executar várias instâncias do serviço de gravação de armazenamento. Se houver um grande volume de eventos, você poderá usar um hub de eventos para enviar os dados para diferentes recursos de computação para processamento e armazenamento.

Consolidação de 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 integridade geral do sistema, é necessário consolidar alguns aspetos dos dados nas visualizações locais. Você pode fazer isso depois que os dados forem armazenados, mas, em alguns casos, você também pode alcançá-lo à medida que os dados são coletados. Em vez de serem gravados diretamente no armazenamento compartilhado, os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combina dados e atua como um processo de filtro e limpeza. Por exemplo, os dados de instrumentação que incluem as mesmas informações de correlação, como um ID de atividade, podem ser amalgamados. (É possível que um usuário comece a executar uma operação de negócios em um nó e, em seguida, seja transferido para outro nó em caso de falha do nó ou dependendo de como o balanceamento de carga está configurado.) Esse processo também pode detetar e remover quaisquer dados duplicados (sempre uma possibilidade se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação para o armazenamento). A Figura 5 ilustra um exemplo desta estrutura.

Figura 5 - Usando um serviço separado para consolidar e limpar dados de instrumentação.

Armazenamento de dados de instrumentação

As discussões anteriores descreveram uma visão bastante simplista da forma como os dados de instrumentação são armazenados. Na realidade, pode fazer sentido armazenar os diferentes tipos de informação utilizando tecnologias mais adequadas à forma como cada tipo é suscetível de ser utilizado.

Por exemplo, o blob do Azure e o armazenamento de tabelas têm algumas semelhanças na forma como são acedidos. Mas eles têm limitações nas operações que você pode executar usando-os, e a granularidade dos dados que eles mantêm é bastante diferente. Se tiver de efetuar operações mais analíticas ou precisar de capacidades de pesquisa em texto completo nos dados, pode ser mais adequado utilizar um armazenamento de dados que forneça capacidades otimizadas para tipos específicos de consultas e acesso a dados. Por exemplo:

• Os dados de contadores de desempenho podem ser armazenados numa base de dados SQL para permitir análises ad hoc.
• Os logs de rastreamento podem ser melhor armazenados no Azure Cosmos DB.
• As informações de segurança podem ser gravadas no HDFS.
• As informações que exigem pesquisa de texto completo podem ser armazenadas por meio do Elasticsearch (que também pode acelerar pesquisas usando indexação avançada).

Você pode implementar um serviço adicional que recupera periodicamente os dados do armazenamento compartilhado, particiona e filtra os dados de acordo com sua finalidade e, em seguida, grava-os em um conjunto apropriado de armazenamentos de dados, como mostra a Figura 6. Uma abordagem alternativa é incluir esta funcionalidade no processo de consolidação e limpeza, e escrever os dados diretamente nestes arquivos à medida que são obtidos em vez de guardá-los numa área de armazenamento partilhada intermédia. Cada abordagem tem vantagens e desvantagens. A implementação de um serviço de particionamento separado diminui a carga no serviço de consolidação e limpeza e permite que pelo menos alguns dos dados particionados sejam regenerados, se necessário (dependendo da quantidade de dados retidos no armazenamento compartilhado). No entanto, consome recursos adicionais. Além disso, pode haver um atraso entre a receção dos dados de instrumentação de cada instância da aplicação e a conversão dos dados em informações acionáveis.

Figura 6 - Particionamento dos dados de acordo com os requisitos analíticos e de armazenamento.

Podem ser necessários os mesmos dados de instrumentação para mais do que um objetivo. Por exemplo, os contadores de desempenho podem ser usados para fornecer uma visão histórica do desempenho do sistema ao longo do tempo. Estas informações podem ser combinadas com outros dados de utilização para gerar informações de faturação do cliente. Nessas situações, os mesmos dados podem ser enviados para mais de um destino, como um banco de dados de documentos que pode atuar como um armazenamento de longo prazo para armazenar informações de faturamento e um armazenamento multidimensional para lidar com análises de desempenho complexas.

Deve também considerar a urgência com que os dados são necessários. Os dados que fornecem informações para alerta devem ser acessados rapidamente, por isso devem ser mantidos em armazenamento rápido de dados e indexados ou estruturados para otimizar as consultas que o sistema de alerta executa. Em alguns casos, pode ser necessário que o serviço de telemetria que reúne os dados em cada nó formate e salve os dados localmente para que uma instância local do sistema de alerta possa notificá-lo rapidamente sobre quaisquer problemas. Os mesmos dados podem ser distribuídos pelo serviço de escrita de armazenamento mostrado nos diagramas anteriores e armazenados centralmente, caso sejam também necessários para outros fins.

As informações usadas para análises mais ponderadas, relatórios e deteção de tendências históricas são menos urgentes e podem ser armazenadas de forma a suportar mineração de dados e consultas ad hoc. Para obter mais informações, consulte a seção Suporte à análise quente, quente e fria mais adiante neste documento.

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

A instrumentação pode gerar volumes consideráveis de dados. Esses dados podem ser mantidos em vários locais, começando com os arquivos de log brutos, arquivos de rastreamento e outras informações capturadas em cada nó até a exibição consolidada, limpa e particionada desses dados mantidos no armazenamento compartilhado. Em alguns casos, após os dados terem sido processados e transferidos, os dados de origem brutos originais podem ser removidos de cada nó. Em outros casos, pode ser necessário ou simplesmente útil salvar as informações brutas. Por exemplo, os dados gerados para fins de depuração podem ser melhor deixados disponíveis em sua forma bruta, mas podem ser descartados rapidamente depois que quaisquer bugs forem corrigidos.

Os dados de desempenho geralmente têm uma vida útil mais longa para que possam ser usados para detetar tendências de desempenho e para planejamento de capacidade. A vista consolidada destes dados é normalmente mantida online durante um período finito para permitir um acesso rápido. Depois disso, pode ser arquivada ou eliminada. Os dados recolhidos para clientes de medição e faturação podem ter de ser guardados indefinidamente. Além disso, os requisitos normativos podem ditar que as informações coletadas para fins de auditoria e segurança também precisam ser arquivadas e salvas. Estes dados também são sensíveis e poderão ter de ser encriptados ou protegidos de outra forma para evitar adulterações. Nunca deve gravar as palavras-passe dos utilizadores ou outras informações que possam ser utilizadas para cometer fraude de identidade. Esses detalhes devem ser removidos dos dados antes de serem armazenados.

Redução da amostragem

É útil armazenar dados históricos para detetar tendências a longo prazo. Em vez de salvar dados antigos em sua totalidade, talvez seja possível reduzir a amostragem dos 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 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 do processo e deve ser simples de implantar.

• 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, emita informações em um formato autodescritivo, como JSON, MessagePack ou Protobuf em vez de ETL/ETW. O uso de um formato padrão permite que o sistema construa pipelines de processamento; Os componentes que leem, transformam e enviam dados no formato acordado podem ser facilmente integrados.

• O processo de monitorização e recolha de dados deve ser à prova de falhas e não deve desencadear quaisquer condições de erro em cascata.

• No caso de uma falha transitória no envio de informações para um coletor de dados, o agente de monitoramento ou o serviço de coleta de dados deve estar preparado para reordenar os dados de telemetria para que as informações mais recentes sejam enviadas primeiro. (O agente de monitoramento/serviço de coleta de dados pode optar por descartar os dados mais antigos ou salvá-los localmente e transmiti-los mais tarde para recuperar o atraso, a seu critério.)

Análise de dados e diagnóstico de problemas

Uma parte importante do processo de monitorização e diagnóstico é analisar os dados recolhidos para obter uma imagem do bem-estar geral do sistema. Você deve ter definido seus próprios KPIs e métricas de desempenho, e é importante entender como você pode estruturar os dados que foram coletados para atender aos seus requisitos de análise. Também é importante entender como os dados capturados em diferentes métricas e arquivos de log estão correlacionados, porque essas informações podem ser fundamentais para rastrear uma sequência de eventos e ajudar a diagnosticar problemas que surgem.

Conforme descrito na seção Consolidando dados de instrumentação, os dados de cada parte do sistema normalmente são capturados localmente, mas geralmente precisam ser combinados com dados gerados em outros locais que participam do sistema. Essas informações exigem uma correlação cuidadosa para garantir que os dados sejam combinados com precisão. Por exemplo, os dados de uso de uma operação podem abranger um nó que hospeda um site ao qual um usuário se conecta, um nó que executa um serviço separado acessado como parte dessa operação e o armazenamento de dados mantido em outro nó. Essas informações precisam ser vinculadas para fornecer uma visão geral do uso de recursos e processamento para a operação. Alguns pré-processamento e filtragem de dados podem ocorrer no nó no qual os dados são capturados, enquanto a agregação e a formatação são mais prováveis de ocorrer em um nó central.

Suporte a análises quentes, quentes e frias

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 são críticas em termos de tempo e requerem uma análise imediata dos dados para serem eficazes. Isso é conhecido como análise quente. Os exemplos incluem as análises necessárias para alertar e alguns aspetos do monitoramento de segurança (como a deteção de um ataque ao sistema). Os dados necessários para esses fins devem estar rapidamente disponíveis e estruturados para um processamento eficiente. Em alguns casos, pode ser necessário mover o processamento da análise para os nós individuais onde os dados são mantidos.

Outras formas de análise são menos críticas em termos de tempo e podem exigir algum cálculo e agregação após a receção dos dados brutos. Isso é chamado de análise calorosa. A análise de desempenho geralmente se enquadra nessa categoria. Neste caso, é improvável que um evento de desempenho isolado e único seja estatisticamente significativo. (Pode ser causada por um pico ou falha repentina.) Os dados de uma série de eventos devem fornecer uma imagem mais fiável do desempenho do sistema.

A análise calorosa também pode ser usada para ajudar a diagnosticar problemas de saúde. Um evento de integridade normalmente é processado por meio de análise ativa e pode gerar um alerta imediatamente. Um operador deve ser capaz de detalhar as razões para o evento de integridade examinando os dados do caminho quente. Esses dados devem conter informações sobre os eventos que levaram ao problema que causou o evento de integridade.

Alguns tipos de monitorização geram dados a mais longo prazo. Esta análise pode ser realizada posteriormente, possivelmente de acordo com um calendário pré-definido. Em alguns casos, a análise pode precisar executar uma filtragem complexa de grandes volumes de dados capturados durante um período de tempo. Isso é chamado de análise fria. O principal requisito é que os dados sejam armazenados com segurança depois de capturados. Por exemplo, o monitoramento e a auditoria de uso exigem uma imagem precisa do estado do sistema em pontos regulares no tempo, mas essas informações de estado não precisam estar disponíveis para processamento imediatamente após terem sido coletadas.

Um operador também pode usar a análise fria para fornecer os dados para análise preditiva de integridade. O operador pode reunir informações históricas durante um período especificado e usá-las em conjunto com os dados de integridade atuais (recuperados do caminho quente) para identificar tendências que podem causar problemas de saúde em breve. Nestes casos, poderá ser necessário emitir um alerta para que possam ser tomadas medidas corretivas.

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:

• O que causou um carregamento intenso de E/S no nível do sistema em um momento específico?
• É o resultado de um grande número de operações de banco de dados?
• Isso se reflete nos tempos de resposta do banco de dados, no número de transações por segundo e nos tempos de resposta do aplicativo no mesmo momento?

Nesse caso, uma ação corretiva que pode reduzir a carga pode ser fragmentar os dados em mais servidores. Além disso, podem surgir exceções como resultado de uma falha em qualquer nível do sistema. Uma exceção em um nível geralmente desencadeia outra falha no nível acima.

Por esses motivos, você precisa ser capaz de correlacionar os diferentes tipos de dados de monitoramento em cada nível para produzir uma visão geral do estado do sistema e dos aplicativos que estão sendo executados nele. Você pode usar essas informações para tomar decisões sobre se o sistema está funcionando de forma aceitável ou não, e determinar o que pode ser feito para melhorar a qualidade do sistema.

Conforme descrito na seção Informações para correlacionar dados, você deve garantir que os dados brutos de instrumentação incluam informações suficientes de contexto e ID de atividade para dar suporte às agregações necessárias para correlacionar eventos. Além disso, esses dados podem ser mantidos em diferentes formatos, e pode ser necessário analisar essas informações para convertê-las em um formato padronizado para análise.

Resolução de problemas e diagnosticar problemas

O diagnóstico requer a capacidade de determinar a causa de falhas ou comportamento inesperado, incluindo a realização de análise de causa raiz. As informações necessárias normalmente incluem:

• Informações detalhadas de logs de eventos e rastreamentos, para todo o sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Rastreamentos de pilha completos resultantes de exceções e falhas de qualquer nível especificado que ocorrem dentro do sistema ou de um subsistema especificado durante um período especificado.
• Despejos de memória para quaisquer processos com falha em qualquer lugar do sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Logs de atividade registrando as operações que são executadas por todos os usuários ou para usuários selecionados durante um período especificado.

A análise de dados para fins de solução de problemas geralmente requer uma compreensão técnica profunda da arquitetura do sistema e dos vários componentes que compõem a solução. Como resultado, um grande grau de intervenção manual é muitas vezes necessário para interpretar os dados, estabelecer a causa dos problemas e recomendar uma estratégia apropriada para corrigi-los. Pode ser adequado simplesmente armazenar uma cópia destas informações no seu formato original e disponibilizá-las para análise fria por um perito.

Visualizar dados e gerar alertas

Um aspeto importante de qualquer sistema de monitorização é a capacidade de apresentar os dados de tal forma que um operador possa detetar rapidamente quaisquer tendências ou problemas. Também importante é a capacidade de informar rapidamente um operador se tiver ocorrido um evento significativo que possa exigir 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 maneira mais comum de visualizar dados é usar painéis que podem exibir informações como uma série de gráficos, gráficos ou alguma outra ilustração. Esses itens podem ser parametrizados, e um analista deve ser capaz de selecionar os parâmetros importantes (como o período de tempo) para qualquer situação específica.

Os painéis podem ser organizados hierarquicamente. Os painéis de nível superior podem fornecer uma visão geral de cada aspeto do sistema, mas permitem que um operador analise detalhadamente os detalhes. Por exemplo, um painel que retrate a E/S geral do disco para o sistema deve permitir que um analista visualize as taxas de E/S de cada disco individual para verificar se um ou mais dispositivos específicos representam um volume desproporcional de tráfego. Idealmente, o painel também deve exibir informações relacionadas, como a origem de cada solicitação (o usuário ou a atividade) que está gerando essa E/S. Essas informações podem ser usadas para determinar se (e como) distribuir a carga de forma mais uniforme entre dispositivos e se o sistema teria um desempenho melhor se mais dispositivos fossem adicionados.

Um painel também pode usar codificação de cores ou algumas outras pistas visuais para indicar valores que parecem anômalos ou que estão fora de um intervalo esperado. Usando o exemplo anterior:

• Um disco com uma taxa de E/S que esteja se aproximando de sua capacidade máxima durante um período prolongado (um disco quente) pode ser destacado em vermelho.
• Um disco com uma taxa de E/S que é executado periodicamente no seu limite máximo durante curtos períodos (um disco quente) pode ser realçado a amarelo.
• Um disco que esteja exibindo uso normal pode ser exibido em verde.

Observe que, para que um sistema de painel funcione de forma eficaz, ele deve ter os dados brutos com os quais trabalhar. Se você estiver criando seu próprio sistema de painel ou usando 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 eles devem ser formatados para o painel consumir.

Um bom painel não apenas exibe informações, mas também permite que um analista faça perguntas ad hoc sobre essas informações. Alguns sistemas fornecem ferramentas de gerenciamento que um operador pode usar para executar essas tarefas e explorar os dados subjacentes. Como alternativa, dependendo do repositório usado para armazenar essas informações, talvez seja possível consultar esses dados diretamente ou importá-los para ferramentas como o Microsoft Excel para análise e emissão de relatórios adicionais.

Observação

Você deve restringir o acesso aos painéis ao pessoal autorizado, pois essas informações podem ser comercialmente sensíveis. Você também deve proteger os dados subjacentes dos painéis para impedir que os usuários os alterem.

Emissão de alertas

O alerta é o processo de analisar os dados de monitoramento e instrumentação e gerar uma notificação se um evento significativo for detetado.

Os alertas ajudam a garantir que o sistema permaneça íntegro, responsivo e seguro. É uma parte importante de qualquer sistema que garante desempenho, disponibilidade e privacidade aos usuários onde os dados podem precisar ser acionados imediatamente. Um operador pode precisar ser notificado do evento que disparou o alerta. Os alertas também podem ser usados para invocar funções do sistema, como o dimensionamento automático.

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

• Eventos de segurança. Se os logs de eventos indicarem que estão ocorrendo repetidas falhas de autenticação ou autorização, o sistema pode estar sob ataque e um operador deve ser informado.
• Métricas de desempenho. O sistema deve responder rapidamente se uma determinada métrica de desempenho exceder um limite especificado.
• Informações sobre disponibilidade. Se uma falha for detetada, pode ser necessário reiniciar rapidamente um ou mais subsistemas ou fazer failover para um recurso de backup. Falhas repetidas em um subsistema podem indicar preocupações mais sérias.

Os operadores podem receber informações de alerta usando muitos canais de entrega, como e-mail, um dispositivo pager ou uma 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 suportam grupos de assinantes, e todos os operadores que são membros do mesmo grupo podem receber o mesmo conjunto de alertas.

Um sistema de alerta deve ser personalizável e os valores apropriados dos dados de instrumentação subjacentes podem ser fornecidos como parâmetros. Essa abordagem permite que um operador filtre dados e se concentre nesses limites ou combinações de valores que são de interesse. Observe que, em alguns casos, os dados brutos da instrumentação podem ser fornecidos ao sistema de alerta. Noutras situações, poderá ser mais adequado fornecer dados agregados. (Por exemplo, um alerta pode ser acionado se a utilização da CPU de um nó tiver excedido 90% nos últimos 10 minutos). Os pormenores fornecidos ao sistema de alerta devem também incluir qualquer resumo adequado e informações contextuais. Esses dados podem ajudar a reduzir a possibilidade de que eventos falso-positivos disparem um alerta.

Elaboração de Relatórios

Os relatórios são utilizados para gerar uma visão global do sistema. Pode incorporar dados históricos para além das informações atuais. Os próprios requisitos de comunicação de informações dividem-se em duas grandes categorias: relatórios operacionais e relatórios de segurança.

Os relatórios operacionais normalmente incluem os seguintes aspetos:

• Estatísticas agregadas que podem ser utilizadas para compreender a utilização de recursos do sistema global ou de subsistemas especificados durante uma janela de tempo especificada.
• Identificação de tendências na utilização de recursos para o sistema global ou subsistemas especificados durante um período específico.
• Monitorar as exceções que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
• Determinar a eficiência do aplicativo em termos de recursos implantados e entender se o volume de recursos (e seu custo associado) pode ser reduzido sem afetar o desempenho desnecessariamente.

Os relatórios de segurança dizem respeito ao rastreamento do uso do sistema pelos clientes. Podem incluir:

• Auditoria de operações de usuários. Isso requer o registro das solicitações individuais que cada usuário executa, juntamente com datas e horas. Os dados devem ser estruturados para permitir que um administrador reconstrua rapidamente a sequência de operações que um usuário executa durante um período especificado.
• Rastreando o uso de recursos pelo usuário. Isso requer o registro de como cada solicitação para um usuário acessa os vários recursos que compõem o sistema e por quanto tempo. Um administrador deve ser capaz de usar esses dados para gerar um relatório de utilização por usuário durante um período especificado, possivelmente para fins de cobrança.

Em muitos casos, os processos em lote podem gerar relatórios de acordo com uma agenda definida. (A latência normalmente não é um problema.) Mas também devem estar disponíveis para geração numa base ad hoc, se necessário. Por exemplo, se você estiver armazenando dados em um banco de dados relacional, como o Banco de Dados SQL do Azure, poderá usar uma ferramenta como o SQL Server Reporting Services para extrair e formatar dados e apresentá-los como um conjunto de relatórios.

Próximos passos

• Descrição geral do Azure Monitor
• Monitorizar, diagnosticar e resolver problemas do Armazenamento do Microsoft Azure
• Descrição geral dos alertas no Microsoft Azure
• Ver notificações do estado de funcionamento do serviço ao utilizar o portal do Azure
• O que é o Application Insights?
• Diagnóstico de desempenho para máquinas virtuais do Azure
• Baixar e instalar o SSDT (SQL Server Data Tools) para Visual Studio

Recursos relacionados

• As diretrizes de dimensionamento automático descrevem como diminuir a sobrecarga de gerenciamento reduzindo a necessidade de um operador monitorar continuamente o desempenho de um sistema e tomar decisões sobre a adição ou remoção de 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 fila de prioridade mostra como priorizar mensagens em fila para que solicitações urgentes sejam recebidas e possam ser processadas antes de mensagens menos urgentes.

As aplicações e serviços distribuídos executados na nuvem são, pela sua natureza, peças complexas de software que compreendem muitas partes móveis. Em um ambiente de produção, é importante ser capaz de rastrear a maneira como os usuários usam seu sistema, rastrear a utilização de recursos e, geralmente, monitorar a integridade e o desempenho do sistema. Pode utilizar estas informações como uma ajuda de diagnóstico para detetar e corrigir problemas, bem como ajudar a detetar potenciais problemas e evitá-los.

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

Você pode usar o monitoramento para obter uma visão de como um sistema está funcionando. A monitorização é uma parte crucial da manutenção dos objetivos de qualidade do serviço. Os cenários comuns para a recolha de dados de monitorização incluem:

• Garantir que o sistema permanece saudável.
• Acompanhamento da disponibilidade do sistema e seus elementos componentes.
• Manter o desempenho para garantir que a taxa de transferência do sistema não se degrade inesperadamente à medida que o volume de trabalho aumenta.
• Garantir que o sistema atenda a quaisquer acordos de nível de serviço (SLAs) estabelecidos com os clientes.
• Proteger a privacidade e a segurança do sistema, dos utilizadores e dos seus dados.
• Acompanhamento das operações realizadas para fins de auditoria ou regulamentação.
• Monitorar o uso diário do sistema e detetar tendências que podem levar a problemas se não forem abordadas.
• Rastreando problemas que ocorrem, desde o relatório inicial até a análise de possíveis causas, retificação, consequentes atualizações de software e implantação.
• Operações de rastreamento e depuração de versões de software.

Observação

Esta lista não pretende ser exaustiva. Este documento se concentra nesses cenários como as situações mais comuns para realizar monitoramento. Pode haver outros que são menos comuns ou são específicos para o seu ambiente.

As seções a seguir descrevem esses cenários com mais detalhes. As informações para cada cenário são discutidas no seguinte formato:

1. Uma breve visão geral do cenário.
2. Os requisitos típicos deste cenário.
3. Os dados brutos de instrumentação necessários para dar suporte ao cenário e possíveis fontes dessas informações.
4. Como esses dados brutos podem ser analisados e combinados para gerar informações de diagnóstico significativas.

Monitorização de saúde

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

Requisitos para a monitorização da saúde

Um operador deve ser alertado rapidamente (em questão de segundos) se qualquer parte do sistema for considerada não íntegra. O operador deve poder verificar quais as partes do sistema que estão a funcionar normalmente e quais as que estão a ter problemas. A integridade do sistema pode ser destacada através de um sistema de semáforos:

• Vermelho para insalubridade (o sistema parou)
• Amarelo para parcialmente saudável (o sistema está funcionando com funcionalidade reduzida)
• Verde para completamente saudável

Um sistema abrangente de monitoramento de integridade permite que um operador analise detalhadamente o sistema para visualizar o status de integridade de subsistemas e componentes. Por exemplo, se o sistema geral for descrito como parcialmente íntegro, o operador deve ser capaz de ampliar e determinar qual funcionalidade está indisponível no momento.

Fontes de dados, instrumentação e requisitos de coleta de dados

Os dados brutos necessários para dar suporte ao monitoramento de integridade podem ser gerados como resultado de:

• Rastreando a execução das solicitações do usuário. Essas informações podem ser usadas para determinar quais solicitações foram bem-sucedidas, quais falharam e quanto tempo cada solicitação leva.
• Monitoramento sintético do usuário. Este processo simula as etapas executadas por um usuário e segue uma série predefinida de etapas. Os resultados de cada etapa devem ser capturados.
• Registro de exceções, falhas e avisos. Essas informações podem ser capturadas como resultado de instruções de rastreamento incorporadas no código do aplicativo, bem como recuperar informações dos logs de eventos de quaisquer serviços que o sistema referencia.
• Monitorizar o estado de funcionamento de quaisquer serviços de terceiros que o sistema utilize. Esse monitoramento pode exigir a recuperação e a análise de dados de integridade fornecidos por esses serviços. Essas informações podem ter vários formatos.
• Monitorização de pontos finais. Esse mecanismo é descrito com mais detalhes na seção "Monitoramento de disponibilidade".
• Coleta de informações de desempenho ambiente, como utilização da CPU em segundo plano ou atividade de E/S (incluindo rede).

Analisando dados de saúde

O foco principal do monitoramento de integridade é indicar rapidamente se o sistema está em execução. A análise a quente dos dados imediatos pode disparar um alerta se um componente crítico for detetado como não íntegro. (Ele não responde a uma série consecutiva de pings, por exemplo.) O operador pode então tomar as medidas corretivas adequadas.

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 fria pode identificar tendências e determinar se é provável que o sistema permaneça íntegro ou se precisará de recursos adicionais. Este elemento preditivo deve basear-se em métricas críticas de desempenho, tais como:

• A taxa de solicitações direcionadas a cada serviço ou subsistema.
• Os tempos de resposta destes pedidos.
• O volume de dados que entram e saem de cada serviço.

Se o valor de qualquer métrica exceder um limite definido, o sistema pode emitir um alerta para permitir que um operador ou dimensionamento automático (se disponível) tome as ações preventivas necessárias para manter a integridade do sistema. Essas ações podem envolver a adição de recursos, a reinicialização de um ou mais serviços que estão falhando ou a aplicação de limitação a solicitações de prioridade mais baixa.

Monitoramento de disponibilidade

Um sistema verdadeiramente saudável requer que os componentes e subsistemas que compõem o sistema estejam disponíveis. O monitoramento de disponibilidade está intimamente relacionado ao monitoramento de integridade. Mas enquanto o monitoramento de integridade fornece uma visão imediata da integridade atual do sistema, o monitoramento de disponibilidade está preocupado em rastrear a disponibilidade do sistema e seus componentes para gerar estatísticas sobre o tempo de atividade do sistema.

Em muitos sistemas, alguns componentes (como um banco de dados) são configurados com redundância interna para permitir um failover rápido no caso de uma falha grave ou perda de conectividade. Idealmente, os usuários não devem estar cientes de que tal falha ocorreu. Mas, do ponto de vista do monitoramento de disponibilidade, é necessário reunir o máximo de informações possível sobre essas falhas para determinar a causa e tomar ações corretivas para evitar que elas se repitam.

Os dados necessários para controlar a disponibilidade podem depender de vários fatores de nível inferior. Muitos desses fatores podem ser específicos do aplicativo, do sistema e do ambiente. Um sistema de monitorização eficaz capta os dados de disponibilidade que correspondem a estes fatores de baixo nível e, em seguida, agrega-os para dar uma imagem global do sistema. Por exemplo, em um sistema de comércio eletrônico, a funcionalidade comercial que permite que um cliente faça pedidos pode depender do repositório onde os detalhes do pedido são armazenados e do sistema de pagamento que lida com as transações monetárias para pagar por esses pedidos. A disponibilidade da parte do sistema relativa à colocação de ordens depende, por conseguinte, da disponibilidade do repositório e do subsistema de pagamento.

Requisitos para monitoramento de disponibilidade

O operador deverá também poder visualizar a disponibilidade histórica de cada sistema e subsistema e utilizar essas informações para detetar quaisquer tendências suscetíveis de provocar falhas periódicas de um ou mais subsistemas. (Os serviços começam a falhar em um determinado horário do dia que corresponde às horas de pico de processamento?)

Uma solução de monitorização deve fornecer uma visão imediata e histórica da disponibilidade ou indisponibilidade de cada subsistema. Também deve ser capaz de alertar rapidamente um operador quando um ou mais serviços falham ou quando os utilizadores não conseguem ligar-se aos serviços. Esta é uma questão não só de monitorar cada serviço, mas também examinar as ações que cada usuário executa se essas ações falharem quando eles tentam se comunicar com um serviço. Até certo ponto, um grau de falha de conectividade é normal e pode ser devido a erros transitórios. Mas pode ser útil permitir que o sistema emita um alerta para o número de falhas de conectividade com um subsistema especificado que ocorrem durante um período específico.

Fontes de dados, instrumentação e requisitos de coleta de dados

Assim como no monitoramento de integridade, os dados brutos necessários para dar suporte ao monitoramento de disponibilidade podem ser gerados como resultado do monitoramento sintético do usuário e do registro de quaisquer exceções, falhas e avisos que possam ocorrer. Além disso, os dados de disponibilidade podem ser obtidos a partir da execução do monitoramento de endpoint. O aplicativo pode expor um ou mais pontos de extremidade de integridade, cada um testando o acesso a uma área funcional dentro do sistema. O sistema de monitoramento pode executar ping em cada ponto final seguindo um cronograma definido e coletar os resultados (sucesso ou falha).

Todos os tempos limites, falhas de conectividade de rede e tentativas de repetição de conexão devem ser registrados. Todos os dados devem ter carimbo de data/hora.

Analisando dados de disponibilidade

Os dados de instrumentação devem ser agregados e correlacionados 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. Idealmente, um operador deve ser capaz de correlacionar falhas com atividades específicas: o que estava acontecendo quando o sistema falhou?
• Uma visão histórica das taxas de falha do sistema ou de quaisquer subsistemas em qualquer período especificado e a carga no sistema (número de solicitações do usuário, por exemplo) quando ocorreu uma falha.
• As razões para a indisponibilidade do sistema ou de quaisquer subsistemas. Por exemplo, os motivos podem ser serviço não em execução, conectividade perdida, conectado mas com tempo limite limite e conectado mas retornando erros.

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

Isso é útil para fins de SLA. (O monitoramento de SLA é descrito mais detalhadamente mais adiante nesta orientação.) A definição de tempo de inatividade depende do serviço. Por exemplo, o Visual Studio Team Services Build Service define o tempo de inatividade como o período (total de minutos acumulados) durante o qual o Serviço de Criação não está disponível. Um minuto é considerado indisponível se todas as solicitações HTTP contínuas ao Serviço de Criação para executar operações iniciadas pelo cliente ao longo do minuto resultarem em um código de erro ou não retornarem uma resposta.

Monitorização do desempenho

À medida que o sistema é colocado sob cada vez mais estresse (aumentando o volume de usuários), o tamanho dos conjuntos de dados que esses usuários acessam cresce e a possibilidade de falha de um ou mais componentes torna-se mais provável. Frequentemente, a falha do componente é precedida por uma diminuição no desempenho. Se você for capaz de detetar essa diminuição, poderá tomar medidas proativas para remediar a situação.

O desempenho do sistema depende de uma série de fatores. Cada fator é normalmente medido por meio de indicadores-chave de desempenho (KPIs), 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 podem ser derivados de uma combinação de métricas.

Observação

Determinar um desempenho ruim ou bom requer que você entenda o nível de desempenho no qual o sistema deve ser capaz de funcionar. Isso requer observar o sistema enquanto ele está funcionando sob uma carga típica e capturar os dados para cada KPI durante um período de tempo. Isso pode envolver a execução do sistema sob uma carga simulada em um ambiente de teste e a coleta dos dados apropriados antes de implantar o sistema em um ambiente de produção.

Deve também assegurar que a monitorização para efeitos de desempenho não se torne um fardo para o sistema. Talvez seja possível ajustar dinamicamente o nível de detalhes dos dados que o processo de monitoramento de desempenho coleta.

Requisitos para a monitorização do desempenho

Para examinar o desempenho do sistema, um operador normalmente precisa ver informações que incluem:

• As taxas de resposta para solicitações de usuários.
• O número de solicitações de usuários simultâneos.
• O volume de tráfego de rede.
• As taxas às quais as transações comerciais estão sendo concluídas.
• O tempo médio de processamento dos pedidos.

Também pode ser útil fornecer ferramentas que permitam a um operador ajudar a identificar correlações, tais como:

• O número de usuários simultâneos versus tempos de latência de solicitação (quanto tempo leva para começar a processar uma solicitação depois que o usuário a enviou).
• O número de usuários simultâneos versus o tempo médio de resposta (quanto tempo leva para concluir uma solicitação depois que ela começou a ser processada).
• O volume de solicitações versus o número de erros de processamento.

Juntamente com essas informações funcionais de alto nível, um operador deve ser capaz de obter uma visão detalhada do desempenho de cada componente do sistema. Esses dados geralmente são fornecidos por meio de contadores de desempenho de baixo nível que rastreiam informações como:

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

Todas as visualizações devem permitir que um operador especifique 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 operador deverá poder emitir um alerta com base em qualquer medida de desempenho para qualquer valor especificado durante qualquer intervalo de tempo especificado.

Fontes de dados, instrumentação e requisitos de coleta de dados

Você pode coletar dados de desempenho de alto nível (taxa de transferência, número de usuários simultâneos, número de transações comerciais, taxas de erro e assim por diante) monitorando o progresso das solicitações dos usuários à medida que chegam e passam pelo sistema. Isso envolve a incorporação de instruções de rastreamento em pontos-chave no código do aplicativo, juntamente com informações de tempo. Todas as falhas, exceções e avisos devem ser capturados com dados suficientes para correlacioná-los com as solicitações que os causaram. O log do IIS (Serviços de Informações da Internet) é outra fonte útil.

Se possível, você também deve capturar dados de desempenho para quaisquer 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 isso não for possível, registre informações como a hora de início e a hora de término de cada solicitação feita a um sistema externo, juntamente com o status (sucesso, falha ou aviso) da operação. Por exemplo, você pode usar uma abordagem de cronômetro para solicitações de tempo: inicie um temporizador quando a solicitação for iniciada e, em seguida, pare o temporizador quando a solicitação terminar.

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 do Windows e Diagnóstico do Azure.

Analisando dados de desempenho

Grande parte do trabalho de análise consiste em agregar dados de desempenho por tipo de solicitação do usuário ou pelo subsistema ou serviço para o qual cada solicitação é enviada. Um exemplo de uma solicitação do usuário é adicionar um item a um carrinho de compras ou realizar o processo de checkout em um sistema de comércio eletrônico.

Outro requisito comum é resumir os dados de desempenho em percentis selecionados. Por exemplo, um operador pode determinar os tempos de resposta para 99% das solicitações, 95% das solicitações e 70% das solicitações. Pode haver metas de SLA ou outras metas definidas para cada percentil. Os resultados em curso devem ser comunicados quase em tempo real para ajudar a detetar problemas imediatos. Os resultados devem também ser agregados ao longo de mais tempo para fins estatísticos.

No caso de problemas de latência que afetem o desempenho, um operador deve ser capaz de identificar rapidamente a causa do gargalo, examinando a latência de cada etapa executada por cada solicitação. Os dados de desempenho devem, portanto, fornecer um meio de correlacionar as medidas de desempenho para cada etapa, a fim de vinculá-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 e análises ad hoc complexas das informações de desempenho.

Monitorização de segurança

Todos os sistemas comerciais que incluam dados sensíveis devem implementar uma estrutura de segurança. A complexidade do mecanismo de segurança é geralmente uma função da sensibilidade dos dados. Em um sistema que exija que os usuários sejam autenticados, você deve registrar:

• Todas as tentativas de início de sessão, independentemente de falharem ou serem bem-sucedidas.
• Todas as operações realizadas por um usuário autenticado e os detalhes de todos os recursos acessados.
• Quando um usuário termina uma sessão e termina sessão.

O monitoramento pode ajudar a detetar ataques ao sistema. Por exemplo, um grande número de tentativas de entrada com falha pode indicar um ataque de força bruta. Um aumento inesperado nas solicitações pode ser o resultado de um ataque distribuído de negação de serviço (DDoS). Você deve estar preparado para monitorar todas as solicitações para todos os recursos, independentemente da origem dessas solicitações. Um sistema que tenha uma vulnerabilidade de início de sessão pode expor acidentalmente recursos ao mundo exterior sem exigir que um utilizador inicie sessão.

Requisitos para o controlo de segurança

Os aspetos mais críticos do controlo de segurança devem permitir ao operador acelerar a:

• Detetar tentativas de intrusão por uma entidade não autenticada.
• Identificar tentativas de entidades de realizar operações em dados para os quais não lhes foi concedido acesso.
• Determine se o sistema, ou alguma parte do sistema, está sob ataque externo ou interno. (Por exemplo, um usuário autenticado mal-intencionado pode estar tentando derrubar o sistema.)

Para satisfazer estes requisitos, o operador deve ser notificado 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.

As informações fornecidas a um operador devem incluir o endereço de host da fonte para cada solicitação. Se as violações de segurança surgirem regularmente de um determinado intervalo de endereços, esses anfitriões podem ser bloqueados.

Uma parte fundamental na manutenção da segurança de um sistema é ser capaz de detetar rapidamente ações que se desviam do padrão usual. Informações como o número de solicitações de entrada com falha ou bem-sucedidas podem ser exibidas visualmente para ajudar a detetar se há um pico de atividade em um momento incomum. (Um exemplo dessa atividade são os usuários que entram às 3:00 da manhã e realizam um grande número de operações quando seu dia de trabalho começa às 9:00 da manhã). Essas informações também podem ser usadas para ajudar a configurar o dimensionamento automático baseado em tempo. Por exemplo, se um operador observar que um grande número de utilizadores inicia sessão regularmente a uma determinada hora do dia, pode organizar o início de serviços de autenticação adicionais para lidar com o volume de trabalho e, em seguida, encerrar esses serviços adicionais quando o pico tiver passado.

Fontes de dados, instrumentação e requisitos de coleta de dados

A segurança é um aspeto abrangente da maioria dos sistemas distribuídos. É provável que os dados pertinentes sejam gerados em vários pontos de um sistema. Você deve considerar a adoção de uma abordagem de Gerenciamento de Informações e Eventos de Segurança (SIEM) para coletar as informações relacionadas à segurança resultantes de eventos gerados pelo aplicativo, equipamento de rede, servidores, firewalls, software antivírus e outros elementos de prevenção de invasões.

O monitoramento de segurança pode incorporar dados de ferramentas que não fazem parte do seu aplicativo. Essas ferramentas podem incluir utilitários que identificam atividades de varredura de portas por agências externas ou filtros de rede que detetam tentativas de obter acesso não autenticado ao seu aplicativo e dados.

Em todos os casos, os dados recolhidos devem permitir que um administrador determine a natureza de qualquer ataque e tome as contramedidas adequadas.

Análise de dados de segurança

Uma característica do monitoramento de segurança é a variedade de fontes das quais os dados surgem. Os diferentes formatos e nível de detalhe geralmente exigem uma análise complexa dos dados capturados para uni-los em um fio coerente de informações. Além dos casos mais simples (como a deteção de um grande número de entradas com falha ou tentativas repetidas de obter acesso não autorizado a recursos críticos), pode não ser possível executar qualquer processamento automatizado complexo de dados de segurança. Em vez disso, pode ser preferível gravar esses dados, com carimbo de data/hora, mas em sua forma original, em um repositório seguro para permitir a análise manual de especialistas.

Monitoramento de SLA

Muitos sistemas comerciais que suportam clientes pagantes fazem garantias sobre o desempenho do sistema na forma de SLAs. Essencialmente, os SLAs afirmam que o sistema pode lidar com um volume definido de trabalho dentro de um período de tempo acordado e sem perder informações críticas. O monitoramento de SLA está preocupado em garantir que o sistema possa atender a SLAs mensuráveis.

Observação

O monitoramento do SLA está intimamente relacionado ao monitoramento de desempenho. Mas enquanto o monitoramento de desempenho se preocupa em garantir que o sistema funcione de forma otimizada, o monitoramento de SLA é regido por uma obrigação contratual que define o que realmente significa otimamente .

Os SLAs são frequentemente definidos em termos de:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode garantir que o sistema estará disponível por 99,9% do tempo. Isso equivale a não mais do que 9 horas de inatividade por ano, ou aproximadamente 10 minutos por semana.
• Rendimento operacional. Esse aspeto é frequentemente expresso como uma ou mais marcas de água altas, como a garantia de que o sistema possa suportar até 100.000 solicitações de usuários simultâneas ou lidar com 10.000 transações comerciais simultâneas.
• Tempo de resposta operacional. O sistema pode também dar garantias quanto ao ritmo a que os pedidos são processados. Um exemplo é que 99% de todas as transações comerciais serão concluídas em 2 segundos, e nenhuma transação levará mais de 10 segundos.

Observação

Alguns contratos para sistemas comerciais também podem incluir SLAs para suporte ao cliente. Um exemplo é que todas as solicitações de help-desk obterão uma resposta em cinco minutos e que 99% de todos os problemas serão totalmente resolvidos dentro de 1 dia útil. O rastreamento eficaz de problemas (descrito mais adiante nesta seção) é fundamental para cumprir SLAs como estes.

Requisitos para monitoramento de SLA

Ao mais alto nível, um operador deve ser capaz de determinar rapidamente se o sistema está a cumprir os SLAs acordados ou não. E, caso contrário, o operador deve ser capaz de detalhar e examinar os fatores subjacentes para determinar as razões para um desempenho abaixo do padrão.

Os indicadores típicos de alto nível que podem ser representados visualmente incluem:

• A porcentagem de tempo de atividade do serviço.
• A taxa de transferência do aplicativo (medida em termos de transações bem-sucedidas ou operações por segundo).
• O número de pedidos de candidatura bem-sucedidos/reprovados.
• O número de falhas, exceções e avisos do aplicativo e do sistema.

Todos estes indicadores devem poder ser filtrados por um período de tempo especificado.

Um aplicativo em nuvem provavelmente compreenderá vários subsistemas e componentes. Um operador deve ser capaz de selecionar um indicador de alto nível e ver como ele é composto a partir da integridade dos elementos subjacentes. Por exemplo, se o tempo de atividade do sistema geral cair abaixo de um valor aceitável, um operador deve ser capaz de aumentar o zoom e determinar quais elementos estão contribuindo para essa falha.

Observação

O tempo de atividade do sistema precisa ser definido com cuidado. Em um sistema que usa redundância para garantir a disponibilidade máxima, instâncias individuais de elementos podem falhar, mas o sistema pode permanecer funcional. O tempo de atividade do sistema, conforme apresentado pelo monitoramento de integridade, deve indicar o tempo de atividade agregado de cada elemento e não necessariamente se o sistema realmente parou. Além disso, as falhas podem ser isoladas. Assim, mesmo que um sistema específico não esteja disponível, o restante do sistema pode permanecer disponível, embora com funcionalidade reduzida. (Em um sistema de comércio eletrônico, uma falha no sistema pode impedir que um cliente faça pedidos, mas o cliente ainda pode navegar no catálogo de produtos.)

Para efeitos de alerta, o sistema deve ser capaz de gerar um evento se algum dos indicadores de alto nível exceder um limiar especificado. Os detalhes de nível inferior dos vários fatores que compõem o indicador de alto nível devem estar disponíveis como dados contextuais para o sistema de alerta.

Fontes de dados, instrumentação e requisitos de coleta de dados

Os dados brutos necessários para dar suporte ao monitoramento de SLA são semelhantes aos dados brutos necessários para o monitoramento de desempenho, juntamente com alguns aspetos do monitoramento de integridade e disponibilidade. (Consulte essas seções para obter mais detalhes.) Você pode capturar esses dados da seguinte forma:

• Execução de monitoramento de endpoint.
• Registro de exceções, falhas e avisos.
• Rastreando a execução de solicitações do usuário.
• Monitorizar a disponibilidade de quaisquer serviços de terceiros que o sistema utilize.
• Usando métricas de desempenho e contadores.

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

Analisando dados de SLA

Os dados de instrumentação devem ser agregados para gerar uma imagem do desempenho geral do sistema. Os dados agregados também devem suportar a análise detalhada para permitir o exame do desempenho dos subsistemas subjacentes. Por exemplo, deve ser capaz de:

• 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 das solicitações do usuário para dividir o tempo de resposta geral de uma solicitação nos tempos de resposta dos itens de trabalho individuais nessa solicitação.
• Determine a disponibilidade geral do sistema como uma porcentagem do tempo de atividade para qualquer período específico.
• Analisar a disponibilidade de tempo percentual dos componentes e serviços individuais no sistema. Isso pode envolver a análise de logs gerados por serviços de terceiros.

Muitos sistemas comerciais são obrigados a relatar números reais de desempenho em relação aos SLAs acordados por um período especificado, normalmente um mês. Essas informações podem ser usadas para calcular créditos ou outras formas de reembolso para clientes se os SLAs não forem cumpridos durante esse período. Você pode calcular a disponibilidade de um serviço usando a técnica descrita na seção Analisando dados de disponibilidade.

Para fins internos, uma organização também pode rastrear o número e a natureza dos incidentes que causaram falhas nos serviços. Aprender a resolver esses problemas rapidamente, ou eliminá-los completamente, ajudará a reduzir o tempo de inatividade e cumprir os SLAs.

Auditoria

Dependendo da natureza do aplicativo, pode haver regulamentos legais ou outros que especifiquem requisitos para auditar as operações dos usuários e registrar todo o acesso aos dados. A auditoria pode fornecer evidências que vinculam os clientes a solicitações específicas. O não repúdio é um fator importante em muitos sistemas de e-business para ajudar a manter a confiança entre um cliente e a organização responsável pelo aplicativo ou serviço.

Requisitos para auditoria

Um analista deve ser capaz de rastrear a sequência de operações de negócios que os usuários estão executando para que você possa reconstruir as ações dos usuários. Isso pode ser necessário simplesmente como uma questão de registro ou como parte de uma investigação forense.

As informações de auditoria são altamente sensíveis. Ele provavelmente incluirá dados que identificam os usuários do sistema, juntamente com as tarefas que eles estão executando. Por esse motivo, as informações de auditoria provavelmente assumirão a forma de relatórios que estão disponíveis apenas para analistas confiáveis, em vez de como um sistema interativo que suporta detalhamento de operações gráficas. Um analista deve ser capaz de gerar uma gama de relatórios. Por exemplo, os relatórios podem listar todas as atividades dos usuários que ocorrem durante um período de tempo especificado, detalhar a cronologia da atividade de um único usuário ou listar a sequência de operações executadas em relação a um ou mais recursos.

Fontes de dados, instrumentação e requisitos de coleta de dados

As principais fontes de informação para auditoria podem incluir:

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

O formato dos dados de auditoria e a forma como são armazenados podem ser determinados por requisitos regulamentares. Por exemplo, pode não ser possível limpar os dados de forma alguma. (Deve ser gravado no seu formato original.) O acesso ao repositório onde é mantido deve ser protegido para evitar adulterações.

Análise de dados de auditoria

Um analista deve ser capaz de acessar os dados brutos em sua totalidade, em sua forma original. Além da exigência de gerar relatórios de auditoria comuns, as ferramentas para analisar esses dados provavelmente serão especializadas e mantidas externas ao sistema.

Monitorização da utilização

O monitoramento de uso rastreia como os recursos e componentes de um aplicativo são usados. Um operador pode utilizar os dados recolhidos para:

• Determine quais recursos são muito usados e determine possíveis pontos de acesso no sistema. Elementos de alto tráfego podem se beneficiar do particionamento funcional ou até mesmo da replicação para distribuir a carga de forma mais uniforme. Um operador também pode usar essas informações para verificar 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.

• Obter informações sobre os eventos operacionais do sistema em uso normal. Por exemplo, em um site de comércio eletrônico, você pode registrar as informações estatísticas sobre o número de transações e o volume de clientes que são responsáveis por elas. Essas informações podem ser usadas para o planejamento de capacidade à medida que o número de clientes cresce.

• Detetar (possivelmente indiretamente) a satisfação do usuário com o desempenho ou funcionalidade do sistema. Por exemplo, se um grande número de clientes em um sistema de comércio eletrônico abandona regularmente seus carrinhos de compras, isso pode ser devido a um problema com a funcionalidade de checkout.

• 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 usuário em um sistema multilocatário exceder sua cota paga de tempo de processamento ou uso de recursos durante um período especificado, seu acesso poderá ser limitado ou o processamento poderá ser limitado.

Requisitos para monitoramento de uso

Para examinar o uso do sistema, um operador normalmente precisa ver informações que incluem:

• O número de solicitações que são processadas por cada subsistema e direcionadas para cada recurso.
• O trabalho que cada usuário está executando.
• O volume de armazenamento de dados que cada usuário ocupa.
• Os recursos que cada usuário está acessando.

Um operador também deve ser capaz de gerar gráficos. Por exemplo, um gráfico pode exibir os usuários que consomem mais recursos ou os recursos ou recursos do sistema acessados com mais frequência.

Fontes de dados, instrumentação e requisitos de coleta de dados

O rastreamento de uso pode ser realizado em um nível relativamente alto. Ele pode anotar os horários de início e término de cada solicitação e a natureza da solicitação (leitura, gravação e assim por diante, dependendo do recurso em questão). Pode obter estas informações da seguinte forma:

• Rastreando a atividade do usuário.
• Captura de contadores de desempenho que medem a utilização de cada recurso.
• Monitorização do consumo de recursos por cada utilizador.

Para fins de medição, você também precisa ser capaz de identificar quais usuários são responsáveis por executar quais operações e os recursos que essas operações usam. As informações recolhidas devem ser suficientemente detalhadas para permitir uma faturação precisa.

Acompanhamento de problemas

Clientes e outros usuários podem relatar problemas se ocorrerem eventos ou comportamentos inesperados no sistema. O rastreamento de problemas está preocupado em gerenciar esses problemas, associá-los aos esforços para resolver quaisquer problemas subjacentes no sistema e informar os clientes sobre possíveis resoluções.

Requisitos para o acompanhamento de problemas

Os operadores geralmente realizam o rastreamento de problemas usando um sistema separado que lhes permite registrar e relatar os detalhes dos problemas relatados pelos usuários. Esses detalhes podem incluir as tarefas que o usuário estava tentando executar, os sintomas do problema, a sequência de eventos e quaisquer mensagens de erro ou aviso que foram emitidas.

Fontes de dados, instrumentação e requisitos de coleta de dados

A fonte de dados inicial para dados de rastreamento de problemas é o usuário que relatou o problema em primeiro lugar. O utilizador poderá fornecer dados adicionais, tais como:

• Um despejo de memória (se o aplicativo incluir um componente executado na área de trabalho do usuário).
• Um instantâneo da tela.
• A data e a hora em que o erro ocorreu, juntamente com quaisquer outras informações ambientais, como a localização do utilizador.

Essas informações podem ser usadas para ajudar no esforço de depuração e ajudar a construir uma lista de pendências para versões futuras do software.

Analisando dados de rastreamento de problemas

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

O progresso do esforço de depuração deve ser registrado em relação a cada relatório de problema. Quando o problema é resolvido, o cliente pode ser informado da solução.

Se um utilizador comunicar um problema que tenha uma solução conhecida no sistema de rastreio de problemas, o operador deve poder informar imediatamente o utilizador da solução.

Operações de rastreamento e depuração de versões de software

Quando um usuário relata um problema, muitas vezes ele só está ciente do efeito imediato que ele tem em suas operações. O utilizador só pode comunicar os resultados da sua própria experiência a um operador responsável pela manutenção do sistema. Estas experiências são geralmente apenas um sintoma visível de um ou mais problemas fundamentais. Em muitos casos, um analista precisará vasculhar a cronologia das operações subjacentes para estabelecer a causa raiz do problema. Esse processo é chamado de análise de causa raiz.

Observação

A análise de causa raiz pode revelar ineficiências no design de um aplicativo. Nessas situações, talvez seja possível retrabalhar os elementos afetados e implantá-los como parte de uma versão subsequente. Este processo requer um controlo cuidadoso e os componentes atualizados devem ser monitorizados de perto.

Requisitos para rastreamento e depuração

Para rastrear eventos inesperados e outros problemas, é vital que os dados de monitoramento forneçam informações suficientes para permitir que um analista rastreie as origens desses problemas e reconstrua a sequência de eventos que ocorreram. Essas informações devem ser suficientes para permitir que um analista diagnostique a causa raiz de quaisquer problemas. Um desenvolvedor pode então fazer as modificações necessárias para evitar que elas se repitam.

Fontes de dados, instrumentação e requisitos de coleta de dados

A solução de problemas pode envolver o rastreamento de todos os métodos (e seus parâmetros) invocados como parte de uma operação para criar uma árvore que retrate o fluxo lógico através do sistema quando um cliente faz uma solicitação específica. As exceções e avisos que o sistema gera como resultado desse fluxo precisam ser capturados e registrados.

Para suportar a depuração, o sistema pode fornecer ganchos que permitem que um operador capture informações de estado em pontos cruciais do sistema. Ou, o sistema pode fornecer informações detalhadas passo a passo à medida que as operações selecionadas progridem. A captura de dados neste nível de detalhe pode impor uma carga adicional ao sistema e deve ser um processo temporário. Um operador usa esse processo principalmente quando uma série altamente incomum de eventos ocorre e é difícil de replicar, ou quando uma nova liberação de um ou mais elementos em um sistema requer monitoramento cuidadoso para garantir que os elementos funcionem conforme o esperado.

O pipeline de monitoramento e diagnóstico

A monitorização de um sistema distribuído em grande escala coloca um desafio significativo. Cada um dos cenários descritos na secção anterior não deve necessariamente ser considerado isoladamente. É provável que haja uma sobreposição significativa nos dados de monitoramento e diagnóstico necessários para cada situação, embora esses dados possam precisar ser processados e apresentados de maneiras diferentes. Por estas razões, deve ter uma visão holística da monitorização e do diagnóstico.

Você pode imaginar todo o processo de monitoramento e diagnóstico como um pipeline que compreende os estágios mostrados na Figura 1.

Figura 1 - As etapas no pipeline de monitoramento e diagnóstico.

A Figura 1 destaca como os dados para monitoramento e diagnóstico podem vir de uma variedade de fontes de dados. As etapas de instrumentação e coleta estão preocupadas em identificar as fontes de onde os dados precisam ser capturados, determinar quais dados capturar, como capturá-los e como formatar esses dados para que possam ser facilmente examinados. A etapa de análise/diagnóstico pega os dados brutos e os usa para gerar informações significativas que um operador pode usar para determinar o estado do sistema. O operador pode usar essas informações para tomar decisões sobre possíveis ações a serem tomadas e, em seguida, alimentar os resultados de volta para as etapas de instrumentação e coleta. A fase de visualização/alerta apresenta uma visão consumível do estado do sistema. Ele pode exibir informações quase em tempo real usando uma série de painéis. E pode gerar relatórios, gráficos e tabelas para fornecer uma visão histórica dos dados que podem ajudar 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 para um operador. Em alguns casos, um alerta também pode ser usado para acionar um processo automatizado que tenta tomar ações corretivas, como o dimensionamento automático.

Note-se que estas etapas constituem um processo de fluxo contínuo onde as etapas estão acontecendo em paralelo. Idealmente, todas as fases devem ser configuradas dinamicamente. Em alguns pontos, especialmente quando um sistema foi implantado recentemente ou está enfrentando problemas, pode ser necessário coletar dados estendidos com mais frequência. Outras vezes, deve ser possível voltar a capturar um nível básico de informações essenciais para verificar se o sistema está funcionando corretamente.

Além disso, todo o processo de monitoramento deve ser considerado uma solução ativa e contínua que está sujeita a ajustes finos e melhorias como resultado do feedback. Por exemplo, você pode começar medindo muitos fatores para determinar a integridade do sistema. A análise ao longo do tempo pode levar a um refinamento à medida que você descarta medidas que não são relevantes, permitindo que você se concentre com mais precisão nos dados de que precisa enquanto minimiza o ruído de fundo.

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

As informações que o processo de monitorização utiliza podem provir de várias fontes, como ilustrado na Figura 1. No nível do aplicativo, as informações vêm de logs de rastreamento incorporados ao 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 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 qualquer outra informação pertinente. O registo dos horários de entrada e saída também pode revelar-se útil.

Você deve registrar todas as exceções e avisos e garantir que você mantenha um rastreamento completo de quaisquer exceções e avisos aninhados. Idealmente, você também deve capturar informações que identifiquem o usuário que está executando o código, juntamente com informações de correlação de atividade (para rastrear solicitações à medida que passam pelo sistema). E você deve registrar as tentativas de acessar todos os recursos, como filas de mensagens, bancos de dados, arquivos e outros serviços dependentes. Essas informações podem ser usadas 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. Essas estruturas podem ser configuráveis para fornecer suas próprias mensagens de rastreamento e informações brutas de diagnóstico, como taxas de transação e sucessos e falhas de transmissão de dados.

Observação

Muitas estruturas modernas publicam automaticamente eventos de desempenho e rastreamento. Capturar essas informações é simplesmente uma questão de fornecer um meio de recuperá-las e armazená-las onde possam ser processadas e analisadas.

O sistema operacional em que o aplicativo está sendo 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. Erros do sistema operacional (como a falha ao abrir um arquivo corretamente) também podem ser relatados.

Você também deve considerar a infraestrutura subjacente e os componentes nos quais o sistema é executado. Máquinas virtuais, 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 seu aplicativo usa outros serviços externos, como um servidor Web ou um sistema de gerenciamento de banco de dados, esses serviços podem publicar suas próprias informações de rastreamento, logs e contadores de desempenho. Os exemplos incluem Exibições de Gerenciamento Dinâmico do SQL Server para controlar operações executadas em um banco de dados do SQL Server e logs de rastreamento do IIS para registrar solicitações feitas a um servidor Web.

À medida que os componentes de um sistema são modificados e novas versões são implantadas, é importante poder atribuir problemas, eventos e métricas a cada versão. Essas informações devem ser vinculadas ao pipeline de liberação para que os problemas com uma versão específica de um componente possam ser rastreados rapidamente e corrigidos.

Problemas de segurança podem ocorrer em qualquer ponto do sistema. Por exemplo, um utilizador pode tentar iniciar sessão com um ID de utilizador ou palavra-passe inválidos. Um usuário autenticado pode tentar obter acesso não autorizado a um recurso. Ou um usuário pode fornecer uma chave inválida ou desatualizada para acessar informações criptografadas. As informações relacionadas à segurança para solicitações bem-sucedidas e com falha devem ser sempre registradas.

A seção Instrumentando um aplicativo contém mais orientações sobre as informações que você deve capturar. Mas você pode usar uma variedade de estratégias para reunir essas informações:

• Monitorização da aplicação/sistema. Essa estratégia usa fontes internas dentro do 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 do cliente. O aplicativo pode incluir instruções de rastreamento que podem ser seletivamente habilitadas ou desabilitadas conforme as circunstâncias ditarem. Também pode ser possível injetar diagnósticos dinamicamente usando uma estrutura de diagnóstico. Essas estruturas geralmente fornecem plug-ins que podem ser anexados a vários pontos de instrumentação em seu código e capturar dados de rastreamento nesses pontos.

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

• Monitorização real do utilizador. Essa abordagem registra as interações entre um usuário e o aplicativo e observa o fluxo de cada solicitação e resposta. Essas informações podem ter uma dupla finalidade: podem ser usadas para medir o uso por cada usuário e podem ser usadas para determinar se os usuários estão recebendo uma qualidade de serviço adequada (por exemplo, tempos de resposta rápidos, baixa latência e erros mínimos). Você pode usar os dados capturados para identificar áreas de preocupação onde as falhas ocorrem com mais frequência. Você também pode usar os dados para identificar elementos em que o sistema fica mais lento, possivelmente devido a pontos críticos no aplicativo ou alguma outra forma de gargalo. Se você implementar essa abordagem cuidadosamente, talvez seja possível reconstruir os fluxos dos usuários através do aplicativo para fins de depuração e teste.

  Importante

  Você deve considerar os dados capturados pelo monitoramento de usuários reais como altamente confidenciais, pois 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.

• Monitoramento sintético do usuário. Nessa abordagem, você escreve seu próprio cliente de teste que simula um usuário e executa 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 que tipo de saída de monitoramento é gerada nessas condições.

  Observação

  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.

• Definição de perfis. Essa abordagem visa principalmente monitorar e melhorar o desempenho do aplicativo. Em vez de operar no nível funcional de monitoramento de usuário real e sintético, ele captura informações de nível inferior à medida que o aplicativo é executado. Você pode implementar a criação de perfil usando amostragem periódica do estado de execução de um aplicativo (determinando qual parte do código o aplicativo está sendo executado em um determinado momento). Você também pode usar instrumentação que insere testes no código em momentos importantes (como o início e o fim de uma chamada de método) e registra quais métodos foram invocados, em que momento e quanto tempo cada chamada levou. Em seguida, você pode analisar esses dados para determinar quais partes do aplicativo podem causar problemas de desempenho.

• Monitorização de pontos finais. Essa técnica 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. Diferentes pontos de extremidade podem se concentrar em vários aspetos da funcionalidade. Você pode escrever seu próprio cliente de diagnóstico que envia solicitações periódicas para esses pontos de extremidade e assimilar as respostas. Para obter mais informações, consulte o padrão Health Endpoint Monitoring.

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

Instrumentando um aplicativo

A instrumentação é uma parte crítica do processo de monitorização. Você pode tomar decisões significativas sobre o desempenho e a integridade de um sistema somente se primeiro capturar os dados que permitem tomar essas decisões. As informações coletadas usando a instrumentação devem ser suficientes para permitir que você avalie o desempenho, diagnostique problemas e tome decisões sem exigir que você entre em um servidor de produção remoto para executar o rastreamento (e a depuração) manualmente. Os dados de instrumentação geralmente incluem métricas e informações gravadas em logs de rastreamento.

O conteúdo de um log de rastreamento pode ser o resultado de dados textuais gravados pelo aplicativo ou dados binários criados como resultado de um evento de rastreamento, se o aplicativo estiver usando o Rastreamento de Eventos para Windows (ETW). Eles também podem ser gerados a partir de logs do sistema que registram eventos decorrentes de partes da infraestrutura, como um servidor web. As mensagens de registo textuais são muitas vezes concebidas para serem legíveis por humanos, mas também devem ser escritas num formato que permita a um sistema automatizado analisá-las facilmente.

Você também deve categorizar logs. Não escreva todos os dados de rastreamento em um único log, mas use logs separados para registrar a saída de rastreamento de diferentes aspetos operacionais do sistema. Em seguida, você pode filtrar rapidamente as mensagens de log lendo o log apropriado em vez de ter que processar um único arquivo longo. Nunca escreva informações com requisitos de segurança diferentes (como informações de auditoria e dados de depuração) no mesmo log.

Observação

Um log pode ser implementado como um arquivo no sistema de arquivos ou pode ser mantido em algum outro formato, como um blob no armazenamento de blobs. As informações de log também podem ser mantidas em um armazenamento mais estruturado, como linhas em uma tabela.

As métricas geralmente serão uma medida ou contagem de algum aspeto ou recurso no sistema em um momento específico, com uma ou mais tags ou dimensões associadas (às vezes chamadas de amostra). Uma única instância de uma métrica geralmente não é útil isoladamente. Em vez disso, as métricas têm de ser capturadas ao longo do tempo. A questão-chave a considerar é quais métricas você deve registrar e com que frequência. A geração de dados para métricas com muita frequência pode impor uma carga adicional significativa ao sistema, enquanto a captura de métricas com pouca frequência 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 variar significativamente de segundo para segundo, mas a alta utilização se torna um problema apenas se for de longa duração 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 monitoramento exigem o estágio de análise e diagnóstico no pipeline de monitoramento para correlacionar os dados recuperados de várias fontes. Esses dados podem assumir várias formas nos dados brutos, e o processo de análise deve ser fornecido com dados de instrumentação suficientes para poder mapear essas diferentes formas. Por exemplo, no nível da estrutura do aplicativo, uma tarefa pode ser identificada por um ID de thread. Dentro de um aplicativo, o mesmo trabalho pode ser associado ao ID do usuário que está executando essa tarefa.

Além disso, é improvável que haja um mapeamento 1:1 entre threads e solicitações de usuário, porque operações assíncronas podem reutilizar os mesmos threads para executar operações em nome de mais de um usuário. Para complicar ainda mais as coisas, uma única solicitação pode ser tratada por mais de um thread à medida que a execução flui pelo sistema. Se possível, associe cada solicitação a um ID de atividade exclusivo que é propagado pelo sistema como parte do contexto da solicitação. (A técnica para gerar e incluir IDs de atividade nas informações de rastreamento depende da tecnologia usada para capturar os dados de rastreamento.)

Todos os dados de monitorização devem ter o carimbo de data/hora da mesma forma. Para consistência, registre todas as datas e horas usando o Tempo Universal Coordenado. Isto irá ajudá-lo a rastrear mais facilmente sequências de eventos.

Observação

Os computadores que operam em fusos horários e redes diferentes podem não estar sincronizados. Não dependa apenas do uso de carimbos de data/hora para correlacionar dados de instrumentação que abrangem várias máquinas.

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

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

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

• Habilite a criação de perfil somente quando necessário, pois ela pode impor uma sobrecarga significativa ao sistema. A criação de perfil usando instrumentação registra um evento (como uma chamada de método) toda vez que ele ocorre, enquanto a amostragem registra apenas eventos selecionados. A seleção pode ser baseada no tempo (uma vez a cada n segundos) ou na frequência (uma vez a cada n solicitações). Se os eventos ocorrerem com muita frequência, a criação de perfis por instrumentação pode causar muita carga e afetar o desempenho geral. Neste caso, pode ser preferível o método de 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 permitir que um desenvolvedor ou administrador determine a origem de cada solicitação. Isso pode incluir alguma forma de ID de atividade que identifique uma instância específica de uma solicitação. Também pode incluir informações que podem ser usadas para correlacionar esta atividade com o trabalho computacional realizado e os recursos utilizados. Observe que esse trabalho pode cruzar os limites do processo e da máquina. Para a medição, o contexto também deve incluir (direta ou indiretamente através de outras informações correlacionadas) uma referência ao cliente que causou o pedido. Esse contexto fornece informações valiosas sobre o estado do aplicativo no momento em que os dados de monitoramento foram capturados.

• Registre todas as solicitações e os locais ou regiões a partir dos quais essas solicitações são feitas. Estas informações podem ajudar a determinar se existem pontos de acesso específicos para cada local. Essas informações também podem ser úteis para determinar se um aplicativo deve ser reparticionado ou os dados que ele usa.

• 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 a pilha de chamadas, se possível.

• Seja consistente nos dados que os diferentes elementos do seu aplicativo capturam, pois isso pode ajudar na análise de eventos e correlacioná-los com as solicitações do usuário. 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. Reúna dados dos principais contadores de desempenho, como o volume de E/S que está sendo executado, a utilização da rede, o número de solicitações, o uso da memória e a utilização da CPU. Alguns serviços de infraestrutura podem fornecer seus próprios contadores de desempenho específicos, como o número de conexões com um banco de dados, a taxa na qual as transações estão sendo executadas e o número de transações bem-sucedidas ou com falha. 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. Registre informações sobre o tempo necessário para executar cada chamada e o sucesso ou falha da chamada. 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 qualquer aplicativo ou tecnologia específica, mas espera que as informações sigam um formato específico que geralmente é definido por um esquema. O esquema especifica efetivamente um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. O esquema deve ser generalizado para permitir que os dados cheguem de uma variedade de plataformas e dispositivos.

Um esquema comum deve incluir campos que são comuns a todos os eventos de instrumentação, como o nome do evento, a hora do evento, o endereço IP do remetente e os detalhes necessários para correlacionar com outros eventos (como um ID de usuário, um ID de dispositivo e um ID de 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; O aplicativo 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. Isso pode ser informações sobre exceções, eventos de início e término do aplicativo e sucesso ou falha de chamadas de API de serviço Web. Todos os aplicativos que usam o mesmo conjunto de campos de domínio devem emitir o mesmo conjunto de eventos, permitindo que um conjunto de relatórios e análises comuns seja criado.

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

Práticas recomendadas para instrumentação de aplicativos

A lista a seguir resume as práticas recomendadas para instrumentar um aplicativo distribuído em execução na nuvem.

• Torne os logs 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.

• Use o mesmo fuso horário e formato para todos os carimbos de data/hora. Isso ajudará 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 os usuários. Limpe essas informações antes de serem registradas, mas certifique-se de que os detalhes relevantes sejam mantidos. Por exemplo, remova o ID e a senha de qualquer cadeia de conexão de banco de dados, mas grave as informações restantes no log para que um analista possa determinar que o sistema está acessando o banco de dados correto. Registre todas as exceções críticas, mas permita que o administrador ative e desative o logon para níveis mais baixos de exceções e avisos. Além disso, capture e registre todas as informações de lógica de repetição. Esses dados podem ser úteis para monitorar a integridade transitória do sistema.

• Rastreie chamadas de 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.

• Com exceção dos eventos de auditoria, certifique-se de que todas as chamadas de registro sejam operações de disparo e esquecimento que não bloqueiem o progresso das operações de negócios. Os eventos de auditoria são excecionais porque são críticos para o negócio e podem ser classificados como uma parte fundamental das operações de negócios.

• Certifique-se de que o registro em log é extensível e não tem dependências diretas em um destino concreto. Por exemplo, em vez de gravar informações usando System.Diagnostics.Trace, defina uma interface abstrata (como ILogger) que exponha métodos de log e que possa ser implementada por qualquer meio apropriado.

• Certifique-se de que todo o registo é à prova de falhas e nunca dispara quaisquer erros em cascata. O registro em log não deve gerar exceções.

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

Recolha e armazenamento de dados

A etapa de coleta do processo de monitoramento está preocupada em recuperar as informações geradas pela instrumentação, formatar esses dados para facilitar o consumo da etapa de análise/diagnóstico e salvar os dados transformados em armazenamento confiável. Os dados de instrumentação que você coleta de diferentes partes de um sistema distribuído podem ser mantidos em uma variedade de locais e com formatos variados. Por exemplo, o código do aplicativo pode gerar arquivos de log de rastreamento e gerar dados de log de eventos do aplicativo, enquanto os contadores de desempenho que monitoram os principais aspetos da infraestrutura que seu aplicativo usa podem ser capturados por meio de outras tecnologias. Quaisquer componentes e serviços de terceiros que seu aplicativo usa podem fornecer informações de instrumentação em formatos diferentes, usando arquivos de rastreamento separados, armazenamento de blob ou até mesmo um armazenamento de dados personalizado.

A coleta de dados geralmente é realizada por meio de um serviço de coleta que pode ser executado de forma autônoma a partir do aplicativo que gera os dados de instrumentação. A Figura 2 ilustra um exemplo dessa arquitetura, destacando o subsistema de coleta de dados de instrumentação.

Figura 2 - Recolha de dados de instrumentação.

Observe que esta é uma exibição simplificada. O serviço de recolha não é necessariamente um processo único e pode incluir muitas partes constituintes que funcionam em máquinas diferentes, conforme descrito nas secções seguintes. Além disso, se a análise de alguns dados de telemetria precisar ser executada rapidamente (análise a quente, conforme descrito na seção Suporte a análise quente, quente e fria mais adiante neste documento), os componentes locais que operam fora do serviço de coleta podem executar as tarefas de análise imediatamente. A Figura 2 mostra essa situação para eventos selecionados. Após o processamento analítico, os resultados podem ser enviados diretamente para o subsistema de visualização e alerta. Os dados que são submetidos a análises quentes ou frias são mantidos em armazenamento enquanto aguardam processamento.

Para aplicativos e serviços do Azure, o Diagnóstico do Azure fornece uma solução possível para capturar dados. O Diagnóstico do Azure reúne dados das seguintes fontes para cada nó de computação, agrega-os e, em seguida, carrega-os no Armazenamento do Azure:

• Registos do IIS
• Logs de solicitação com falha do IIS
• Registos de eventos do Windows
• Contadores de desempenho
• Relatórios de falha
• Registos da infraestrutura do Diagnóstico do Azure
• Registos de erros personalizados
• Fonte de eventos do .NET
• ETW baseado no manifesto

Para obter mais informações, consulte o artigo Azure: Noções básicas de telemetria e solução de problemas.

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

Considerando a natureza elástica da nuvem e para evitar a necessidade de recuperar manualmente dados de telemetria de cada nó do sistema, você deve providenciar para que os dados sejam transferidos para um local central e consolidados. Em um sistema que abrange vários datacenters, pode ser útil primeiro coletar, consolidar e armazenar dados região a região e, em seguida, agregar os dados regionais em um único sistema central.

Para otimizar o uso da largura de banda, você pode optar por transferir dados menos urgentes em partes, como lotes. No entanto, os dados não devem ser adiados indefinidamente, especialmente se contiverem informações sensíveis em termos de tempo.

Extraindo e enviando dados de instrumentação

O subsistema de coleta de dados de instrumentação pode recuperar ativamente dados de instrumentação de vários logs e outras fontes para cada instância do aplicativo (o modelo pull). Ou, ele pode atuar como um recetor passivo que aguarda que os dados sejam enviados dos componentes que constituem cada instância do aplicativo (o modelo push).

Uma abordagem para implementar o modelo pull é usar agentes de monitoramento que são executados localmente com cada instância do aplicativo. Um agente de monitoramento é um processo separado que periodicamente recupera (extrai) dados de telemetria coletados no nó local e grava essas informações diretamente no armazenamento centralizado que todas as instâncias do aplicativo compartilham. Este é o mecanismo que o Diagnóstico do Azure implementa. Cada instância de uma função Web ou de trabalho do Azure pode ser configurada para capturar informações de diagnóstico e outras informações de rastreamento armazenadas localmente. O agente de monitoramento executado ao lado de cada instância copia os dados especificados para o Armazenamento do Azure. O artigo Habilitando diagnósticos nos Serviços de Nuvem do Azure e Máquinas Virtuais fornece mais detalhes sobre esse processo. Alguns elementos, como logs do IIS, despejos de memória e logs de erros personalizados, são gravados no armazenamento de blobs. Os dados do log de eventos do Windows, eventos ETW e contadores de desempenho são registrados no armazenamento de tabelas. A Figura 3 ilustra este mecanismo.

Figura 3 - Usando um agente de monitoramento para extrair informações e gravar no armazenamento compartilhado.

Observação

A utilização de um agente de monitorização é o processo mais adequado para capturar dados de instrumentação extraídos naturalmente de uma origem de dados. Um exemplo são as informações das Exibições de Gerenciamento Dinâmico do SQL Server ou o comprimento de uma fila do Barramento de Serviço do Azure.

É viável usar a abordagem descrita anteriormente para armazenar dados de telemetria para um aplicativo de pequena escala executado em um número limitado de nós em um único local. No entanto, um aplicativo de nuvem global complexo, altamente escalável pode gerar grandes volumes de dados de centenas de funções Web e de trabalho, fragmentos de banco 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. Portanto, sua solução de telemetria deve ser escalável para evitar que atue como 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 faturamento) se parte do sistema falhar.

Para resolver esses problemas, você pode implementar o enfileiramento, como mostra a Figura 4. Nessa arquitetura, o agente de monitoramento local (se puder ser configurado adequadamente) ou o serviço de coleta de dados personalizado (se não) posta dados em uma fila. Um processo separado executado de forma assíncrona (o serviço de gravação de armazenamento na Figura 4) pega os dados nessa fila e os grava no armazenamento compartilhado. Uma fila de mensagens é adequada para esse cenário porque fornece semântica "pelo menos uma vez" que ajuda a garantir que os dados enfileirados não sejam perdidos depois de publicados. Você pode implementar o serviço de gravação de armazenamento usando uma função de trabalho separada.

Figura 4 - Usando uma fila para armazenar dados de instrumentação em buffer.

O serviço de coleta de dados local pode adicionar dados a uma fila imediatamente após seu recebimento. A fila atua como um buffer e o serviço de gravação de armazenamento pode recuperar e gravar os dados em seu próprio ritmo. Por padrão, uma fila opera em uma base de primeiro a entrar, primeiro a sair. Mas você pode priorizar mensagens para acelerá-las na fila se elas contiverem dados que devem ser tratados mais rapidamente. Para obter mais informações, consulte o padrão de fila de prioridade. Como alternativa, você pode usar diferentes canais (como tópicos do Service Bus) para direcionar dados para destinos diferentes, dependendo da forma de processamento analítico necessária.

Para escalabilidade, você pode executar várias instâncias do serviço de gravação de armazenamento. Se houver um grande volume de eventos, você poderá usar um hub de eventos para enviar os dados para diferentes recursos de computação para processamento e armazenamento.

Consolidação de 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 integridade geral do sistema, é necessário consolidar alguns aspetos dos dados nas visualizações locais. Você pode fazer isso depois que os dados forem armazenados, mas, em alguns casos, você também pode alcançá-lo à medida que os dados são coletados. Em vez de serem gravados diretamente no armazenamento compartilhado, os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combina dados e atua como um processo de filtro e limpeza. Por exemplo, os dados de instrumentação que incluem as mesmas informações de correlação, como um ID de atividade, podem ser amalgamados. (É possível que um usuário comece a executar uma operação de negócios em um nó e, em seguida, seja transferido para outro nó em caso de falha do nó ou dependendo de como o balanceamento de carga está configurado.) Esse processo também pode detetar e remover quaisquer dados duplicados (sempre uma possibilidade se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação para o armazenamento). A Figura 5 ilustra um exemplo desta estrutura.

Figura 5 - Usando um serviço separado para consolidar e limpar dados de instrumentação.

Armazenamento de dados de instrumentação

As discussões anteriores descreveram uma visão bastante simplista da forma como os dados de instrumentação são armazenados. Na realidade, pode fazer sentido armazenar os diferentes tipos de informação utilizando tecnologias mais adequadas à forma como cada tipo é suscetível de ser utilizado.

Por exemplo, o blob do Azure e o armazenamento de tabelas têm algumas semelhanças na forma como são acedidos. Mas eles têm limitações nas operações que você pode executar usando-os, e a granularidade dos dados que eles mantêm é bastante diferente. Se tiver de efetuar operações mais analíticas ou precisar de capacidades de pesquisa em texto completo nos dados, pode ser mais adequado utilizar um armazenamento de dados que forneça capacidades otimizadas para tipos específicos de consultas e acesso a dados. Por exemplo:

• Os dados de contadores de desempenho podem ser armazenados numa base de dados SQL para permitir análises ad hoc.
• Os logs de rastreamento podem ser melhor armazenados no Azure Cosmos DB.
• As informações de segurança podem ser gravadas no HDFS.
• As informações que exigem pesquisa de texto completo podem ser armazenadas por meio do Elasticsearch (que também pode acelerar pesquisas usando indexação avançada).

Você pode implementar um serviço adicional que recupera periodicamente os dados do armazenamento compartilhado, particiona e filtra os dados de acordo com sua finalidade e, em seguida, grava-os em um conjunto apropriado de armazenamentos de dados, como mostra a Figura 6. Uma abordagem alternativa é incluir esta funcionalidade no processo de consolidação e limpeza, e escrever os dados diretamente nestes arquivos à medida que são obtidos em vez de guardá-los numa área de armazenamento partilhada intermédia. Cada abordagem tem vantagens e desvantagens. A implementação de um serviço de particionamento separado diminui a carga no serviço de consolidação e limpeza e permite que pelo menos alguns dos dados particionados sejam regenerados, se necessário (dependendo da quantidade de dados retidos no armazenamento compartilhado). No entanto, consome recursos adicionais. Além disso, pode haver um atraso entre a receção dos dados de instrumentação de cada instância da aplicação e a conversão dos dados em informações acionáveis.

Figura 6 - Particionamento dos dados de acordo com os requisitos analíticos e de armazenamento.

Podem ser necessários os mesmos dados de instrumentação para mais do que um objetivo. Por exemplo, os contadores de desempenho podem ser usados para fornecer uma visão histórica do desempenho do sistema ao longo do tempo. Estas informações podem ser combinadas com outros dados de utilização para gerar informações de faturação do cliente. Nessas situações, os mesmos dados podem ser enviados para mais de um destino, como um banco de dados de documentos que pode atuar como um armazenamento de longo prazo para armazenar informações de faturamento e um armazenamento multidimensional para lidar com análises de desempenho complexas.

Deve também considerar a urgência com que os dados são necessários. Os dados que fornecem informações para alerta devem ser acessados rapidamente, por isso devem ser mantidos em armazenamento rápido de dados e indexados ou estruturados para otimizar as consultas que o sistema de alerta executa. Em alguns casos, pode ser necessário que o serviço de telemetria que reúne os dados em cada nó formate e salve os dados localmente para que uma instância local do sistema de alerta possa notificá-lo rapidamente sobre quaisquer problemas. Os mesmos dados podem ser distribuídos pelo serviço de escrita de armazenamento mostrado nos diagramas anteriores e armazenados centralmente, caso sejam também necessários para outros fins.

As informações usadas para análises mais ponderadas, relatórios e deteção de tendências históricas são menos urgentes e podem ser armazenadas de forma a suportar mineração de dados e consultas ad hoc. Para obter mais informações, consulte a seção Suporte à análise quente, quente e fria mais adiante neste documento.

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

A instrumentação pode gerar volumes consideráveis de dados. Esses dados podem ser mantidos em vários locais, começando com os arquivos de log brutos, arquivos de rastreamento e outras informações capturadas em cada nó até a exibição consolidada, limpa e particionada desses dados mantidos no armazenamento compartilhado. Em alguns casos, após os dados terem sido processados e transferidos, os dados de origem brutos originais podem ser removidos de cada nó. Em outros casos, pode ser necessário ou simplesmente útil salvar as informações brutas. Por exemplo, os dados gerados para fins de depuração podem ser melhor deixados disponíveis em sua forma bruta, mas podem ser descartados rapidamente depois que quaisquer bugs forem corrigidos.

Os dados de desempenho geralmente têm uma vida útil mais longa para que possam ser usados para detetar tendências de desempenho e para planejamento de capacidade. A vista consolidada destes dados é normalmente mantida online durante um período finito para permitir um acesso rápido. Depois disso, pode ser arquivada ou eliminada. Os dados recolhidos para clientes de medição e faturação podem ter de ser guardados indefinidamente. Além disso, os requisitos normativos podem ditar que as informações coletadas para fins de auditoria e segurança também precisam ser arquivadas e salvas. Estes dados também são sensíveis e poderão ter de ser encriptados ou protegidos de outra forma para evitar adulterações. Nunca deve gravar as palavras-passe dos utilizadores ou outras informações que possam ser utilizadas para cometer fraude de identidade. Esses detalhes devem ser removidos dos dados antes de serem armazenados.

Redução da amostragem

É útil armazenar dados históricos para detetar tendências a longo prazo. Em vez de salvar dados antigos em sua totalidade, talvez seja possível reduzir a amostragem dos 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 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 do processo e deve ser simples de implantar.

• 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, emita informações em um formato autodescritivo, como JSON, MessagePack ou Protobuf em vez de ETL/ETW. O uso de um formato padrão permite que o sistema construa pipelines de processamento; Os componentes que leem, transformam e enviam dados no formato acordado podem ser facilmente integrados.

• O processo de monitorização e recolha de dados deve ser à prova de falhas e não deve desencadear quaisquer condições de erro em cascata.

• No caso de uma falha transitória no envio de informações para um coletor de dados, o agente de monitoramento ou o serviço de coleta de dados deve estar preparado para reordenar os dados de telemetria para que as informações mais recentes sejam enviadas primeiro. (O agente de monitoramento/serviço de coleta de dados pode optar por descartar os dados mais antigos ou salvá-los localmente e transmiti-los mais tarde para recuperar o atraso, a seu critério.)

Análise de dados e diagnóstico de problemas

Uma parte importante do processo de monitorização e diagnóstico é analisar os dados recolhidos para obter uma imagem do bem-estar geral do sistema. Você deve ter definido seus próprios KPIs e métricas de desempenho, e é importante entender como você pode estruturar os dados que foram coletados para atender aos seus requisitos de análise. Também é importante entender como os dados capturados em diferentes métricas e arquivos de log estão correlacionados, porque essas informações podem ser fundamentais para rastrear uma sequência de eventos e ajudar a diagnosticar problemas que surgem.

Conforme descrito na seção Consolidando dados de instrumentação, os dados de cada parte do sistema normalmente são capturados localmente, mas geralmente precisam ser combinados com dados gerados em outros locais que participam do sistema. Essas informações exigem uma correlação cuidadosa para garantir que os dados sejam combinados com precisão. Por exemplo, os dados de uso de uma operação podem abranger um nó que hospeda um site ao qual um usuário se conecta, um nó que executa um serviço separado acessado como parte dessa operação e o armazenamento de dados mantido em outro nó. Essas informações precisam ser vinculadas para fornecer uma visão geral do uso de recursos e processamento para a operação. Alguns pré-processamento e filtragem de dados podem ocorrer no nó no qual os dados são capturados, enquanto a agregação e a formatação são mais prováveis de ocorrer em um nó central.

Suporte a análises quentes, quentes e frias

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 são críticas em termos de tempo e requerem uma análise imediata dos dados para serem eficazes. Isso é conhecido como análise quente. Os exemplos incluem as análises necessárias para alertar e alguns aspetos do monitoramento de segurança (como a deteção de um ataque ao sistema). Os dados necessários para esses fins devem estar rapidamente disponíveis e estruturados para um processamento eficiente. Em alguns casos, pode ser necessário mover o processamento da análise para os nós individuais onde os dados são mantidos.

Outras formas de análise são menos críticas em termos de tempo e podem exigir algum cálculo e agregação após a receção dos dados brutos. Isso é chamado de análise calorosa. A análise de desempenho geralmente se enquadra nessa categoria. Neste caso, é improvável que um evento de desempenho isolado e único seja estatisticamente significativo. (Pode ser causada por um pico ou falha repentina.) Os dados de uma série de eventos devem fornecer uma imagem mais fiável do desempenho do sistema.

A análise calorosa também pode ser usada para ajudar a diagnosticar problemas de saúde. Um evento de integridade normalmente é processado por meio de análise ativa e pode gerar um alerta imediatamente. Um operador deve ser capaz de detalhar as razões para o evento de integridade examinando os dados do caminho quente. Esses dados devem conter informações sobre os eventos que levaram ao problema que causou o evento de integridade.

Alguns tipos de monitorização geram dados a mais longo prazo. Esta análise pode ser realizada posteriormente, possivelmente de acordo com um calendário pré-definido. Em alguns casos, a análise pode precisar executar uma filtragem complexa de grandes volumes de dados capturados durante um período de tempo. Isso é chamado de análise fria. O principal requisito é que os dados sejam armazenados com segurança depois de capturados. Por exemplo, o monitoramento e a auditoria de uso exigem uma imagem precisa do estado do sistema em pontos regulares no tempo, mas essas informações de estado não precisam estar disponíveis para processamento imediatamente após terem sido coletadas.

Um operador também pode usar a análise fria para fornecer os dados para análise preditiva de integridade. O operador pode reunir informações históricas durante um período especificado e usá-las em conjunto com os dados de integridade atuais (recuperados do caminho quente) para identificar tendências que podem causar problemas de saúde em breve. Nestes casos, poderá ser necessário emitir um alerta para que possam ser tomadas medidas corretivas.

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:

• O que causou um carregamento intenso de E/S no nível do sistema em um momento específico?
• É o resultado de um grande número de operações de banco de dados?
• Isso se reflete nos tempos de resposta do banco de dados, no número de transações por segundo e nos tempos de resposta do aplicativo no mesmo momento?

Nesse caso, uma ação corretiva que pode reduzir a carga pode ser fragmentar os dados em mais servidores. Além disso, podem surgir exceções como resultado de uma falha em qualquer nível do sistema. Uma exceção em um nível geralmente desencadeia outra falha no nível acima.

Por esses motivos, você precisa ser capaz de correlacionar os diferentes tipos de dados de monitoramento em cada nível para produzir uma visão geral do estado do sistema e dos aplicativos que estão sendo executados nele. Você pode usar essas informações para tomar decisões sobre se o sistema está funcionando de forma aceitável ou não, e determinar o que pode ser feito para melhorar a qualidade do sistema.

Conforme descrito na seção Informações para correlacionar dados, você deve garantir que os dados brutos de instrumentação incluam informações suficientes de contexto e ID de atividade para dar suporte às agregações necessárias para correlacionar eventos. Além disso, esses dados podem ser mantidos em diferentes formatos, e pode ser necessário analisar essas informações para convertê-las em um formato padronizado para análise.

Resolução de problemas e diagnosticar problemas

O diagnóstico requer a capacidade de determinar a causa de falhas ou comportamento inesperado, incluindo a realização de análise de causa raiz. As informações necessárias normalmente incluem:

• Informações detalhadas de logs de eventos e rastreamentos, para todo o sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Rastreamentos de pilha completos resultantes de exceções e falhas de qualquer nível especificado que ocorrem dentro do sistema ou de um subsistema especificado durante um período especificado.
• Despejos de memória para quaisquer processos com falha em qualquer lugar do sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Logs de atividade registrando as operações que são executadas por todos os usuários ou para usuários selecionados durante um período especificado.

A análise de dados para fins de solução de problemas geralmente requer uma compreensão técnica profunda da arquitetura do sistema e dos vários componentes que compõem a solução. Como resultado, um grande grau de intervenção manual é muitas vezes necessário para interpretar os dados, estabelecer a causa dos problemas e recomendar uma estratégia apropriada para corrigi-los. Pode ser adequado simplesmente armazenar uma cópia destas informações no seu formato original e disponibilizá-las para análise fria por um perito.

Visualizar dados e gerar alertas

Um aspeto importante de qualquer sistema de monitorização é a capacidade de apresentar os dados de tal forma que um operador possa detetar rapidamente quaisquer tendências ou problemas. Também importante é a capacidade de informar rapidamente um operador se tiver ocorrido um evento significativo que possa exigir 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 maneira mais comum de visualizar dados é usar painéis que podem exibir informações como uma série de gráficos, gráficos ou alguma outra ilustração. Esses itens podem ser parametrizados, e um analista deve ser capaz de selecionar os parâmetros importantes (como o período de tempo) para qualquer situação específica.

Os painéis podem ser organizados hierarquicamente. Os painéis de nível superior podem fornecer uma visão geral de cada aspeto do sistema, mas permitem que um operador analise detalhadamente os detalhes. Por exemplo, um painel que retrate a E/S geral do disco para o sistema deve permitir que um analista visualize as taxas de E/S de cada disco individual para verificar se um ou mais dispositivos específicos representam um volume desproporcional de tráfego. Idealmente, o painel também deve exibir informações relacionadas, como a origem de cada solicitação (o usuário ou a atividade) que está gerando essa E/S. Essas informações podem ser usadas para determinar se (e como) distribuir a carga de forma mais uniforme entre dispositivos e se o sistema teria um desempenho melhor se mais dispositivos fossem adicionados.

Um painel também pode usar codificação de cores ou algumas outras pistas visuais para indicar valores que parecem anômalos ou que estão fora de um intervalo esperado. Usando o exemplo anterior:

• Um disco com uma taxa de E/S que esteja se aproximando de sua capacidade máxima durante um período prolongado (um disco quente) pode ser destacado em vermelho.
• Um disco com uma taxa de E/S que é executado periodicamente no seu limite máximo durante curtos períodos (um disco quente) pode ser realçado a amarelo.
• Um disco que esteja exibindo uso normal pode ser exibido em verde.

Observe que, para que um sistema de painel funcione de forma eficaz, ele deve ter os dados brutos com os quais trabalhar. Se você estiver criando seu próprio sistema de painel ou usando 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 eles devem ser formatados para o painel consumir.

Um bom painel não apenas exibe informações, mas também permite que um analista faça perguntas ad hoc sobre essas informações. Alguns sistemas fornecem ferramentas de gerenciamento que um operador pode usar para executar essas tarefas e explorar os dados subjacentes. Como alternativa, dependendo do repositório usado para armazenar essas informações, talvez seja possível consultar esses dados diretamente ou importá-los para ferramentas como o Microsoft Excel para análise e emissão de relatórios adicionais.

Observação

Você deve restringir o acesso aos painéis ao pessoal autorizado, pois essas informações podem ser comercialmente sensíveis. Você também deve proteger os dados subjacentes dos painéis para impedir que os usuários os alterem.

Emissão de alertas

O alerta é o processo de analisar os dados de monitoramento e instrumentação e gerar uma notificação se um evento significativo for detetado.

Os alertas ajudam a garantir que o sistema permaneça íntegro, responsivo e seguro. É uma parte importante de qualquer sistema que garante desempenho, disponibilidade e privacidade aos usuários onde os dados podem precisar ser acionados imediatamente. Um operador pode precisar ser notificado do evento que disparou o alerta. Os alertas também podem ser usados para invocar funções do sistema, como o dimensionamento automático.

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

• Eventos de segurança. Se os logs de eventos indicarem que estão ocorrendo repetidas falhas de autenticação ou autorização, o sistema pode estar sob ataque e um operador deve ser informado.
• Métricas de desempenho. O sistema deve responder rapidamente se uma determinada métrica de desempenho exceder um limite especificado.
• Informações sobre disponibilidade. Se uma falha for detetada, pode ser necessário reiniciar rapidamente um ou mais subsistemas ou fazer failover para um recurso de backup. Falhas repetidas em um subsistema podem indicar preocupações mais sérias.

Os operadores podem receber informações de alerta usando muitos canais de entrega, como e-mail, um dispositivo pager ou uma 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 suportam grupos de assinantes, e todos os operadores que são membros do mesmo grupo podem receber o mesmo conjunto de alertas.

Um sistema de alerta deve ser personalizável e os valores apropriados dos dados de instrumentação subjacentes podem ser fornecidos como parâmetros. Essa abordagem permite que um operador filtre dados e se concentre nesses limites ou combinações de valores que são de interesse. Observe que, em alguns casos, os dados brutos da instrumentação podem ser fornecidos ao sistema de alerta. Noutras situações, poderá ser mais adequado fornecer dados agregados. (Por exemplo, um alerta pode ser acionado se a utilização da CPU de um nó tiver excedido 90% nos últimos 10 minutos). Os pormenores fornecidos ao sistema de alerta devem também incluir qualquer resumo adequado e informações contextuais. Esses dados podem ajudar a reduzir a possibilidade de que eventos falso-positivos disparem um alerta.

Elaboração de Relatórios

Os relatórios são utilizados para gerar uma visão global do sistema. Pode incorporar dados históricos para além das informações atuais. Os próprios requisitos de comunicação de informações dividem-se em duas grandes categorias: relatórios operacionais e relatórios de segurança.

Os relatórios operacionais normalmente incluem os seguintes aspetos:

• Estatísticas agregadas que podem ser utilizadas para compreender a utilização de recursos do sistema global ou de subsistemas especificados durante uma janela de tempo especificada.
• Identificação de tendências na utilização de recursos para o sistema global ou subsistemas especificados durante um período específico.
• Monitorar as exceções que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
• Determinar a eficiência do aplicativo em termos de recursos implantados e entender se o volume de recursos (e seu custo associado) pode ser reduzido sem afetar o desempenho desnecessariamente.

Os relatórios de segurança dizem respeito ao rastreamento do uso do sistema pelos clientes. Podem incluir:

• Auditoria de operações de usuários. Isso requer o registro das solicitações individuais que cada usuário executa, juntamente com datas e horas. Os dados devem ser estruturados para permitir que um administrador reconstrua rapidamente a sequência de operações que um usuário executa durante um período especificado.
• Rastreando o uso de recursos pelo usuário. Isso requer o registro de como cada solicitação para um usuário acessa os vários recursos que compõem o sistema e por quanto tempo. Um administrador deve ser capaz de usar esses dados para gerar um relatório de utilização por usuário durante um período especificado, possivelmente para fins de cobrança.

Em muitos casos, os processos em lote podem gerar relatórios de acordo com uma agenda definida. (A latência normalmente não é um problema.) Mas também devem estar disponíveis para geração numa base ad hoc, se necessário. Por exemplo, se você estiver armazenando dados em um banco de dados relacional, como o Banco de Dados SQL do Azure, poderá usar uma ferramenta como o SQL Server Reporting Services para extrair e formatar dados e apresentá-los como um conjunto de relatórios.

Próximos passos

• Descrição geral do Azure Monitor
• Monitorizar, diagnosticar e resolver problemas do Armazenamento do Microsoft Azure
• Descrição geral dos alertas no Microsoft Azure
• Ver notificações do estado de funcionamento do serviço ao utilizar o portal do Azure
• O que é o Application Insights?
• Diagnóstico de desempenho para máquinas virtuais do Azure
• Baixar e instalar o SSDT (SQL Server Data Tools) para Visual Studio

Recursos relacionados

• As diretrizes de dimensionamento automático descrevem como diminuir a sobrecarga de gerenciamento reduzindo a necessidade de um operador monitorar continuamente o desempenho de um sistema e tomar decisões sobre a adição ou remoção de 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 fila de prioridade mostra como priorizar mensagens em fila para que solicitações urgentes sejam recebidas e possam ser processadas antes de mensagens menos urgentes.