Diretrizes de monitoramento e diagnóstico

Aplicativos e serviços distribuídos em execução na nuvem são, por sua natureza, peças complexas de software que compreendem muitas partes móveis. Em um ambiente de produção, é importante poder acompanhar a maneira como os usuários usam seu sistema, rastrear a utilização de recursos e geralmente monitorar a integridade e o desempenho do sistema. Você pode usar essas informações como um auxílio de diagnóstico para detectar e corrigir problemas e para ajudar a identificar possíveis problemas e impedir que eles ocorram.

Cenários de monitoramento e diagnóstico

Você pode usar o monitoramento para obter uma visão de quão bem um sistema está funcionando. O monitoramento é uma parte crucial da manutenção de destinos de qualidade de serviço. Cenários comuns para coletar dados de monitoramento incluem:

• Garantindo que o sistema permaneça íntegro.
• Acompanhando a disponibilidade do sistema e seus elementos de componente.
• Manter o desempenho para garantir que a taxa de transferência do sistema não se degrade inesperadamente à medida que o volume de trabalho aumenta.
• Garantindo que o sistema atenda a quaisquer SLAs (contratos de nível de serviço) estabelecidos com os clientes.
• Protegendo a privacidade e a segurança do sistema, dos usuários e de seus dados.
• Acompanhamento das operações executadas para fins de auditoria ou regulamentação.
• Monitorando o uso diário do sistema e detectando tendências que podem levar a problemas se eles não forem resolvidos.
• Acompanhamento de problemas que ocorrem, desde o relatório inicial até a análise de possíveis causas, retificação, atualizações de software e implantação conseqüentes.
• Operações de rastreamento e depuração de versões de software.

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

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

Monitoramento da integridade

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

Requisitos para monitoramento de integridade

Um operador deve ser alertado rapidamente (em questão de segundos) se qualquer parte do sistema for considerada não íntegra. O operador deve ser capaz de verificar quais partes do sistema estão funcionando normalmente e quais partes estão enfrentando problemas. A integridade do sistema pode ser realçada por meio de um sistema de semáforo:

• Vermelho para não íntegro (o sistema parou)
• Amarelo para parcialmente íntegro (o sistema está em execução com funcionalidade reduzida)
• Verde para completamente saudável

Um sistema abrangente de monitoramento de integridade permite que um operador faça drill down pelo sistema para exibir o status de integridade de subsistemas e componentes. Por exemplo, se o sistema geral for descrito como parcialmente íntegro, o operador deverá ser capaz de ampliar e determinar qual funcionalidade está indisponível no momento.

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

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

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

Analisando dados de integridade

O foco principal do monitoramento de integridade é indicar rapidamente se o sistema está em execução. A análise frequente dos dados imediatos poderá disparar um alerta se um componente crítico for detectado como não íntegro. (Falha ao responder a uma série consecutiva de pings, por exemplo.) Em seguida, o operador pode executar a ação corretiva apropriada.

Um sistema mais avançado pode incluir um elemento preditivo que executa uma análise a frio em cargas de trabalho recentes e atuais. Uma análise a frio pode detectar tendências e determinar se o sistema provavelmente permanecerá íntegro ou se o sistema precisa de recursos adicionais. Esse elemento preditivo deve ser baseado em métricas críticas de desempenho, como:

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

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

Monitoramento de disponibilidade

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

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

Os dados necessários para controlar a disponibilidade podem depender de vários fatores de nível inferior. Muitos desses fatores podem ser específicos para o aplicativo, o sistema e o ambiente. Um sistema de monitoramento eficaz captura os dados de disponibilidade que correspondem a esses fatores de baixo nível e os agrega para dar uma visão geral do sistema. Por exemplo, em um sistema de comércio eletrônico, a funcionalidade de negócios que permite que um cliente faça pedidos pode depender do repositório em que os detalhes do pedido são armazenados e do sistema de pagamento que manipula as transações monetárias para pagar esses pedidos. A disponibilidade da parte de posicionamento de pedidos do sistema é, portanto, uma função da disponibilidade do repositório e do subsistema de pagamento.

Requisitos para monitoramento de disponibilidade

Um operador também deve ser capaz de exibir a disponibilidade histórica de cada sistema e subsistema e usar essas informações para identificar quaisquer tendências que possam fazer com que um ou mais subsistemas falhem periodicamente. (Os serviços começam a falhar em uma hora específica do dia que corresponde ao horário de processamento de pico?)

Uma solução de monitoramento deve fornecer uma exibição imediata e histórica da disponibilidade ou indisponibilidade de cada subsistema. Ele também deve ser capaz de alertar rapidamente um operador quando um ou mais serviços falharem ou quando os usuários não puderem se conectar aos serviços. Essa é uma questão de não apenas monitorar cada serviço, mas também examinar as ações executadas por cada usuário se essas ações falharem quando tentarem se comunicar com um serviço. Até certo ponto, um grau de falha de conectividade é normal e pode ser devido a erros transitórios. Mas pode ser útil permitir que o sistema gere um alerta para o número de falhas de conectividade em um subsistema especificado que ocorrem durante um período específico.

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

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

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

