Partilhar via

Recomendações para instrumentar uma aplicação

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:07 Crie e implemente um sistema de monitorização para validar escolhas de conceção e informar futuras decisões empresariais e de design. Este sistema captura e expõe telemetria operacional, métricas e registos que emitem a partir da infraestrutura e do código da carga de trabalho.

Guia relacionado: Recomendações para conceber e criar um sistema de monitorização

Este guia descreve as recomendações para permitir a observabilidade da sua aplicação através da instrumentação. Gere telemetria significativa que pode ser ingerida e integrada no seu sistema de monitorização. Ao utilizar a instrumentação, pode recolher informações sem iniciar sessão num servidor de produção remoto para efetuar manualmente o rastreio ou a depuração. Os dados de instrumentação incluem métricas e registos que pode utilizar para avaliar o desempenho, diagnosticar problemas e tomar decisões de carga de trabalho.

Principais estratégias de conceção

Para otimizar a telemetria para a carga de trabalho, instrumente a aplicação para gerar os seguintes dados:

  • Os registos são registos com carimbo de data/hora de eventos discretos. Existem três formas de registos: texto simples, estruturado e binário.

  • Os registos de rastreio distribuído permitem-lhe ver o caminho de um pedido à medida que percorre diferentes serviços e componentes.

  • As métricas são valores numéricos que descrevem um aspeto de um sistema num determinado momento.

Nota

Pode utilizar ferramentas como o Application Insights, o Dynatrace e a Monitorização do Desempenho de Aplicações Elásticas para instrumentar automaticamente a sua aplicação. Estas ferramentas facilitam a instrumentação, mas também podem ser limitativas. Se utilizar uma ferramenta de instrumentação automática, pode adicionar mais capacidades através da instrumentação manual, conforme necessário.

Registos e registos de rastreio distribuídos

Utilize o registo estruturado para integrar facilmente registos em plataformas de monitorização e análise. Instrumente a sua aplicação para que os níveis de verbosidade possam ser alterados. O registo verboso constante pode desperdiçar recursos de armazenamento, pelo que deve ser ativado e desativado conforme necessário para a resolução de problemas.

Os registos de rastreio contêm dados textuais ou dados binários criados a partir de um evento de rastreio, se a aplicação utilizar o Rastreio de Eventos para Windows (ETW). Os registos do sistema geram conteúdos de registo de rastreio a partir de eventos na infraestrutura, como o servidor Web. O conteúdo de registo textual foi concebido para ser legível por humanos, mas deve certificar-se de que está escrito num formato que um sistema automatizado também pode analisar.

Categorize os registos e utilize registos separados para registar a saída de rastreio de cada aspeto operacional do sistema. Se categorizar os seus registos, pode filtrar rapidamente mensagens de registo em vez de processar um único ficheiro longo. Nunca escreva informações que tenham requisitos de segurança diferentes, como informações de auditoria e depuração de dados, para o mesmo registo.

Nota

Um registo pode ser implementado como um ficheiro no sistema de ficheiros ou pode ser mantido noutro formato, como um blob no armazenamento de blobs. As informações de registo também podem ser guardadas no armazenamento estruturado, como linhas numa tabela.

Métricas

As métricas, ou exemplos, são uma contagem de alguns aspetos ou recursos no sistema num momento específico, com uma ou mais etiquetas ou dimensões associadas. Uma única instância de uma métrica não é útil isoladamente, as métricas devem ser capturadas ao longo do tempo. Considere que métricas deve registar e com que frequência. Os dados gerados com demasiada frequência podem impor uma carga pesada no sistema, mas a captura de dados pouco frequente pode fazer com que perca as circunstâncias que levam a um evento significativo. A frequência adequada para capturar dados pode variar de métrica para métrica. Por exemplo, a utilização da CPU num servidor pode variar significativamente de segundo para segundo, mas a utilização elevada só se torna um problema se for consistente ao longo de muitos minutos.

Informações para correlacionar dados

Pode monitorizar facilmente contadores de desempenho individuais e ao nível do sistema, capturar métricas de recursos e obter informações de rastreio de aplicações de vários ficheiros de registo. Algumas monitorizações requerem correlação de dados durante a fase de análise e diagnóstico no pipeline de monitorização. Estes dados podem assumir várias formas e o processo de análise tem de ser fornecido com dados de instrumentação suficientes para mapear estas diferentes formas. Por exemplo, ao nível da arquitetura da aplicação, um ID de thread pode identificar uma tarefa. Numa aplicação, o mesmo trabalho pode estar associado ao ID de utilizador do utilizador que conclui essa tarefa.

