Capturez la bonne télémétrie de service

Déterminez vos besoins en instrumentation

Tout d’abord, vous devrez déterminer précisément ce que vous devez faire. Chaque service répondant à un besoin commercial doit disposer de suffisamment d'instruments pour répondre aux questions suivantes, et c'est le moment idéal pour déterminer celles auxquelles vous pouvez et ne pouvez pas répondre afin de savoir sur quels domaines vous devez vous concentrer.

• Combien de requests est-ce que je reçois ?
• Combien de messages et requests HTTP dois-je envoyer ?
• Combien de requests aboutissent ?
• Quel est le temps de réponse pour une demande complète ?
• Quel est le temps de réponse pour l’invocation d’une dépendance ?
• Quelle quantité de ressources ce processus devrait-il prendre en fonction de quel nombre de requests?
• Quels sont tous mes points de défaillance ?

Configurez votre instrumentation

Ensuite, il est temps de commencer à configurer votre instrumentation. Chaque agent New Relic fournit une variété d'options de configuration. En règle générale, vous définirez une approche standard pour inclure les agents dans les hôtes infrastructure , les environnements d'exécution d'application et les connexions à votre fournisseur de services cloud . La configuration de l'agent par défaut a été créée pour être largement applicable.

L’une des meilleures façons pour les développeurs d’influencer l’applicabilité du déploiement est de remplacer les options de configuration par défaut de votre instance de service. Voici les options d’instrumentation par défaut à prendre en compte :

Remplacer la configuration par défaut de l’agent

Chaque agent New Relic APM fournit une variété d'options pour modifier la configuration par défaut. L’emplacement le plus cohérent dans lequel nous le faisons est le fichier de configuration qui accompagne chaque installation d’agent. Cependant, vous pouvez également configurer nos agents en transmettant des paramètres de ligne de commande directement à l'exécution de l'instance de service, en utilisant des variables d'environnement ou en appelant des fonctions dans le SDK de l'agent au moment de l'exécution.

Voici les options de configuration de l'agent .NET :

• Utilisation de l'API du SDK New Relic .NET
• Variables d'environnement
• Options du fichier de configuration

Isoler les fonctions de service

Comme l’indique la section Créer un nom de service efficace , l’un des principaux objectifs de l’instrumentation est de configurer l’agent New Relic pour regrouper les contraintes d’exécution similaires en une seule unité nommée. Pour un ensemble spécifique d’entrées, vous devriez obtenir une gamme attendue de résultats mesurables. La mesure dans laquelle nous pouvons confortablement les contenir dans des composants d’exécution de service nommés nous aide grandement à comprendre le comportement normal et à isoler les problèmes.

L'agent New Relic est configuré avec un ensemble d'hypothèses qui créent un espace de nommage pour les transactions lorsqu'elles sont détectées. Ces hypothèses diffèrent selon le langage d’exécution de l’agent. Un bon exemple de la manière dont notre agent Java détermine le nom de la transaction peut être trouvé dans le document de dénomination des transactions de l'agent Java.

Cependant, même après avoir appliqué le protocole de dénomination des transactions d'agent, il peut vous donner un résultat insatisfaisant en fonction de vos besoins. En ajoutant une instrumentation supplémentaire pour nommer la transaction et améliorer son contexte, vous pouvez considérablement améliorer votre compréhension du comportement d'exécution du service.

L'objectif de la dénomination des transactions doit être une vue des transactions APM qui fournit une bonne segmentation des fonctions de services dans une approche facile à comprendre pour les non-développeurs. L'image de répartition des transactions ci-dessus est un bon exemple de segmentation des transactions. Il fournit un suivi détaillé de la quantité de travail effectuée par chaque transaction au sein de la base de code plus large du service ainsi que de la transaction avec un nom simple et convivial qui offre des informations détaillées sur ce que fait la transaction. À mesure que vous en apprenez davantage sur la dénomination des transactions et l’inclusion des attributs, assurez-vous de rendre votre approche de dénomination accessible aux observateurs non techniques des données.

La répartition des transactions dans l’image ci-dessus illustre un mauvais exemple de segmentation du nom de transaction. Dans ce cas, environ 60 % du volume de transactions serait nommé OperationHandler/handle. Tant l'attribution en pourcentage du volume de transactions que la nature générique du nom indiquent qu'il pourrait y avoir trop d'agrégation de transactions sous cet espace de nommage.

Votre objectif est de créer un nom de transaction qui facilite le regroupement des transactions avec le moins de caractéristiques uniques, comme ci-dessous.

L'image de distribution normale illustre des transactions nommées de manière plus ciblée au sein d'un service. Dans ce cas, les temps de réponse des transactions Web sont regroupés plus étroitement, indiquant des caractéristiques d'exécution cohérentes.