Analisando dados de disponibilidade

Os dados de instrumentação devem ser agregados e correlacionados para dar suporte aos seguintes tipos de análise:

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

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

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

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

Monitoramento de desempenho

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

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

Requisitos para monitoramento de desempenho

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

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

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

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

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

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

Todas as visualizações devem permitir que um operador especifique um período de tempo. Os dados exibidos podem ser um instantâneo da situação atual ou uma exibição histórica do desempenho.

Um operador deve ser capaz de gerar um alerta com base em qualquer medida de desempenho para qualquer valor especificado durante qualquer intervalo de tempo especificado.

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

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

Se possível, você também deve capturar dados de desempenho para todos os sistemas externos que o aplicativo usa. Esses sistemas externos podem fornecer seus próprios contadores de desempenho ou outros recursos para solicitar dados de desempenho. Se isso não for possível, registre informações como a hora de início e a hora de término de cada solicitação feita a um sistema externo, juntamente com o status (êxito, falha ou aviso) da operação. Por exemplo, você pode usar uma abordagem de cronômetro para solicitações de tempo: iniciar um temporizador quando a solicitação for iniciada e parar o temporizador quando a solicitação for concluída.

Dados de desempenho de baixo nível para componentes individuais em um sistema podem estar disponíveis por meio de recursos e serviços, como contadores de desempenho do Windows e Diagnóstico do Azure.

Analisando dados de desempenho

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

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

No caso de problemas de latência que afetam o desempenho, um operador deve ser capaz de identificar rapidamente a causa do gargalo examinando a latência de cada etapa executada por cada solicitação. Os dados de desempenho devem, portanto, fornecer um meio de correlacionar medidas de desempenho para cada etapa para vinculá-los a uma solicitação específica.

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

Monitoramento de segurança

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

• Todas as tentativas de entrada, se falharem ou forem bem-sucedidas.
• Todas as operações executadas por — e os detalhes de todos os recursos acessados por — um usuário autenticado.
• Quando um usuário termina uma sessão e sai.

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

Requisitos para monitoramento de segurança

Os aspectos mais críticos do monitoramento de segurança devem permitir que um operador habilite rapidamente:

• Detectar tentativas de invasões por uma entidade não autenticada.
• Identifique as tentativas das entidades de executar operações em dados para os quais elas não receberam acesso.
• Determine se o sistema ou alguma parte do sistema está sob ataque de fora ou de dentro. (Por exemplo, um usuário autenticado mal-intencionado pode estar tentando baixar o sistema.)

Para dar suporte a esses requisitos, um operador deverá ser notificado se:

• Uma conta faz repetidas tentativas de entrada com falha em um período especificado.
• Uma conta autenticada tenta acessar repetidamente um recurso proibido durante um período especificado.
• Um grande número de solicitações não autenticadas ou não autorizadas ocorre durante um período especificado.

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

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

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

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

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

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

Analisando dados de segurança

Um dos principais recursos de monitoramento de segurança é que ele coleta dados de várias fontes. Os diferentes formatos e o nível de detalhes geralmente exigem uma análise complexa dos dados capturados para vinculá-los a um thread coerente de informações. Além dos casos mais simples (como detectar um grande número de entradas com falha ou tentativas repetidas de obter acesso não autorizado a recursos críticos), talvez não seja possível executar nenhum processamento automatizado complexo de dados de segurança. Em vez disso, pode ser preferível gravar esses dados, carimbo de data/hora, mas de outra forma em sua forma original, em um repositório seguro para permitir a análise manual de especialistas.

Monitoramento de SLA

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

Os SLAs geralmente são definidos em termos de:

• Disponibilidade geral do sistema. Por exemplo, uma organização pode garantir que o sistema esteja disponível por 99,9% das vezes. Isso equivale a no máximo 9 horas de tempo de inatividade por ano ou aproximadamente 10 minutos por semana.
• Taxa de transferência operacional. Esse aspecto geralmente é expresso como uma ou mais marcas de água alta, como garantir que o sistema possa dar suporte a até 100.000 solicitações de usuário simultâneas ou lidar com 10.000 transações comerciais simultâneas.
• Tempo de resposta operacional. O sistema também pode fazer garantias para a taxa na qual as solicitações são processadas. Um exemplo é que 99% de todas as transações comerciais terminam em dois segundos e nenhuma transação única leva mais de 10 segundos.

Requisitos para monitoramento de SLA

No nível mais alto, um operador deve ser capaz de determinar rapidamente se o sistema está atendendo aos SLAs acordados ou não. E, caso contrário, o operador deve ser capaz de fazer drill down e examinar os fatores subjacentes para determinar os motivos para o desempenho abaixo do padrão.

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

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

Todos esses indicadores devem ser capazes de serem filtrados por um período de tempo especificado.

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

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

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

