Documentação de orientação sobre monitorização e diagnóstico

As aplicações distribuídas e os serviços em execução na cloud são, por sua natureza, elementos de software complexos constituídos por inúmeras partes móveis. Num ambiente de produção, é importante conseguir controlar a forma como os utilizadores utilizam o seu sistema, rastrear a utilização de recursos e monitorizar geralmente o estado de funcionamento e o desempenho do seu 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

Pode utilizar a monitorização para obter informações detalhadas sobre o desempenho de um sistema. A monitorização é uma parte fundamental da manutenção dos objetivos de qualidade do serviço. Os cenários comuns de recolha de dados de monitorização incluem:

• Garantir que o sistema permanece num bom estado de funcionamento.
• Monitorizar a disponibilidade do sistema e dos respetivos elementos dos componentes.
• Manter o desempenho para assegurar que o débito do sistema não diminui inesperadamente à medida que o volume de trabalho aumenta.
• Garantir que o sistema cumpre os contratos de nível de serviço (SLAs) estabelecidos com os clientes.
• Proteger a privacidade e a segurança do sistema, dos utilizadores e dos respetivos dados.
• Controlar as operações efetuadas para fins de auditoria ou regulamentação.
• Monitorizar a utilização diária do sistema e detetar as tendências que podem originar problemas se não forem resolvidos.
• Controlar os problemas ocorridos, desde o relatório inicial à análise das possíveis causas, retificação, atualizações de software consequentes e implementação.
• Rastrear as operações e depurar as versões de software.

As secções seguintes descrevem estes cenários mais detalhadamente. As informações de cada cenário são explicadas no seguinte formato:

1. Uma breve descrição geral do cenário.
2. Os requisitos típicos deste cenário.
3. Os dados de instrumentação não processados necessários para suportar o cenário e possíveis origens destas informações.
4. Como estes dados não processados podem ser analisados e combinados para gerar informações de diagnóstico significativas.

Monitorização do estado de funcionamento

Um sistema está em bom estado de funcionamento se estiver em execução e conseguir processar pedidos. O objetivo da monitorização do estado de funcionamento é gerar um instantâneo do estado de funcionamento atual do sistema para que possa verificar se todos os componentes do sistema estão a funcionar conforme esperado.

Requisitos para monitorização do estado de funcionamento

Um operador deve ser alertado rapidamente (numa questão de segundos) se qualquer parte do sistema estiver em mau estado de funcionamento. O operador deve conseguir apurar que partes do sistema estão a funcionar normalmente e que partes estão a ter problemas. O estado de funcionamento do sistema pode ser realçado através de um sistema de semáforos:

• Vermelho para mau estado de funcionamento (o sistema parou)
• Amarelo para parcialmente em bom estado de funcionamento (o sistema está em execução com funcionalidade reduzida)
• Verde para completamente em bom estado de funcionamento

Um sistema de monitorização do estado de funcionamento abrangente permite a um operador pesquisar através do sistema para ver o estado de funcionamento dos subsistemas e dos componentes. Por exemplo, se o sistema geral for descrito como parcialmente em bom estado de funcionamento, o operador deve conseguir ampliar e determinar que funcionalidade não está atualmente disponível.

Requisitos para origens de dados, instrumentação e recolha de dados

Os dados não processados necessárias para suportar a monitorização do estado de funcionamento podem ser gerados como resultado de:

• Rastreio da execução de pedidos de utilizador. Estas informações podem ser utilizadas para determinar que pedidos tiveram êxito, os que falharam e quanto tempo demora cada pedido.
• Monitorização sintética de utilizadores. Este processo simula os passos efetuados por um utilizador e segue uma série de passos predefinida. Os resultados de cada passo devem ser capturados.
• Exceções de registo, falhas e avisos. Estas informações podem ser capturadas como resultado das declarações de rastreio incorporadas no código da aplicação, bem como das informações obtidas a partir dos registos de eventos de quaisquer serviços referenciados pelo sistema.
• Monitorização do estado de funcionamento de quaisquer serviços de terceiros utilizados pelo sistema. Esta monitorização pode requerer a obtenção e a análise dos dados de estado de funcionamento que fornecem estes serviços. Estas informações podem ter vários formatos.
• Monitorização de pontos finais. Este mecanismo é descrito mais detalhadamente na secção "Monitorização da disponibilidade".
• Recolha de informações de desempenho do ambiente, como a utilização da CPU em segundo plano ou a atividade de E/S (incluindo rede).

Analisar os dados de estado de funcionamento

O foco principal da monitorização do estado de funcionamento é indicar rapidamente se o sistema está em execução. A análise frequente dos dados imediatos pode acionar um alerta se for detetado que um componente crítico tem um mau estado de funcionamento. (Falha ao responder a uma série consecutiva de pings, por exemplo.) Em seguida, o operador pode tomar a ação corretiva adequada.

Um sistema mais avançado pode incluir um elemento preditivo que efetua uma análise esporádica das cargas de trabalho recentes e atuais. Uma análise esporádica pode detetar as tendências e determinar se é provável que o sistema permaneça em bom estado de funcionamento ou se vai precisar de recursos adicionais. Este elemento preditivo deve basear-se em métricas de desempenho críticas, tais como:

• A taxa de pedidos direcionados em cada serviço ou subsistema.
• Os tempos de resposta dos pedidos.
• O volume de dados que flui para dentro e fora de cada serviço.

Se o valor de qualquer métrica exceder um limiar definido, o sistema pode emitir um alerta para ativar um operador ou o dimensionamento automático (se disponível) para efetuar as ações preventivas necessárias para manter o bom estado de funcionamento do sistema. Estas ações podem envolver a adição de recursos, o reinício de um ou mais serviços que estejam a falhar ou a aplicação de uma limitação de pedidos de prioridade mais baixa.

Monitorização da disponibilidade

Um sistema verdadeiramente em bom estado de funcionamento requer que os componentes e os subsistemas que o compõem estejam disponíveis. A monitorização da disponibilidade está estritamente relacionada com a monitorização do estado de funcionamento. No entanto, enquanto a monitorização do estado de funcionamento fornece uma vista imediata do estado de funcionamento atual do sistema, a monitorização da disponibilidade pretende controlar a disponibilidade do sistema e dos respetivos componentes para gerar estatísticas sobre o tempo de atividade do sistema.

Em muitos sistemas, alguns componentes (como uma base de dados) estão configurados com redundância incorporada para permitir uma rápida ativação pós-falha em caso de uma falha grave ou perda de conectividade. Idealmente, os utilizadores não devem ter conhecimento de que ocorreu uma falha deste tipo. No entanto, de uma perspetiva de monitorização da disponibilidade, é necessário recolher a maior quantidade possível de informações sobre essas falhas para determinar a causa e efetuar ações corretivas para impedir que ocorram novamente.

Os dados necessárias para monitorizar a disponibilidade podem depender de vários fatores de nível inferior. Muitas destes fatores podem ser específicos da aplicação, do sistema e do ambiente. Um sistema de monitorização eficaz captura os dados de disponibilidade que correspondem a estes fatores de baixo nível e, em seguida, agrega-os para lhe dar uma visão geral do estado do sistema. Por exemplo, num sistema de comércio eletrónico, a funcionalidade empresarial que permite a um cliente efetuar encomendas pode depender do repositório onde estão armazenados os detalhes das encomendas e do sistema de pagamento que processa as transações monetárias para pagá-las. Por conseguinte, a disponibilidade da execução de encomendas do sistema é uma função da disponibilidade do repositório e do subsistema de pagamento.

Requisitos para monitorização da disponibilidade

Um operador deve também conseguir ver a disponibilidade histórica de cada sistema e subsistema, e utilizar estas informações para detetar as tendências que podem causar a falha periódica de um ou mais subsistemas. (Os serviços começam a falhar num determinado momento do dia que corresponde ao pico das horas de processamento?)

Uma solução de monitorização deve fornecer uma vista imediata e histórica da disponibilidade ou indisponibilidade de cada subsistema. Deve também conseguir alertar rapidamente um operador quando um ou mais serviços falham ou quando os utilizadores não conseguem ligar aos serviços. É uma questão não só de monitorizar cada serviço, mas também de examinar as ações que cada utilizador executa se estas falharem quando tentam comunicar com um serviço. Em parte, um grau de falha de conectividade é normal e pode dever-se a erros transitórios. No entanto, pode ser útil permitir ao sistema emitir um alerta para o número de falhas de conectividade referente a um subsistema especificado ocorridas durante um determinado período.

Requisitos para origens de dados, instrumentação e recolha de dados

Tal como acontece com a monitorização do estado de funcionamento, os dados não processados necessários para suportar a monitorização da disponibilidade podem ser gerados como resultado da monitorização sintética de utilizadores e do registo de quaisquer exceções, falhas e avisos que possam ocorrer. Além disso, os dados de disponibilidade podem ser obtidos a partir da monitorização de pontos finais. A aplicação pode expor um ou mais pontos finais de estado de funcionamento, em que cada um testa o acesso a uma área funcional no sistema. O sistema de monitorização pode enviar um ping a cada ponto final ao seguir um agendamento definido e recolher os resultados (êxito ou falha).

Todos os tempos limite, falhas de conectividade de rede e tentativas de repetição da ligação têm de ser registados. Todos os dados devem ser carimbos de data/hora.

Analisar os dados de disponibilidade

Os dados de instrumentação têm de ser agregados e correlacionados para suportar os seguintes tipos de análise:

• A disponibilidade imediata do sistema e subsistemas.
• As taxas de falhas de disponibilidade do sistema e subsistemas. Idealmente, um operador deve conseguir correlacionar as falhas com atividades específicas: o que estava a acontecer quando o sistema falhou?
• Uma vista histórica das taxas de falhas do sistema ou de quaisquer subsistemas em qualquer período especificado e a carga no sistema (número de pedidos de utilizador, por exemplo) quando ocorreu uma falha.
• As razões da indisponibilidade do sistema ou de quaisquer subsistemas. Por exemplo, os motivos podem ser o serviço não estar em execução, perda de conectividade, ligado mas a exceder o tempo limite e ligado mas a devolver erros.