Définir des noms de transaction personnalisés

Le service de dénomination des transactions de l'agent New Relic nécessite l'invocation d'un appel d'API de type SetName(String name)au SDK de l'agent New Relic. Chaque agent d'exécution de langage possède sa propre syntaxe et sa propre option pour définir le nom. Consultez l'exemple ci-dessous si vous avez besoin de plus d'informations :

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"));

Il existe une capacité maximale pour les noms de transaction. Lorsque trop de noms de transactions sont signalés, nous tenterons de créer des règles pour regrouper ces noms de transactions. Plus de détails peuvent être trouvés dans le guide de dépannage de l'agent lié aux problèmes de regroupement métrique. Votre stratégie de dénomination de transaction devra faire un compromis sur un certain degré de spécificité s'il existe des milliers de noms de transaction potentiels.

Si vous suspectez un problème de regroupement métrique, ouvrez un dossier d'assistance avec nous et nous serons heureux de travailler avec vous pour isoler la cause du problème de dénomination des transactions.

Capturez les paramètres avec vos transactions

Le nom de la transaction est un moyen puissant de segmenter votre service afin de mieux comprendre son comportement. Il vous permet d'isoler discrètement les fonctionnalités directement dans l'interface utilisateur de New Relic.

Cependant, il existe de nombreuses occasions dans lesquelles vous souhaiterez obtenir un contexte supplémentaire sur la fonction de votre service sans avoir recours à l'isolement du nom de la transaction. Cela peut être accompli en introduisant la capture d’attributs par votre service.

Vous pouvez ajouter l'attribut de paire name:value pour décorer les détails de chaque transaction. L'attribut sera disponible dans chaque événement de transaction via l'interface utilisateur trace de transaction et d'erreurs APM, ou via une requête directe de paramètres à partir du type d'événement Transaction. Voici un exemple des détails de trace de transaction que vous pouvez voir dans l'interface utilisateur des erreurs APM.

Si vous avez développé une segmentation de nom de transaction utile, vous pouvez utiliser le contexte ajouté de l'attribut pour mieux comprendre les entrées, les cohortes ou les segments qui ont conduit à un résultat inattendu.

En plus de pouvoir comprendre le contexte de votre transaction dans l'interface utilisateur APM, l'utilisation de paramètres est utile pour analyser les transactions en interrogeant directement les données de transaction. Ajoutez un attribut personnalisé à chaque transaction pour faciliter l'isolement de conditions spécifiques.

L'approche de capture de paramètres peut également être utilisée avec un système d'indicateurs de fonctionnalités comme Split ou LaunchDarkly. Dans ce cas, lorsque vous implémentez le gestionnaire de décision pour l'indicateur de fonctionnalité, pensez à capturer le contexte de l'indicateur (par exemple, optimized_version = on) qui est appliqué au bloc de code contrôlant la version ou la fonctionnalité que les clients voient.

Par exemple, pour prendre la valeur d'un paramètre de requête HTTP et l'enregistrer en tant qu'attribut personnalisé avec l'agent Java New Relic, vous pouvez utiliser un code similaire à celui-ci :

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"));

Mesurer les composants du service

Le comportement d’une transaction spécifique dans le contexte d’un service est un moyen efficace de garantir le fonctionnement efficace d’un système logiciel. Cependant, une autre façon d’observer le comportement d’un système logiciel est d’examiner le modèle détaillé d’exécution des composants de son implémentation. Les composants du code framework applicatif sont partagés dans l'ensemble du service et l'évaluation continue des performances des composants peut fournir des informations détaillées sur l'état de santé global du service.

Dans New Relic, il existe deux endroits où vous pouvez observer les détails d'exécution des composants. Le dashboard récapitulatif du service dans APM fournit une vue de l'exécution composite du service décomposée par ses composants (par exemple, l'exécution du garbage collection ou les appels de base de données).

Les segments de composants de transaction ont tendance à démontrer un comportement de performance cohérent. Vous pouvez l’utiliser pour détecter un changement de comportement fondamental. Cela peut indiquer un problème sous-jacent. Cela vous permet de trouver la dépendance à travers les parties communes du code exécuté au sein d'un service.

Assurez-vous que vos frameworks soient mesurés

La syntaxe de l'instrumentation du framework est spécifique au langage dans lequel votre service est écrit, mais l'approche générale est cohérente pour tous. Chaque exécution de méthode ou de fonction sur la stack est une opportunité d'ajouter une instrumentation supplémentaire.

Si un segment particulier de logique est requis pour le fonctionnement de votre service ou transaction, envisagez d'encapsuler cet appel avec rappel vers l'agent New Relic afin que l'agent puisse comprendre qu'il a entré un composant de code discret et puisse agréger le temps consommé dans ce composant en conséquence. En transmettant un nom de métrique au rappel, vous créerez une métrique de segment de composant pour votre service et votre transaction.

L'option de dénomination métrique est spécifique au langage d'instrumentation, assurez-vous donc de consulter la documentation du langage spécifique.

Nos agents vous permettent de spécifier un nom métrique personnalisé pour l'instrumentation. Nous utilisons metricName pour déterminer la métrique agrégée pour le composant. L'exemple suivant montre le paramètre metricName transmis à une annotation Java SDK d'agent @Trace.

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

}

