Capture a telemetria de serviço certa

Determine suas necessidades de instrumentação

Primeiro, você precisará determinar especificamente o que precisa fazer. Todo serviço que atenda a uma necessidade de negócios deve ter instrumentação suficiente para responder às seguintes perguntas, e agora é um bom momento para definir quais você pode ou não responder, para saber em quais áreas precisa se concentrar.

• Quantas solicitações recebo?
• Quantas mensagens e solicitações HTTP devo enviar?
• Quantas solicitações foram bem-sucedidas?
• Qual é o tempo de resposta para uma solicitação completa?
• Qual é o tempo de resposta para invocação de uma dependência?
• Quanto recurso esse processo deve consumir sob qual número de solicitações?
• Quais são todos os meus pontos de falha?

Configure sua instrumentação

Em seguida, é hora de começar a configurar sua instrumentação. Cada agente New Relic oferece uma variedade de opções de configuração. Normalmente, você definirá uma abordagem padrão para incluir o agente em hosts de infraestrutura, tempos de execução de aplicativos e conexões com seu provedor de serviço em nuvem. A configuração padrão do agente foi criada para ser amplamente aplicável.

Uma das melhores maneiras para os desenvolvedores influenciarem a aplicabilidade da implantação é substituindo as opções de configuração padrão da sua instância de serviço. A seguir estão as opções de instrumentação padrão a serem consideradas:

newrelic.appname = PORTAL_AMER

newrelic.appname = PORTAL_EMEA

newrelic.appname = PORTAL_MAIN

newrelic.appname = PORTAL_ADMIN

newrelic.appname = PORTAL_MAIN_V112

newrelic.appname = PORTAL_MAIN_V115

newrelic.appname = PORTAL_NYC_DC

newrelic.appname = PORTAL_REALLY_BIG_FOOTPRINT

Substituir a configuração padrão do agente

Cada agente New Relic APM oferece uma variedade de opções para modificar a configuração padrão. O local mais consistente para fazer isso é o arquivo de configuração que acompanha a instalação de cada agente. No entanto, você também pode configurar nossos agentes passando parâmetros de linha de comando diretamente para o tempo de execução da instância de serviço, usando variáveis de ambiente ou chamando funções dentro do SDK do agente em tempo de execução.

Aqui estão as opções de configuração do agente .NET:

• Usando a API do SDK .NET da New Relic
• Variáveis ambientais
• Opções de arquivo de configuração

Isolar funções de serviço

Conforme indicado na seção Criar um nome de serviço efetivo , um dos principais objetivos da instrumentação é configurar o agente New Relic para agrupar restrições de tempo de execução semelhantes como uma única unidade nomeada. Para um conjunto específico de insumos, você deve obter uma gama esperada de resultados mensuráveis. O grau em que podemos contê-los confortavelmente em componentes de tempo de execução de serviço nomeados nos ajuda muito a compreender o comportamento normal e a isolar problemas.

O agente New Relic é configurado com um conjunto de suposições que criam namespace para transação à medida que são detectadas. Essas suposições diferem entre o tempo de execução da linguagem do agente. Um bom exemplo de como nosso agente Java determina o nome da transação pode ser encontrado no documento de nomenclatura da transação do agente Java.

No entanto, mesmo depois de aplicar o protocolo de nomenclatura de transação do agente, ele poderá fornecer um resultado insatisfatório dependendo de suas necessidades. Ao adicionar instrumentação adicional para nomear a transação e melhorar seu contexto, você pode melhorar bastante sua compreensão do comportamento de execução do serviço.

O objetivo do naming de transação deve ser uma visão de transação de APM que proporcione uma boa segmentação das funções de serviços em uma abordagem que seja fácil de entender para quem não está envolvido. A imagem de detalhamento da transação acima é um bom exemplo de segmentação da transação. Ele fornece rastreamento detalhado da quantidade de trabalho realizado por cada transação dentro da base de código mais ampla do serviço, bem como da transação com um nome simples e amigável ao usuário que oferece insights sobre o que a transação faz. À medida que você aprende mais sobre nomenclatura e inclusão de atributo, certifique-se de tornar sua abordagem de nomenclatura acessível para observadores não técnicos dos dados.