Os dados brutos necessários para dar suporte ao monitoramento de SLA são semelhantes aos dados brutos necessários para o monitoramento de desempenho, juntamente com alguns aspectos do monitoramento de integridade e disponibilidade. Para obter mais informações, consulte essas seções. Você pode capturar esses dados:

• Executando o monitoramento de ponto de extremidade.
• Registrar exceções, falhas e avisos em log.
• Rastreamento da execução de solicitações de usuário.
• Monitorando a disponibilidade de quaisquer serviços de terceiros que o sistema usa.
• Usando contadores e métricas de desempenho.

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

Analisando dados SLA

Os dados de instrumentação devem ser agregados para gerar uma imagem do desempenho geral do sistema. Os dados agregados também devem dar suporte à busca detalhada para habilitar o exame do desempenho dos subsistemas subjacentes. Por exemplo, você deve ser capaz de:

• Calcule o número total de solicitações de usuário durante um período especificado e determine a taxa de êxito e falha dessas solicitações.
• Combine os tempos de resposta das solicitações do usuário para gerar uma exibição geral dos tempos de resposta do sistema.
• Analise o progresso das solicitações do usuário para dividir o tempo de resposta geral de uma solicitação nos tempos de resposta dos itens de trabalho individuais nessa solicitação.
• Determine a disponibilidade geral do sistema como um percentual de tempo de atividade para qualquer período específico.
• Analise a disponibilidade de tempo percentual dos componentes e serviços individuais no sistema. Isso pode envolver a análise de logs gerados por serviços de terceiros.

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

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

Auditoria

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

Requisitos para auditoria

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

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

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

As principais fontes de informações para auditoria podem incluir:

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

O formato dos dados de auditoria e a maneira como eles são armazenados podem ser orientados por requisitos regulatórios. Por exemplo, talvez não seja possível limpar os dados de forma alguma. (Ele deve ser gravado em seu formato original.) O acesso ao repositório onde ele está mantido deve ser protegido para evitar adulteração.

Analisando dados de auditoria

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

Monitoramento do uso

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

• Determine quais recursos são muito usados e determine os possíveis pontos de acesso no sistema. Elementos de alto tráfego podem se beneficiar do particionamento funcional ou até mesmo da replicação para distribuir a carga de forma mais uniforme. Um operador também pode usar essas informações para verificar quais recursos são usados com pouca frequência e são possíveis candidatos à aposentadoria ou substituição em uma versão futura do sistema.

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

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

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

• Impor cotas. Se um usuário em um sistema multilocatário exceder sua cota paga de tempo de processamento ou uso de recursos durante um período especificado, seu acesso poderá ser limitado ou o processamento poderá ser limitado.

Requisitos para monitoramento de uso

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

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

Um operador também deve ser capaz de gerar grafos. Por exemplo, um grafo pode exibir os usuários com mais fome de recursos ou os recursos de sistema ou recursos do sistema acessados com mais frequência.

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

O acompanhamento de uso pode ser executado em um nível relativamente alto. Ele pode observar os horários de início e término de cada solicitação e a natureza da solicitação (leitura, gravação e outras solicitações, dependendo do recurso em questão). Você pode obter essas informações:

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

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

Acompanhamento de problemas

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

Requisitos para acompanhamento de problemas

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

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

A fonte de dados inicial para dados de acompanhamento de problemas é o usuário que relatou o problema em primeiro lugar. O usuário pode ser capaz de fornecer dados adicionais, como:

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

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

Analisando dados de acompanhamento de problemas

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

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

Se um usuário relatar um problema que tenha uma solução conhecida no sistema de acompanhamento de problemas, o operador deverá ser capaz de informar o usuário da solução imediatamente.

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

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

Requisitos para rastreamento e depuração

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

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

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

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

O pipeline de monitoramento e diagnóstico

O monitoramento de um sistema distribuído em larga escala representa um desafio significativo. Cada um dos cenários descritos na seção anterior não deve necessariamente ser considerado isoladamente. É provável que haja uma sobreposição significativa nos dados de monitoramento e diagnóstico necessários para cada situação, embora esses dados possam precisar ser processados e apresentados de maneiras diferentes. Por esses motivos, você deve ter uma visão holística do monitoramento e do diagnóstico.

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

Figura 1 – Os estágios no pipeline de monitoramento e diagnóstico.

A Figura 1 destaca como os dados de monitoramento e diagnóstico podem vir de várias fontes de dados. Os estágios de instrumentação e coleta se preocupam em identificar as fontes de onde os dados precisam ser capturados, determinar quais dados capturar, como capturá-los e como formatar esses dados para que possam ser facilmente examinados. O estágio de análise/diagnóstico usa os dados brutos e os usa para gerar informações significativas que um operador pode usar para determinar o estado do sistema. O operador pode usar essas informações para tomar decisões sobre possíveis ações a serem tomadas e, em seguida, alimentar os resultados novamente nos estágios de instrumentação e coleção. A fase de estágio de visualização/alerta apresenta uma exibição consumível do estado do sistema. Ele pode exibir informações quase em tempo real usando uma série de painéis. E pode gerar relatórios, gráficos e gráficos para fornecer uma exibição histórica dos dados que podem ajudar a identificar tendências de longo prazo. Se as informações indicarem que um KPI provavelmente excederá os limites aceitáveis, esse estágio também poderá disparar um alerta para um operador. Em alguns casos, um alerta também pode ser usado para disparar um processo automatizado que tenta executar ações corretivas, como dimensionamento automático.

