Capture la telemetría de servicio adecuada

Determine sus necesidades de instrumentación

Primero, deberá determinar específicamente qué debe hacer. Cada servicio que satisfaga una necesidad empresarial debe tener suficiente instrumentación para responder las siguientes preguntas, y ahora es un buen momento para determinar cuáles puede y no puede responder para saber en qué áreas debe concentrarse.

• ¿Cuántas solicitudes recibo?
• ¿Cuántos mensajes y solicitudes HTTP envío?
• ¿Cuántas solicitudes tienen éxito?
• ¿Cuál es el tiempo de respuesta para una solicitud completa?
• ¿Cuál es el tiempo de respuesta para la invocación de una dependencia?
• ¿Cuántos recursos debería tomar este proceso bajo qué cantidad de solicitudes?
• ¿Cuáles son todos mis puntos de fracaso?

Configura tu instrumentación

A continuación, es hora de comenzar a configurar su instrumentación. Cada agente de New Relic proporciona una variedad de opciones de configuración. Normalmente, definirá un enfoque estándar para incluir el agente dentro de los hosts de la infraestructura, los tiempos de ejecución de las aplicaciones y las conexiones a su proveedor de servicios en la nube. La configuración predeterminada del agente se ha creado para que sea ampliamente aplicable.

Una de las mejores formas para que los desarrolladores influyan en la aplicabilidad del despliegue es anulando las opciones de configuración predeterminadas para su instancia de servicio. Las siguientes son opciones de instrumentación predeterminadas a considerar:

Anular la configuración predeterminada del agente

Cada agente New Relic APM proporciona una variedad de opciones para modificar la configuración predeterminada. La ubicación más consistente donde hacemos esto es el archivo de configuración que acompaña a cada instalación de agente. Sin embargo, también puede configurar nuestros agentes pasando el parámetro de línea de comando directamente al tiempo de ejecución de la instancia de servicio, usando variables de entorno o llamando funciones dentro del SDK del agente en tiempo de ejecución.

Estas son las opciones de configuración del agente .NET:

• Uso de la API del SDK .NET de New Relic
• Variables de entorno
• Opciones del archivo de configuración

Aislar funciones de servicio

Como se indica en la sección Crear un nombre de servicio efectivo , uno de los objetivos principales de la instrumentación es configurar el agente New Relic para agrupar restricciones de tiempo de ejecución similares como una sola unidad con nombre. Para un conjunto específico de entradas, se debe obtener un rango esperado de resultados mensurables. El grado en que podemos contenerlos cómodamente en componentes de tiempo de ejecución de servicios con nombre nos ayuda enormemente a comprender el comportamiento normal y aislar problemas.

El agente New Relic está configurado con un conjunto de suposiciones que crean un espacio de nombres para las transacciones a medida que se detectan. Esas suposiciones difieren entre el tiempo de ejecución del lenguaje del agente. Un buen ejemplo de cómo nuestro agente de Java determina el nombre de la transacción se puede encontrar en el documento de nomenclatura de transacciones del agente de Java.

Sin embargo, incluso después de haber aplicado el protocolo de denominación de transacciones de agentes, es posible que obtenga un resultado insatisfactorio según sus necesidades. Al agregar instrumentación adicional para nombrar la transacción y mejorar su contexto, puede mejorar en gran medida su comprensión del comportamiento de ejecución del servicio.

El objetivo de la denominación de transacciones debe ser una vista de transacciones APM que proporcione una buena segmentación de las funciones de los servicios en un enfoque que sea fácil de entender para quienes no son desarrolladores. La imagen de desglose de transacciones de arriba es un buen ejemplo de segmentación de transacciones. Proporciona un seguimiento detallado de la cantidad de trabajo realizado por cada transacción dentro de la base de código más amplia del servicio, así como la transacción con un nombre sencillo y fácil de usar que ofrece información valiosa sobre lo que hace la transacción. A medida que aprenda más sobre cómo nombrar transacciones e incluir atributos, asegúrese de que su método de nomenclatura sea accesible para observadores no técnicos de los datos.

El desglose de transacciones en la imagen de arriba demuestra un mal ejemplo de segmentación de nombres de transacciones. En este caso, aproximadamente el 60% del volumen de transacciones se denominaría OperationHandler/handle. Tanto la atribución porcentual del volumen de transacciones como la naturaleza genérica del nombre indican que podría haber demasiada agregación de transacciones debajo de ese namespace.

Su objetivo es crear un nombre de transacción que facilite agrupar transacciones con la menor cantidad de características únicas, como las que se muestran a continuación.