Pode calcular a percentagem de disponibilidade de um serviço durante período de tempo através da fórmula seguinte:

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

Isto é útil para fins de SLA. (A monitorização do SLA é descrita mais detalhadamente mais adiante nesta documentação de orientação.) A definição de tempo de inatividade depende do serviço. Por exemplo, o Serviço de Criação do Visual Studio Team Services define o período de indisponibilidade como o período (total acumulado de minutos) durante o qual o Serviço de Criação está indisponível. Um minuto é considerado indisponível se todos os pedidos HTTP contínuos para o Serviço de Criação efetuar operações iniciadas pelo cliente durante o minuto resultarem num código de erro ou não devolverem uma resposta.

Monitorização de desempenho

À medida que o sistema está cada vez mais em esforço (através do aumento do volume de utilizadores), o tamanho dos conjuntos de dados a que os utilizadores acedem cresce e aumenta a possibilidade de falha de um ou mais componentes. Frequentemente, a falha de componentes é precedida por uma diminuição no desempenho. Se conseguir detetar essa diminuição, pode tomar medidas proativas para resolver a situação.

O desempenho do sistema depende de vários fatores. Normalmente, cada fator é medido através de indicadores chave de desempenho (KPIs), como o número de transações da base de dados por segundo ou o volume de pedidos de rede fornecidos com êxito num intervalo de tempo especificado. Alguns destes KPIs podem estar disponíveis como medidas de desempenho específicas, enquanto que outros podem derivar de uma combinação de métricas.

Requisitos para monitorização de desempenho

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

• As taxas de resposta dos pedidos de utilizador.
• O número de pedidos de utilizador em simultâneo.
• O volume de tráfego de rede.
• A velocidade a que as transações comerciais estão a ser concluídas.
• O tempo médio de processamento dos pedidos.

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

• O número de utilizadores em simultâneo em comparação com as horas de latência dos pedidos (quanto tempo demora a começar a processar um pedido depois de ter sido enviado pelo utilizador).
• O número de utilizadores em simultâneo em comparação com o tempo médio de resposta (quanto tempo demora a concluir um pedido após ter sido iniciado o processamento).
• O volume de pedidos em comparação com o número de erros de processamento.

Juntamente com estas informações funcionais de alto nível, um operador deve conseguir obter uma vista detalhada do desempenho de cada componente no sistema. Geralmente, estes dados são fornecidos através de contadores de desempenho de baixo nível que controlam informações como:

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

Todas as visualizações devem permitir a um operador especificar um período de tempo. Os dados apresentados podem ser um instantâneo da situação atual e/ou uma vista histórica do desempenho.

Um operador deve conseguir emitir um alerta com base em qualquer medida de desempenho para qualquer valor especificado durante qualquer intervalo de tempo especificado.

Requisitos para origens de dados, instrumentação e recolha de dados

Pode recolher dados de desempenho de alto nível (débito, número de utilizadores em simultâneo, número de transações comerciais, taxas de erros, etc.) ao monitorizar o progresso dos pedidos dos utilizadores à medida que chegam e passam pelo sistema. Isto envolve incorporar declarações de rastreio em pontos-chave no código da aplicação, juntamente com informações de temporização. Todas as falhas, exceções e avisos devem ser capturados com dados suficientes para correlacioná-los com os pedidos que os causaram. O registo dos Serviços de Informação Internet (IIS) é outra fonte útil.

Se for possível, deve capturar os dados de desempenho de quaisquer sistemas externos utilizados pela aplicação. Estes sistemas externos podem fornecer os seus próprios contadores de desempenho ou outras funcionalidades para solicitar dados de desempenho. Se não for possível, registe as informações, como a hora de início e a hora de fim de cada pedido efetuado a um sistema externo, juntamente com o estado (êxito, falha ou aviso) da operação. Por exemplo, pode utilizar uma abordagem de cronómetro para pedidos de tempo: inicie um temporizador quando o pedido é iniciado e, em seguida, pare o temporizador quando o pedido é concluído.

Os dados de desempenho de baixo nível para componentes individuais num sistema podem estar disponíveis através de funcionalidades e serviços, como contadores de desempenho do Windows e Diagnóstico do Azure.

Analisar os dados de desempenho

Grande parte do trabalho de análise consiste em agregar dados de desempenho por tipo de pedido de utilizador e/ou subsistema ou serviço para o qual é enviado cada pedido. Um exemplo de um pedido de utilizador é adicionar um item a um carrinho de compras ou efetuar o processo de finalização da compra num 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 de 99 por cento dos pedidos, 95 por cento dos pedidos e 70 por cento dos pedidos. Podem existir objetivos de SLA ou de outro tipo definidos para cada percentil. Os resultados em curso devem ser comunicados em tempo real para ajudar a detetar problemas imediatos. Os resultados também devem ser agregados pelo período de tempo mais longo para fins estatísticos.

Em caso de problemas de latência que afetem o desempenho, um operador deve conseguir identificar rapidamente a causa do estrangulamento ao examinar a latência de cada passo executado por cada pedido. Por conseguinte, os dados de desempenho têm de fornecer uma forma de correlacionar as medidas de desempenho de cada passo para associá-las a um pedido específico.

Consoante os requisitos de visualização, pode ser útil gerar e armazenar um cubo de dados que contenha vistas dos dados não processados. Este cubo de dados pode permitir consultas ad-hoc complexas e análises das informações de desempenho.

Monitorização de segurança

Todos os sistemas comerciais que incluem dados confidenciais têm de implementar uma estrutura de segurança. A complexidade do mecanismo de segurança é, normalmente, uma função da sensibilidade dos dados. Num sistema que requer a autenticação dos utilizadores, deve registar:

• Todas as tentativas de início de sessão, falhadas ou com êxito.
• Todas as operações realizadas por e os detalhes de todos os recursos acedidos por um utilizador autenticado.
• Quando um utilizador termina a sessão.

A monitorização pode ajudar a detetar ataques no sistema. Por exemplo, um elevado número de tentativas de início de sessão falhadas pode indicar um ataque de força bruta. Um pico inesperado de pedidos pode ser resultado de um ataque denial of service (DDoS) distribuído. Tem de estar preparado para monitorizar todos os pedidos a todos os recursos, independentemente da origem dos mesmos. Um sistema com uma vulnerabilidade de início de sessão pode expor acidentalmente os recursos ao mundo exterior sem que um utilizador tenha de iniciar sessão.

Requisitos para monitorização de segurança

Os aspetos mais importantes da monitorização de segurança devem permitir rapidamente a um operador:

• Detetar tentativas de intrusões de uma entidade sem autenticação.
• Identificar tentativas de entidades efetuarem operações nos dados para os quais não lhes foi concedido acesso.
• Determinar se o sistema, ou alguma parte do sistema, está sob ataque externo ou interno. (Por exemplo, um utilizador autenticado mal intencionado pode tentar inativar o sistema.)

Para suportar estes requisitos, um operador deve ser notificado se:

• Uma conta efetua tentativas de início de sessão falhadas repetidas num período especificado.
• Uma conta autenticada tenta repetidamente aceder a um recurso proibido durante um período especificado.
• Um grande número de pedidos não autenticados ou não autorizados ocorrem durante um período especificado.

As informações fornecidas a um operador devem incluir o endereço do anfitrião da origem de cada pedido. Se as violações de segurança tiverem origem regularmente num determinado intervalo de endereços, estes anfitriões podem ser bloqueados.

Uma parte essencial da manutenção da segurança de um sistema é conseguir detetar rapidamente as ações derivadas do padrão normal. Informações como o número de pedidos de início de sessão falhados e/ou com êxito podem ser apresentadas visualmente para ajudar a detetar se existe um pico de atividade numa hora invulgar. (Um exemplo desta atividade é os utilizadores iniciarem sessão às 3:00 e efetuarem um elevado número de operações quando o dia de trabalho começa às 9:00). Estas informações também podem ser utilizadas para ajudar a configurar o dimensionamento automático baseado no tempo. Por exemplo, se um operador observar que um elevado número de utilizadores inicia sessão regularmente a uma determinada hora do dia, pode iniciar serviços de autenticação adicionais para processar o volume de trabalho e, em seguida, encerrar estes serviços adicionais quando o pico tiver passado.

Requisitos para origens de dados, instrumentação e recolha de dados

A segurança é um aspeto que abrange a maioria dos sistemas distribuídos. É provável que os dados pertinentes sejam gerados em múltiplos pontos num sistema. Deve considerar adotar uma abordagem de Gestão de Informações e Eventos de Segurança (SIEM) para reunir as informações relacionadas com segurança resultantes dos eventos gerados pela aplicação, equipamento de rede, servidores, firewalls, software antivírus e outros elementos de prevenção contra intrusões.

A monitorização de segurança pode incorporar dados de ferramentas que não fazem parte da sua aplicação. Estas ferramentas podem incluir utilitários que identificam atividades de análise de portas de agências externas ou filtros de rede que detetam as tentativas de obter acesso não autenticado às suas aplicações e dados.

Em todos os casos, os dados recolhidos têm de permitir a um administrador determinar a natureza de qualquer ataque e tomar as medidas preventivas adequadas.

Analisar os dados de segurança

Uma funcionalidade de monitorização de segurança é a variedade de origens dos dados. Os diferentes formatos e o nível de detalhe requerem muitas vezes uma análise complexa dos dados capturados para serem associados a um thread coerente de informações. Além dos casos mais simples (como detetar um elevado número de inícios de sessão falhados ou tentativas repetidas para obter acesso não autorizado a recursos críticos), pode não ser possível efetuar qualquer processamento automatizado complexo de dados de segurança. Em vez disso, pode ser preferível escrever estes dados, com carimbo de data/hora, mas de outra forma na sua forma original, num repositório seguro para permitir a análise manual de especialistas.

Monitorização de SLAs

Muitos sistemas comerciais que suportam clientes pagantes garantem o desempenho do sistema sob a forma de SLAs. Essencialmente, os SLAs indicam que o sistema consegue processar um volume definido de trabalho num intervalo de tempo definido e sem perda de informações importantes. A monitorização de SLAs pretende garantir que o sistema consegue cumprir SLAs mensuráveis.