O detalhamento da transação na imagem acima demonstra um mau exemplo de segmentação de nomes de transação. Nesse caso, você teria cerca de 60% do volume de transação sendo denominado OperationHandler/handle. Tanto a atribuição percentual do volume de transação quanto a natureza genérica do nome indicam que pode haver muita agregação de transação sob esse namespace.

Seu objetivo é criar um nome de transação que facilite o agrupamento de transações com o menor número de características exclusivas, como abaixo.

A imagem de distribuição normal demonstra transações nomeadas de forma mais proposital dentro de um serviço. Neste caso, as transações da web tempo de resposta são agrupadas de forma mais próxima, indicando características de execução consistentes.

Definir nomes de transação personalizados

O serviço de nomenclatura de transação do agente New Relic requer a invocação de uma chamada de API semelhante a SetName(String name)para o SDK do agente New Relic. Cada agente de tempo de execução de linguagem possui sua própria sintaxe e opção para configurar o nome. Veja o exemplo abaixo se precisar de mais informações:

com.newrelic.agent.Agent.LOG.finer("[my query handler] Renaming transaction based on an important query parameter");

com.newrelic.api.agent.NewRelic.setTransactionName("Query Handler_" + (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));

Existe uma capacidade máxima para a transação de nomes. Quando muitos nomes de transação estiverem sendo relatados, tentaremos criar regras para agrupar esses nomes de transação. Mais detalhes podem ser encontrados no guia de resolução de problemas de agentes relacionados a questões de agrupamento métrico. Sua estratégia de nomenclatura de transação terá que compensar um certo grau de especificidade se houver milhares de nomes de transação em potencial.

Caso você suspeite de um problema de agrupamento métrico, abra um caso de suporte conosco e teremos prazer em trabalhar com você para isolar a causa do problema de nomenclatura da transação.

Capture parâmetro com sua transação

O nome da transação é uma maneira poderosa de segmentar seu serviço para entender melhor seu comportamento. Ele permite isolar discretamente a funcionalidade diretamente na interface do New Relic.

No entanto, há muitas ocasiões em que você desejará obter algum contexto adicional sobre a função do seu serviço sem precisar isolar o nome da transação. Isso pode ser conseguido introduzindo a captura de atributo em seu serviço.

Você pode adicionar name:value pares de atributos para decorar os detalhes de cada transação. O atributo estará disponível em cada evento de transação através da interface de trace da transação e erros do APM, ou através de consulta direta de parâmetro do tipo de evento Transaction . Aqui está um exemplo dos detalhes do rastreamento da transação que você pode ver na interface de erros do APM.

Se você desenvolveu uma segmentação de nome de transação útil, poderá usar o contexto adicionado do atributo para entender melhor as entradas, coortes ou segmentos que levaram a um resultado inesperado.

Além de poder entender o contexto da sua transação dentro da interface do APM, o uso de parâmetros é útil para analisar transações consultando diretamente os dados da transação. Adicione um atributo personalizado a cada transação para facilitar o isolamento de condições específicas.

A abordagem de captura de parâmetro também pode ser usada com sistemas de flag de recurso como Split ou LaunchDarkly. Nesse caso, ao implementar o manipulador de decisão para o sinalizador de recurso, considere capturar o contexto do sinalizador (por exemplo, optimized_version = on) que está sendo aplicado ao bloco de código que controla a versão ou recurso que os clientes veem.

Por exemplo, para pegar o valor de um parâmetro de solicitação HTTP e salvá-lo como um atributo personalizado com o agente Java New Relic, você pode usar um código semelhante a este:

com.newrelic.agent.Agent.LOG.finer("[my query handler] Adding an Attribute to transaction based on an important query parameter");

com.newrelic.api.agent.NewRelic.addCustomParameter("ImportantParm", (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));

Medir componentes de serviço