La imagen de distribución normal demuestra transacciones nombradas de manera más intencionada dentro de un servicio. En este caso, las transacciones sitio web tiempo de respuesta están agrupadas más estrechamente, lo que indica características de ejecución consistentes.

Definir nombres de transacciones personalizados

El servicio de nombres de transacciones del agente New Relic requiere la invocación de una llamada API similar a SetName(String name)al SDK del agente New Relic. Cada agente de tiempo de ejecución de lenguaje tiene su propia sintaxis y opción para configurar el nombre. Vea el ejemplo a continuación si necesita más información:

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 una capacidad máxima para nombres de transacciones. Cuando se informan demasiados nombres de transacciones, intentaremos crear reglas para agrupar esos nombres de transacciones. Se pueden encontrar más detalles en la guía de resolución de problemas del agente relacionada con temas de agrupación métrica. Su estrategia de denominación de transacciones tendrá que compensar un grado de especificidad si hay miles de nombres de transacciones potenciales.

Si sospecha que hay un problema de agrupación métrica, abra un caso de soporte con nosotros y estaremos encantados de trabajar con usted para aislar la causa del problema de nombre de transacción.

Captura parámetros con tu transacción

El nombre de la transacción es una forma poderosa de segmentar su servicio para poder comprender mejor su comportamiento. Le permite aislar discretamente la funcionalidad directamente en la UI de New Relic.

Sin embargo, hay muchas ocasiones en las que querrás obtener contexto adicional sobre la función de tu servicio sin tener que aislar el nombre de la transacción. Esto se puede lograr introduciendo la captura de atributos por parte de su servicio.

Puedes agregar name:value atributo de par para decorar los detalles de cada transacción. El atributo estará disponible en cada evento de transacción a través de la UI de traza de la transacción y errores de APM, o mediante consulta directa del parámetro del tipo de evento Transaction. Aquí hay un ejemplo de los detalles de la traza de la transacción que puede ver en la UI de errores de APM.

Si ha desarrollado una segmentación de nombres de transacciones útil, puede utilizar el contexto agregado del atributo para comprender mejor las entradas, cohortes o segmentos que llevaron a un resultado inesperado.

Además de poder comprender el contexto de su transacción dentro de la UI de APM, el uso de parámetros es útil para analizar transacciones consultando los datos de la transacción directamente. Agregue un atributo personalizado a cada transacción para que sea más fácil aislar condiciones específicas.

El enfoque de captura de parámetros también se puede utilizar con sistemas de banderas características como Split o LaunchDarkly. En este caso, mientras implementa el controlador de decisiones para la marca de característica, considere capturar el contexto de la marca (por ejemplo, optimized_version = on) que se aplica al bloque de código que controla la versión o característica que ven los clientes.

Por ejemplo, para tomar el valor de un parámetro de solicitud HTTP y guardarlo como un atributo personalizado con el agente de Java New Relic, puede usar un código similar 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 los componentes del servicio

El comportamiento de una transacción específica dentro del contexto de un servicio es una forma poderosa de garantizar que un sistema de software esté funcionando de manera efectiva. Sin embargo, otra forma de observar el comportamiento de un sistema de software es revisar el modelo detallado de ejecución de componentes de su implementación. Los componentes del código framework de la aplicación se comparten en todo el servicio y la evaluación continua del rendimiento de los componentes puede proporcionar información valiosa sobre el estado general del servicio.

En New Relic, hay dos lugares donde puede observar los detalles de ejecución de los componentes. El dashboard de resumen del servicio en APM proporciona una vista de la ejecución compuesta del servicio desglosada por sus componentes (por ejemplo, ejecución de recolección de basura o llamadas a base de datos).

Los segmentos de componentes de transacciones tienden a demostrar un comportamiento de rendimiento consistente. Puede emplear esto para detectar un cambio en el comportamiento fundamental. Esto puede indicar un problema subyacente. Esto le permite encontrar dependencia a través de las partes comunes en el código que se ejecuta dentro de un servicio.

Asegúrese de que su marco esté medido

La sintaxis para la instrumentación framework es específica del lenguaje en el que está escrito su servicio, pero el enfoque general es consistente en todos ellos. Cada ejecución de método o función en la stack es una oportunidad para agregar instrumentación adicional.

Si se requiere un segmento particular de lógica para la función de su servicio o transacción, considere envolver esa llamada con devolución de llamada al agente de New Relic para que el agente pueda entender que ha ingresado un componente de código discreto y pueda agregar el tiempo consumido. dentro de ese componente en consecuencia. Al pasar un nombre de métrica a la devolución de llamada, creará una métrica de segmento de componente para su servicio y transacción.