Os SLAs são muitas vezes definidos em termos de:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode garantir que o sistema estará disponível 99,9% do tempo. Isto equivale a não mais do que 9 horas de período de indisponibilidade por ano ou cerca de 10 minutos por semana.
• Débito operacional. Este aspeto é frequentemente expresso como um ou mais limites máximos, como garantir que o sistema consegue suportar até 100 000 pedidos de utilizador em simultâneo ou processar 10 000 transações comerciais em simultâneo.
• Tempo de resposta operacional. O sistema também pode garantir a velocidade a que os pedidos são processados. Um exemplo é que 99 por cento de todas as transações comerciais serão concluídas em 2 segundos e nenhuma transação única irá demorar mais de 10 segundos.

Requisitos para monitorização de SLAs

No nível mais elevado, um operador deve conseguir determinar rapidamente se o sistema está a cumprir os SLAs definidos ou não. Caso contrário, o operador deve desagregar e examinar os fatores subjacentes para determinar as razões para um desempenho inadequado.

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

• A percentagem de tempo de atividade do serviço.
• O débito da aplicação (medido em termos de transações com êxito e/ou operações por segundo).
• O número de pedidos da aplicação com êxito/falhados.
• O número de falhas, exceções e avisos da aplicação e do sistema.

Deve ser possível filtrar todos estes indicadores por um período de tempo especificado.

Uma aplicação na cloud englobará provavelmente vários subsistemas e componentes. Um operador deve conseguir selecionar um indicador de alto nível e ver como é constituído a partir do estado de funcionamento dos elementos subjacentes. Por exemplo, se o tempo de atividade do sistema global estiver abaixo de um valor aceitável, um operador deve conseguir ampliar e determinar os elementos que estão a contribuir para esta falha.

Para fins de alerta, o sistema deve conseguir gerar um evento se qualquer um dos indicadores de alto nível exceder um limiar especificado. Os detalhes de nível inferior dos diversos fatores que compõem o indicador de alto nível devem estar disponíveis como dados contextuais para o sistema de alerta.

Requisitos para origens de dados, instrumentação e recolha de dados

Os dados não processados necessários para suportar a monitorização de SLAs são semelhantes aos dados não processados necessários para a monitorização de desempenho, juntamente com alguns aspetos da monitorização do estado de funcionamento e da disponibilidade. (Consulte essas secções para obter mais detalhes.) Pode capturar estes dados ao:

• Efetuar uma monitorização de pontos finais.
• Exceções de registo, falhas e avisos.
• Rastrear a execução de pedidos de utilizador.
• Monitorizar a disponibilidade de quaisquer serviços de terceiros utilizados pelo sistema.
• Utilizar contadores e métricas de desempenho.

Todos os dados têm de ser cronometrados e carimbos de data/hora.

Analisar os dados de SLA

Os dados de instrumentação têm de ser agregados para gerar uma imagem do desempenho global do sistema. Os dados agregados também têm de suportar a desagregação para permitir a verificação do desempenho dos subsistemas subjacentes. Por exemplo, deverá conseguir:

• Calcular o número total de pedidos de utilizador durante um período especificado e determinar a taxa de êxito e falha destes pedidos.
• Combinar os tempos de resposta dos pedidos de utilizador para gerar uma vista geral dos tempos de resposta do sistema.
• Analisar o progresso dos pedidos de utilizador para dividir o tempo de resposta global de um pedido por tempos de resposta dos itens de trabalho individuais nesse pedido.
• Determinar a disponibilidade geral do sistema como uma percentagem do tempo de atividade para qualquer período específico.
• Analisar a disponibilidade do tempo de percentagem dos serviços e componentes individuais no sistema. Isto pode envolver a análise de registos gerados por serviços de terceiros.

Muitos sistemas comerciais precisam de comunicar números de desempenho reais relativamente aos SLAs definidos durante um período especificado, normalmente um mês. Estas informações podem ser utilizadas para calcular créditos ou outras formas de reembolso para os clientes se os SLAs não forem cumpridos durante esse período. Pode calcular a disponibilidade de um serviço através da técnica descrita na secção Analisar os dados de disponibilidade.

Para fins internos, uma organização pode também controlar o número e a natureza dos incidentes que causaram a falha dos serviços. Aprender a resolver rapidamente estes problemas, ou a eliminá-los completamente, irá ajudar a reduzir o período de indisponibilidade e a cumprir os SLAs.

Auditoria

Consoante a natureza da aplicação, podem existir regulamentos estatutários ou legais que especifiquem os requisitos de auditoria das operações dos utilizadores e do registo de acesso a todos os dados. A auditoria pode fornecer provas que liguem os clientes a pedidos específicos. A não auditoria é 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 pela aplicação ou serviço.

Requisitos para auditoria

Um analista tem de conseguir rastrear a sequência de operações comerciais que os utilizadores estão a efetuar para que possa reconstruir as ações dos utilizadores. Isto pode ser simplesmente uma questão de registo ou ser parte de uma investigação forense.

As informações de auditoria são altamente confidenciais. Provavelmente incluirão dados que identificam os utilizadores do sistema, juntamente com as tarefas que estão a efetuar. Por este motivo, as informações de auditoria irão provavelmente assumir a forma de relatórios que só estão disponíveis para analistas fidedignos e não como um sistema interativo que suporte a desagregação de operações gráficas. Um analista deve conseguir gerar uma série de relatórios. Por exemplo, os relatórios podem listar todas as atividades dos utilizadores que ocorram durante um período de tempo especificado, detalhar a cronologia da atividade de um único utilizador ou listar a sequência de operações executadas relativamente a um ou mais recursos.

Requisitos para origens de dados, instrumentação e recolha de dados

As principais origens de informações de auditoria podem incluir:

• O sistema de segurança que gere a autenticação de utilizadores.
• Registos de rastreio que registam a atividade dos utilizadores.
• Registos de segurança que controlam todos os pedidos de rede identificáveis e não identificáveis.

O formato dos dados de auditoria e a forma como estão armazenados podem ser orientados por requisitos regulamentares. Por exemplo, pode não ser possível limpar os dados de qualquer forma. (Tem de ser registado no formato original.) O acesso ao repositório onde é mantido tem de ser protegido para impedir a adulteração.

Analisar os dados de auditoria

Um analista tem de conseguir aceder integralmente aos dados não processados no formato original. Além do requisito para gerar relatórios de auditoria comuns, as ferramentas para analisar estes dados são provavelmente especializadas e mantidas fora do sistema.

Monitorização da utilização

A monitorização da utilização controla a forma como são utilizadas as funcionalidades e os componentes de uma aplicação. Um operador pode utilizar os dados recolhidos para:

• Determinar as funcionalidades mais utilizadas e quaisquer hotspots potenciais no sistema. Os elementos de tráfego elevado podem beneficiar da criação de partições funcionais ou mesmo da replicação para propagar a carga mais uniformemente. Um operador também pode utilizar estas informações para determinar as funcionalidades menos utilizadas e possíveis candidatas a extinção ou substituição numa versão futura do sistema.

• Obter informações sobre os eventos operacionais do sistema em utilização normal. Por exemplo, num site de comércio eletrónico, pode registar as informações estatísticas sobre o número de transações e o volume de clientes responsáveis pelas mesmas. Estas informações podem ser utilizadas no planeamento da capacidade à medida que o número de clientes aumenta.

• Detetar (possivelmente de forma indireta) a satisfação do utilizador com o desempenho ou a funcionalidade do sistema. Por exemplo, se um elevado número de clientes num sistema de comércio eletrónico abandonar regularmente os carrinhos de compras, isto pode dever-se a um problema com a funcionalidade de finalização da compra.

• Gerar informações de faturação. Uma aplicação comercial ou um serviço multi-inquilino podem cobrar os recursos utilizados pelos clientes.

• Impor quotas. Se um utilizador num sistema multi-inquilino exceder a quota paga de tempo de processamento ou de utilização de recursos durante um período especificado, o acesso ou o processamento podem ser limitados.

Requisitos para monitorização da utilização

Para examinar a utilização do sistema, um operador precisa normalmente de ver informações que incluam:

• O número de pedidos processados por cada subsistema e direcionados para cada recurso.
• O trabalho que cada utilizador está a efetuar.
• O volume de armazenamento de dados que cada utilizador ocupa.
• Os recursos a que cada utilizador está a aceder.

Um operador também deve conseguir gerar gráficos. Por exemplo, um gráfico pode apresentar os utilizadores com mais falta de recursos, bem como as funcionalidades do sistema ou os recursos acedidos mais frequentemente.

Requisitos para origens de dados, instrumentação e recolha de dados

O controlo da utilização pode ser efetuado a um nível relativamente elevado. Pode anotar as horas de início e de fim de cada pedido e a natureza do pedido (leitura, escrita, etc., consoante o recurso em questão). Pode obter estas informações ao:

• Rastrear a atividade do utilizador.
• Capturar os contadores de desempenho que medem a utilização de cada recurso.
• Monitorizar o consumo de recursos por cada utilizador.

Para efeitos de medição, também tem de conseguir identificar que utilizadores são responsáveis por realizar as operações e os recursos que estas operações utilizam. As informações recolhidas devem ser suficientemente detalhadas para permitir uma faturação exata.

Controlo de problemas

Os clientes e outros utilizadores podem comunicar problemas se ocorrerem eventos ou comportamentos inesperados no sistema. O controlo de problemas pretende gerir estes problemas, associá-los a esforços para resolver quaisquer problemas subjacentes no sistema e informar os clientes de possíveis resoluções.

Requisitos para controlo de problema

Os operadores efetuam frequentemente o controlo de problemas através da utilização de um sistema separado que lhes permite registar e comunicar os detalhes dos problemas reportados pelos utilizadores. Estes detalhes podem incluir as tarefas que o utilizador estava a tentar efetuar, sintomas do problema, a sequência de eventos e quaisquer mensagens de erro ou aviso emitidas.

Requisitos para origens de dados, instrumentação e recolha de dados

A origem de dados inicial do controlo de problemas é o utilizador que comunicou o problema primeiro. O utilizador pode fornecer dados adicionais, tais como:

