Le traçage des journaux est une question extrêmement importante, j'ai donc joué un peu avec ce code, pour faire correspondre / connecter les identifiants de demande avec ceux de réponse. Cela fonctionne pour suivre les réponses aux demandes de / vers mes ressources ws.rs:
@Provider
public class LoggingFilter implements ContainerRequestFilter, ContainerResponseFilter {
private static final Logger LOG = Logger.getLogger(LoggingFilter.class);
AtomicInteger _id = new AtomicInteger(0);
AtomicInteger requestId = new AtomicInteger(0);
@Context
UriInfo info;
@Context
HttpServerRequest request;
@Override
public void filter(ContainerRequestContext context) {
final String method = context.getMethod();
final String path = info.getPath();
final String address = request.remoteAddress().toString();
// request.ge
final long id = requestId.incrementAndGet();
context.setProperty("prop", id);
LOG.infof("Request %s %s from IP %s", method, path, address);
}
@Override
public void filter(final ContainerRequestContext requestContext, final ContainerResponseContext responseContext) {
String LOGGING_ID_PROPERTY = "prop";
String RESPONSE_PREFIX = "responsePrefix";
final Object requestId = requestContext.getProperty(LOGGING_ID_PROPERTY);
final long id = requestId != null ? (Long) requestId : _id.incrementAndGet();
final StringBuilder b = new StringBuilder();
b.append("text");
printResponseLine(b, "Client response received", id, responseContext.getStatus());
printPrefixedHeaders(b, id, RESPONSE_PREFIX, responseContext.getHeaders());
}
private void printResponseLine(StringBuilder b, String string, long id, int status) {
LOG.info(b.toString() + id);
}
private void printPrefixedHeaders(StringBuilder b, long id, String string, MultivaluedMap<String, Object> headerMap) {
LOG.info(b.toString() + id);
}
}
Mais si j'appelle des points de terminaison de repos (en utilisant des clients de repos) à partir de mon application, la trace est perdue. L'attente est de voir les ID tout au long de la transe du journal de l'origine vers l'aval jusqu'à la réponse au client appelant. Comme c'est le cas avec spring-cloud-sleuth par exemple;
Existe-t-il déjà un moyen de le faire dans Quarkus?
3 Réponses :
Juste pour garder le format de SO, je vais le mettre sous la forme de la réponse (j'ai obtenu une réponse partielle, n'hésitez pas à donner la réponse complète!):
1.
2019-11-28 15:52:36,726 INFO [io.jae.int.rep.LoggingReporter] (hystrix-DefaultCommandGroup-1) Span reported: e4dc03bd6270f8fb:e62c79391515c053:e4dc03bd6270f8fb:1 - com.myconpany.myapp.infrastructure.repository.init.pg.MyStuffPgRepository.config 2019-11-28 15:52:36,726 INFO [io.jae.int.rep.LoggingReporter] (hystrix-DefaultCommandGroup-1) Span reported: e4dc03bd6270f8fb:d512b915e876ae4c:e4dc03bd6270f8fb:1 - com.myconpany.myapp.infrastructure.repository.init.pg.MyAnotherStuffPgRepository.findAll
2.
quarkus.jaeger.service-name = mon-service
quarkus.jaeger.sampler-type = const quarkus.jaeger.sampler-param = 1
quarkus.jaeger.reporter-log-spans = true // cela le fera enregistrer dans les journaux.
3.
Assurez-vous d'ajouter l'annotation @Traced sur les classes / services qui devaient être tracés. Cela appelle le db ou http.
En conséquence, vous obtiendrez quelque chose comme ceci:
<dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-smallrye-opentracing</artifactId> </dependency>
comme je peux le voir, seule la catégorie [io.ja.in.re.LoggingReporter] contient des étendues .. pas d'autres
N'a toujours pas répondu à ceci:
Existe-t-il un moyen d'ajouter span par LOG.info(...) partir du code chaque fois que je le rythme? Je ne vois aucune portée pour ces journaux. J'utilise org.slf4j.LoggerFactory et org.slf4j.LoggerFactory essayé org.jboss.logging.Logger ;
Donc, fondamentalement, LoggingFilter ci-dessus est toujours sans travées.
Je m'attendrais à ce que ContainerRequestContext les ait à l'intérieur. Mais ne voyez pas tout en débogage.
de plus, pour les appels parallèles (celui qui crée dans les nouveaux threads), il y a des étendues qui ne sont pas liées aux threads parents précédents, donc ce n'est pas vraiment pratique et non traçable.
Vous pouvez l'implémenter avec ContainerRequestFilter, MDC et le format de journal
quarkus.log.console.format=%d{yyyy-MM-dd HH:mm:ss.SSS} span_id:%X{SPAN_ID} %-5p [%c{3.}] (%t) %s%e%n
application.properties
@Provider
public class RestRequestFilter implements ContainerRequestFilter {
private final Logger logger = LoggerFactory.getLogger(getClass());
@Inject
Tracer tracer;
@Override
public void filter(ContainerRequestContext containerRequestContext) {
MDC.put("SPAN_ID", tracer.activeSpan().context().toString());
}
}
une fois ce filtre exécuté, tous vos journaux contiendront SPAN_ID
Je pense que la réponse est bien expliquée ici: https://www.gepardec.com/jee-microservices-with-microprofile-opentracing/
// If span decorators are not needed or you have a custom tracing feature
@RegisterRestClient(configKey = "externalResource")
@RegisterProviders(@RegisterProvider(ClientTracingFeature.class))
@Path("/")
public interface ExternalRestResource {
...
}
// If you want to use span decorators
See code snippet Register client side tracing via JAX-RS DynamicFeature
Les informations de suivi sont transmises entre les services via un en-tête Http et le service appelé peut extraire l'étendue active actuelle et y ajouter ses étendues en tant qu'enfant.
Si vous utilisez
quarkus-rest-clientet avezquarkus-smallrye-open-tracingtant que dépendance, alors toutes lesquarkus-smallrye-open-tracingtrace existantes sont propagées à l'appel enfantc'est sympa joué avec trace dans jaeger. mais à la question, comment pourrais-je le faire apparaître dans les journaux de la console avec LOG.info avec ces délais? Je veux peut-être enregistrer les corps de demande / réponse, il ne semble pas stocké dans jaeger.