Идентификатор трассировки регистратора Spring AOP с помощью Spring Cloud Sleuth? - PullRequest
0 голосов
/ 31 января 2019

У меня есть несколько микросервисов, работающих с Spring Cloud Sleuth в качестве диспетчера распределенных журналов.Для некоторых микросервисов также включен Spring AOP, в основном с @Around рекомендацией для регистрации времени выполнения методов (код ниже).

Теперь, я, вероятно, упускаю здесь точку AOP и не совсем понимаю, когда действительно срабатывает @Around рекомендация, но возможно ли включить идентификатор трассировки сна в журнал, сгенерированный из @Aspect определенного класса?

Код:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface LogExecutionTime {
}

@Aspect класс (импорт из org.aspectj и org.slf4j):

@Aspect
@Component
public class PerformanceAspect {

private static final Logger logger = LoggerFactory.getLogger(PerformanceAspect.class);

@Around("@annotation(LogExecutionTime)")
public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    final long start = System.currentTimeMillis();

    final Object proceed = joinPoint.proceed();

    final long executionTime = System.currentTimeMillis() - start;

    logger.debug("\n---- Performance aspect ----\n" +
                "method: {}\n" +
                "execution time: {} [ms]\n" +
                "------------------------\n",
            joinPoint.getSignature().getName(), executionTime);

    return proceed;
    }
} 

Версия Spring Boot - 2.0.7.RELEASE (Spring Cloud Finchley.SR2) и связанные с ним (Maven) зависимости:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

@LogExecutionTime устанавливается для некоторых критичных ко времени методов (загрузка файлов в хранилище, внешние вызовы API и т. Д.)..), и было бы очень желательно, если бы для регистрации производительности методов можно было также установить идентификатор трассировки действий пользователя.

Любая помощь приветствуется, спасибо.

ОБНОВЛЕНИЕ:

Существуют идентификаторы трассировки для других журналов, вот пример:

January 31st 2019, 09:44:31.024 dev-backend customer-service    31.01.2019 08:44:50 DEBUG [customer-service,f9c173ae7a161cd6,f9c173ae7a161cd6,false] Request for file upload.

Сразу после этого вот журналы производительности (без идентификатора трассировки):

January 31st 2019, 09:44:50.532 dev-backend customer-service    method: fileUploadAzure

January 31st 2019, 09:44:50.532 dev-backend customer-service    ---- Performance aspect ----

January 31st 2019, 09:44:50.532 dev-backend customer-service    execution time: 19507 [ms]

Импорт в обоих случаях:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

Шаблон журнала из конфигурации:

logging:
  // other config
  pattern:
    console: "%d{dd.MM.yyyy HH:mm:ss} ${LOG_LEVEL_PATTERN:-%5p} %m%n"

1 Ответ

0 голосов
/ 01 февраля 2019

Решение: не используйте разделители строк в журналах (\n), если вы хотите проанализировать все строки с помощью Kibana и увидеть идентификатор трассы в каждой строке.

...