• Informação de falha de sistema (se a aplicação incluir um componente executado no ambiente de trabalho do utilizador).
• Um instantâneo do ecrã.
• A data e a hora em que ocorreu o erro, bem como outras informações ambientais, como a localização do utilizador.

Estas informações podem ser utilizadas para ajudar no esforço de depuração e na criação de um registo de tarefas pendentes para versões futuras do software.

Analisar os dados de controlo de problemas

Diferentes utilizadores podem comunicar o mesmo problema. O sistema de controlo de problemas deve associar os relatórios comuns.

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

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

Rastrear as operações e depurar as versões de software

Quando um utilizador comunica um problema, muitas vezes o utilizador só tem conhecimento do efeito imediato que tem nas suas operações. O utilizador pode apenas informar os resultados da sua própria experiência a um operador responsável pela manutenção do sistema. Normalmente, estas experiências são apenas um sintoma visível de um ou mais problemas fundamentais. Em muitos casos, um analista terá de analisar a cronologia das operações subjacentes para estabelecer a causa raiz do problema. Este processo é denominado análise da causa raiz.

Requisitos para rastreio e depuração

Para rastrear eventos inesperados e outros problemas, é vital que os dados de monitorização forneçam informações suficientes para permitir a um analista rastrear as origens destes problemas e reconstruir a sequência de eventos que ocorreram. Estas informações devem ser suficientes para permitir a um analista diagnosticar a causa de raiz de quaisquer problemas. Em seguida, um programador pode efetuar as modificações necessárias para evitar que se repitam.

Requisitos para origens de dados, instrumentação e recolha de dados

A resolução de problemas pode envolver o rastreio de todos os métodos (e dos respetivos parâmetros) invocados como parte de uma operação para criar uma árvore com o fluxo lógico através do sistema quando um cliente faz um pedido específico. As exceções e os avisos gerados pelo sistema como resultado deste fluxo têm de ser capturados e registados.

Para suportar a depuração, o sistema pode fornecer hooks que permitem a um operador capturar as informações de estado em pontos fundamentais no sistema. Em alternativa, o sistema pode fornecer informações passo a passo detalhadas à 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 utiliza este processo principalmente quando ocorre uma série de eventos bastante invulgar e é difícil replicar ou quando uma nova versão de um ou mais elementos num sistema requer uma monitorização cuidadosa para garantir que os elementos funcionam conforme esperado.

Pipeline de monitorização 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 de forma isolada. É provável que seja uma sobreposição significativa nos dados de monitorização e diagnóstico necessários para cada situação, embora estes dados possam ter de ser processados e apresentados de formas diferentes. Por estes motivos, deve ter uma vista holística da monitorização e diagnóstico.

Pode prever todo o processo de monitorização e diagnóstico como um pipeline que abrange as fases mostradas na Figura 1.

Figura 1 – as fases no pipeline de monitorização e diagnóstico.

A Figura 1 realça como os dados de monitorização e diagnóstico podem ser provenientes de várias origens de dados. As fases de instrumentação e recolha pretendem identificar as origens de onde os dados têm de ser capturados, determinar os dados a capturar, como capturá-los e como formatá-los para que possam ser facilmente examinados. A fase de análise/diagnóstico utiliza os dados não processados para gerar informações importantes que um operador pode utilizar para determinar o estado do sistema. O operador pode utilizar estas informações para tomar decisões sobre as possíveis ações a efetuar e, em seguida, colocar os resultados novamente nas fases de instrumentação e recolha. A fase de fase de visualização/alerta apresenta uma vista consumível do estado do sistema. Pode apresentar informações praticamente em tempo real através de uma série de dashboards. Pode ainda gerar relatórios e gráficos para fornecer uma vista histórica dos dados que podem ajudar a identificar tendências a longo prazo. Se as informações indicarem que é provável que um KPI exceda os limites aceitáveis, esta fase também pode acionar um alerta para um operador. Em alguns casos, um alerta também pode ser utilizado para acionar um processo automatizado que tenta efetuar ações corretivas como, por exemplo, o dimensionamento automático.

Tenha em atenção que estes passos constituem um processo de fluxo contínuo em que as fases ocorrem em paralelo. Idealmente, todas as fases devem ser configuráveis dinamicamente. Em alguns momentos, especialmente quando um sistema foi implementado recentemente ou está com problemas, pode ser necessário recolher dados expandidos com mais frequência. Noutros casos, deve ser possível voltar a capturar um nível base de informações essenciais para verificar se o sistema está a funcionar corretamente.

Além disso, todo o processo de monitorização deve ser considerado uma solução contínua em direto sujeita a otimizações e melhoramentos em resultado dos comentários. Por exemplo, pode começar por medir vários fatores para determinar o estado de funcionamento do sistema. A análise ao longo do tempo pode originar um aperfeiçoamento quando ignora medidas que não são relevantes, o que lhe permite concentrar-se de forma mais precisa nos dados de que precisa enquanto minimiza o ruído de fundo.

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

As informações utilizadas pelo processo de monitorização podem ter várias origens, conforme ilustrado na Figura 1. Ao nível da aplicação, as informações provêm de registos de rastreio incorporados no código do sistema. Os programadores devem seguir uma abordagem padrão para monitorizar o fluxo de controlo através do respetivo código. Por exemplo, uma entrada para um método pode emitir uma mensagem de rastreio que especifica o nome do método, a hora atual, o valor de cada parâmetro e outras informações pertinentes. O registo das horas de entrada e saída também pode ser útil.

Deve registar todas as exceções e avisos, e assegurar que mantém um rastreio completo de quaisquer exceções e avisos aninhados. Idealmente, deve também capturar as informações que identificam o utilizador que está a executar o código, juntamente com as informações de correlação da atividade (para controlar os pedidos à medida que passam pelo sistema). Deve ainda registar as tentativas de acesso a todos os recursos, tais como filas de mensagens, bases de dados, ficheiros e outros serviços dependentes. Estas informações podem ser utilizadas para fins de medição e auditoria.

Muitas aplicações utilizam bibliotecas e arquiteturas para realizar tarefas comuns, como aceder a um arquivo de dados ou comunicar através de uma rede. Estas estruturas podem ser configuráveis para fornecer as suas próprios mensagens de rastreio e informações de diagnóstico não processadas, por exemplo, velocidades de transação e êxitos e falhas da transmissão de dados.

O sistema operativo em que a aplicação está em execução pode ser uma origem de informações de baixo nível de todo sistema, como os contadores de desempenho que indicam as taxas de E/S, a utilização da memória e a utilização da CPU. Também podem ser comunicados erros do sistema operativo (por exemplo, não conseguir abrir um ficheiro corretamente).

Deve também considerar a infraestrutura e os componentes subjacentes em que o sistema é executado. Máquinas virtuais, redes virtuais e serviços de armazenamento podem ser origens de contadores de desempenho importantes ao nível da infraestrutura e outros dados de diagnóstico.

Se a sua aplicação utilizar outros serviços externos, como um servidor Web ou o sistema de gestão de base de dados, estes serviços podem publicar as suas próprias informações de rastreio, registos e contadores de desempenho. Os exemplos incluem Vistas de Gestão Dinâmica do SQL Server para controlar as operações efetuadas em relação a uma base de dados do SQL Server e registos de rastreio do IIS para registar os pedidos efetuados a um servidor Web.

À medida que os componentes de um sistema são modificados e são implementadas novas versões, é importante conseguir atribuir problemas, eventos e métricas a cada versão. Estas informações devem ser novamente associadas ao pipeline de versões para que os problemas com uma versão específica de um componente possam ser controlados e retificados rapidamente.

Podem ocorrer problemas de segurança em qualquer momento no sistema. Por exemplo, um utilizador pode tentar iniciar sessão com um ID ou palavra-passe de utilizador inválidos. Um utilizador autenticado pode tentar obter acesso não autorizado a um recurso. Ou um utilizador pode fornecer uma chave inválida ou desatualizada para aceder a informações encriptadas. As informações relacionadas com a segurança de pedidos com êxito ou falhados devem ser sempre registadas.

A secção Instrumentar uma aplicação contém mais orientações sobre as informações que deve capturar. No entanto, pode utilizar várias estratégias para recolher estas informações:

• Monitorização de aplicações/sistema. Esta estratégia utiliza origens internas na aplicação, estruturas de aplicações, sistema operativo e infraestrutura. O código da aplicação pode gerar os seus próprios dados de monitorização em pontos relevantes durante o ciclo de vida de um pedido de cliente. A aplicação pode incluir declarações de rastreio que podem ser ativadas ou desativadas seletivamente conforme as circunstâncias definirem. Também poderá ser possível inserir o diagnóstico dinamicamente através de uma estrutura de diagnóstico. Estas estruturas fornecem normalmente plug-ins que podem ligar a vários pontos de instrumentação no código e capturar dados de rastreio nos mesmos.

  Além disso, o código e/ou a infraestrutura subjacente pode gerar eventos em pontos críticos. Os agentes de monitorização configurados para escutarem estes eventos podem registar as informações de eventos.

• Monitorização real de utilizadores. Esta abordagem regista as interações entre um utilizador e a aplicação, e situa o fluxo de cada pedido e resposta. Estas informações podem ter um duplo objetivo: podem ser utilizadas para medir a utilização de cada utilizador e determinar se os utilizadores estão a receber uma qualidade de serviço adequada (por exemplo, tempos de resposta rápidos, baixa latência e erros mínimos). Pode utilizar os dados capturados para identificar as áreas de preocupação onde as falhas ocorrem com mais frequência. Também pode utilizar os dados para identificar os elementos onde o sistema se torna lento, possivelmente devido a hotspots na aplicação ou outra forma de estrangulamento. Se implementar esta abordagem cuidadosamente, poderá ser possível reconstruir os fluxos dos utilizadores através da aplicação para fins de depuração e teste.

  Importante

  Deve considerar os dados capturados pela monitorização real de utilizadores como altamente confidenciais, uma vez que podem incluir material confidencial. Se guardar os dados capturados, armazene-os em segurança. Se quiser utilizar os dados para monitorização ou depuração de desempenho, remova primeiro todas as informações pessoais.

