Вопросы Теги

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

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

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

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

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

Запуск TomEE в контейнерах происходит через сценарий оболочки BASH, который в конце вызывает bin / catalina.sh run . Однако мы также попытались не использовать сценарий оболочки и запустить TomEE из файла Docker с помощью 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.
0
задан 2 July 2018 в 18:40
1 ответ

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

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

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

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

0
ответ дан 5 December 2019 в 05:47

Теги

Похожие вопросы