2017-08-13 1 views
1

Le canal de demande est un canal de dispersion. Envoi de la demande à 3 micro-services (passerelles sortantes). Je m'attendais à une durée différente pour les différents services de suivre correctement. J'utilise le limier de printemps. Utilisé DefaultHeaderMapper pour mapper l'en-tête. Mes questions sont: 1. Comment span id est généré, côté serveur/client? Tout document de référence à étudier. 2. Comment résoudre le problème de la double travée dans l'intégration du ressort?Intégration du ressort Span en double

+0

J'ai une idée du fonctionnement de Sleuth. Si TraceId, SpanId ne sont pas passés dans l'en-tête, ils sont générés côté serveur. J'ai donc essayé d'enlever SpanId de Header. Comme j'utilise defaultHttpHeaderMapper, il existe un moyen d'exclure l'en-tête. –

+0

WARN osihsDefaultHttpHeaderMapper - En-tête 'errorChannel' avec la valeur ------ WARN osihsDefaultHttpHeaderMapper - En-tête 'replyChannel' avec la valeur ------ WARN osihsDefaultHttpHeaderMapper - En-tête 'currentSpan' avec la valeur « [Trace: 5cd1817fb7f77f47 , Span: 0744723df67d9f43, Parent: 5cd1817fb7f77f47, exportable: false] '------ WARN osihsDefaultHttpHeaderMapper - En-tête' X-Current-Span 'avec la valeur' ​​[Trace: 5cd1817fb7f77f47, Span: 0744723df67d9f43, Parent: 5cd1817fb7f77f47, exportable : false] ' –

+0

Mais je ne pouvais pas trouver le où X-Current-Span, currentSpan est créé et défini sur DeafultHeaderMapper. Cela ouvre à nouveau un autre problème: comment supprimer ces en-têtes et passer X-B3-TraceId uniquement pour éviter la recréation de trace dans le serveur. –

Répondre

1

L'étendue est générée du côté client lorsque le message est envoyé. Ensuite, il se propage lorsque le message arrive. Si un message est arrivé et qu'il n'y a pas d'en-tête de message, l'intervalle est créé. Tout est écrit dans la documentation (http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html) alors il suffit de lire les docs. En ce qui concerne la résolution des doublons, je n'ai aucune idée de ce dont vous parlez donc je suppose que vous devez fournir une description plus détaillée ou un échantillon pour reproduire le problème.

+0

> Envoyer la demande à 3 micro-services Je suppose que vous faites cela via 'PublishSubscribeChannel'. Dans ce cas, le même message est envoyé 3 fois et, par conséquent, nous avons 3 copies de celui-ci et il est évident avec les mêmes en-têtes, y compris 'span'. Je ne suis pas sûr comment cela fonctionne, mais IMO vous devriez envisager d'utiliser 'span enfant 'ici, car le même message parent est envoyé à différentes branches en aval. Ou .. copier-coller le 'span' actuel à un nouveau pour chaque branche de publication-abonnement. –

+0

Oui, le canal publishSubscribe est le canal de requête pour les trois passerelles sortantes. –

+0

J'ai fourni plus de détails à mon problème, s'il vous plaît trouvez les détails si vous pouvez aider –