Disable DEBUG Log Level in keycloak container logs

Environment details:

EKS: 1.29 version
Keycloak Version: 26.0.5
Jgroups Kubernetes Version: 2.0.2.Final
Keycloak base docker image: quay.io/keycloak/keycloak:26.0.5

What are we doing:

We are building our own Docker image with adding js scripts on top on base keycloak container

Configuration being used:

        - name: KC_LOG_LEVEL
          value: "INFO"
        - name: KC_LOG_CONSOLE_LEVEL
          value: "info"

What we expect:

After adding above configuration in deployment.yaml only INFO level logs are printed in container console logs.

Issue being observed:

Even after configuring the above parameters in keycloak deployment.yaml file we are still observing DEBUG level logs from application container as shown below.

JAVA_OPTS already set in environment; overriding default settings
Appending additional Java properties to JAVA_OPTS
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/keycloak/lib/../providers/custom-spi.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/keycloak/lib/lib/main/org.jboss.slf4j.slf4j-jboss-logmanager-2.0.0.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
06:14:37.084 [main] DEBUG io.netty.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
06:14:37.086 [main] DEBUG io.netty.util.internal.InternalThreadLocalMap - -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
06:14:37.086 [main] DEBUG io.netty.util.internal.InternalThreadLocalMap - -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
06:14:38.012 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - -Dio.netty.noUnsafe: false
06:14:38.013 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - Java version: 21
06:14:38.013 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.theUnsafe: available
06:14:38.014 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe base methods: all available
06:14:38.014 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.storeFence: available
06:14:38.015 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - java.nio.Buffer.address: available
06:14:38.015 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - direct buffer constructor: unavailable: Reflective setAccessible(true) disabled
06:14:38.016 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - java.nio.Bits.unaligned: available, true
06:14:38.017 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - jdk.internal.misc.Unsafe.allocateUninitializedArray(int): unavailable: class io.netty.util.internal.PlatformDependent0$7 cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @76a4d6c
06:14:38.017 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent0 - java.nio.DirectByteBuffer.<init>(long, {int,long}): unavailable
06:14:38.017 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - sun.misc.Unsafe: available
06:14:38.018 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - -Dio.netty.tmpdir: /tmp (java.io.tmpdir)
06:14:38.018 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - -Dio.netty.bitMode: 64 (sun.arch.data.model)
06:14:38.018 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - -Dio.netty.maxDirectMemory: -1 bytes
06:14:38.018 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - -Dio.netty.uninitializedArrayAllocationThreshold: -1
06:14:38.019 [Thread-2] DEBUG io.netty.util.internal.CleanerJava9 - java.nio.ByteBuffer.cleaner(): available
06:14:38.019 [Thread-2] DEBUG io.netty.util.internal.PlatformDependent - -Dio.netty.noPreferDirect: false
06:14:38.021 [Thread-2] DEBUG io.netty.channel.DefaultChannelId - -Dio.netty.processId: 1 (auto-detected)
06:14:38.023 [Thread-2] DEBUG io.netty.channel.DefaultChannelId - -Dio.netty.machineId: 53:75:f6:a4:b1:08:d8:cd (user-set)
06:14:38.037 [main] DEBUG io.vertx.core.logging.LoggerFactory - Using io.vertx.core.logging.SLF4JLogDelegateFactory
06:14:38.052 [main] DEBUG io.netty.util.ResourceLeakDetector - -Dio.netty.leakDetection.level: simple
06:14:38.052 [main] DEBUG io.netty.util.ResourceLeakDetector - -Dio.netty.leakDetection.targetRecords: 4
06:14:38.067 [main] DEBUG io.netty.channel.MultithreadEventLoopGroup - -Dio.netty.eventLoopThreads: 16
06:14:38.071 [main] DEBUG io.netty.util.concurrent.GlobalEventExecutor - -Dio.netty.globalEventExecutor.quietPeriodSeconds: 1
06:14:38.075 [main] DEBUG io.netty.channel.nio.NioEventLoop - -Dio.netty.noKeySetOptimization: false
06:14:38.075 [main] DEBUG io.netty.channel.nio.NioEventLoop - -Dio.netty.selectorAutoRebuildThreshold: 512
06:14:38.078 [main] DEBUG io.netty.util.internal.PlatformDependent - org.jctools-core.MpscChunkedArrayQueue: available
06:14:38.738 [ForkJoinPool.commonPool-worker-1] DEBUG org.jgroups.protocols.pbcast.GMS - address=custom-keycloak-v26-5cc856b56b-f8s4w-21352, cluster=ISPN, physical address=10.244.1.182:7800
06:14:38.898 [ForkJoinPool.commonPool-worker-1] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-58bdbc967d-rcgsb, group 58bdbc967d
06:14:38.899 [ForkJoinPool.commonPool-worker-1] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-5cc856b56b-f8s4w, group 5cc856b56b
06:14:38.910 [ForkJoinPool.commonPool-worker-1] DEBUG org.jgroups.protocols.pbcast.GMS - custom-keycloak-v26-5cc856b56b-f8s4w-21352: sending JOIN(custom-keycloak-v26-5cc856b56b-f8s4w-21352) to custom-keycloak-v26-58bdbc967d-rcgsb-36016
06:14:39.076 [main] DEBUG io.micrometer.common.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
06:14:39.080 [main] DEBUG io.micrometer.core.instrument.composite.CompositeMeterRegistry - A MeterFilter is being configured after a Meter has been registered to this registry. All MeterFilters should be configured before any Meters are registered. If that is not possible or you have a use case where it should be allowed, let the Micrometer maintainers know at https://github.com/micrometer-metrics/micrometer/issues/4920.
06:14:40.480 [vert.x-eventloop-thread-7] DEBUG io.netty.util.NetUtil - -Djava.net.preferIPv4Stack: true
06:14:40.480 [vert.x-eventloop-thread-7] DEBUG io.netty.util.NetUtil - -Djava.net.preferIPv6Addresses: false
06:14:40.481 [vert.x-eventloop-thread-7] DEBUG io.netty.util.NetUtilInitializations - Loopback interface: lo (lo, 127.0.0.1)
06:14:40.481 [vert.x-eventloop-thread-7] DEBUG io.netty.util.NetUtil - /proc/sys/net/core/somaxconn: 4096
06:14:40.513 [vert.x-eventloop-thread-5] DEBUG io.netty.buffer.ByteBufUtil - -Dio.netty.allocator.type: pooled
06:14:40.513 [vert.x-eventloop-thread-5] DEBUG io.netty.buffer.ByteBufUtil - -Dio.netty.threadLocalDirectBufferSize: 0
06:14:40.513 [vert.x-eventloop-thread-5] DEBUG io.netty.buffer.ByteBufUtil - -Dio.netty.maxThreadLocalCharBufferSize: 16384
06:14:40.514 [vert.x-eventloop-thread-5] DEBUG io.netty.bootstrap.ChannelInitializerExtensions - -Dio.netty.bootstrap.extensions: null
06:15:38.049 [jgroups-6,custom-keycloak-v26-5cc856b56b-f8s4w-21352] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-5cc856b56b-f8s4w, group 5cc856b56b
06:16:07.232 [jgroups-6,custom-keycloak-v26-5cc856b56b-f8s4w-21352] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-5cc856b56b-f8s4w, group 5cc856b56b
06:16:28.960 [jgroups-9,custom-keycloak-v26-5cc856b56b-f8s4w-21352] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-5cc856b56b-f8s4w, group 5cc856b56b
06:17:08.055 [jgroups-6,custom-keycloak-v26-5cc856b56b-f8s4w-21352] DEBUG org.jgroups.protocols.kubernetes.KUBE_PING - pod custom-keycloak-v26-5cc856b56b-f8s4w, group 5cc856b56b

There is no additional configuration that I have done; so I’m not sure if there’s any missing log configuration required to disable the DEBUG level.

“ya I have the same problem, no environment variables seem to stop it from logging DEBUG to the console”