La opción de denominación métrica es específica del lenguaje de instrumentación, así que asegúrese de consultar la documentación del idioma específico.

Nuestro agente le permitirá especificar un nombre métrico personalizado para la instrumentación. Usamos metricName para determinar la métrica agregada del componente. El siguiente ejemplo demuestra cómo se pasa el parámetro metricName a una anotación @Trace del SDK de 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();
    }

}

Realice un seguimiento de sus llamadas de servicio externo

La instrumentación del cliente se refiere a realizar una llamada desde su servicio a un recurso externo. Generalmente, los agentes de New Relic conocen clientes populares para HTTP, gRPC, mensajería y protocolos de base de datos y aplicarán el patrón de instrumentación apropiado para agregar llamadas a esos clientes como servicios externos.

Si ha escrito su propio controlador de cliente para un protocolo o está utilizando algo muy nuevo, es posible que nuestro agente no reconozca al cliente y registre el comportamiento de la llamada del cliente. Con este fin, debe verificar los servicios externos y la base de datos dentro de APM para representar todas las externalidades esperadas para su servicio.

Es importante validar que aquí estén representadas todas las dependencias de tus servicios. Si no ve la dependencia de su servicio, deberá introducir nueva instrumentación para interceptar la llamada externa para que su agente APM pueda rastrearla. El siguiente ejemplo demuestra cómo envolver una llamada externa en Golang para que el agente la capture.

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()
}

Ejemplos de otras API del agente de rastreo externo de llamadas:

• Go ExternalSegment
• Java ExternalParameters
• Python external_trace

Prueba tu extremo

Extremo testing proporciona dos beneficios a su programa de instrumentación de servicio:

• Defect detection: Al codificar una prueba para un extremo que produce un resultado simple de verdadero/falso, sus operaciones pueden aislar fallas discretas para determinar si la integridad de la prestación del servicio se ha visto comprometida.

• Baselining: Las pruebas sintéticas o de máquina proporcionan un conjunto predecible de condiciones que le permiten evaluar la coherencia de la prestación de su servicio desde una perspectiva de control.

  Nuestro monitoreo sintético ofrece la capacidad de crear una variedad de tipos de pruebas empleando un SDK de JavaScript de Selenium mejorado. Una vez que se haya definido un script de prueba basado en Selenium, administraremos la ubicación de ejecución del script, así como su frecuencia. La prueba sintética ofrece una variedad de opciones de prueba, cada una con su propio enfoque. Para obtener más información, consulte nuestra documentación de monitoreo sintético.

  Primero, deberá crear una matriz de decisión para los checks sintéticos. Saber si necesita o no crear checks sintéticos es sencillo. Querrá saber la primera vez que se produce un error en una dependencia. Si responde "sí" a cualquiera de las siguientes preguntas, considere crear controles sintéticos dedicados:

• ¿El extremo está orientado al cliente?

• ¿El extremo invoca una nueva dependencia?

• ¿El extremo está en una infraestructura de red diferente?

• ¿El extremo se comparte entre múltiples servicios?

• ¿Es el extremo un origen de contenido soportado por una CDN?

  Luego debería considerar implementar la prueba más simple posible para evaluar la disponibilidad e integridad de los extremos. Por ejemplo, acaba de crear un nuevo Servicio extremo que proporciona el tipo de cambio actual para un grupo de monedas. Este es un GET simple en un extremo que devuelve una matriz de objetos JSON.

• Ejemplo de solicitud: http://example-ip:3000/exchange

• Ejemplo de respuesta:

  [
      {
        "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
      }
    ]

  Copia

  Para que este servicio se considere operativo, debe responder a las solicitudes pero también proporcionar respuestas en las cuatro monedas. No estamos preocupados por el contenido en este momento, solo por el hecho de que recuperamos cuatro elementos en la matriz uno, para cada moneda CDN, USD, EUR y MEX.

  Al utilizar el monitoreo sintético de New Relic, un script de prueba de API podría tener el siguiente aspecto:

  /**
    * 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);

  Copia

  Puedes configurar directamente el script Sintético en la interfaz New Relic , pero te recomendamos encarecidamente que mantengas tus pruebas extremas dentro de tu sistema de repositorio de origen y emplees automatización. Esto garantiza que sus pruebas extremas acompañen la nueva dependencia extrema que sus servicios introducen en la capacidad del servicio de producción.