• Monitorização de utilizador sintético. Nesta abordagem, escreve o seu próprio cliente de teste que simula um utilizador e efetua uma série de operações configuráveis mas típicas. Pode controlar o desempenho do cliente de teste para ajudar a determinar o estado do sistema. Também pode utilizar várias instâncias do cliente de teste como parte de uma operação de teste de carga para estabelecer a forma como o sistema responde em esforço e que tipo de monitorização de saída é gerado sob estas condições.

  Nota

  Pode implementar a monitorização real e sintética de utilizadores, incluindo o código que rastreia e temporiza a execução de chamadas de métodos e outras partes críticas de uma aplicação.

• Criação de perfis. Esta abordagem é direcionada principalmente para monitorização e melhoramento do desempenho da aplicação. Em vez de ser aplicada ao nível funcional da monitorização real e sintética de utilizadores, captura informações de baixo nível durante a execução da aplicação. Pode implementar a criação de perfis através de uma amostragem periódica do estado de execução de uma aplicação (determinar o fragmento de código que a aplicação está a executar num determinado ponto no tempo). Também pode utilizar a instrumentação, a qual insere sondas no código em junções importantes (por exemplo, no início e no fim de uma chamada de método) e regista os métodos invocados, em que altura e quanto tempo demorou cada chamada. Em seguida, pode analisar estes dados para determinar que partes da aplicação podem causar problemas de desempenho.

• Monitorização de pontos finais. Esta técnica utiliza um ou mais pontos finais de diagnóstico que a aplicação expõe especificamente para permitir a monitorização. Um ponto final fornece um caminho para o código da aplicação e pode devolver informações sobre o estado de funcionamento do sistema. Pontos finais diferentes podem concentrar-se em vários aspetos da funcionalidade. Pode escrever o seu próprio cliente de diagnóstico que envia pedidos periódicos para estes pontos finais e assimilar as respostas. Para obter mais informações, veja o padrão Monitorização do Ponto Final de Estado de Funcionamento.

Para obter a máxima cobertura, deve utilizar uma combinação destas técnicas.

Instrumentar uma aplicação

A instrumentação é uma parte crucial do processo de monitorização. Apenas pode tomar decisões importantes sobre o desempenho e o estado de funcionamento de um sistema se capturar primeiro os dados que lhe permitem tomar estas decisões. As informações recolhidas através de instrumentação devem ser suficientes para permitir avaliar o desempenho, diagnosticar problemas e tomar decisões sem necessidade de iniciar sessão num servidor de produção remoto para efetuar o rastreio (e a depuração) manualmente. Normalmente, os dados de instrumentação são compostos por métricas e informações escritas nos registos de rastreio.

O conteúdo de um registo de rastreio pode ser o resultado de dados textuais escritos pela aplicação ou dados binários criados como resultado de um evento de rastreio (se a aplicação estiver a utilizar o Rastreio de Eventos para o Windows – ETW). Também podem ser gerados a partir de registos do sistema que registam os eventos resultantes de partes da infraestrutura, como um servidor Web. As mensagens de registo textuais foram concebidas para serem legíveis por humanos, mas também devem ser escritas num formato que permita a um sistema automatizado analisá-las facilmente.

Assim, deve categorizar os registos. Não escreva todos os dados de rastreio num único registo e utilize registos separados para registar os resultados de rastreio de diferentes aspetos operacionais do sistema. Em seguida, pode filtrar rapidamente as mensagens de registo ao lê-las a partir do registo adequado em vez de ter de processar um único ficheiro demorado. Nunca escreva informações com diferentes requisitos de segurança (por exemplo, informações de auditoria e dados de depuração) no mesmo registo.

Geralmente, as métricas são uma medida ou contagem de algum aspeto ou recurso no sistema num momento específico, com uma ou mais etiquetas ou dimensões associadas (por vezes denominadas exemplo). Normalmente, uma única instância de uma métrica não é útil para isolamento. Em vez disso, as métricas têm de ser capturadas ao longo do tempo. O principal problema a ter em consideração é as métricas que deve registar e com que frequência. Gerar dados para métricas demasiadas vezes pode impor uma carga adicional significativa ao sistema, enquanto que capturar métricas com pouca frequência pode fazer perder as circunstâncias que originaram um evento significativo. As considerações variam consoante a métrica. Por exemplo, a utilização da CPU num servidor pode variar significativamente a cada segundo, mas uma elevada utilização é um problema apenas se for de longa duração.

Informações para correlacionar dados

Pode monitorizar facilmente contadores de desempenho individuais ao nível do sistema, capturar métricas para recursos e obter informações de rastreio de aplicações a partir de vários ficheiros de registo. No entanto, algumas formas de monitorização necessitam da fase de análise e diagnóstico no pipeline de monitorização para correlacionar os dados obtidos de várias origens. Estes dados podem assumir várias formas nos dados não processados e o processo de análise tem de ser fornecido com dados de instrumentação suficientes para que seja possível mapear estas formas diferentes. Por exemplo, ao nível da estrutura da aplicação, uma tarefa pode ser identificada por um ID de thread. Numa aplicação, o mesmo trabalho pode ser associado ao ID do utilizador que está a efetuar essa tarefa.

Além disso, é pouco provável ser um mapeamento de 1:1 entre threads e pedidos de utilizador, porque as operações assíncronas podem reutilizar os mesmos threads para efetuar operações em nome de mais do que um utilizador. Para dificultar ainda mais, um único pedido pode ser processado por mais de um thread como fluxos de execução no sistema. Se for possível, associe cada pedido com um ID de atividade exclusivo propagado pelo sistema como parte do contexto do pedido. (A técnica para gerar e incluir IDs de atividade nas informações de rastreio depende da tecnologia utilizada para capturar os dados de rastreio.)

Todos os dados de monitorização devem ser carimbos de data/hora da mesma forma. Por razões de consistência, registe todas as datas e horas através da Hora Universal Coordenada. Isto irá ajudá-lo a rastrear mais facilmente as sequências de eventos.

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

Quando estiver a decidir que dados de instrumentação tem de recolher, considere os seguintes pontos:

• Certifique-se de que as informações capturadas por eventos de rastreio são legíveis por máquinas e humanos. Adote esquemas bem definidos para estas informações para facilitar o processamento automatizado de dados de registo entre sistemas e fornecer consistência ao pessoal de operações e engenharia que vai ler os registos. Inclua informações ambientais, como o ambiente de implementação, a máquina em que o processo está em execução, os detalhes do processo e a pilha de chamadas.

• Ative a criação de perfis apenas quando for necessário, uma vez que pode impor uma sobrecarga significativa ao sistema. A criação de perfis com instrumentação regista um evento (por exemplo, uma chamada de método) sempre que este ocorrer, enquanto que a amostragem regista apenas determinados eventos. A seleção pode ser baseada no tempo (uma vez a cada n segundos) ou com base na frequência (uma vez a cada n pedidos). Se os eventos ocorrerem muito frequentemente, a criação de perfis por instrumentação pode provocar excesso de carga e afetar o desempenho global. Neste caso, poderá ser preferível a abordagem de amostragem. No entanto, se a frequência de eventos for baixa, a amostragem pode perdê-los. Neste caso, a instrumentação poderá ser a melhor abordagem.

• Forneça contexto suficiente para permitir a um programador ou administrador determinar a origem de cada pedido. Isto pode incluir alguma forma de ID da atividade que identifica uma instância específica de um pedido. Pode também incluir informações que podem ser utilizadas para correlacionar esta atividade com o trabalho computacional realizado e os recursos utilizados. Tenha em atenção que este trabalho pode ultrapassar os limites de processos e computadores. Para medição, o contexto também deverá incluir (direta ou indiretamente através de outras informações correlacionadas) uma referência ao cliente que efetuou o pedido. Este contexto fornece informações importantes sobre o estado da aplicação no momento em que os dados de monitorização foram capturados.

• Registe todos os pedidos e as localizações ou regiões a partir das quais estes pedidos são efetuados. Estas informações podem ajudar a determinar se existem hotspots específicos da localização. Estas informações também podem ser úteis para determinar se quer criar novas partições de uma aplicação ou dos dados que esta utiliza.

• Registe e capture cuidadosamente os detalhes de exceções. Muitas vezes, são perdidas informações de depuração críticas devido a um fraco processamento de exceções. Capture todos os detalhes de exceções emitidas pela aplicação, incluindo quaisquer exceções internas e outras informações de contexto. Inclua a pilha de chamadas, se possível.

• Seja consistente nos dados capturados pelos diferentes elementos da aplicação, porque pode ajudar a analisar eventos e a correlacioná-los com os pedidos de utilizador. Considere utilizar um pacote de registo abrangente e configurável para recolher informações, em vez de depender dos programadores para adotar a mesma abordagem à medida que implementam partes diferentes do sistema. Recolha dados dos contadores chave de desempenho, como o volume de E/S a efetuar, utilização da rede, número de pedidos, utilização da memória e utilização da CPU. Alguns serviços de infraestrutura podem fornecer os seus próprios contadores de desempenho específicos, como o número de ligações a uma base de dados, a velocidade a que as transações estão a ser efetuadas e o número de transações com êxito ou falhadas. As aplicações também podem definir os seus próprios contadores de desempenho específicos.

• Registe todas as chamadas efetuadas a serviços externos, como sistemas de base de dados, serviços Web ou outros serviços ao nível do sistema que fazem parte da infraestrutura. Registe as informações sobre o tempo necessário para efetuar cada chamada e o êxito ou falha da chamada. Se possível, capture informações sobre todas as tentativas e falhas de repetição para quaisquer erros transitórios que ocorram.

Garantir a compatibilidade com sistemas de telemetria

Em muitos casos, as informações produzidas pela instrumentação são geradas como uma série de eventos e transmitidas a um sistema de telemetria separado para processamento e análise. Geralmente, um sistema de telemetria é independente de qualquer aplicação ou tecnologia específica, mas espera que as informações sigam um formato específico normalmente definido por um esquema. O esquema especifica de forma eficiente um contrato que define os campos e tipos de dados que o sistema de telemetria pode ingerir. O esquema deve ser generalizado para permitir dados obtidos de várias plataformas e dispositivos.

