Princípio e estrutura do APM
Sanfeng soft Zhang Sanfeng
Introdução ao APM
Com a popularidade da arquitetura de microsserviço, uma solicitação geralmente envolve vários serviços, portanto, o monitoramento do desempenho do serviço e a solução de problemas se tornam mais complicados:
Diferentes serviços podem ser desenvolvidos por diferentes equipes e podem até mesmo ser implementados em diferentes linguagens de programação. Os serviços podem ser distribuídos em milhares de servidores, abrangendo vários data centers diferentes. Portanto, alguns ajudam a compreender o comportamento e uso do sistema é necessária. Uma ferramenta para analisar problemas de desempenho para que, quando ocorrer uma falha, você possa localizar e resolver rapidamente o problema. Este é o sistema APM, o nome completo é (Application Performance Monitor, é claro, também chamado de Application Performance Management tools)
AMP foi o primeiro Google Dapper mencionado nos artigos publicados do Google. Dapper é um sistema de rastreamento distribuído no ambiente de produção do Google. Como o Dapper se tornou um sistema de monitoramento de primeira classe, ele ajudou muito os desenvolvedores e equipes de operação e manutenção do Google, então o Google compartilhou o Dapper em um jornal público.
Introdução ao Google Dapper
O que acontecerá após o envio de uma solicitação de consulta na página inicial do Google:
• Uma consulta da Web pode ser iniciada em centenas de servidores de consulta, e cada consulta tem seu próprio Índice.
• Esta consulta pode ser enviada a vários subsistemas, que são usados para processar anúncios, verificação ortográfica ou Encontrar alguns resultados especiais como fotos, vídeos ou notícias
• Filtre de acordo com os resultados da consulta de cada subsistema para obter os resultados finais e, por fim, resuma-os na página
• Em suma:
uma pesquisa global pode chamar milhares de servidores, envolvendo vários serviços. Os usuários são muito sensíveis ao tempo de pesquisa, e a ineficiência de qualquer subsistema leva ao tempo de pesquisa final. Se uma consulta não for demorada, como os engenheiros podem solucionar o problema de qual chamada de serviço está causando isso?
• Em primeiro lugar, o engenheiro pode não conseguir localizar com precisão quais serviços são chamados nesta busca global, porque um novo serviço, ou mesmo um determinado segmento do serviço, pode estar online ou ser modificado a qualquer momento. funções orientadas para o usuário, também pode haver algumas melhorias funcionais, como desempenho ou certificação de segurança.
Em segundo lugar, você não pode exigir que este engenheiro conheça todos os serviços envolvidos nesta pesquisa global. Cada serviço pode ser desenvolvido por uma equipe diferente ou mantido
• Novamente, esses serviços ou servidores expostos também podem ser usados por outros clientes ao mesmo tempo, de modo que o problema de desempenho dessa pesquisa global pode até ser causado por outros aplicativos.
Do exposto, podemos ver que o Dapper precisa:
Implantação onipresente, a importância da onipresença é evidente, pois ao usar um sistema de rastreamento para monitorar, mesmo que apenas uma pequena parte dele não seja monitorada, as pessoas terão grandes dúvidas sobre se o sistema é confiável ou não. Monitoramento contínuo
Três objetivos de design específicos do Dapper
Consumo de baixo desempenho
O impacto dos serviços do componente APM deve ser pequeno o suficiente. O próprio ponto de enterramento da chamada de serviço trará perda de desempenho, o que requer baixa perda de rastreamento de chamadas.Na prática, uma parte da solicitação é selecionada para analisar o caminho da solicitação configurando a taxa de amostragem. Em alguns serviços altamente otimizados, mesmo uma pequena perda pode ser facilmente percebida e pode forçar a equipe de implantação de serviços online a encerrar o sistema de rastreamento.
Transparência do aplicativo, ou seja, o código é menos intrusivo
Ou seja, como um componente de negócios, deve haver o mínimo ou nenhum outro sistema de negócios possível, o que é transparente para os usuários e reduz a carga sobre os desenvolvedores.
Para programadores de aplicativos, não há necessidade de saber que existe um sistema de rastreamento. Para que um sistema de rastreamento seja eficaz, ele deve ser ativamente cooperado pelos desenvolvedores que dependem do aplicativo. O sistema de rastreamento também é muito frágil. Freqüentemente, o sistema de rastreamento tem bugs ou negligência no aplicativo, o que causa problemas com o aplicativo. Atenda à demanda de "implantação onipresente" do sistema de rastreamento.
Escalabilidade
Um excelente sistema de rastreamento de chamadas deve suportar implantação distribuída e ter boa escalabilidade. Quanto mais componentes puderem ser suportados, melhor. Ou forneça uma API de desenvolvimento de plug-in conveniente. Para alguns componentes que não são monitorados, os desenvolvedores de aplicativos também podem estender os seus próprios.
Análise de dados
A análise dos dados deve ser rápida, com tantas dimensões quanto possível. O sistema de rastreamento pode fornecer feedback de informações rápido o suficiente para responder rapidamente a condições anormais no ambiente de produção. A análise abrangente pode evitar o desenvolvimento secundário.
Princípio de rastreamento distribuído de Dapper
método básico
Por exemplo, a relação de chamada mostrada na figura a seguir:
• Esquema de caixa preta: Supondo que não haja informações adicionais além das informações acima a serem rastreadas, técnicas de regressão estatística são usadas para inferir a relação entre os dois. Alguns dados adicionais são necessários para obter precisão suficiente.
• Solução baseada em anotação: Confie no aplicativo ou middleware para marcar claramente um ID global para conectar cada registro com a solicitação do iniciador. A desvantagem é que existe código ***.
Trace tree and span
Na estrutura de árvore de rastreamento do Dapper, o nó da árvore é a unidade básica de toda a arquitetura e cada nó é uma referência ao período. A conexão entre os nós representa o relacionamento direto entre a extensão e sua extensão pai. Embora os spans representem simplesmente os horários de início e término dos spans no arquivo de log, eles são relativamente independentes em toda a estrutura da árvore. Aqui, span é a unidade básica da estrutura de rastreamento e também representa um curto período de tempo. A imagem abaixo mostra a relação de curto prazo de 5 vãos rastreando espécies de árvores em Dapper
A figura acima ilustra a aparência de span em um grande processo de rastreamento. O Dapper registra o nome do período, bem como o ID e o ID pai de cada período para reconstruir o relacionamento entre os diferentes períodos em um processo de rastreamento. Se um intervalo não tiver um ID pai, ele é chamado de intervalo raiz. Todos os spans estão vinculados a uma trilha específica e também compartilham um id de rastreamento (não mostrado na figura). Todos esses IDs são marcados com um número inteiro de 64 bits globalmente exclusivo. Em um rastreamento Dapper típico, esperamos corresponder a um único intervalo para cada RPC, e cada camada de componente adicional corresponde a um nível da estrutura da árvore de rastreamento.
A figura acima mostra uma visão mais detalhada de um ponto de registro de amplitude de rastreamento Dapper típico. Na figura, um intervalo expressa dois RPCs "Helper.Call" (lado do servidor e lado do cliente, respectivamente). A hora de início e de término do período, bem como qualquer informação de tempo RPC, são registrados através da implantação do Dapper na biblioteca de componentes RPC. Se os desenvolvedores de aplicativos escolherem adicionar suas próprias notas (comentário "foo" na figura) (dados de negócios) ao rastreamento, essas informações também serão registradas como outras informações de abrangência.
Ponto enterrado
1. As informações de contexto rastreado são armazenadas em ThreadLocal.
2. Quando o processo de cálculo é atrasado ou assíncrono, o Google chama de volta por meio do fluxo de controle geral para garantir que todos os retornos de chamada possam armazenar as informações de contexto desse rastreamento. Quando a função de retorno de chamada é disparada, desta vez o contexto rastreado será associado ao thread apropriado. Dessa forma, o Dapper pode usar o ID de rastreamento e o ID de abrangência para auxiliar na construção do caminho de chamadas assíncronas.
3. Todos os processos de comunicação do Google são baseados em uma estrutura RPC. Incorpore pontos na própria estrutura RPC para definir todas as extensões.
4. O Dapper permite que os usuários adicionem informações adicionais durante o processo de rastreamento do Dapper para monitorar o comportamento do sistema de nível superior ou ajudar a depurar problemas. Permitimos que os usuários definam anotações com carimbos de data / hora por meio de uma API simples. O código de amostra principal é mostrado na figura abaixo.
5. dapper suporta a anotação de texto conforme mostrado na figura abaixo e também suporta a anotação de mapeamento de valor-chave. Como contadores contínuos, registros de mensagens binárias e dados arbitrários do usuário em execução em um processo.
Coleção de rastreamento
A figura a seguir demonstra o pipeline de coleta Dapper:
Como pode ser visto na figura acima, o registro de rastreamento de Dapper e o processo de pipeline de coleta são divididos em três estágios: os dados de extensão são gravados no arquivo de log local. Em seguida, o daemon de Dapper e os componentes de coleta extraem esses dados do host no ambiente de produção e os gravam no armazém Bigtable de Dapper. Um rastreamento é projetado como uma linha no Bigtable e cada coluna é equivalente a um intervalo. O suporte do Bigtable para layout de tabela esparsa é adequado para essa situação, porque cada rastreamento pode ter qualquer número de extensões. O Dapper também fornece uma API para simplificar o acesso aos dados de rastreamento em nosso warehouse. Os desenvolvedores do Google usam essa API para construir ferramentas de análise para aplicativos gerais e específicos.
Seleção de componente APM
A maioria dos modelos teóricos de monitoramento de link completo no mercado são baseados em documentos do Google Dapper, com foco nos três componentes APM a seguir:
• Zipkin: código aberto, sistema de rastreamento distribuído de código aberto do Twitter, usado para coletar dados de tempo de serviço para resolver o problema de atraso na arquitetura de microsserviço, incluindo: coleta de dados, armazenamento, pesquisa e exibição.
• Pinpoint: Uma ferramenta APM para sistemas distribuídos de grande escala escritos em Java, um componente de rastreamento distribuído de código aberto por coreanos.
• Skywalking: O excelente componente APM produzido internamente é um sistema para rastrear, alertar e analisar a operação comercial do cluster de aplicativos distribuídos JAVA.
Item de comparação
Principais itens de comparação:
Desempenho da sonda
Principalmente a influência do agente no throughput do serviço, CPU e memória. A escala e a dinâmica dos microsserviços aumentam muito o custo da coleta de dados.
A escalabilidade do coletor
Pode ser dimensionado horizontalmente para oferecer suporte a clusters de servidores em grande escala.
Análise abrangente de dados de link de chamada
Fornece visibilidade em nível de código para localizar facilmente pontos de falha e gargalos.
Transparente para o desenvolvimento, fácil de mudar
Adicione novos recursos sem modificar o código, fácil de ativar ou desativar.
Topologia de aplicativo de cadeia de chamadas completa
Detecta automaticamente a topologia do aplicativo para ajudá-lo a descobrir a arquitetura do aplicativo
Como coletar dados
O APM coleta dados do aplicativo por meio de probes de coleta. A detecção de aquisição usa tecnologia de aprimoramento de bytecode para enterrar pontos e gerar dados de chamada. Os dados da chamada são adquiridos e processados pelo agente de coleta ICAgent, e então relatados e apresentados na interface. O relacionamento é mostrado na figura abaixo:
Quais dados são coletados
O APM coleta apenas os dados da cadeia de chamadas de negócios do aplicativo, informações de recursos, atributos de recursos, informações de detecção de memória e dados KPI de solicitação de chamadas e não envolve dados de privacidade pessoais. Os dados coletados são usados apenas para análise de desempenho de APM e diagnóstico de falhas, e não serão usados para outros fins comerciais. A tabela a seguir mostra o escopo e o propósito da coleta de dados.
análise da indústria
Atualmente, existem principalmente dois tipos de empresas principais no mercado externo de APM. Um tipo são os quatro gigantes tradicionais de TI (IBM, HP, CATechnologies, BMC) e o outro tipo são as startups de mercado ITOM, incluindo Dynatrace, NewRelic, AppDynamics, Splunk, etc. Com a melhoria contínua da maturidade do mercado, a estrutura de mercado do mercado de APM é igual à estrutura de mercado geral da ITOM, mostrando que as start-ups estão se acelerando e começando a ocupar uma tendência de mercado líder de mercado.
De acordo com os dados da pesquisa, NewRelic, AppDynamics e Dynatrace, como start-ups, ainda permanecem no quadrante líder do mercado de APM, essas três empresas são as atuais empresas de referência no mercado global de APM.
Na China, Borui, Tingyun, OneAPM e Cloud Wisdom ocupam uma grande fatia do mercado doméstico