O comportamento de uma transação específica no contexto de um serviço é uma forma poderosa de garantir que um sistema de software esteja operando de maneira eficaz. Entretanto, outra maneira de observar o comportamento de um sistema de software é revisar o modelo detalhado de execução dos componentes de sua implementação. Os componentes do código framework do aplicativo são compartilhados por todo o serviço, e a avaliação contínua do desempenho dos componentes pode fornecer insights sobre a integridade geral do serviço.

No New Relic, há dois lugares onde você pode observar os detalhes de execução dos componentes. O dashboard de resumo de serviço no APM fornece uma visão da execução composta do serviço dividida por suas partes componentes (por exemplo, execução de coleta de lixo ou chamadas de banco de dados).

Os segmentos de componentes de transação tendem a demonstrar um comportamento de desempenho consistente. Você pode usar isso para detectar uma mudança no comportamento fundamental. Isso pode indicar um problema subjacente. Isso permite que você encontre dependência por meio das partes comuns do código em execução em um serviço.

Certifique-se de que sua estrutura seja medida

A sintaxe da instrumentação framework é específica para a linguagem em que seu serviço está escrito, mas a abordagem geral é consistente em todas elas. Cada execução de método ou função na stack é uma oportunidade para adicionar instrumentação adicional.

Se um determinado segmento de lógica for necessário para a função do seu serviço ou transação, considere agrupar essa chamada com retorno de chamada para o agente New Relic para que o agente possa entender que inseriu um componente de código discreto e possa agregar o tempo consumido dentro desse componente adequadamente. Ao passar um nome de métrica para o retorno de chamada, você criará uma métrica de segmento de componente para seu serviço e transação.

A opção de nomenclatura de métrica é específica da linguagem de instrumentação, portanto, consulte a documentação específica da linguagem.

Nosso agente permite que você especifique um nome métrico personalizado para a instrumentação. Usamos metricName para determinar a métrica agregada do componente. O exemplo a seguir demonstra o parâmetro metricName sendo transmitido para uma anotação @Trace do SDK do agente Java.

@Weave
public abstract class MQOutboundMessageContext implements OutboundTransportMessageContext {

    @Trace(dispatcher = true, metricName="MQTransport")
    public void send(final TransportSendListener listener) throws TransportException {
        try {
            NewRelic.getAgent().getTracedMethod().setMetricName("Message", "MQ", "Produce");
            MQHelper.processSendMessage(this, NewRelic.getAgent().getTracedMethod());
        } catch (Exception e) {
            NewRelic.getAgent().getLogger().log(Level.FINE, e, "Unable to set metadata on outgoing MQ message");
        }

        Weaver.callOriginal();
    }

}

Rastreie suas chamadas de serviço externas

A instrumentação do cliente refere-se a fazer uma chamada do seu serviço para um recurso externo. Geralmente, os agentes da New Relic conhecem clientes populares para protocolos HTTP, gRPC, mensagens e banco de dados e aplicarão o padrão de instrumentação apropriado para agregar chamadas a esses clientes como serviços externos.

Se você escreveu seu próprio manipulador de cliente para um protocolo ou está usando algo muito novo, nosso agente pode não reconhecer o cliente e registrar o comportamento da chamada do cliente. Para tanto, você deve verificar os serviços externos e o banco de dados dentro do APM para representar todas as externalidades esperadas para o seu serviço.

É importante validar que todas as dependências dos seus serviços estão aqui representadas. Se você não vir sua dependência de serviço, precisará introduzir uma nova instrumentação para interceptar a chamada externa para que seu agente APM possa rastreá-la. O exemplo a seguir demonstra o encapsulamento de uma chamada externa em Golang para captura pelo agente.

package main

import (
    "net/http"

    "github.com/newrelic/go-agent/v3/newrelic"
)

func currentTransaction() *newrelic.Transaction {
    return nil
}

func main() {
    txn := currentTransaction()
    client := &http.Client{}
    request, _ := http.NewRequest("GET", "http://www.example.com", nil)
    segment := newrelic.StartExternalSegment(txn, request)
    response, _ := client.Do(request)
    segment.Response = response
    segment.End()
}