Essas etapas constituem um processo de fluxo contínuo em que os estágios estão ocorrendo em paralelo. O ideal é que todas as fases sejam configuráveis dinamicamente. Em alguns pontos, especialmente quando um sistema foi implantado recentemente ou está enfrentando problemas, pode ser necessário coletar dados estendidos com mais frequência. Em outros momentos, deve ser possível reverter para capturar um nível base de informações essenciais para verificar se o sistema está funcionando corretamente.

Além disso, todo o processo de monitoramento deve ser considerado uma solução dinâmica e contínua que está sujeita a ajustes finos e melhorias como resultado de comentários. Por exemplo, você pode começar com a medição de muitos fatores para determinar a integridade do sistema. A análise ao longo do tempo pode levar a um refinamento, pois você descarta medidas que não são relevantes, permitindo que você se concentre mais precisamente nos dados necessários, minimizando o ruído em segundo plano.

Fontes de dados de monitoramento e diagnóstico

As informações que o processo de monitoramento usa podem vir de várias fontes, conforme ilustrado na Figura 1. No nível do aplicativo, as informações são provenientes de logs de rastreamento incorporados ao código do sistema. Os desenvolvedores devem seguir uma abordagem padrão para acompanhar o fluxo de controle por meio de seu código. Por exemplo, uma entrada para um método pode emitir uma mensagem de rastreamento que especifica o nome do método, a hora atual, o valor de cada parâmetro e qualquer outra informação pertinente. Registrar os horários de entrada e saída também pode ser útil.

Você deve registrar todas as exceções e avisos e garantir que mantenha um rastreamento completo de quaisquer exceções e avisos aninhados. Idealmente, você também deve capturar informações que identifiquem o usuário que está executando o código, juntamente com informações de correlação de atividade (para acompanhar solicitações à medida que passam pelo sistema). E você deve registrar tentativas de acesso a todos os recursos, como filas de mensagens, bancos de dados, arquivos e outros serviços dependentes. Essas informações podem ser usadas para fins de medição e auditoria.

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

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

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

Se o aplicativo usar outros serviços externos, como um servidor Web ou um sistema de gerenciamento de banco de dados, esses serviços poderão publicar suas próprias informações de rastreamento, logs e contadores de desempenho. Exemplos incluem exibições de gerenciamento dinâmico do SQL Server para operações de acompanhamento executadas em um banco de dados do SQL Server e logs de rastreamento do IIS para registrar solicitações feitas em um servidor Web.

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

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

A seção Instrumentação de um aplicativo contém mais diretrizes sobre as informações que você deve capturar. Mas você pode usar várias estratégias para coletar essas informações:

• Monitoramento de aplicativo/sistema. Essa estratégia usa fontes internas dentro do aplicativo, estruturas de aplicativo, sistema operacional e infraestrutura. O código do aplicativo pode gerar seus próprios dados de monitoramento em pontos importantes durante o ciclo de vida de uma solicitação de cliente. O aplicativo pode incluir instruções de rastreamento que podem ser seletivamente habilitadas ou desabilitadas conforme as circunstâncias ditam. Também pode ser possível injetar diagnóstico dinamicamente usando uma estrutura de diagnóstico. Essas estruturas normalmente fornecem plug-ins que podem ser anexados a vários pontos de instrumentação em seu código e capturam dados de rastreamento nesses pontos.

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

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

  Importante

  Você deve considerar os dados capturados monitorando usuários reais como altamente confidenciais, pois podem incluir material confidencial. Se você salvar os dados capturados, armazene-os com segurança. Se você quiser usar os dados para fins de monitoramento de desempenho ou depuração, remova todos os dados pessoais primeiro.

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

  Observação

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

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

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

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

Instrumentando um aplicativo

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

O conteúdo de um log de rastreamento pode ser o resultado de dados textuais gravados pelo aplicativo ou dados binários criados como resultado de um evento de rastreamento, se o aplicativo estiver usando o ETW (Rastreamento de Eventos para Windows). Eles também podem ser gerados a partir de logs do sistema que registram eventos decorrentes de partes da infraestrutura, como um servidor Web. As mensagens de log textual geralmente são projetadas para serem legíveis por humanos, mas também devem ser escritas em um formato que permite que um sistema automatizado as analise facilmente.

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