Suivez vos appels de service externes

L'instrumentation client fait référence à l'émission d'un appel depuis votre service vers une ressource externe. En règle générale, les agents New Relic connaissent les clients populaires pour les protocoles HTTP, gRPC, de messagerie et de base de données et appliqueront le modèle d'instrumentation approprié pour regrouper les appels vers ces clients en tant que services externes.

Si vous avez écrit votre propre gestionnaire client pour un protocole ou si vous utilisez quelque chose de très nouveau, il se peut que notre agent ne reconnaisse pas le client et n'enregistre pas le comportement de l'appel client. À cette fin, vous devez vérifier les services externes et la base de données dans APM pour représenter toutes les externalités attendues pour votre service.

Il est important de valider que toutes les dépendances de vos services sont représentées ici. Si vous ne voyez pas votre dépendance de service, vous devrez introduire une nouvelle instrumentation pour intercepter l'appel externe afin que votre agent APM puisse le suivre. L'exemple suivant montre comment encapsuler un appel externe dans Golang pour qu'il soit capturé par l'agent.

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

Exemples d’autres suivis d’appels externes d’API d’agent :

• Go ExternalSegment
• Java ExternalParameters
• Python external_trace

Testez votre point de terminaison

Les tests de point de terminaison offrent deux avantages à votre programme d'instrumentation de service :

• Defect detection: En codant un test pour un point de terminaison qui produit un simple résultat vrai/faux, vos opérations peuvent isoler des échecs discrets pour déterminer si l'intégrité de la prestation de services a été compromise.

• Baselining: Les tests synthétiques ou machines fournissent un ensemble prévisible de conditions qui vous permettent d'évaluer la cohérence de votre prestation de services dans une perspective de contrôle.

  Notre monitoring synthétique offre la possibilité de créer une variété de types de tests en utilisant un SDK JavaScript sélénium amélioré. Une fois qu'un script de test basé sur Sélénium a été défini, nous gérerons l'emplacement d'exécution du script ainsi que sa fréquence. Le test synthétique offre une variété d’options de test, chacune avec son propre objectif. Pour plus d'informations, consultez notre documentation monitoring Synthétique.

  Tout d’abord, vous devrez créer une matrice de décision pour les contrôles Synthétique. Il est simple de savoir si vous devez ou non créer un test Synthétique. Vous souhaiterez connaître la première occurrence d’un échec pour une dépendance. Si vous répondez « oui » à l’une des questions suivantes, pensez à créer un contrôle Synthétique dédié :

• Le point de terminaison est-il destiné aux clients ?

• Le point de terminaison invoque-t-il une nouvelle dépendance ?

• Le point de terminaison se trouve-t-il sur une infrastructure réseau différente ?

• Le point de terminaison est-il partagé entre plusieurs services ?

• Le point de terminaison est-il une origine de contenu prise en charge par un CDN ?

  Vous devez alors envisager de mettre en œuvre le test le plus simple possible pour évaluer la disponibilité et l’intégrité du point de terminaison. Par exemple, vous venez de créer un nouveau point de terminaison de service qui fournit le taux de change actuel pour un groupe de devises. Il s'agit d'un simple GET à un point de terminaison qui renvoie un éventail d'objets JSON.

• Exemple de demande : http://example-ip:3000/exchange

• Exemple de réponse :

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

  Copier

  Pour que ce service soit considéré comme opérationnel, il doit répondre aux requests mais également fournir les quatre réponses monétaires. Nous ne nous inquiétons pas du contenu pour le moment, juste du fait que nous récupérons quatre éléments dans l'éventail, un pour chaque devise CDN, USD, EUR et MEX.

  En utilisant monitoring New Relic Synthetics, un script de test d'API pourrait ressembler à ce qui suit :

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

  Copier

  Vous pouvez configurer directement le script Synthetics dans l'interface New Relic, mais nous vous recommandons fortement de conserver vos tests de point de terminaison dans votre système de référentiel source et d'utiliser l'automatisation. Cela garantit que vos tests de point de terminaison accompagnent la nouvelle dépendance de point de terminaison que vos services introduisent dans la fourniture de services de production.