É pouco provável que seja um mapa 1:1 entre threads e pedidos de utilizador, uma vez que as operações assíncronas podem reutilizar os mesmos threads para mais do que um utilizador. Para complicar ainda mais as coisas, um único pedido pode correlacionar-se com mais do que um thread à medida que flui pelo sistema. Se for possível, associe cada pedido com um ID de atividade exclusivo propagado pelo sistema como parte do contexto do pedido. A técnica para gerar e incluir IDs de atividade em informações de rastreio depende da tecnologia utilizada para capturar os dados de rastreio.

Todos os dados de monitorização devem ter o carimbo de data/hora da mesma forma. Por razões de consistência, registe todas as datas e horas através da Hora Universal Coordenada.

Nota

Os computadores que operam em fusos horários e redes diferentes podem não ser sincronizados. Não dependa apenas dos carimbos de data/hora para correlacionar os dados de instrumentação que abrangem vários computadores.

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

Considere os seguintes pontos quando decidir que dados de instrumentação precisa de recolher.

Dados legíveis por humanos

Certifique-se de que as informações capturadas por eventos de rastreio são legíveis por computador e humanos. Adote esquemas bem definidos para estas informações para ajudar a implementar o processamento automatizado de dados de registo em todos os sistemas e fornecer consistência para operações e pessoal de engenharia que lê os registos.

Inclua as seguintes informações ambientais nos seus dados:

  • Ambiente de implementação
  • Máquina de processamento
  • Detalhes do processo
  • Pilha de chamadas

Investir na rastreabilidade e correlação

Forneça contexto suficiente, como um ID de atividade associado a uma instância específica de um pedido, para que o programador ou administrador possa determinar a origem de cada pedido.

O contexto de dados também pode incluir informações que são utilizadas para correlacionar uma atividade com o trabalho computacional realizado e os recursos utilizados. Este trabalho pode ultrapassar os limites do processo e da máquina.

Para medição, o contexto deve incluir direta ou indiretamente uma referência ao cliente que causou o pedido. Este contexto fornece informações importantes sobre o estado da aplicação no momento em que os dados de monitorização foram capturados.

Capturar todos os dados relevantes

Registe todos os pedidos e as localizações ou regiões onde são efetuados. Pode utilizar estas informações para ajudar a identificar hotspots específicos da localização. Estas informações também podem ser úteis para determinar se pretende criar novas partições de uma aplicação ou os dados que utiliza.

Registe e capture cuidadosamente os detalhes de exceções. Muitas vezes, as informações de depuração críticas são perdidas devido ao mau processamento de exceções. Capture todos os detalhes de exceção que a aplicação gera, incluindo quaisquer exceções internas ou outras informações contextuais, como a pilha de chamadas, se possível.

Procurar consistência de dados

Os dados consistentes podem ajudá-lo a analisar eventos e correlacioná-los com pedidos de utilizador. Considere utilizar um pacote de registo abrangente e configurável para recolher informações. Os pacotes de registo podem ajudá-lo a evitar a dependência dos programadores para adotarem a sua abordagem à medida que implementam diferentes partes do sistema.

Recolha dados, como volume de entrada/saída, número de pedidos e memória, rede e utilização da CPU, a partir dos principais contadores de desempenho. Alguns serviços de infraestrutura fornecem os seus próprios contadores de desempenho, tais como:

  • O número de ligações a uma base de dados.
  • A taxa de transação.
  • O número de transações que são bem-sucedidas ou falhadas.

As aplicações também podem definir os seus próprios contadores de desempenho.

Considerar dependências externas

Registe todas as chamadas de serviço externo. Podem ser efetuadas chamadas externas para:

  • Sistemas de bases de dados.
  • Serviços Web.
  • Outros serviços ao nível do sistema que fazem parte da infraestrutura.

Registe informações sobre a duração de cada chamada e o êxito ou falha da chamada. Se possível, capture informações sobre todas as tentativas e falhas de repetição para quaisquer erros transitórios que ocorram.

Garantir a compatibilidade do sistema de telemetria

Em muitos casos, as informações de instrumentação são geradas como uma série de eventos e transmitidas para um sistema de telemetria separado para processamento e análise. Normalmente, um sistema de telemetria é independente de qualquer aplicação ou tecnologia específica.