As métricas geralmente são uma medida ou contagem de algum aspecto ou recurso no sistema em um momento específico, com uma ou mais marcas ou dimensões associadas (às vezes chamada de exemplo). Uma única instância de uma métrica geralmente não é útil isoladamente. Em vez disso, as métricas precisam ser capturadas ao longo do tempo. O principal problema a ser considerado é quais métricas você deve registrar e com que frequência. Gerar dados para métricas com muita frequência pode impor uma carga adicional significativa no sistema, enquanto capturar métricas com pouca frequência pode fazer com que você perca as circunstâncias que levam a um evento significativo. As considerações variam de métrica para métrica. Por exemplo, a utilização da CPU em um servidor pode flutuar de segundo para segundo, mas a alta utilização só se tornará uma preocupação se persistir por vários minutos.

Informações para correlacionar dados

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

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

Todos os dados de monitoramento devem ser carimbos de data/hora da mesma maneira. Para consistência, registre todas as datas e horas usando o Tempo Universal Coordenado. Isso ajuda você a rastrear mais facilmente sequências de eventos.

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

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

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

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

• Forneça contexto suficiente para permitir que um desenvolvedor ou administrador determine a origem de cada solicitação. Isso pode incluir alguma forma de ID de atividade que identifica uma instância específica de uma solicitação. Ele também pode incluir informações que podem ser usadas para correlacionar essa atividade com o trabalho computacional executado e os recursos usados. Esse trabalho pode cruzar os limites do processo e do computador. Para medição, o contexto também deve incluir (direta ou indiretamente por meio de outras informações correlacionadas) uma referência ao cliente que fez com que a solicitação fosse feita. Esse contexto fornece informações valiosas sobre o estado do aplicativo no momento em que os dados de monitoramento foram capturados.

• Registre todas as solicitações e os locais ou regiões das quais essas solicitações são feitas. Essas informações podem ajudar a determinar se há pontos de acesso específicos à localização. Essas informações também podem ser úteis para determinar se deseja reparticionar um aplicativo ou os dados que ele usa.

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

• Seja consistente nos dados que os diferentes elementos do aplicativo capturam, pois isso pode ajudar na análise de eventos e na correlação deles com solicitações do usuário. Considere usar um pacote de log abrangente e configurável para coletar informações, em vez de depender dos desenvolvedores para adotar a mesma abordagem que implementam diferentes partes do sistema. Colete dados dos principais contadores de desempenho, como o volume de E/S que está sendo executado, a utilização da rede, o número de solicitações, o uso de memória e a utilização da CPU. Alguns serviços de infraestrutura podem fornecer seus próprios contadores de desempenho específicos, como o número de conexões com um banco de dados, a taxa na qual as transações estão sendo executadas e o número de transações que têm êxito ou falha. Os aplicativos também podem definir seus próprios contadores de desempenho específicos.

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

Garantindo compatibilidade com sistemas de telemetria

Em muitos casos, as informações que a instrumentação produz são geradas como uma série de eventos e passadas para um sistema de telemetria separado para processamento e análise. Um sistema de telemetria normalmente é independente de qualquer aplicativo ou tecnologia específico, mas espera que as informações sigam um formato específico que geralmente é definido por um esquema. O esquema especifica efetivamente um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. O esquema deve ser generalizado para permitir que os dados cheguem de uma variedade de plataformas e dispositivos.

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

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

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

Práticas recomendadas para instrumentar aplicativos

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

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

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

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

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

• Não divulgue informações confidenciais sobre o sistema ou informações pessoais sobre os usuários. Limpe essas informações antes de serem registradas, mas certifique-se de que os detalhes relevantes sejam mantidos. Por exemplo, remova a ID e a senha de qualquer cadeia de conexão de banco de dados, mas escreva as informações restantes no log para que um analista possa determinar que o sistema está acessando o banco de dados correto. Registre todas as exceções críticas, mas permita que o administrador ative e desative o log para níveis mais baixos de exceções e avisos. Além disso, capture e registre todas as informações lógicas de repetição. Esses dados podem ser úteis para monitorar a integridade transitória do sistema.

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

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

• Com exceção dos eventos de auditoria, verifique se todas as chamadas de registro em log são operações de fogo e esquecer que não bloqueiam o progresso das operações de negócios. Os eventos de auditoria são excepcionais porque são fundamentais para a empresa e podem ser classificados como uma parte fundamental das operações de negócios.

• Verifique se o log é extensível e não tem nenhuma dependência direta em um alvo específico. Por exemplo, em vez de escrever informações usando System.Diagnostics.Trace, defina uma interface abstrata (como ILogger) que expõe métodos de log e que podem ser implementados por meio de quaisquer meios apropriados.

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

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

Coletando e armazenando dados