Exemplos de outro rastreamento de chamadas externas da API do agente:

• Go ExternalSegment
• Java ExternalParameters
• Python external_trace

Teste seu terminal

O teste de endpoint oferece dois benefícios ao seu programa de instrumentação de serviço:

• Defect detection:

  Ao codificar um teste para um endpoint que produz um resultado simples de verdadeiro/falso, suas operações podem isolar falhas discretas para determinar se a integridade da entrega do serviço foi comprometida.

• Baselining:

  Os testes sintéticos ou de máquina fornecem um conjunto previsível de condições que permitem avaliar a consistência da entrega do seu serviço a partir de uma perspectiva de controle.

  Nosso monitoramento sintético oferece a capacidade de criar uma variedade de tipos de testes, empregando um Selenium JavaScript SDK aprimorado. Depois que um script de teste baseado em Selenium for definido, gerenciaremos o local de execução do script, bem como sua frequência. O teste sintético oferece uma variedade de opções de teste, cada uma com seu foco. Para obter mais informações, consulte nossa documentação de monitoramento sintético.

  Primeiro, você precisará criar uma matriz de decisão para verificações sintéticas. Saber se você precisa ou não criar verificações sintéticas é simples. Você vai querer saber a primeira ocorrência de falha em uma dependência. Se você responder “sim” a qualquer uma das perguntas a seguir, considere a criação de um relatório dedicado de verificações sintéticas:

• O endpoint é voltado para o cliente?

• O endpoint invoca nova dependência?

• O endpoint está em uma infraestrutura de rede diferente?

• O endpoint é compartilhado entre vários serviços?

• O endpoint é uma origem de conteúdo suportada por uma CDN?

  Você deve então considerar a implementação do teste mais simples possível para avaliar a disponibilidade e integridade do endpoint. Por exemplo, você acabou de criar um novo endpoint de serviço que fornece a taxa de câmbio atual para um grupo de moedas. Este é um GET simples em um endpoint que retorna uma matriz de objetos JSON.

• Exemplo de solicitação: http://example-ip:3000/exchange

• Exemplo de resposta:

[
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bf97f61c22f4fb5beb5c9",
    "name": "cdn",
    "Created_date": "2021-07-12T18:10:07.488Z",
    "__v": 1
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb2a61c22f4fb5beb5ca",
    "name": "usd",
    "Created_date": "2021-07-12T18:17:14.224Z",
    "__v": 0.80
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb3261c22f4fb5beb5cb",
    "name": "eur",
    "Created_date": "2021-07-12T18:17:22.476Z",
    "__v": 0.68
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb3761c22f4fb5beb5cc",
    "name": "mex",
    "Created_date": "2021-07-12T18:17:27.009Z",
    "__v": 15.97
  }
]

Para que este serviço seja considerado operacional, necessita de responder às solicitações, mas também de fornecer as respostas em quatro moedas. Não estamos preocupados com o conteúdo no momento, apenas com o fato de termos quatro elementos de volta na matriz um, para cada moeda CDN, USD, EUR e MEX.

Usando o monitoramento sintético da New Relic, um script de teste de API poderia ter a seguinte aparência:

/**
* This script checks to see if we get the currency data from the endpoint.
*/
var assert = require('assert');
var myQueryKey = 'secret_key';
var options = {
  uri: 'http://example_ip:3000/exchange',
  headers: {
    'X-Query-Key': myQueryKey,
    'Accept': 'application/json'
  }
};

function callback (err, response, body){
  var data = JSON.parse(body);
  var info = body;
  if (Array.isArray(data)) {
    if (data.length !== 4) {
      assert.fail('Unexpected results in API Call, result was ' + JSON.stringify(data));
    }
  }
}

$http.get(options, callback);

Você pode configurar diretamente o script Sintético na interface do New Relic, mas é altamente recomendável manter seus testes de endpoint dentro do sistema de repositório de origem e empregar automação. Isso garante que seu teste de endpoint acompanhe a nova dependência de endpoint que seus serviços introduzem na entrega de serviços de produção.