Um esquema comum deve incluir campos 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 (por exemplo, um ID de utilizador, um ID de dispositivo e um ID de aplicação). Não se esqueça de que qualquer número de dispositivos pode acionar eventos, pelo que o esquema não deve depender do tipo de dispositivo. Além disso, vários dispositivos podem gerar eventos para a mesma aplicação; a aplicação pode suportar roaming ou outra forma de distribuição entre dispositivos.

O esquema também pode incluir campos de domínio relevantes para um determinado cenário comum entre diferentes aplicações. Podem ser informações sobre exceções, eventos de início e fim da aplicação, e êxito e/ou falha de chamadas de API do serviço Web. Todas as aplicações que utilizam o mesmo conjunto de campos de domínio devem emitir o mesmo conjunto de eventos, o que permite criar um conjunto de relatórios e análises comuns.

Por fim, um esquema pode conter campos personalizados para capturar os detalhes de eventos específicos da aplicação.

Melhores práticas para instrumentar aplicações

A lista seguinte resume as melhores práticas para instrumentar uma aplicação distribuída em execução na cloud.

• Facilite a leitura e a análise dos registos. Utilize registos estruturados sempre que possível. Seja conciso e descritivo nas mensagens de registo.

• Em todos os registos, identifique a origem e forneça informações de contexto e temporização à medida que é escrito cada registo.

• Utilize o mesmo fuso horário e formato para todos os carimbos de data/hora. Isto ajudará a correlacionar eventos para operações que abrangem o hardware e os serviços em execução em diferentes regiões geográficas.

• Categorize os registos e escreva mensagens no ficheiro de registo adequado.

• Não divulgue informações confidenciais sobre o sistema ou informações pessoais sobre os utilizadores. Limpe estas informações antes de serem registadas, mas certifique-se de que os detalhes relevantes são mantidos. Por exemplo, remova o ID e a palavra-passe de todas as cadeias de ligação da base de dados, mas escreva as restantes informações no registo para que um analista possa determinar se o sistema está a aceder à base de dados correta. Registe todas as exceções críticas, mas permita ao administrador ativar e desativar o registo para níveis inferiores de exceções e avisos. Além disso, capture e registe todas as informações lógicas de repetição. Estes dados podem ser úteis na monitorização do estado de funcionamento transitório do sistema.

• Rastreie fora das chamadas de processo, tais como pedidos a bases de dados ou serviços Web externos.

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

• À exceção dos eventos de auditoria, certifique-se de que todas as chamadas de registo são operações de "disparar e esquecer" que não bloqueiam o progresso das operações comerciais. Os eventos de auditoria são excecionais, uma vez que são essenciais para as empresas e podem ser classificados como uma parte fundamental das operações comerciais.

• Certifique-se de que o registo é extensível e não tem dependências diretas num destino concreto. Por exemplo, em vez de escrever as informações com System.Diagnostics.Trace, defina uma interface abstrata (como o ILogger) que exponha métodos de registo e possa ser implementada através de qualquer meio adequado.

• Certifique-se de que todos os registos estão isentos de falhas e nunca acionam erros em cascata. O registo não deve emitir quaisquer exceções.

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

Recolher e armazenar dados

A fase de recolha do processo de monitorização pretende obter as informações geradas pela instrumentação, formatar os dados para facilitar o consumo por parte da fase de análise/diagnóstico e guardar os dados transformados em armazenamento fiável. Os dados de instrumentação recolhidos de diferentes partes de um sistema distribuído podem ser mantidos em várias localizações e formatos diferentes. Por exemplo, o código da aplicação pode gerar ficheiros de registo de rastreio e dados de registo de eventos da aplicação, enquanto que os contadores de desempenho que monitorizam os aspetos fundamentais da infraestrutura utilizados pela aplicação podem ser capturados através de outras tecnologias. Quaisquer serviços e componentes de terceiros utilizados pela aplicação podem fornecer informações de instrumentação em diferentes formatos através de ficheiros de rastreio separados, do armazenamento de blobs ou até mesmo de um arquivo de dados personalizado.

A recolha de dados é frequentemente efetuada através de um serviço de recolha que pode ser executado de forma autónoma a partir da aplicação que gera os dados de instrumentação. A Figura 2 ilustra um exemplo desta arquitetura e realça o subsistema de recolha de dados de instrumentação.

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

Tenha em atenção que se trata de uma vista simplificada. O serviço de recolha não é necessariamente um processo único e pode englobar várias partes constituintes em execução em diferentes computadores, conforme descrito nas secções seguintes. Além disso, se a análise de alguns dados telemétricos tiver de ser executada rapidamente (análise frequente, conforme descrito na secção Suporte de análise frequente, pouco frequente e esporádica mais à frente neste documento), os componentes locais que funcionam fora do serviço de recolha podem executar as tarefas de análise imediatamente. A Figura 2 ilustra esta situação para determinados eventos. Após o processamento analítico, os resultados podem ser enviados diretamente para o subsistema de visualização e alerta. Os dados sujeitos a uma análise pouco frequente ou esporádica são mantidos no armazenamento enquanto aguardam o processamento.

Para aplicações e serviços do Azure, o Diagnóstico do Azure fornece uma solução possível para capturar dados. O Diagnóstico do Azure recolhe dados das seguintes origens para cada nó de computação, agrega-os e, em seguida, carrega-os para o Armazenamento do Azure:

• Registos do IIS
• Registos de Falha de Pedidos do IIS
• Registos de eventos do Windows
• Contadores de desempenho
• Informações de falha de sistema
• Registos da infraestrutura do Diagnóstico do Azure
• Registos de erros personalizados
• .NET EventSource
• ETW baseado no manifesto

Para obter mais informações, veja o artigo Azure: Noções Básicas de Telemetria e Resolução de Problemas.

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

Se tivermos em consideração a natureza elástica da cloud e para evitar a necessidade de obter manualmente dados telemétricos de cada nó no sistema, deve dispor os dados para serem transferidos para uma localização central e consolidada. Num sistema que abranja vários datacenters, poderá ser útil primeiro recolher, consolidar e armazenar os dados região a região e, em seguida, agregar os dados regionais num único sistema central.

Para otimizar a utilização da largura de banda, pode optar por transferir os dados menos urgentes em segmentos, como lotes. No entanto, os dados não podem ser atrasados indefinidamente, sobretudo se contiverem informações sensíveis ao tempo.

Extrair e enviar dados de instrumentação

O subsistema de recolha de dados de instrumentação pode obter ativamente dados de instrumentação a partir de vários registos e outras origens para cada instância da aplicação (o modelo de extração). Também pode agir como um recetor passivo que aguarda que os dados sejam enviados a partir dos componentes que constituem cada instância da aplicação (o modelo de envio).

Uma abordagem para implementar o modelo de extração é utilizar agentes de monitorização executados localmente com cada instância da aplicação. Um agente de monitorização é um processo separado que obtém (extrai) periodicamente dados telemétricos recolhidos no nó local e escreve estas informações diretamente no armazenamento centralizado partilhado por todas as instâncias da aplicação. Este é o mecanismo que implementa o Diagnóstico do Azure. Cada instância de uma função Web ou de trabalho do Azure pode ser configurada para capturar dados de diagnóstico e outras informações de rastreio armazenadas localmente. O agente de monitorização executado em conjunto com cada instância copia os dados especificados para o Armazenamento do Azure. O artigo Ativar Diagnósticos nos Serviços Cloud e Máquinas Virtuais do Azure fornece mais detalhes sobre este processo. Alguns elementos, como registos do IIS, informações de falha de sistema e registos de erros personalizados, são escritos no armazenamento de blobs. Os dados do registo de eventos do Windows, eventos do ETW e contadores de desempenho são registados no armazenamento de tabelas. A Figura 3 ilustra este mecanismo.

Figura 3 – utilizar um agente de monitorização para solicitar informações e escrever no armazenamento partilhado.

É possível utilizar a abordagem descrita acima para armazenar dados telemétricos para uma aplicação em pequena escala em execução num número limitado de nós numa única localização. No entanto, uma aplicação na cloud global complexa e altamente dimensionável pode gerar grandes volumes de dados de centenas de funções Web e de trabalho, shards de base de dados e outros serviços. Esta grande quantidade de dados pode sobrecarregar facilmente a largura de banda de E/S disponível numa única localização central. Por conseguinte, a solução de telemetria tem de ser dimensionável para impedi-la de ser um estrangulamento à medida que o sistema se expande. O ideal é a solução incorporar um grau de redundância para reduzir os riscos de perda de informações de monitorização importantes (como dados de auditoria ou de faturação) se parte do sistema falhar.

Para resolver estes problemas, pode implementar a colocação em fila, conforme mostrado na Figura 4. Nesta arquitetura, o agente de monitorização local (se puder ser configurado corretamente) ou o serviço de recolha de dados personalizado (caso contrário) publica os dados numa fila. Um processo separado em execução no modo assíncrono (o serviço de escrita de armazenamento na Figura 4) aceita os dados nesta fila e escreve-os no armazenamento partilhado. Uma fila de mensagens é adequada para este cenário, porque fornece a semântica "pelo menos uma vez" que ajuda a garantir que os dados em fila não serão perdidos depois de serem publicados. Pode implementar o serviço de escrita de armazenamento ao utilizar uma função de trabalho separada.

Figura 4 - Utilizar uma fila para colocar dados de instrumentação em memória intermédia.

O serviço de recolha de dados local pode adicionar dados a uma fila imediatamente depois de serem recebidos. A fila funciona como uma memória intermédia e o serviço de escrita de armazenamento pode obter e escrever os dados ao seu próprio ritmo. Por predefinição, uma fila funciona numa base first in, first out. No entanto, pode atribuir prioridades às mensagens para acelerá-las na fila se contiverem dados que tenham de ser processados mais rapidamente. Para obter mais informações, veja o padrão Fila de Prioridade. Em alternativa, pode utilizar diferentes canais (como tópicos do Service Bus) para direcionar os dados para diversos destinos, consoante a forma de processamento analítico necessária.

Para escalabilidade, pode executar várias instâncias do serviço de escrita de armazenamento. Se existir um grande volume de eventos, pode utilizar um hub de eventos para distribuir os dados por diversos recursos de computação para processamento e armazenamento.