O estágio de coleta do processo de monitoramento se preocupa em recuperar as informações que a instrumentação gera, formatar esses dados para facilitar o consumo do estágio de análise/diagnóstico e salvar os dados transformados no armazenamento confiável. Os dados de instrumentação coletados de diferentes partes de um sistema distribuído podem ser mantidos em vários locais e com formatos variados. Por exemplo, o código do aplicativo pode gerar arquivos de log de rastreamento e gerar dados de log de eventos do aplicativo, enquanto contadores de desempenho que monitoram os principais aspectos da infraestrutura que seu aplicativo usa podem ser capturados por meio de outras tecnologias. Todos os componentes e serviços de terceiros que seu aplicativo usa podem fornecer informações de instrumentação em formatos diferentes, usando arquivos de rastreamento separados, armazenamento de blobs ou até mesmo um armazenamento de dados personalizado.

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

Figura 2 – Coletando dados de instrumentação.

Essa é uma exibição simplificada. O serviço de coleção não é necessariamente um único processo e pode incluir muitas partes constituintes em execução em computadores diferentes, conforme descrito nas seções a seguir. Além disso, se a análise de alguns dados de telemetria precisar ser executada rapidamente (análise frequente, conforme descrito na seção Suportando análises quentes, quentes e frias posteriormente neste documento), os componentes locais que operam fora do serviço de coleta poderão executar as tarefas de análise imediatamente. A Figura 2 ilustra essa situação para eventos selecionados. Após o processamento analítico, os resultados podem ser enviados diretamente para o subsistema de visualização e alerta. Os dados submetidos à análise morna ou fria são mantidos no armazenamento enquanto aguardam o processamento.

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

• Logs IIS
• Logs de solicitação com falha do IIS
• Logs de eventos do Windows
• Contadores de desempenho
• Despejos de memória
• Logs de infraestrutura de Diagnóstico de Azure
• Logs de erros personalizados
• EventSource do .NET
• ETW baseado em manifesto

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

Estratégias para coletar dados de instrumentação

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

Para otimizar o uso da largura de banda, você pode optar por transferir dados menos urgentes em partes, como lotes. No entanto, os dados não devem ser atrasados indefinidamente, especialmente se contiver informações confidenciais.

Puxando e pressionando dados de instrumentação

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

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

Figura 3 – Usando um agente de monitoramento para efetuar pull de informações e gravar no armazenamento compartilhado.

É viável usar a abordagem descrita para armazenar dados de telemetria para um aplicativo de pequena escala em execução em um número limitado de nós em um único local. No entanto, um aplicativo de nuvem global complexo e altamente escalonável pode gerar grandes volumes de dados de centenas de funções web e de trabalho, fragmentos de banco de dados e outros serviços. Essa inundação de dados pode facilmente sobrecarregar a largura de banda de E/S disponível com um único local central. Portanto, sua solução de telemetria deve ser escalonável para impedir que ela atue como um gargalo à medida que o sistema se expande. Idealmente, sua solução deve incorporar um grau de redundância para reduzir os riscos de perda de informações de monitoramento importantes (como auditoria ou dados de cobrança) se parte do sistema falhar.

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

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

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

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

Consolidando dados de instrumentação

Os dados de instrumentação que o serviço de coleta de dados recupera de uma única instância de um aplicativo dão uma exibição localizada da integridade e do desempenho dessa instância. Para avaliar a integridade geral do sistema, é necessário consolidar alguns aspectos dos dados nas exibições locais. Você pode executar isso depois que os dados tiverem sido armazenados, mas em alguns casos, você também pode obtê-los à medida que os dados são coletados. Em vez de serem gravados diretamente no armazenamento compartilhado, os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combina dados e atua como um processo de filtragem e limpeza. Por exemplo, os dados de instrumentação que incluem as mesmas informações de correlação, como uma ID de atividade, podem ser amalgamados. (É possível que um usuário comece a executar uma operação de negócios em um nó e, em seguida, seja transferido para outro nó em caso de falha de nó ou dependendo de como o balanceamento de carga está configurado.) Esse processo também pode detectar e remover quaisquer dados duplicados (sempre uma possibilidade se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação por push para o armazenamento). A Figura 5 ilustra um exemplo dessa estrutura.

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

Armazenando dados de instrumentação

As discussões anteriores ilustraram uma visão bastante simplista da maneira como os dados de instrumentação são armazenados. Na realidade, pode fazer sentido armazenar os diferentes tipos de informações usando tecnologias mais apropriadas para a maneira como cada tipo provavelmente será usado.

Por exemplo, o armazenamento de blobs e tabelas do Azure tem algumas semelhanças na maneira como são acessados. Mas elas têm limitações nas operações que você pode executar usando-as e a granularidade dos dados que eles contêm é bem diferente. Se você precisar executar operações mais analíticas ou exigir recursos de pesquisa de texto completo nos dados, talvez seja mais apropriado usar o armazenamento de dados que fornece recursos otimizados para tipos específicos de consultas e acesso a dados. Por exemplo:

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

Você pode implementar um serviço adicional que recupera periodicamente os dados do armazenamento compartilhado, particiona e filtra os dados de acordo com sua finalidade e grava-os em um conjunto apropriado de armazenamentos de dados, conforme mostrado na Figura 6. Uma abordagem alternativa é incluir essa funcionalidade no processo de consolidação e limpeza e gravar os dados diretamente nesses repositórios conforme eles são recuperados em vez de salvá-los em uma área de armazenamento compartilhado intermediária. Cada abordagem tem suas vantagens e desvantagens. A implementação de um serviço de particionamento separado diminui a carga no serviço de consolidação e limpeza e permite que pelo menos alguns dos dados particionados sejam regenerados se necessário (dependendo da quantidade de dados retidos no armazenamento compartilhado). No entanto, ele consome recursos adicionais. Além disso, pode haver um atraso entre o recebimento de dados de instrumentação de cada instância do aplicativo e a conversão desses dados em informações acionáveis.

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

Os mesmos dados de instrumentação podem ser necessários para mais de uma finalidade. Por exemplo, contadores de desempenho podem ser usados para fornecer uma exibição histórica do desempenho do sistema ao longo do tempo. Essas informações podem ser combinadas com outros dados de uso para gerar informações de cobrança do cliente. Nessas situações, os mesmos dados podem ser enviados para mais de um destino, como um banco de dados de documento que pode atuar como um repositório de longo prazo para armazenar informações de cobrança e um repositório multidimensional para lidar com análises de desempenho complexas.

Você também deve considerar a urgência com que os dados são necessários. Os dados que fornecem informações para alertas devem ser acessados rapidamente, portanto, devem ser mantidos no armazenamento rápido de dados e indexados ou estruturados para otimizar as consultas executadas pelo sistema de alertas. Em alguns casos, pode ser necessário que o serviço de telemetria que coleta os dados em cada nó formate e salve dados localmente para que uma instância local do sistema de alertas possa notificá-lo rapidamente sobre quaisquer problemas. Os mesmos dados podem ser enviados para o serviço de gravação de armazenamento mostrado nos diagramas anteriores e armazenados centralmente se também forem necessários para outras finalidades.

As informações usadas para análises mais consideradas, para relatórios e para detectar tendências históricas são menos urgentes e podem ser armazenadas de forma a dar suporte à mineração de dados e consultas ad hoc. Para obter mais informações, consulte a seção Suportando análises quentes, quentes e frias mais adiante neste documento.

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

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

Os dados de desempenho geralmente têm uma vida útil mais longa para que possam ser usados para detectar tendências de desempenho e para planejamento de capacidade. A exibição consolidada desses dados geralmente é mantida online por um período finito para habilitar o acesso rápido. Depois disso, ele pode ser arquivado ou descartado. Os dados coletados para os clientes de medição e cobrança podem precisar ser salvos indefinidamente. Além disso, os requisitos regulatórios podem ditar que as informações coletadas para fins de auditoria e segurança também precisam ser arquivadas e salvas. Esses dados também são confidenciais e talvez precisem ser criptografados ou protegidos de outra forma para evitar adulteração. Você nunca deve registrar senhas de usuários ou outras informações que possam ser usadas para cometer fraude de identidade. Esses detalhes devem ser limpos dos dados antes de serem armazenados.

Amostragem para baixo

É útil armazenar dados históricos para que você possa identificar tendências de longo prazo. Em vez de salvar dados antigos em sua totalidade, talvez seja possível reduzir os dados para reduzir sua resolução e economizar custos de armazenamento. Por exemplo, em vez de salvar indicadores de desempenho minuto a minuto, você pode consolidar dados com mais de um mês de idade para formar uma exibição hora a hora.

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

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

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

• Toda a saída do agente de monitoramento ou do serviço de coleta de dados deve ser um formato independente do computador, do sistema operacional ou do protocolo de rede. Por exemplo, emita informações em um formato autodescrevendo, como JSON, MessagePack ou Protobuf, em vez de ETL/ETW. O uso de um formato padrão permite que o sistema construa pipelines de processamento; os componentes que leem, transformam e enviam dados no formato acordado podem ser facilmente integrados.

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

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

Analisando dados e diagnosticando problemas

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

Conforme descrito na seção Consolidando dados de instrumentação, os dados de cada parte do sistema normalmente são capturados localmente, mas geralmente precisam ser combinados com dados gerados em outros sites que participam do sistema. Essas informações exigem correlação cuidadosa para garantir que os dados sejam combinados com precisão. Por exemplo, os dados de uso de uma operação podem abranger um nó que hospeda um site ao qual um usuário se conecta, um nó que executa um serviço separado acessado como parte dessa operação e armazenamento de dados mantido em outro nó. Essas informações precisam ser vinculadas para fornecer uma exibição geral do recurso e do uso de processamento para a 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 a formatação são mais propensas a ocorrer em um nó central.

Suporte à análise quente, quente e fria

