de messagerie framework instrumentation

Il existe certains frameworks de messagerie que New Relic ne prend pas en charge par défaut. Si vous êtes intéressé à instrumenter ce framework avec notre API voici quelques lignes directrices à suivre.

Messagerie typique

Dans le cas typique, il y a un processus qui produit un message et un processus qui consomme le message. Voici quelques choses utiles que vous pourriez faire ici. Veuillez noter que vous devez être dans une transaction pour que ces informations soient signalées.

Déclarer la production/consommation comme externe

Vous pouvez créer MessageProduceParameters et MessageConsumeParameters avec des données pertinentes, puis appeler reportAsExternal(Params) pour signaler les appels comme externes.

Par exemple, lors de la production d'un message, cela ressemblerait à :

MessageProduceParameters params = MessageProduceParameters
                                    .library("libraryName")
                                    .destinationType(NAMED_TOPIC)
                                    .destinationName("topicName")
                                    .inboundHeaders(null).build();
NewRelic.getAgent().getTransaction().getTracedMethod().reportAsExternal(params);

Une solution similaire fonctionnerait du côté du consommateur.

Ajouter un message métriques/paramètre personnalisé à la transaction en cours

Si vous souhaitez ajouter des informations utiles à votre transaction actuelle concernant le message, vous pouvez le faire facilement en appelant notre API addCustomParameter(). Cela ressemble à ceci :

NewRelic.addCustomParameter("topic-name", topic);

Passer une traces distribuées en charge

Afin de suivre le travail sur les différents processus/services, le framework de messagerie doit disposer d'un moyen de transmettre des métadonnées avec le message, que ce soit via des en-têtes ou un autre mécanisme. Vous pouvez créer une tracedes charges distribuées côté producteur qui peut être jointe au message et lue côté consommateur. Vous devez être dans une transaction pour que cela fonctionne. Pour ce faire, vous suivrez un modèle comme celui-ci :

@Trace(dispatcher = true)
public void sendData(Producer producer){
    NewRelic.getAgent().getTransaction().insertDistributedTraceHeaders(headers);
    data = new ProducerRecord<String, String>("topic", "key", "value", headers);
    producer.send(data);
}

Et du côté du consommateur :

@Trace(dispatcher = true)
public void processData(ConsumerRecord record){
    NewRelic.getAgent().getTransaction().acceptDistributedTraceHeaders(TransportType.Kafka, record.headers());
}

Cet exemple utilise Kafka, que vous pouvez instrument. Instrumenter les message de file d'attente Kafka fournit des informations sur l'instrumenté.

Cas limites

Il existe certains cas limites qui nécessitent une attention particulière. Vous trouverez ci-dessous des suggestions sur la meilleure façon de les résoudre.

Créez une traces distribuées et recevez ensuite un message

Le problème ici est que vous ne pouvez pas créer une trace de frais distribués, puis accepter une tracede frais distribués dans la même transaction dans cet ordre. Cela signifie qu'il y a deux tentatives de traçage distribué et que vous devez choisir celle que vous voulez. Si vous souhaitez accepter la deuxième charge utile plutôt que de créer la première, vous devez empêcher la création de la première charge utile. Vous pouvez supprimer l'instrumentation personnalisée (si c'est ce qui crée la charge utile) ou désactiver l'instrumentation via notre configuration

Lecture par lots de messages

Pour la consommation par lots de messages, il existe un problème de répartition des frais de traçage que vous acceptez. Si vous acceptez de lier une seule des charges des traces distribuées, vous pouvez accepter n'importe quelle charge du lot, mais le reste de la charge sera perdu. Cependant, si vous souhaitez voir toutes les traces distribuées, vous devrez créer une transaction par message. La deuxième solution pourrait entraîner des frais généraux, alors prenez-le en considération lorsque vous prenez une décision. Une solution comme celle-ci ressemblerait à ceci :

public void processMessages(ConsumerRecords<String, String> records) {
    for(ConsumerRecord<String, String> record: records) {
        processRecord(record);
    }
}

@Trace(dispatcher = true)
private void processRecord(ConsumerRecord<String, String> record) {
    final Iterator<Header> nrHeaders = record.headers().headers("newrelicDTPayload").iterator();
    if (nrHeaders.hasNext()) {
        final Header nrHeader = nrHeaders.next();
        final String payload = new String(nrHeader.value(), StandardCharsets.UTF_8);
        NewRelic.getAgent().getTransaction().acceptDistributedTracePayload(payload);
    }
}

Cela ne fonctionnera que s'il n'y a pas encore de transaction démarrée sur le thread à ce moment. S'il y en a un, accepter une seule charge utile du lot est votre seule solution.

Capture du temps de traitement du message

Si vous souhaitez capturer le temps de traitement d'un message, vous devrez déplacer le travail de traitement dans une méthode, puis trace cette méthode. Par exemple:

public void getMessages(){
    KafkaConsumer consumer = new KafkaConsumer(props);
    consumer.subscribe(Arrays.asList("topic"));
    while (true) {
        ConsumerRecords<String, String> recs = consumer.poll(10000);
        if (recs.count() > 0) {
            for (ConsumerRecord<String, String> rec : recs) {
                processRec(rec);
            }
        }
    }
}

@Trace(dispatcher = true)
private void processRec(ConsumerRecord<String, String> rec) {
    // some processing
}