Consolidar dados de instrumentação

Os dados de instrumentação obtidos pelo serviço de recolha de dados a partir de uma única instância de uma aplicação fornece uma vista localizada do estado de funcionamento e do desempenho dessa instância. Para avaliar o estado de funcionamento geral do sistema, é necessário consolidar alguns aspetos dos dados nas vistas locais. Pode efetuar este procedimento após o armazenamento dos dados, mas em alguns casos, pode também fazê-lo durante a recolha dos dados. Em vez de serem escritos diretamente no armazenamento partilhado, os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combina os dados e age 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 utilizador comece a executar uma operação empresarial num nó e, em seguida, seja transferido para outro nó em caso de falha do nó ou consoante a forma como o balanceamento de carga está configurado.) Este processo também pode detetar e remover quaisquer dados duplicados (sempre uma possibilidade se o serviço de telemetria utilizar filas de mensagens para enviar dados de instrumentação para o armazenamento). A Figura 5 ilustra um exemplo desta estrutura.

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

Armazenar dados de instrumentação

Os debates anteriores têm apresentado uma vista mais simplista do modo de armazenamento dos dados de instrumentação. Na realidade, pode fazer sentido armazenar os diferentes tipos de informações através da utilização de tecnologias mais adequadas à forma como é provável que cada tipo vá ser utilizado.

Por exemplo, o armazenamento de blobs e tabelas do Azure tem algumas semelhanças com a forma como são acedidos. No entanto, têm limitações nas operações que podem efetuar ao utilizá-los e a granularidade dos dados que contê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 registos de rastreio podem ser melhor armazenados no Azure Cosmos DB.
• As informações de segurança podem ser escritas no HDFS.
• As informações que requerem pesquisa em texto completo podem ser armazenadas através do Elasticsearch (o qual também acelera as pesquisas com indexação avançada).

Pode implementar um serviço adicional que obtenha periodicamente os dados a partir do armazenamento partilhado, crie partições e filtre os dados de acordo com o objetivo e, em seguida, os escreva num conjunto de arquivos de dados adequado, conforme mostrado na 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. Implementar um serviço de criação de partições separado reduz a carga sobre o serviço de consolidação e limpeza, e permite que pelo menos alguns dos dados particionados sejam regenerados se for necessário (consoante a quantidade de dados mantida no armazenamento partilhado). 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 – Criação de partições de 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, podem ser utilizados contadores de desempenho para fornecer uma vista 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. Nestas situações, podem ser enviados os mesmos dados para mais do que um destino, como uma base de dados de documentos que possa atuar como um arquivo de longo prazo de informações de faturação e um arquivo multidimensional para processamento de 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 alertas têm de ser acedidos rapidamente, pelo que devem ser mantidos num armazenamento de dados rápido e indexados ou estruturados para otimizar as consultas efetuadas pelo sistema de alerta. Em alguns casos, pode ser necessário que o serviço de telemetria recolha os dados em cada nó para formatá-los e guardá-los 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 utilizadas para análises mais consideradas, criação de relatórios e detetação de tendências históricas são menos urgentes e podem ser armazenadas de forma a suportarem extração de dados e consultas ad hoc. Para obter mais informações, veja a secção Suporte de análise frequente, pouco frequente e esporádica mais à frente neste documento.

Rotação do registo e retenção de dados

A instrumentação pode gerar volumes de dados consideráveis. Estes dados podem ser mantidos em vários locais, a começar pelos ficheiros de registo não processados, ficheiros de rastreio e outras informações capturadas em cada nó para a vista consolidada, limpa e particionada destes dados guardados no armazenamento partilhado. Em alguns casos, depois de os dados serem processados e transferidos, os dados não processados originais podem ser removidos de cada nó. Noutros casos, pode ser necessário ou simplesmente útil guardar as informações não processadas. Por exemplo, pode ser preferível disponibilizar os dados gerados para depuração no seu formato não processado, mas rejeitá-los rapidamente depois de os erros terem sido retificados.

Os dados de desempenho têm muitas vezes um período de tempo mais longo para que possam ser utilizados para detetar as tendências de desempenho e para planeamento da 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 de regulamentação podem ditar que as informações recolhidas para auditoria e segurança também têm de ser arquivadas e guardadas. Estes dados também são confidenciais e podem ter de ser encriptados ou protegidos para evitar adulteração. Nunca deve gravar as palavras-passe dos utilizadores ou outras informações que possam ser utilizadas para uma fraude de identidade. Esses detalhes devem ser limpos dos dados antes de serem armazenados.

Dimensionar

É útil armazenar dados históricos para detetar tendências a longo prazo. Em vez de guardar dados antigos, pode dimensionar os dados para reduzir a resolução e os custos de armazenamento. Por exemplo, em vez de guardar indicadores de desempenho minuto a minuto, pode consolidar os dados com mais de um mês para formar uma vista por hora.

Melhores práticas para recolher e armazenar informações de registo

A lista seguinte resume as melhores práticas para capturar e armazenar informações de registo:

• O agente de monitorização ou serviço de recolha de dados deve ser executado como um serviço fora do processo e ser fácil de implementar.

• Todos os resultados do agente de monitorização ou do serviço de recolha de dados devem estar num formato agnóstico independente do computador, sistema operativo ou protocolo de rede. Por exemplo, emita as informações num formato descrito automaticamente, como JSON, MessagePack ou Protobuf, em vez de ETL/ETW. A utilização de um formato padrão permite ao sistema criar pipelines de processamento. Os componentes que leem, transformam e enviam dados no formato definido podem ser facilmente integrados.

• O processo de monitorização e recolha de dados tem de estar isento de falhas e não deve acionar condições de erro em cascata.

• Se ocorrer uma falha transitória no envio de informações para um sink de dados, o agente de monitorização ou serviço de recolha de dados deve estar preparado para reordenar os dados telemétricos para que as informações mais recentes sejam enviadas primeiro. (O agente de monitorização/serviço de recolha de dados pode optar por remover os dados mais antigos ou guardá-los localmente e transmiti-los mais tarde, por sua decisão.)

Analisar dados e diagnosticar problemas

Uma parte importante do processo de monitorização e diagnóstico é analisar os dados recolhidos para obter uma ideia do funcionamento geral do sistema. Deve definir os seus próprios KPIs e métricas de desempenho, e é importante compreender como pode estruturar os dados que foram recolhidos para cumprir os seus requisitos de análise. É igualmente importante compreender como os dados capturados em diferentes métricas e ficheiros de registo estão correlacionados, uma vez que estas informações podem ser essenciais para controlar uma sequência de eventos e ajudar a diagnosticar problemas.

Conforme descrito na secção Consolidar dados de instrumentação, os dados de cada parte do sistema são normalmente capturados localmente, mas geralmente têm de ser combinados com dados gerados noutros locais do sistema. Estas informações requerem uma correlação cuidadosa para garantir que os dados são combinados com precisão. Por exemplo, os dados de utilização de uma operação podem abranger um nó que aloja um site ao qual um utilizador se liga, um nó que executa um serviço separado acedido como parte desta operação e o armazenamento de dados existente noutro nó. Estas informações precisam de ser associadas para fornecer uma vista geral da utilização dos recursos e do processamento da operação. Alguns pré-processamentos e filtragem de dados podem ocorrer no nó no qual os dados são capturados, enquanto a agregação e formatação são mais propensos a ocorrer num nó central.

Suporte de análise frequente, pouco frequente e esporádica

Analisar e reformatar os dados para visualização, criação de relatórios e alertas pode ser um processo complexo que consome o seu próprio conjunto de recursos. Algumas formas de monitorização são prementes e requerem uma análise imediata dos dados para serem eficazes. Isto é conhecido como análise frequente. Os exemplos incluem as análises necessárias para alertas e alguns aspetos da monitorização de segurança (como detetar um ataque no sistema). Os dados necessários para estes fins têm de ser disponibilizados e estruturados rapidamente para um processamento eficiente. Em alguns casos, pode ser necessário mover o processamento de análise para os nós individuais onde os dados são mantidos.

Outras formas de análise são menos prementes e podem requerer cálculo e agregação depois de os dados não processados terem sido recebidos. Isto é denominado análise pouco frequente. A análise de desempenho enquadra-se muitas vezes nesta categoria. Neste caso, é pouco provável que um evento de desempenho único isolado seja estatisticamente significativo. (Pode ser causado por um pico repentino ou falha.) Os dados de uma série de eventos devem fornecer uma imagem mais fiável do desempenho do sistema.

A análise pouco frequente também pode ser utilizada para ajudar a diagnosticar problemas do estado de funcionamento. Normalmente, um evento de estado de funcionamento é processado através da análise frequente e pode emitir imediatamente um alerta. Um operador deve conseguir analisar as razões do evento de estado de funcionamento ao examinar os dados a partir do caminho de acesso pouco frequente. Estes dados devem conter informações sobre os eventos que originaram o problema que causou o evento de estado de funcionamento.

Alguns tipos de monitorização geram dados mais a longo prazo. Esta análise pode ser efetuada numa data posterior, possivelmente de acordo com uma agenda predefinida. Em alguns casos, a análise pode ter de efetuar uma filtragem complexa de grandes volumes de dados capturados durante um certo período de tempo. Isto é denominado análise esporádica. O principal requisito é os dados serem armazenados em segurança depois de serem capturados. Por exemplo, a monitorização e auditoria da utilização requerem uma ideia exata do estado do sistema em pontos no tempo regulares, mas estas informações de estado não têm de ser disponibilizadas para serem processadas de imediato depois de serem recolhidas.

Um operador também pode utilizar a análise esporádica para fornecer os dados para análise preditiva do estado de funcionamento. O operador pode recolher informações históricas durante um período específico e utilizá-las em conjunto com os dados de estado de funcionamento atuais (obtidos a partir do caminho de acesso frequente) para detetar tendências que podem causar problemas de estado de funcionamento em breve. Nestes casos, pode ser necessário emitir um alerta para que possa ser efetuada uma ação corretiva.

Correlacionar dados