Analisar e reformatar dados para fins de visualização, relatórios e alertas pode ser um processo complexo que consome seu próprio conjunto de recursos. Algumas formas de monitoramento são críticas ao tempo e exigem que a análise imediata dos dados seja eficaz. Isso é conhecido como análise frequente. Exemplos incluem as análises necessárias para alertas e alguns aspectos do monitoramento de segurança (como detectar um ataque ao sistema). Os dados necessários para essas finalidades devem estar rapidamente disponíveis e estruturados para processamento eficiente. Em alguns casos, talvez seja necessário mover o processamento de análise para os nós individuais em que os dados são mantidos.

Outras formas de análise são menos críticas ao tempo e podem exigir alguma computação e agregação depois que os dados brutos forem recebidos. Isso é chamado de análise calorosa. A análise de desempenho geralmente se enquadra nessa categoria. Nesse caso, é improvável que um evento de desempenho único isolado seja estatisticamente significativo. (Pode ser causado por um pico repentino ou uma falha.) Os dados de uma série de eventos devem fornecer uma imagem mais confiável do desempenho do sistema.

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

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

Um operador também pode usar a análise a frio para fornecer os dados para análise de integridade preditiva. O operador pode coletar informações históricas durante um período especificado e usá-la em conjunto com os dados de integridade atuais (recuperados do caminho quente) para detectar tendências que podem causar problemas de integridade em breve. Nesses casos, talvez seja necessário gerar um alerta para que medidas corretivas possam ser tomadas.

Correlacionar dados

Os dados que a instrumentação captura podem fornecer um instantâneo do estado do sistema, mas a finalidade da análise é tornar esses dados acionáveis. Por exemplo:

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

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

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

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

Solução de problemas e diagnósticos

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

• Informações detalhadas de logs de eventos e rastreamentos, seja para todo o sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Concluir rastreamentos de pilha resultantes de exceções e falhas de qualquer nível especificado que ocorram no sistema ou em um subsistema especificado durante um período especificado.
• Despejos de falha para todos os processos com falha em qualquer lugar do sistema ou para um subsistema especificado durante uma janela de tempo especificada.
• Logs de atividades registrando as operações executadas por todos os usuários ou para usuários selecionados durante um período especificado.

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

Visualizando dados e gerando alertas

Um aspecto importante de qualquer sistema de monitoramento é a capacidade de apresentar os dados de forma que um operador possa detectar rapidamente quaisquer tendências ou problemas. Também é importante a capacidade de informar rapidamente um operador se ocorreu um evento significativo que pode exigir atenção.

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

Visualização usando dashboards

A maneira mais comum de visualizar dados é usar painéis que podem exibir informações como uma série de gráficos, gráficos ou alguma outra ilustração. Esses itens podem ser parametrizados e um analista deve ser capaz de selecionar os parâmetros importantes (como o período de tempo) para qualquer situação específica.

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

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

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

Para que um sistema de dashboard funcione efetivamente, ele deve ter os dados brutos com os quais trabalhar. Se você estiver criando seu próprio sistema de dashboard ou usando um painel desenvolvido por outra organização, deverá entender quais dados de instrumentação você precisa coletar, em quais níveis de granularidade e como eles devem ser formatados para o dashboard consumir.

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

Levantando alertas

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

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

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

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

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

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

Reportagem

Os relatórios são usados para gerar uma visão geral do sistema. Ele pode incorporar dados históricos além das informações atuais. Os próprios requisitos de relatório se enquadram em duas categorias amplas: relatórios operacionais e relatórios de segurança.

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

• Estatísticas agregadas que você pode usar para entender a utilização de recursos do sistema geral ou de subsistemas especificados durante uma janela de tempo especificada.
• Identificar tendências no uso de recursos para o sistema geral ou subsistemas especificados durante um período especificado.
• Monitorando as exceções que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
• Determinar a eficiência do aplicativo em termos de recursos implantados e entender se o volume de recursos (e seu custo associado) pode ser reduzido sem afetar o desempenho desnecessariamente.

Os relatórios de segurança estão preocupados com o acompanhamento do uso do sistema pelos clientes. Eles podem incluir:

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

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

Próximas etapas

• visão geral do Azure Monitor
• Monitoramento, diagnóstico e solução de problemas de Armazenamento do Microsoft Azure
• Visão geral dos alertas no Microsoft Azure
• Exibir as notificações de integridade do serviço usando o Portal do Azure
• O que é o Application Insights?
• Diagnóstico de desempenho de máquinas virtuais do Azure
• Baixar e instalar o SSDT (SQL Server Data Tools) para Visual Studio

Recursos relacionados

• As diretrizes de dimensionamento automático descrevem como diminuir a sobrecarga de gerenciamento reduzindo a necessidade de um operador monitorar continuamente o desempenho de um sistema e tomar decisões sobre como adicionar ou remover recursos.
• O padrão de Monitoramento de Ponto de Extremidade de Integridade descreve como implementar verificações funcionais em um aplicativo que as ferramentas externas podem acessar por meio de pontos de extremidade expostos em intervalos regulares.
• O padrão fila de prioridade mostra como priorizar mensagens enfileiradas para que solicitações urgentes sejam recebidas e possam ser processadas antes de mensagens menos urgentes.