Развертываем наше приложение на 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 они имеют уровень «INFO»; 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
Буду очень рад любым подсказкам относительно
Stackdriver Logging использует Fluentd в качестве агента ведения журнала. В GKE Fluentd управляется Мастером. Обычно вам нужно настроить Fluentd для настройки того, что регистрируется в Stackdriver; однако, поскольку Fluentd настраивается главным узлом, любые внесенные в него изменения вернутся к исходной конфигурации. Он также настроен как «ловушка для всех», где регистрируется каждое отдельное действие.
Если вы хотите настроить то, что регистрируется в Stackdriver, я бы предложил использовать Исключения журнала.
Изменить: есть еще два варианта, которые я могу порекомендовать. Первый - это отключить ведение журнала полностью. Вы по-прежнему сможете видеть журналы Kubernetes в кластере, такие как журналы модулей и контейнеров; однако вам придется использовать kubectl. Вы больше не будете видеть журналы из Stackdriver Logging.
Другой вариант - создать свой собственный кастомный кластер кубернетов с нуля внутри ГЦЭ. Несмотря на то, что это будет более изнурительная задача для настройки, но вы будете контролировать главный узел и сможете настроить ведение журнала по своему вкусу.