Tomcat/TomEE создает множество журналов DEBUG в Google KubernetesEngine, но не в обычном Docker.

Мы разворачиваем наше приложение на TomEE 7.0.3 (Tomcat 8.5.11) в образах Docker. Рабочие платформы работают на кластерах Google Kubernetes Engine, а разработка, подготовка и т. Д. Выполняются как простые Docker-контейнеры на серверах Linux.

На производстве мы видим сотни гигабайт в месяц журналов DEBUG, которые TomEE записывает в Stackdriver. Мы не можем воспроизвести это в любой другой системе. Контейнеры на производстве и другие настроены одинаково, за исключением Java Keystore и соединения с базой данных. Конечно, все файлы logging.properties и logback.xml идентичны.

Кажется, что журналы DEBUG поступают только от определенных компонентов. Мы могли бы идентифицировать, например, org.apache.cxf и net.sf.ehcache. Мы попытались внести множество изменений в файлы конфигурации JULI и slf4j, чтобы либо уменьшить уровень журнала для этих компонентов на производстве, либо увеличить его в других системах для локального воспроизведения проблемы. Но, как ни странно, никакие изменения в файлах logging.properties или logback.xml, похоже, не имеют никакого эффекта.

Я не уверен на 100%, но мне кажется, что эти журналы находятся на stdout, потому что в Stackdriver они имеют уровень "INFO"; stderr будет классифицироваться как "ОШИБКА" в соответствии с документацией.

Запуск TomEE в контейнерах происходит через BASH-скрипт оболочки, который в конце вызывает bin/catalina.sh run, Однако мы также попытались исключить скрипт-обертку и запустить TomEE из Dockerfile с помощью CMD ["catalina.sh", "run"], Это не имеет значения.

Примеры этих журналов:

14:56:17.316 [https-jsse-nio-8443-exec-4] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor@21657494
14:56:17.316 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.j.i.JAXRSOutInterceptor - Response content type is: application/json
14:56:17.316 [https-jsse-nio-8443-exec-4] DEBUG o.a.cxf.ws.addressing.ContextUtils - retrieving MAPs from context property javax.xml.ws.addressing.context.inbound
14:56:17.317 [https-jsse-nio-8443-exec-4] DEBUG o.a.cxf.ws.addressing.ContextUtils - WS-Addressing - failed to retrieve Message Addressing Properties from context
14:56:17.317 [https-jsse-nio-8443-exec-4] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor@5ff7053d
14:56:17.317 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.t.http.AbstractHTTPDestination - Finished servicing http request on thread: Thread[https-jsse-nio-8443-exec-4,5,main]

а также

15:07:14.805 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by bus: []
15:07:14.805 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by service: []
15:07:14.805 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by endpoint: [org.apache.cxf.interceptor.MessageSenderInterceptor
@461a6713]
15:07:14.805 [https-jsse-nio-8443-exec-4] DEBUG o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by binding: [org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor
@21657494]
15:07:14.805 [https-jsse-nio-8443-exec-4] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain org.apache.cxf.phase.PhaseInterceptorChain@7780f3e8 was created. Current flow:
  prepare-send [MessageSenderInterceptor]
  marshal [JAXRSOutInterceptor]

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

12:28:33.575 [main] DEBUG o.apache.cxf.common.logging.LogUtils - Using org.apache.cxf.common.logging.Slf4jLogger for logging.
12:28:33.681 [main] INFO  o.a.c.m.j.InstrumentationManagerImpl - registering MBean org.apache.cxf:bus.id=openejb.cxf.bus,type=Bus,instance.id=996125997: org.apache.cxf.bus.ManagedBus@5e17553a
12:28:33.696 [main] INFO  o.a.c.m.j.InstrumentationManagerImpl - registering MBean org.apache.cxf:bus.id=openejb.cxf.bus,type=Bus,instance.id=996125997: javax.management.modelmbean.RequiredModelMBean@189cbd7c
12:28:33.696 [main] INFO  o.a.c.m.j.InstrumentationManagerImpl - registered org.apache.cxf:bus.id=openejb.cxf.bus,type=Bus,instance.id=996125997

Буду очень рад любым советам

  • почему TomEE создает журналы DEBUG в Google Kubernetes Engine, которые не видны ни в одной чистой системе Docker, и
  • почему мы не можем настроить регистрацию этих компонентов с помощью файлов logging.properties и logback.xml.

1 ответ

Stackdriver Logging использует Fluentd в качестве агента ведения журнала. В GKE Fluentd контролируется Мастером. Обычно вам необходимо настроить Fluentd для настройки того, что записывается в Stackdriver; однако, поскольку Fluentd настраивается главным узлом, любые внесенные в него изменения вернутся к своей первоначальной конфигурации. Он также настроен как "поймать все", где он будет регистрировать каждое отдельное действие.

Если вы хотите настроить то, что регистрируется в Stackdriver, я бы предложил использовать исключения журналов.

Изменить: есть два других варианта, которые я могу порекомендовать. Первый - полностью отключить ведение журнала. Вы по-прежнему сможете видеть журналы Kubernetes внутри кластера, такие как журналы pod и container; Тем не менее, вам придется использовать kubectl. Вы больше не будете видеть журналы в журнале Stackdriver.

Другой вариант - создать собственный кластер kubernetes с нуля в GCE. Несмотря на то, что это было бы более изнурительной задачей для установки, но вы будете иметь контроль над главным узлом и сможете настроить протоколирование по своему вкусу.

Другие вопросы по тегам