Os sistemas de telemetria utilizam esquemas definidos para analisar informações. O esquema especifica um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. Generalize o esquema para permitir dados provenientes de várias plataformas e dispositivos. Um esquema comum deve incluir campos relevantes para todos os eventos de instrumentação, tais como:

  • Nome do evento.
  • Hora do evento.
  • Endereço IP do remetente.
  • Detalhes necessários para a correlação de eventos, incluindo:
    • ID de Utilizador
    • ID do Dispositivo
    • ID da aplicação

Lembre-se de que muitos dispositivos podem gerar eventos para a mesma aplicação, pelo que o esquema não deve depender do tipo de dispositivo. A aplicação deve suportar a distribuição em roaming ou entre dispositivos. O esquema também pode incluir campos de domínio relevantes para um cenário específico que é comum em todas as aplicações, como:

  • Informações sobre exceções.
  • Eventos de início e fim da aplicação.
  • Êxito ou falha das chamadas à API do serviço Web.

Estabeleça campos de domínio que produzem o mesmo conjunto de eventos para criar um conjunto de relatórios e análises comuns entre aplicações. Poderá ter de configurar um esquema para conter campos personalizados para capturar os detalhes de eventos específicos da aplicação.

O OpenTelemetry é uma coleção neutra em termos de fornecedor de APIs, SDKs e outras ferramentas. Pode utilizar o OpenTelemetry para instrumentar aplicações e gerar telemetria significativa de forma consistente em todos os idiomas. O OpenTelemetry é agnóstico de ferramentas, pelo que é compatível com muitas plataformas de observabilidade, incluindo ofertas open source e comerciais. A Microsoft está a adotar o OpenTelemetry como a ferramenta padrão para instrumentação.

Melhores práticas para instrumentar aplicações

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

  • Facilite a leitura e a análise dos registos. Utilize registos estruturados sempre que possível.

  • Seja conciso e descritivo nas mensagens de registo.

  • Identifique a origem do registo.

  • Adicione informações de carimbo de data/hora à medida que cada registo de registo é escrito.

  • Utilize o mesmo fuso horário e formato para todos os carimbos de data/hora.

  • Categorize os registos e escreva mensagens no local adequado.

  • Não revele informações confidenciais sobre o sistema ou informações pessoais sobre os utilizadores. Limpe estas informações antes de serem registadas, mas mantenha os detalhes relevantes.

  • Registe todas as exceções críticas, mas permita ao administrador ativar e desativar o registo conforme necessário para menos exceções e avisos.

  • Capturar e registar todas as informações lógicas de repetição. Estes dados são úteis na monitorização do estado de funcionamento transitório do sistema.

  • Trace as chamadas de processo, como pedidos para serviços Web externos ou bases de dados.

  • Não misture mensagens de registo com diferentes requisitos de segurança no mesmo ficheiro de registo.

  • Certifique-se de que todas as chamadas de registo são operações de "fire-and-forget " que não bloqueiam o progresso das operações empresariais. Exclua eventos de auditoria desta regra porque são críticos para a empresa.

  • Certifique-se de que o registo é extensível e não tem dependências diretas num destino concreto.

  • Certifique-se de que todos os registos são seguros de falha e não acionam erros em cascata.

  • Trate a instrumentação como um processo iterativo em curso e reveja os registos regularmente.

Considerações

  • Implemente a criação de perfis apenas quando necessário, uma vez que pode impor uma sobrecarga significativa no sistema. Ao utilizar a instrumentação, a criação de perfis regista um evento, como uma chamada de método, sempre que ocorre. No entanto, os registos de amostragem só selecionaram eventos.

  • As seleções de criação de perfis podem ser baseadas no tempo, como uma vez a cada n segundos ou com base na frequência, como uma vez a cada n pedidos. Se os eventos ocorrerem frequentemente, a criação de perfis pode causar demasiados encargos para o sistema e afetar o desempenho geral. Neste caso, a abordagem de amostragem é preferível. No entanto, se a frequência de eventos for baixa, a amostragem pode perdê-los. Neste caso, a criação de perfis pode ser a melhor abordagem.

Facilitação do Azure

A autoinstrução está disponível para muitos tipos de aplicações do Azure e no local monitorizadas com o Application Insights. A função de autoinstrumentação configura automaticamente a sua aplicação para fornecer telemetria avançada ao Application Insights e fornece acesso fácil a experiências como o dashboard da aplicação e o mapa de aplicações. Para obter plataformas de alojamento e linguagens de desenvolvimento suportadas, veja Ambientes, idiomas e fornecedores de recursos suportados.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional