Application Real-Time Monitoring Service:Vinculação de rastros de front-end e back-end com o Managed Service for OpenTelemetry

Pré-requisitos

Instale o agente usando npm. Para mais informações, consulte Configurar o Browser Monitoring com npm.

Contexto

Por padrão, o Browser Monitoring e o Application Monitoring são integrados automaticamente, permitindo visualizar dados de rastreamento de requisições ponta a ponta por meio do Browser Monitoring e do rastreamento de sessões. No entanto, ao usar o protocolo OpenTracing (que utiliza o ID de rastro de código aberto uber-trace-id), é necessário conectar manualmente a configuração JavaScript do Browser Monitoring ao Managed Service for OpenTelemetry. Na aba trace, uma tabela detalha cada chamada com colunas para Application Name, Log Time, Status, IP Address, Call Type, Service Name, pilha de chamadas, perfilamento de threads e linha do tempo (em milissegundos). Por exemplo, uma requisição com tipo de chamada frontend pode levar 30.889 ms e apresentar status anormal (ponto vermelho), enquanto a chamada correspondente de HTTP entry leva 68.964 ms e tem status normal (ponto verde). Clique no ícone de lupa na coluna de pilha de chamadas ou de perfilamento de threads para visualizar informações detalhadas.

Parâmetros

Ao instalar o agente usando npm, configure os seguintes parâmetros.

const BrowserLogger = require('alife-logger');
const __bl = BrowserLogger.singleton({
    pid:"xxx",     // site ID
    appType:"web",
    enableLinkTrace:true,
    linkType: 'tracing', // The tracing type. The default value is 'arms', which uses a proprietary ARMS protocol and sends headers prefixed with 'EagleEye'. You can change this to 'tracing', which uses the Jaeger protocol and sends the 'uber-trace-id' header.
    enableApiCors: true  // Specifies whether to allow cross-origin requests and custom headers. The default value is false. If set to true, your backend service must be configured to support this.
});                      

• enableApiCors:true: Seu serviço de back-end deve suportar requisições de origem cruzada e valores de cabeçalho personalizados. Caso contrário, as requisições falharão, conforme mostra a mensagem de erro a seguir.

  [WDS] Live Reloading enabled.                                              client:52
  Access to fetch at 'http://xxx.xxx.xxx.155:9000/api' from origin 'http://127.0.0.1:9000' has been blocked by CORS policy: Response to preflight request doesn't pass    arms.html:1
  access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors'
  to fetch the resource with CORS disabled.
  GET http://xxx.xxx.xxx.155:9000/api net::ERR_FAILED

  Se uma requisição falhar, consulte o seguinte exemplo de configuração Node.js:

  // Allow cross-origin access to the service.
  app.all('*', function (req, res, next) {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('Access-Control-Allow-Headers', 'Content-Type,uber-trace-id'); // If linkType is 'tracing', the 'uber-trace-id' header must be allowed. If linkType is 'arms', the 'EagleEye-TraceID', 'EagleEye-SessionID', and 'EagleEye-pAppName' headers must be allowed.
    res.header('Access-Control-Allow-Methods', '*');
    next();
  });                    

• enableLinkTrace:true: Quando este parâmetro é definido como true:

  • Se a requisição de API e a página tiverem a mesma origem, o ID de rastro será adicionado automaticamente ao cabeçalho da requisição para habilitar o rastreamento de front-end para back-end.

  • Caso a requisição de API e a página tenham origens diferentes, defina também enableApiCors como true. Além disso, seu serviço de back-end precisa suportar requisições de origem cruzada e cabeçalhos personalizados.

    Importante

    Garanta que todas as requisições estejam configuradas corretamente para funcionar com seu back-end; caso contrário, elas podem falhar. Se ocorrer falha em alguma requisição, consulte o exemplo de configuração Node.js acima.

• linkType:

  • arms (padrão): Utiliza o protocolo proprietário do ARMS e envia vários cabeçalhos que começam com EagleEye.

  • tracing: Utiliza o protocolo Jaeger e envia o cabeçalho uber-trace-id.