Os dados capturados pela instrumentação podem fornecer um instantâneo do estado do sistema, mas o objetivo da análise é tornar estes dados acionáveis. Por exemplo:

• O que causou um carregamento intenso de E/S ao nível do sistema num momento específico?
• É o resultado de um elevado número de operações da base de dados?
• Reflete-se nos tempos de resposta da base de dados, no número de transações por segundo e nos tempos de resposta da aplicação na mesma junção?

Se assim for, uma ação corretiva que consiga reduzir a carga pode ser distribuir os dados por mais servidores. Além disso, podem ocorrer exceções como resultado de uma falha em qualquer nível do sistema. Uma exceção num nível aciona frequentemente outra falha no nível acima.

Por estas razões, tem de conseguir correlacionar os diferentes tipos de dados em cada nível para produzir uma vista geral do estado do sistema e das aplicações em execução no mesmo. Em seguida, pode utilizar estas informações para tomar decisões sobre se o sistema está a funcionar ou não de forma aceitável e determinar o que pode ser feito para melhorar a qualidade do sistema.

Conforme descrito na secção Informações para correlacionar dados, tem de garantir que os dados de instrumentação não processados incluem informações de contexto e ID de atividade suficientes para suportar as agregações necessárias para correlacionar eventos. Além disso, estes dados podem ser mantidos em diferentes formatos e poderá ser necessário analisar estas informações para convertê-las num formato padronizado para análise.

Resolução de problemas e diagnosticar problemas

O diagnóstico requer a capacidade de determinar a causa das falhas ou do comportamento inesperado, incluindo efetuar uma análise da causa raiz. As informações necessárias incluem normalmente:

• Informações detalhadas de registos de eventos e rastreios, de todo o sistema ou de um subsistema especificado durante a janela de tempo indicada.
• Rastreios de pilha completos resultantes de exceções e falhas de qualquer nível especificado ocorridas no sistema ou num subsistema especificado durante o período de tempo indicado.
• Informações de falha de sistema de todos os processos falhados em qualquer local no sistema ou num subsistema especificado durante a janela de tempo indicada.
• Registos de atividade das operações efetuadas por todos os utilizadores ou pelos utilizadores selecionados durante um período de tempo especificado.

A análise de dados para resolução de problemas requer, muitas vezes, uma compreensão particularmente técnica sobre a arquitetura de sistema e os vários componentes que compõem a solução. Como resultado, é muitas vezes necessário um elevado grau de intervenção manual para interpretar os dados, estabelecer a causa dos problemas e recomendar uma estratégia adequada para resolvê-los. Pode ser adequado simplesmente armazenar uma cópia destas informações no formato original e disponibilizá-la para análise esporádica de um especialista.

Visualizar dados e gerar alertas

Um aspeto importante de qualquer sistema de monitorização é a capacidade de apresentar os dados de forma a que um operador consiga 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 precisar de atenção.

A apresentação de dados pode assumir várias formas, incluindo visualização através de dashboards, alertas e relatórios.

Visualização através de dashboards

A forma mais comum de visualizar dados consiste em utilizar dashboards que apresentam as informações como uma série de gráficos ou outra ilustração. Estes itens podem ser parametrizados e um analista deve conseguir selecionar os parâmetros importantes (como o período de tempo) para qualquer situação específica.

Os dashboards podem ser organizados hierarquicamente. Os dashboards de nível superior fornecem uma vista geral de cada aspeto do sistema, mas permitem a um operador desagregar os detalhes. Por exemplo, um dashboard que ilustra a E/S do disco geral do sistema deve permitir a um analista ver as velocidades de E/S de cada disco individual para determinar se um ou mais dispositivos têm um volume de tráfego desproporcionado. Idealmente, o dashboard deve também apresentar informações relacionadas, como a origem de cada pedido (o utilizador ou a atividade) que está a gerar esta E/S. Estas informações podem ser utilizadas para determinar se a carga deve ser distribuída mais uniformemente pelos dispositivos (e como), e se o sistema teria um melhor desempenho se fossem adicionados mais dispositivos.

Um dashboard também pode utilizar a codificação por cores ou outras ajudas visuais para indicar os valores que parecem anómalos ou que estão fora de um intervalo esperado. Utilizando o exemplo anterior:

• Um disco com uma velocidade de E/S que esteja a aproximar-se da capacidade máxima durante um período prolongado (um disco de acesso frequente) pode ser realçado a vermelho.
• Um disco com uma velocidade de E/S executado periodicamente no seu limite máximo durante períodos curtos (um disco de acesso pouco frequente) pode ser realçado a amarelo.
• Um disco que esteja a exibir uma utilização normal pode ser apresentado a verde.

Tenha em atenção que, para um sistema de dashboard funcionar de forma eficaz, tem de utilizar os dados não processados. Se estiver a criar o seu próprio sistema de dashboard ou a utilizar um dashboard desenvolvido por outra organização, tem de compreender quais os dados de instrumentação que tem de recolher, a que níveis de granularidade e como deve ser formatado para o dashboard a consumir.

Um bom dashboard não só apresenta informações, mas também permite a um analista fazer perguntas ad hoc sobre essas informações. Alguns sistemas fornecem ferramentas de gestão que um operador pode utilizar para efetuar estas tarefas e explorar os dados subjacentes. Em alternativa, consoante o repositório utilizado para armazenar estas informações, pode ser possível consultar estes dados diretamente ou importá-los para ferramentas, como o Microsoft Excel, para análise e relatórios.

Gerar alertas

Os alertas são o processo de analisar os dados de monitorização e instrumentação, e gerar uma notificação se for detetado um evento significativo.

Os alertas ajudam a garantir que o sistema permanece num bom estado de funcionamento, com capacidade de resposta e seguro. É uma parte importante de qualquer sistema que garante o desempenho, a disponibilidade e a privacidade aos utilizadores onde os dados possam ter de ser analisados imediatamente. Um operador pode ter de ser notificado do evento que acionou o alerta. Os alertas também podem ser utilizados para invocar funções do sistema, como o dimensionamento automático.

Normalmente, os alertas dependem dos dados de instrumentação seguintes:

• Eventos de segurança. Se os registos de eventos indicarem que estão a ocorrer falhas de autenticação e/ou autorização repetidas, o sistema pode estar a ser atacado e um operador deve ser informado.
• Métricas de desempenho. O sistema tem de responder rapidamente se uma métrica de desempenho específica exceder um limiar especificado.
• Informações de disponibilidade. Se for detetada uma falha, pode ser necessário reiniciar rapidamente um ou mais subsistemas ou efetuar a ativação pós-falha para um recurso de cópia de segurança. As falhas repetidas num subsistema podem indicar preocupações mais graves.

Os operadores podem receber informações de alerta através de inúmeros canais de entrega, como e-mail, pager ou mensagem de texto. Um alerta também pode incluir uma indicação da gravidade de uma situação. Muitos sistemas de alerta suportam grupos de subscritores e todos os operadores que sejam membros do mesmo grupo podem receber o mesmo conjunto de alertas.

Um sistema de alerta deve ser personalizável e os valores adequados dos dados de instrumentação subjacentes podem ser fornecidos como parâmetros. Esta abordagem permite a um operador filtrar os dados e concentrar-se nesses limiares ou combinações de valores de maior interesse. Tenha em atenção que, em alguns casos, podem ser fornecidos dados de instrumentação não processados ao sistema de alerta. Noutras situações, pode ser mais adequado fornecer dados agregados. (Por exemplo, pode ser acionado um alerta se a utilização da CPU para um nó tiver ultrapassado 90 por cento nos últimos 10 minutos). Os detalhes fornecidos ao sistema de alerta também devem incluir quaisquer informações de resumo e contexto adequadas. Estes dados podem ajudar a reduzir a possibilidade de eventos falso positivos acionarem um alerta.

Relatórios

Os relatórios são utilizados para gerar uma vista geral do sistema. Podem incorporar dados históricos, além das informações atuais. Os requisitos enquadram-se em duas vastas categorias: relatórios operacionais e relatórios de segurança.

Normalmente, os relatórios operacionais incluem os seguintes aspetos:

• Agregar estatísticas que pode utilizar para compreender a utilização de recursos do sistema geral ou subsistemas especificados durante um período de tempo especificado.
• Identificar tendências na utilização de recursos para o sistema geral ou subsistemas especificados durante um período especificado.
• Monitorizar as exceções que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
• Determinar a eficiência da aplicação em termos dos recursos implementados e compreender se o volume de recursos (e os custos associados) podem ser reduzidos sem afetar desnecessariamente o desempenho.

Os relatórios de segurança pretendem controlar a utilização do sistema por parte dos clientes. Podem incluir:

• Auditar operações de utilizador. Requer o registo dos pedidos individuais efetuados por cada utilizador, juntamente com datas e horas. Os dados devem ser estruturados para permitir a um administrador reconstruir rapidamente a sequência de operações efetuadas por um utilizador no período indicado.
• Controlar a utilização de recursos pelo utilizador. Requer o registo de como cada pedido de utilizador acede aos vários recursos que compõem o sistema e durante quanto tempo. Um administrador tem de conseguir utilizar estes dados para gerar um relatório de utilização por utilizador durante um período especificado, possivelmente para fins de faturação.

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

Passos seguintes

• Descrição geral do Azure Monitor
• Monitorizar, diagnosticar e resolver problemas do Armazenamento do Microsoft Azure (Monitor, diagnose, and troubleshoot Microsoft Azure Storage)
• 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
• Transferir e instalar SQL Server Data Tools (SSDT) para Visual Studio

Recursos relacionados

• A documentação de orientação sobre dimensionamento automático descreve como diminuir os custos de gestão ao reduzir a necessidade de um operador monitorizar continuamente o desempenho de um sistema e tomar decisões quanto a adicionar ou remover recursos.
• O padrão de Monitorização de Pontos Finais de Estado de Funcionamento descreve como implementar verificações funcionais numa aplicação à qual as ferramentas externas podem aceder através de pontos finais expostos em intervalos regulares.
• O padrão Fila de Prioridade mostra como atribuir prioridades às mensagens em fila para que os pedidos urgentes sejam recebidos e possam ser processados antes de mensagens menos urgentes.