Журналы движка приложения Spring boot неправильно отформатированы

Я развернул приложение spring boot 2 на appengine, и оно отлично работает.

Единственное, что стандартный механизм ведения журнала конфликтует с системой ведения журнала gcp. Я получаю сотни информационных журналов, даже когда возникает исключение или предупреждение.

журналы

Думаю, проблема в том, что журналы очень длинные и начинаются с каких-то ненужных данных.

В моей конфигурации я использую lombok + Slf4j для входа в свое приложение, и я думаю, что возврат в систему включен по умолчанию, поскольку у меня есть spring-boot-starter-web.

у моего pom есть эти зависимости:

   <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-rest</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-tomcat</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-gcp-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-gcp-starter-data-datastore</artifactId>
        </dependency>

        <!--Standard dep-->

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.google.appengine</groupId>
            <artifactId>appengine-api-1.0-sdk</artifactId>
            <version>${appengine.target.version}</version>
        </dependency>
        <dependency>
            <groupId>com.google.api-client</groupId>
            <artifactId>google-api-client-appengine</artifactId>
            <version>1.29.2</version>
        </dependency>

        <!--Provided-->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>

        <!--Test related-->

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

а в папке ресурсов есть файл logging.properties, как это предлагается в страница загрузки Spring для движка приложения (избегайте ошибок переполнения стека во время запуска)

С той лишь разницей, что если я исключу jul-to-slf4j, я не увижу никаких логов в консоли.

Кто-нибудь еще может указать мне в правильном направлении?


spring-boot java spring google-app-engine google-cloud-logging
person Pievis    schedule 05.07.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Добавьте файл logback.xml в папку ресурсов вашего проекта. Spring boot загрузит это при запуске и переопределит конфигурацию входа в систему по умолчанию, связанную с весенней загрузкой.

Внутри вашего logback.xml вы можете определить свой собственный шаблон ведения журнала и удалить ненужные данные.

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <root level="info">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

В приведенном выше примере не будет метки времени или потока в шаблоне журнала. Вы можете изменить это в соответствии с вашим конкретным вариантом использования.

ОБНОВЛЕНИЕ

В качестве альтернативы вы можете добиться этого, переопределив шаблон журнала через свойство приложения.

Для консольного ведения журнала

logging.pattern.console=%-5level %logger{36} - %msg%n

Для ведения журнала файлов

logging.pattern.file=%-5level %logger{36} - %msg%n

Вы можете найти объяснение значения каждой части шаблона ведения журнала здесь: https://logback.qos.ch/manual/layouts.html#conversionWord

person Michael McFadyen    schedule 06.07.2019
comment
После некоторых тестов я не думаю, что проблема в логбэке, возможно, что-то это меняет мои логи до этого. Я вижу, что журналы меняются, как вы предлагаете, когда я запускаю его локально на удаленном компьютере, но в удаленном режиме в журналах GCP у меня всегда есть бесполезная информация перед журналами, например: [h ~ projectx-dev / 1-0-0.419452159733438541]. ‹Stdout ›: - person Pievis; 08.07.2019
comment
извини, чувак, у меня нет опыта работы с движком приложений, поэтому я не могу здесь помочь. - person Michael McFadyen; 08.07.2019

arrow_upward
1
arrow_downward

В конце концов, я не нашел надлежащего способа отображать журналы на консольном принтере в стандартном движке приложений с пружинной загрузкой. Однако при использовании api stackdriver журналы действительно выглядят красивее.

Я сделал следующее:

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

И в logback-spring.xml

<include resource="org/springframework/cloud/gcp/autoconfigure/logging/logback-appender.xml"/>
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>

<springProfile name="local">
    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>
</springProfile>

<springProfile name="!local">
    <root level="INFO">
        <appender-ref ref="STACKDRIVER"/>
    </root>
</springProfile>

However, the main request log level don't show the highest log level (but the "any log value") making filtering harder. On the other end, error reporting works because the inner logs have the proper level set.

person Pievis    schedule 26.07.2019