Repository: strimzi/strimzi-kafka-operator
Pull request #11254: docs(logging): log4j2 support updates
Author: login: PaulRMellor
Labels: name: documentation
Created: 2025-03-11T11:53:01Z | Merged: 2025-03-26T16:18:24Z

**Documentation**

Updates the logging content to reflect new support and Kafka 4.0 adoption of log4j2
- Removes/updates references to log4j1 and log4j1 logger names
- Updates logging content in the deploying guide 
  - Refreshes logging config overview
- streamlines logging information in API reference guide to remove repetition


### Checklist

_Please go through this checklist and make sure all applicable tasks have been done_

- [ ] Write tests
- [ ] Make sure all tests pass
- [x] Update documentation
- [ ] Check RBAC rights for Kubernetes / OpenShift roles
- [ ] Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
- [ ] Reference relevant issue(s) and close them after merging
- [ ] Update CHANGELOG.md
- [ ] Supply screenshots for visual changes, such as Grafana dashboards




Diff:
diff --git a/documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
index 0fb75f14daf..fb9f3d63da2 100644
--- a/documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
@@ -11,12 +11,36 @@ Configuration options relate to:
 [id='property-kafka-bridge-logging-{context}']
 = Logging
 
-Kafka Bridge has its own configurable loggers:
+Kafka Bridge has its own preconfigured loggers:
 
-* `rootLogger.level`
-* `logger.__<operation-id>__`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                                          | Default Level
 
-You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to set log levels for specific operations:
+| rootLogger | Default logger for all classes                       | INFO
+| bridge     | All classes in the `io.strimzi.kafka.bridge` package | INFO
+| healthy    | Uses `http.openapi.operation.healthy` endpoint       | WARN
+| ready      | Uses `http.openapi.operation.ready` endpoint         | WARN
+|===
+
+You can configure log levels directly for these loggers.
+For example:
+
+[source,yaml,subs="+quotes,attributes"]
+----
+apiVersion: {KafkaApiVersion}
+kind: KafkaBridge
+spec:
+  # ...
+  logging:
+    type: inline
+    loggers:
+      rootLogger.level: INFO
+      logger.ready.level: DEBUG
+  # ...
+----
+
+You can also specify custom loggers for other operations:
 
 * `createConsumer`
 * `deleteConsumer`
@@ -30,44 +54,34 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+Each operation maps to an API endpoint,  defined according to the OpenAPI specification, and supports fine-grained logging via `http.openapi.operation.<operation_id>`.
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+For example, to set the logging level for the `send` operation logger:
 
-```
-logger.send.name = http.openapi.operation.send
-logger.send.level = DEBUG
-```
+[source,yaml,subs="+quotes,attributes"]
+----
+apiVersion: {KafkaApiVersion}
+kind: KafkaBridge
+spec:
+  # ...
+  logging:
+    type: inline
+    loggers:
+      logger.send.name: http.openapi.operation.send
+      logger.send.level: DEBUG
+  # ...
+----
 
 Kafka Bridge uses the Apache `log4j2` logger implementation.
-Loggers are defined in the `log4j2.properties` file, which has the following default configuration for `healthy` and `ready` endpoints:
-
-```
-logger.healthy.name = http.openapi.operation.healthy
-logger.healthy.level = WARN
-logger.ready.name = http.openapi.operation.ready
-logger.ready.level = WARN
-```
-The log level of all other operations is set to `INFO` by default.
-
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration.
-The `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory.
-Default logging is used if the `name` or `key` is not set.
-Inside the ConfigMap, the logging configuration is described using `log4j.properties`.
-For more information about log levels, see {ApacheLoggers}.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -78,13 +92,15 @@ spec:
     type: inline
     loggers:
       rootLogger.level: INFO
-      # enabling DEBUG just for send operation
-      logger.send.name: "http.openapi.operation.send"
+      # enabling DEBUG for send operation
+      logger.send.name: http.openapi.operation.send
       logger.send.level: DEBUG
   # ...
 ----
 
-.External logging
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
+
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -95,18 +111,12 @@ spec:
     type: external
     valueFrom:
       configMapKeyRef:
+        # name and key are mandatory
         name: customConfigMap
-        key: bridge-logj42.properties
+        key: log4j2.properties
   # ...
 ----
 
-Any available loggers that are not configured have their level set to `OFF`.
-
-If the Kafka Bridge was deployed using the Cluster Operator,
-changes to Kafka Bridge logging levels are applied dynamically.
-
-If you use external logging, a rolling update is triggered when logging appenders are changed.
-
 .Garbage collector (GC)
 
 Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].
diff --git a/documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
index 96aec602bc1..0512c8a85ce 100644
--- a/documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
@@ -78,10 +78,19 @@ In this case, fix the configuration so that the Cluster Operator can roll out th
 
 [id='property-kafka-connect-logging-{context}']
 = Logging
-Kafka Connect has its own configurable loggers:
 
-* `connect.root.logger.level`
-* `log4j.logger.org.reflections`
+WARNING: Kafka 3.9 and earlier versions use log4j1 for logging.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^]. 
+
+Kafka Connect has its own preconfigured loggers:
+
+[cols="1m,2,1",options="header"]
+|===
+| Logger      | Description                                                         | Default Level
+
+| rootLogger  | Default logger for all classes                                      | INFO
+| reflections | Logs classpath scanning and metadata discovery used to find plugins | ERROR
+|===
 
 Further loggers are added depending on the Kafka Connect plugins running.
 
@@ -92,19 +101,14 @@ Use a curl request to get a complete list of Kafka Connect loggers running from
 curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
 ----
 
-Kafka Connect uses the Apache `log4j` logger implementation.
-
+Kafka Connect uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaConnectApiVersion}
@@ -114,15 +118,31 @@ spec:
   logging:
     type: inline
     loggers:
-      connect.root.logger.level: INFO
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSourceTask: TRACE
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSinkTask: DEBUG
+      rootLogger.level: INFO
+      logger.reflections.level: DEBUG
   # ...
 ----
 
-NOTE: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+You can define additional loggers by specifying the full class or package name using `logger.<name>.name`.
+For example, to configure logging for Kafka Connect runtime classes inline:
 
-.External logging
+.Example custom inline loggers
+[source,yaml]
+----
+# ...
+logger.sourcetask.name: org.apache.kafka.connect.runtime.WorkerSourceTask # <1>
+logger.sourcetask.level: TRACE # <2>
+logger.sinktask.name: org.apache.kafka.connect.runtime.WorkerSinkTask # <3>
+logger.sinktask.level: DEBUG # <4>
+----
+<1> Creates a logger for the runtime `WorkerSourceTask` class.
+<2> Sets the logging level for `WorkerSourceTask`.
+<3> Creates a logger for the runtime `WorkerSinkTask` class.
+<4> Sets the logging level for `WorkerSinkTask`.
+
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
+
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaConnectApiVersion}
@@ -133,18 +153,12 @@ spec:
     type: external
     valueFrom:
       configMapKeyRef:
-        name: customConfigMap
-        key: connect-logging.log4j
+        # name and key are mandatory
+        name: customConfigMap 
+        key: log4j2.properties
   # ...
 ----
 
-Any available loggers that are not configured have their level set to `OFF`.
-
-If Kafka Connect was deployed using the Cluster Operator,
-changes to Kafka Connect logging levels are applied dynamically.
-
-If you use external logging, a rolling update is triggered when logging appenders are changed.
-
 .Garbage collector (GC)
 
 Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].
diff --git a/documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
index 4f0f5002252..50df20bdb90 100644
--- a/documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
@@ -117,32 +117,34 @@ Be aware that if the configured image is not compatible with Strimzi images, it
 [id='property-kafka-logging-{context}']
 = Logging
 
-Kafka has its own configurable loggers, which include the following:
-
-* `log4j.logger.kafka`
-* `log4j.logger.org.apache.kafka`
-* `log4j.logger.kafka.request.logger`
-* `log4j.logger.kafka.network.Processor`
-* `log4j.logger.kafka.server.KafkaApis`
-* `log4j.logger.kafka.network.RequestChannel$`
-* `log4j.logger.kafka.controller`
-* `log4j.logger.kafka.log.LogCleaner`
-* `log4j.logger.state.change.logger`
-* `log4j.logger.kafka.authorizer.logger`
-
-Kafka uses the Apache `log4j` logger implementation.
-
+WARNING: Kafka 3.9 and earlier versions use log4j1 for logging.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^]. 
+
+Kafka has its own preconfigured loggers:
+
+[cols="1m,2,1",options="header"]
+|===
+| Logger              | Description                                              | Default Level
+
+| rootLogger          | Default logger for all classes                           | INFO
+| kafka               | Logs Kafka node classes                                  | INFO
+| orgapachekafka      | Logs Kafka library classes                               | INFO
+| requestlogger       | Logs client request details                              | WARN
+| requestchannel      | Logs request handling in the broker                      | WARN
+| controller          | Logs controller activity, such as leadership changes     | INFO
+| logcleaner          | Logs log compaction and cleanup processes                | INFO
+| statechange         | Logs broker and partition state transitions              | INFO
+| authorizer          | Logs access control decisions                            | INFO
+|===
+
+Kafka uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -154,18 +156,29 @@ spec:
     logging:
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
-        log4j.logger.kafka.coordinator.transaction: TRACE
-        log4j.logger.kafka.log.LogCleanerManager: DEBUG
-        log4j.logger.kafka.request.logger: DEBUG
-        log4j.logger.io.strimzi.kafka.oauth: DEBUG
-        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
+        rootLogger.level: INFO
+        logger.kafka.level: DEBUG 
+        logger.logcleaner.level: DEBUG 
+        logger.authorizer.level: TRACE
   # ...
 ----
 
-NOTE: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure logging for OAuth components inline:
 
-.External logging
+.Example custom inline loggers
+[source,yaml]
+----
+# ...
+logger.oauth.name: io.strimzi.kafka.oauth # <1>
+logger.oauth.level: DEBUG # <2>
+----
+<1> Creates a logger for the `io.strimzi.kafka.oauth` package.
+<2> Sets the logging level for the OAuth package.
+
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
+
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -176,18 +189,12 @@ spec:
     type: external
     valueFrom:
       configMapKeyRef:
+        # name and key are mandatory
         name: customConfigMap
-        key: kafka-log4j.properties
+        key: log4j2.properties
   # ...
 ----
 
-Any available loggers that are not configured have their level set to `OFF`.
-
-If Kafka was deployed using the Cluster Operator,
-changes to Kafka logging levels are applied dynamically.
-
-If you use external logging, a rolling update is triggered when logging appenders are changed.
-
 .Garbage collector (GC)
 
 Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].
diff --git a/documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc
index 17f67460597..ae26ec333b2 100644
--- a/documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc
@@ -301,22 +301,23 @@ For more information, refer to the xref:type-BrokerCapacity-reference[BrokerCapa
 [id='property-cruise-control-logging-{context}']
 = Logging
 
-Cruise Control has its own configurable logger:
+Cruise Control has its own preconfigured logger:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                        | Default Level
 
-Cruise Control uses the Apache `log4j2` logger implementation.
+| rootLogger | Default logger for all classes     | INFO
+|===
 
+Cruise Control uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -329,20 +330,29 @@ spec:
       type: inline
       loggers:
         rootLogger.level: INFO
-        logger.exec.name: com.linkedin.kafka.cruisecontrol.executor.Executor # <1>
-        logger.exec.level: TRACE # <2>
-        logger.go.name: com.linkedin.kafka.cruisecontrol.analyzer.GoalOptimizer # <3>
-        logger.go.level: DEBUG # <4>
     # ...
 ----
+
+You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure more detailed logging for Cruise Control inline:
+
+.Example custom inline loggers
+[source,yaml]
+----
+# ...
+logger.exec.name: com.linkedin.kafka.cruisecontrol.executor.Executor # <1>
+logger.exec.level: TRACE # <2>
+logger.go.name: com.linkedin.kafka.cruisecontrol.analyzer.GoalOptimizer # <3>
+logger.go.level: DEBUG # <4>
+----
 <1> Creates a logger for the Cruise Control `Executor` class.
 <2> Sets the logging level for the `Executor` class.
 <3> Creates a logger for the Cruise Control `GoalOptimizer` class.
 <4> Sets the logging level for the `GoalOptimizer` class.
 
-NOTE: When investigating an issue with Cruise Control, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
 
-.External logging
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -355,8 +365,9 @@ spec:
       type: external
       valueFrom:
         configMapKeyRef:
+          # name and key are mandatory
           name: customConfigMap
-          key: cruise-control-log4j.properties
+          key: log4j2.properties
     # ...
 ----
 
diff --git a/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc
index 623af664830..f01a59ad671 100644
--- a/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc
@@ -3,23 +3,24 @@ Configures the Topic Operator.
 [id='property-topic-operator-logging-{context}']
 = Logging
 
-The Topic Operator has a configurable logger:
+The Topic Operator has its own preconfigured loggers:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                    | Default Level
 
-The Topic Operator uses the Apache `log4j2` logger implementation.
+| rootLogger | Default logger for all classes | INFO
+| jetty      | Logs HTTP server activity      | INFO
+|===
 
-Use the `logging` property in the `entityOperator.topicOperator` field of the Kafka resource `Kafka` resource to configure loggers and logger levels.
+The Topic Operator uses the Apache `log4j2` logger implementation.
+Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j2.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -38,21 +39,30 @@ spec:
         type: inline
         loggers:
           rootLogger.level: INFO
-          logger.top.name: io.strimzi.operator.topic # <1>
-          logger.top.level: DEBUG # <2> 
-          logger.toc.name: io.strimzi.operator.topic.TopicOperator # <3>
-          logger.toc.level: TRACE # <4>
+          logger.jetty.level: WARN
   # ...
 ----
+
+You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure more detailed logging for the Topic Operator inline:
+
+.Example custom inline loggers
+[source,yaml]
+----
+# ...
+logger.top.name: io.strimzi.operator.topic # <1>
+logger.top.level: DEBUG # <2> 
+logger.toc.name: io.strimzi.operator.topic.TopicOperator # <3>
+logger.toc.level: TRACE # <4>
+----
 <1> Creates a logger for the `topic` package.
 <2> Sets the logging level for the `topic` package.
 <3> Creates a logger for the `TopicOperator` class.
 <4> Sets the logging level for the `TopicOperator` class.
 
-NOTE: When investigating an issue with the operator, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. 
-However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
 
-.External logging
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -71,8 +81,9 @@ spec:
         type: external
         valueFrom:
           configMapKeyRef:
+            # name and key are mandatory
             name: customConfigMap
-            key: topic-operator-log4j2.properties
+            key: log4j2.properties
   # ...
 ----
 
diff --git a/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc b/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc
index 4226de073aa..492393ddbf5 100644
--- a/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc
+++ b/documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc
@@ -3,23 +3,24 @@ Configures the User Operator.
 [id='property-user-operator-logging-{context}']
 = Logging
 
-The User Operator has a configurable logger:
+The User Operator has its own preconfigured loggers:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                    | Default Level
 
-The User Operator uses the Apache `log4j2` logger implementation.
+| rootLogger | Default logger for all classes | INFO
+| jetty      | Logs HTTP server activity      | INFO
+|===
 
-Use the `logging` property in the `entityOperator.userOperator` field of the `Kafka` resource to configure loggers and logger levels.
+The User Operator uses the Apache `log4j2` logger implementation.
+Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j2.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+You can set log levels using either the `inline` or `external` logging configuration types.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the `rootLogger.level`.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+Specify loggers and levels directly in the custom resource for inline configuration:
 
-.Inline logging
+.Example inline logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -38,24 +39,30 @@ spec:
         type: inline
         loggers:
           rootLogger.level: INFO
-          logger.uop.name: io.strimzi.operator.user # <1>
-          logger.uop.level: DEBUG # <2> 
-          logger.abstractcache.name: io.strimzi.operator.user.operator.cache.AbstractCache # <3>
-          logger.abstractcache.level: TRACE # <4>
-          logger.jetty.level: DEBUG # <5>
-          
+          logger.jetty.level: WARN  
   # ...
 ----
+
+You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure more detailed logging for the User Operator inline:
+
+.Example custom inline loggers
+[source,yaml]
+----
+# ...
+logger.uop.name: io.strimzi.operator.user # <1>
+logger.uop.level: DEBUG # <2> 
+logger.abstractcache.name: io.strimzi.operator.user.operator.cache.AbstractCache # <3>
+logger.abstractcache.level: TRACE # <4>     
+----
 <1> Creates a logger for the `user` package.
 <2> Sets the logging level for the `user` package.
 <3> Creates a logger for the `AbstractCache` class.
-<4> Sets the logging level for the `AbstractCache` class.
-<5> Changes the logging level for the default `jetty` logger. The `jetty` logger is part of the logging configuration provided with Strimzi.
-By default, it is set to `INFO`.  
+<4> Sets the logging level for the `AbstractCache` class. 
 
-NOTE: When investigating an issue with the operator, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:
 
-.External logging
+.Example external logging configuration
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -74,8 +81,9 @@ spec:
         type: external
         valueFrom:
           configMapKeyRef:
+            # name and key are mandatory
             name: customConfigMap
-            key: user-operator-log4j2.properties
+            key: log4j2.properties
    # ...
 ----
 
diff --git a/documentation/assemblies/configuring/assembly-logging-configuration.adoc b/documentation/assemblies/configuring/assembly-logging-configuration.adoc
index 960e80d26e8..f64b7c94bdd 100644
--- a/documentation/assemblies/configuring/assembly-logging-configuration.adoc
+++ b/documentation/assemblies/configuring/assembly-logging-configuration.adoc
@@ -6,31 +6,46 @@
 = Configuring logging levels
 
 [role="_abstract"]
-Configure logging levels in the custom resources of Kafka components and Strimzi operators.
-You can specify the logging levels directly in the `spec.logging` property of the custom resource.
-Or you can define the logging properties in a ConfigMap that's referenced in the custom resource using the `configMapKeyRef` property.
 
-The advantages of using a ConfigMap are that the logging properties are maintained in one place and are accessible to more than one resource.
-You can also reuse the ConfigMap for more than one resource.
-If you are using a ConfigMap to specify loggers for Strimzi Operators, you can also append the logging specification to add filters.
+WARNING: Strimzi operators and Kafka components use log4j2 for logging.
+However, Kafka 3.9 and earlier versions rely on log4j1.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^].
 
-You specify a logging `type` in your logging specification:
+Configure the logging levels of Kafka components and Strimzi operators through their custom resources.
+You can use either of these options:
+
+* Specify logging levels directly in the `spec.logging` property of the custom resource.
+* Define logging properties in a custom `ConfigMap` and reference it using the `configMapKeyRef` property.
+
+Advantages of using a `ConfigMap`:
+
+* Centralized maintenance
+* Reusable with multiple resources
+* Flexibility to append logging specifications to add filters
+
+Specify a logging `type` in your logging specification:
 
 * `inline` when specifying logging levels directly
-* `external` when referencing a ConfigMap
+* `external` when referencing a `ConfigMap`
+
+For `inline` configuration, use the `loggers` property to set the root logger level and levels for specific classes or loggers.
 
-.Example `inline` logging configuration
+.Example inline logging configuration
 [source,shell,subs="+quotes,attributes"]
 ----
 # ...
 logging:
   type: inline
   loggers:
-    kafka.root.logger.level: INFO
+    rootLogger.level: INFO
 # ...
 ----
 
-.Example `external` logging configuration
+For `external` configuration, use a `ConfigMap` to define logging configurations using a full `log4j2.properties` file. 
+Set the logging `name` and `key` properties to reference the `ConfigMap`. 
+Both properties are mandatory. 
+
+.Example external logging configuration
 [source,shell,subs="+quotes,attributes"]
 ----
 # ...
@@ -39,29 +54,31 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: my-config-map
-      key: my-config-map-key
+      key: log4j2.properties
 # ...
 ----
 
-Values for the `name` and `key` of the ConfigMap are mandatory.
-Default logging is used if the `name` or `key` is not set.
+Default logging is used if logging is not specified in the resource using either method.
+Loggers that haven't been explicitly configured inherit settings from their parent loggers. 
 
-== Logging options for Kafka components and operators
+When a resource managed by the Cluster Operator is created, a `ConfigMap` with the specified logging configuration is also created. 
+For components managed by the Strimzi operators, changes to logging levels are applied dynamically.
 
-For more information on configuring logging for specific Kafka components or operators, see the following sections.
+WARNING: Setting a log level to `DEBUG` or `TRACE` may result in a large amount of log output and may have performance implications.
 
-.Kafka component logging
+== Configurable loggers
 
-* link:{BookURLConfiguring}#property-kafka-logging-reference[Kafka logging^]
-* link:{BookURLConfiguring}#property-kafka-connect-logging-reference[Kafka Connect and MirrorMaker 2 logging^]
-* link:{BookURLConfiguring}#property-kafka-bridge-logging-reference[Kafka Bridge logging^]
-* link:{BookURLConfiguring}#property-cruise-control-logging-reference[Cruise Control logging^]
+The following Kafka components and operators have specific loggers available for configuration:
 
-.Operator logging
+* link:{BookURLConfiguring}#property-kafka-logging-reference[Kafka loggers^]
+* link:{BookURLConfiguring}#property-kafka-connect-logging-reference[Kafka Connect and MirrorMaker 2 loggers^]
+* link:{BookURLConfiguring}#property-kafka-bridge-logging-reference[Kafka Bridge loggers^]
+* link:{BookURLConfiguring}#property-cruise-control-logging-reference[Cruise Control loggers^]
+* xref:ref-operator-cluster-logging-configmap-str[Cluster Operator loggers]
+* link:{BookURLConfiguring}#property-topic-operator-logging-reference[Topic Operator loggers^]
+* link:{BookURLConfiguring}#property-user-operator-logging-reference[User Operator loggers^]
 
-* xref:ref-operator-cluster-logging-configmap-str[Cluster Operator logging]
-* link:{BookURLConfiguring}#property-topic-operator-logging-reference[Topic Operator logging^]
-* link:{BookURLConfiguring}#property-user-operator-logging-reference[User Operator logging^]
+For information about log levels, see {ApacheLoggers}.
 
 //creating a configmap for logging
 include::../../modules/configuring/proc-creating-configmap.adoc[leveloffset=+1]
diff --git a/documentation/modules/configuring/con-config-kafka-bridge.adoc b/documentation/modules/configuring/con-config-kafka-bridge.adoc
index 85fdb8ac41b..9ba6e3af5f2 100644
--- a/documentation/modules/configuring/con-config-kafka-bridge.adoc
+++ b/documentation/modules/configuring/con-config-kafka-bridge.adoc
@@ -68,9 +68,9 @@ spec:
   logging: # <10>
     type: inline
     loggers:
-      logger.bridge.level: INFO
+      rootLogger.level: INFO
       # Enabling DEBUG just for send operation
-      logger.send.name: "http.openapi.operation.send"
+      logger.send.name: http.openapi.operation.send
       logger.send.level: DEBUG
   # JVM options (optional)
   jvmOptions: # <11>
@@ -120,7 +120,7 @@ spec:
 By default, the Kafka Bridge connects to Kafka brokers without authentication.
 <8> Consumer configuration options.
 <9> Producer configuration options.
-<10> Specified Kafka Bridge loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` or `log4j2.properties` key in the ConfigMap. For the Kafka Bridge loggers, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
+<10> Kafka Bridge loggers and log levels added directly (`inline`) or indirectly (`external`) through a `ConfigMap`. Custom Log4j configuration must be placed under the `log4j2.properties` key in the `ConfigMap`. You can set log levels to `INFO`, `ERROR`, `WARN`, `TRACE`, `DEBUG`, `FATAL` or `OFF`.
 <11> JVM configuration options to optimize performance for the Virtual Machine (VM) running the Kafka Bridge.
 <12> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <13> Optional: Container image configuration, which is recommended only in special situations.
diff --git a/documentation/modules/configuring/con-config-kafka-connect.adoc b/documentation/modules/configuring/con-config-kafka-connect.adoc
index 46bc9be96ad..5cf50dd33a0 100644
--- a/documentation/modules/configuring/con-config-kafka-connect.adoc
+++ b/documentation/modules/configuring/con-config-kafka-connect.adoc
@@ -97,7 +97,8 @@ spec:
   logging: # <12>
     type: inline
     loggers:
-      log4j.rootLogger: INFO
+      # Kafka 4.0+ uses Log4j2
+      rootLogger.level: INFO
   # Readiness probe (optional)
   readinessProbe: # <13>
     initialDelaySeconds: 15
@@ -172,7 +173,7 @@ By default, Kafka Connect connects to Kafka brokers using a plain text connectio
 <9> Build configuration properties for building a container image with connector plugins automatically.
 <10> (Required) Configuration of the container registry where new images are pushed.
 <11> (Required) List of connector plugins and their artifacts to add to the new container image. Each plugin must be configured with at least one `artifact`.
-<12> Specified Kafka Connect loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` or `log4j2.properties` key in the ConfigMap. For the Kafka Connect `log4j.rootLogger` logger, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
+<12> Kafka Connect loggers and log levels added directly (`inline`) or indirectly (`external`) through a `ConfigMap`. Custom Log4j configuration must be placed under the `log4j2.properties` key in the `ConfigMap`. You can set log levels to `INFO`, `ERROR`, `WARN`, `TRACE`, `DEBUG`, `FATAL` or `OFF`.
 <13> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <14> Prometheus metrics, which are enabled by referencing a ConfigMap containing configuration for the Prometheus JMX exporter in this example. You can enable metrics without further configuration using a reference to a ConfigMap containing an empty file under `metricsConfig.valueFrom.configMapKeyRef.key`.
 <15> JVM configuration options to optimize performance for the Virtual Machine (VM) running Kafka Connect.
diff --git a/documentation/modules/configuring/con-config-kafka-kraft.adoc b/documentation/modules/configuring/con-config-kafka-kraft.adoc
index 4488402225d..ee318469379 100644
--- a/documentation/modules/configuring/con-config-kafka-kraft.adoc
+++ b/documentation/modules/configuring/con-config-kafka-kraft.adoc
@@ -85,7 +85,8 @@ spec:
     logging: # <14>
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
+        # Kafka 4.0+ uses Log4j2
+        rootLogger.level: INFO
     # Readiness probe (optional)
     readinessProbe: # <15>
       initialDelaySeconds: 15
@@ -167,7 +168,7 @@ spec:
 <11> Kafka metadata version, which can be changed to a supported version by following the upgrade procedure.
 <12> Broker configuration. Standard Apache Kafka configuration may be provided, restricted to those properties not managed directly by Strimzi.
 <13> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
-<14> Kafka loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` key in the ConfigMap. For the Kafka `kafka.root.logger.level` logger, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
+<14> Kafka loggers and log levels added directly (`inline`) or indirectly (`external`) through a `ConfigMap`. Custom Log4j configuration must be placed under the `log4j2.properties` key in the `ConfigMap`. You can set log levels to `INFO`, `ERROR`, `WARN`, `TRACE`, `DEBUG`, `FATAL` or `OFF`.
 <15> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <16> JVM configuration options to optimize performance for the Virtual Machine (VM) running Kafka.
 <17> ADVANCED OPTION: Container image configuration, which is recommended only in special situations.
diff --git a/documentation/modules/configuring/con-config-mirrormaker2.adoc b/documentation/modules/configuring/con-config-mirrormaker2.adoc
index 1808e5a2911..3ec5eed20a3 100644
--- a/documentation/modules/configuring/con-config-mirrormaker2.adoc
+++ b/documentation/modules/configuring/con-config-mirrormaker2.adoc
@@ -169,7 +169,8 @@ spec:
   logging: # <36>
     type: inline
     loggers:
-      connect.root.logger.level: INFO
+      # Kafka 4.0+ uses Log4j2
+      rootLogger.level: INFO
   # Readiness probe (optional)
   readinessProbe: # <37>
     initialDelaySeconds: 15
@@ -247,7 +248,7 @@ Standard Apache Kafka configuration may be provided, restricted to those propert
 <33> Adjusts the frequency of checks for offset tracking. If you change the frequency of offset synchronization, you might also need to adjust the frequency of these checks.
 <34> The Kafka Connect and MirrorMaker 2 version, which will always be the same.
 <35> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
-<36> Specified Kafka Connect loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` or `log4j2.properties` key in the ConfigMap. For the Kafka Connect `log4j.rootLogger` logger, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
+<36> Specified Kafka Connect loggers and log levels added directly (`inline`) or indirectly (`external`) through a `ConfigMap`. Custom Log4j configuration must be placed under the `log4j2.properties` key in the `ConfigMap`. You can set log levels to `INFO`, `ERROR`, `WARN`, `TRACE`, `DEBUG`, `FATAL` or `OFF`.
 <37> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <38> JVM configuration options to optimize performance for the Virtual Machine (VM) running Kafka MirrorMaker.
 <39> ADVANCED OPTION: Container image configuration, which is recommended only in special situations.
diff --git a/documentation/modules/configuring/con-configuration-points-configmaps.adoc b/documentation/modules/configuring/con-configuration-points-configmaps.adoc
index 73d4656f490..ce9df621f17 100644
--- a/documentation/modules/configuring/con-configuration-points-configmaps.adoc
+++ b/documentation/modules/configuring/con-configuration-points-configmaps.adoc
@@ -2,29 +2,28 @@
 //
 // assembly-config.adoc
 
-[id="configuration-points-configmaps-{context}"]
-= Using ConfigMaps to add configuration 
+[id="configuration-points-config-maps-{context}"]
+= Using ConfigMap resources to add configuration 
 
 [role="_abstract"]
 Add specific configuration to your Strimzi deployment using `ConfigMap` resources.
-ConfigMaps use key-value pairs to store non-confidential data.  
-Configuration data added to ConfigMaps is maintained in one place and can be reused amongst components.
+Config maps use key-value pairs to store non-confidential data.  
+Configuration data added to config maps is maintained in one place and can be reused amongst components.
 
-ConfigMaps can only store the following types of configuration data:
+Config maps can only store the following types of configuration data:
 
 * Logging configuration
 * Metrics configuration
 * External configuration for Kafka Connect connectors
 
-You can't use ConfigMaps for other areas of configuration.
+You can't use config maps for other areas of configuration.
 
-When you configure a component, you can add a reference to a ConfigMap using the `configMapKeyRef` property. 
+When you configure a component, you can add a reference to a `ConfigMap` using the `configMapKeyRef` property. 
 
-For example, you can use `configMapKeyRef` to reference a ConfigMap that provides configuration for logging. 
-You might use a ConfigMap to pass a Log4j configuration file.
-You add the reference to the `logging` configuration. 
+For example, you can use `configMapKeyRef` to reference a `ConfigMap` that provides configuration for logging. 
+You define logging levels using the `log4j2.properties` key in the `ConfigMap` and then reference it in the `logging` configuration of the resource. 
 
-.Example ConfigMap for logging
+.Example reference to a `ConfigMap`
 [source,shell,subs="+quotes,attributes"]
 ----
 # ...
@@ -33,17 +32,17 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: my-config-map
-      key: my-config-map-key
+      key: log4j2.properties
 # ...
 ----
 
-To use a ConfigMap for metrics configuration, you add a reference to the `metricsConfig` configuration of the component in the same way.
+To use a `ConfigMap` for metrics configuration, you add a reference to the `metricsConfig` configuration of the component in the same way.
 
 `template` properties allow data from a `ConfigMap` or `Secret` to be mounted in a pod as environment variables or volumes.
 You can use external configuration data for the connectors used by Kafka Connect.
 The data might be related to an external data source, providing the values needed for the connector to communicate with that data source.
 
-For example, you can use the `configMapKeyRef` property to pass configuration data from a ConfigMap as an environment variable.  
+For example, you can use the `configMapKeyRef` property to pass configuration data from a `ConfigMap` as an environment variable.  
 
 .Example ConfigMap providing environment variable values
 [source,yaml,subs="attributes+"]
@@ -64,19 +63,21 @@ spec:
               key: my-key
 ----
 
-If you are using ConfigMaps that are managed externally, use configuration providers to load the data in the ConfigMaps.  
+If you are using config maps that are managed externally, use configuration providers to load the data in the config maps.  
 
-== Naming custom ConfigMaps 
+== Naming custom config maps 
 
-Strimzi xref:ref-list-of-kafka-cluster-resources-str[creates its own ConfigMaps and other resources] when it is deployed to Kubernetes. 
-The ConfigMaps contain data necessary for running components.  
-The ConfigMaps created by Strimzi must not be edited. 
+Strimzi xref:ref-list-of-kafka-cluster-resources-str[creates its own config maps and other resources] when it is deployed to Kubernetes. 
+The config maps contain data necessary for running components.  
+The config maps created by Strimzi must not be edited. 
 
-Make sure that any custom ConfigMaps you create do not have the same name as these default ConfigMaps. If they have the same name, they will be overwritten. For example, if your ConfigMap has the same name as the ConfigMap for the Kafka cluster, it will be overwritten when there is an update to the Kafka cluster.
+Make sure that any custom config maps you create do not have the same name as these default config maps. 
+If they have the same name, they are overwritten. 
+For example, if the custom `ConfigMap` has the same name as the `ConfigMap` for the Kafka cluster, it is overwritten when there is an update to the Kafka cluster.
 
 [role="_additional-resources"]
 .Additional resources
-* xref:ref-list-of-kafka-cluster-resources-str[List of Kafka cluster resources] (including ConfigMaps)
+* xref:ref-list-of-kafka-cluster-resources-str[List of Kafka cluster resources] (including config maps)
 * xref:external-logging_str[Logging configuration]
 * link:{BookURLConfiguring}#con-common-configuration-prometheus-reference[`metricsConfig`^]
 * link:{BookURLConfiguring}#type-ContainerTemplate-reference[`ContainerTemplate` schema reference^]
diff --git a/documentation/modules/configuring/proc-creating-configmap.adoc b/documentation/modules/configuring/proc-creating-configmap.adoc
index 34ba7c62aec..6894d84a3d4 100644
--- a/documentation/modules/configuring/proc-creating-configmap.adoc
+++ b/documentation/modules/configuring/proc-creating-configmap.adoc
@@ -6,25 +6,16 @@
 = Creating a ConfigMap for logging
 
 [role="_abstract"]
-To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the `spec` of a resource.
+To use a `ConfigMap` to define logging properties, you create and then reference it as part of the logging definition in the `spec` of a resource.
+Place the configuration under `log4j2.properties` 
 
-The ConfigMap must contain the appropriate logging configuration.
-
-* `log4j.properties` for Kafka components and the Kafka Bridge
-* `log4j2.properties` for the Topic Operator and User Operator
-
-The configuration must be placed under these properties.
-
-In this procedure a ConfigMap defines a root logger for a Kafka resource.
+In this procedure a `ConfigMap` defines a root logger for a `Kafka` resource.
 
 .Procedure
 
-. Create the ConfigMap.
-+
-You can create the ConfigMap as a YAML file or from a properties file.
-+
-ConfigMap example with a root logger definition for Kafka:
+. Create the `ConfigMap` as a YAML file or from a properties file.
 +
+.Example ConfigMap for logging
 [source,yaml,subs="+attributes"]
 ----
 kind: ConfigMap
@@ -32,27 +23,35 @@ apiVersion: v1
 metadata:
   name: logging-configmap
 data:
-  log4j.properties:
-    kafka.root.logger.level="INFO"
+  log4j2.properties: |
+    rootLogger.level = "INFO"
+    appender.console.type = Console
+    appender.console.name = STDOUT
+    appender.console.layout.type = PatternLayout
+    appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+    rootLogger.level = INFO
+    rootLogger.appenderRefs = console
+    rootLogger.appenderRef.console.ref = STDOUT
+    rootLogger.additivity = false
 ----
 +
-If you are using a properties file, specify the file at the command line:
-+
-[source,shell]
-----
-kubectl create configmap logging-configmap --from-file=log4j.properties
-----
-+
-The properties file defines the logging configuration:
+If you are using a properties file, define the logging configuration and specify the file at the command line when creating the `ConfigMap`.
 +
+.Properties file definition
 [source,text]
 ----
 # Define the logger
-kafka.root.logger.level="INFO"
+rootLogger.level = "INFO"
 # ...
 ----
++
+.Specifying the properties file
+[source,shell]
+----
+kubectl create configmap logging-configmap --from-file=log4j2.properties
+----
 
-. Define _external_ logging in the `spec` of the resource, setting the `logging.valueFrom.configMapKeyRef.name` to the name of the ConfigMap and `logging.valueFrom.configMapKeyRef.key` to the key in this ConfigMap.
+. Add `external` logging to the `spec` of the `Kafka` resource, specifying the `name` and `key` of the `ConfigMap`:
 +
 [source,shell,subs="+quotes,attributes"]
 ----
@@ -62,13 +61,8 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: logging-configmap
-      key: log4j.properties
+      key: log4j2.properties
 # ...
 ----
 
-. Create or update the resource.
-+
-[source,shell,subs=+quotes]
-----
-kubectl apply -f _<kafka_configuration_file>_
-----
+. Apply the changes to the `Kafka` configuration.
diff --git a/documentation/modules/configuring/proc-creating-logging-filters.adoc b/documentation/modules/configuring/proc-creating-logging-filters.adoc
index 5b3ed0259ea..8597c64cf23 100644
--- a/documentation/modules/configuring/proc-creating-logging-filters.adoc
+++ b/documentation/modules/configuring/proc-creating-logging-filters.adoc
@@ -6,59 +6,63 @@
 = Adding logging filters to Strimzi operators
 
 [role="_abstract"]
-If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi operators,
-you can also define logging filters to limit what's returned in the log.
+Add logging filters to Strimzi operators by using a `ConfigMap` that contains a complete `log4j2.properties` file with your custom log4j2 configuration.
 
-Logging filters are useful when you have a large number of logging messages.
-Suppose you set the log level for the logger as DEBUG (`rootLogger.level="DEBUG"`).
-Logging filters reduce the number of logs returned for the logger at that level, so you can focus on a specific resource.
-When the filter is set, only log messages matching the filter are logged.
+Filters are useful when too many logging messages are being produced. 
+For instance, if `rootLogger.level="DEBUG"`, filters reduce the number of logs to focus on a specific resource by logging only messages matching the filter.
 
-Filters use _markers_ to specify what to include in the log.
-You specify a kind, namespace and name for the marker.
-For example, if a Kafka cluster is failing, you can isolate the logs by specifying the kind as `Kafka`, and use the namespace and name of the failing cluster.
-
-This example shows a marker filter for a Kafka cluster named `my-kafka-cluster`.
+Markers specify what to include in the log using kind, namespace, and resource name values. 
+For example, to isolate the logs of a failing Kafka cluster, set the kind to `Kafka` and use the namespace and name of the cluster.
 
 .Basic logging filter configuration
-[source,yaml,subs="+attributes"]
+[source,properties]
 ----
-rootLogger.level="INFO"
-appender.console.filter.filter1.type=MarkerFilter <1>
-appender.console.filter.filter1.onMatch=ACCEPT <2>
-appender.console.filter.filter1.onMismatch=DENY <3>
-appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster) <4>
+rootLogger.level = "INFO"
+rootLogger.appenderRefs = console
+rootLogger.appenderRef.console.ref = STDOUT
+
+appender.console.type = Console
+appender.console.name = STDOUT
+appender.console.layout.type = PatternLayout
+appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+
+appender.console.filter.filter1.type = MarkerFilter <1>
+appender.console.filter.filter1.onMatch = ACCEPT <2>
+appender.console.filter.filter1.onMismatch = DENY <3>
+appender.console.filter.filter1.marker = Kafka(my-namespace/my-kafka-cluster) <4>
 ----
-<1> The `MarkerFilter` type compares a specified marker for filtering.
-<2> The `onMatch` property accepts the log if the marker matches.
-<3> The `onMismatch` property rejects the log if the marker does not match.
-<4> The marker used for filtering is in the format __KIND(NAMESPACE/NAME-OF-RESOURCE)__.
+<1> The `MarkerFilter` compares a specified marker.
+<2> `onMatch` accepts logs if the marker matches.
+<3> `onMismatch` rejects logs if the marker does not match.
+<4> Marker format: `kind(namespace/resource_name)`.
 
-You can create one or more filters.
-Here, the log is filtered for two Kafka clusters.
+For multiple filters, define each one separately:
 
 .Multiple logging filter configuration
-[source,yaml,subs="+attributes"]
+[source,properties]
 ----
-appender.console.filter.filter1.type=MarkerFilter
-appender.console.filter.filter1.onMatch=ACCEPT
-appender.console.filter.filter1.onMismatch=DENY
-appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster-1)
-appender.console.filter.filter2.type=MarkerFilter
-appender.console.filter.filter2.onMatch=ACCEPT
-appender.console.filter.filter2.onMismatch=DENY
-appender.console.filter.filter2.marker=Kafka(my-namespace/my-kafka-cluster-2)
+# ...
+
+appender.console.name = STDOUT
+
+appender.console.filter.filter1.type = MarkerFilter
+appender.console.filter.filter1.onMatch = ACCEPT
+appender.console.filter.filter1.onMismatch = DENY
+appender.console.filter.filter1.marker = Kafka(my-namespace/my-kafka-cluster-1)
+
+appender.console.filter.filter2.type = MarkerFilter
+appender.console.filter.filter2.onMatch = ACCEPT
+appender.console.filter.filter2.onMismatch = DENY
+appender.console.filter.filter2.marker = Kafka(my-namespace/my-kafka-cluster-2)
 ----
 
 .Adding filters to the Cluster Operator
 
-To add filters to the Cluster Operator, update its logging ConfigMap YAML file (`install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`).
+To add filters to the Cluster Operator, update the `ConfigMap` YAML file (`install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`):
 
 .Procedure
 
-. Update the `050-ConfigMap-strimzi-cluster-operator.yaml` file to add the filter properties to the ConfigMap.
-+
-In this example, the filter properties return logs only for the `my-kafka-cluster` Kafka cluster:
+. Update the `050-ConfigMap-strimzi-cluster-operator.yaml` file to add the filter properties:
 +
 [source,yaml,subs="+attributes"]
 ----
@@ -67,8 +71,16 @@ apiVersion: v1
 metadata:
   name: strimzi-cluster-operator
 data:
-  log4j2.properties:
-    #...
+  log4j2.properties: |
+    rootLogger.level = "INFO"
+    rootLogger.appenderRefs = console
+    rootLogger.appenderRef.console.ref = STDOUT
+
+    appender.console.type = Console
+    appender.console.name = STDOUT
+    appender.console.layout.type = PatternLayout
+    appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+    
     appender.console.filter.filter1.type=MarkerFilter
     appender.console.filter.filter1.onMatch=ACCEPT
     appender.console.filter.filter1.onMismatch=DENY
@@ -82,28 +94,18 @@ Alternatively, edit the `ConfigMap` directly:
 kubectl edit configmap strimzi-cluster-operator
 ----
 
-. If you updated the YAML file instead of editing the `ConfigMap` directly, apply the changes by deploying the ConfigMap:
-+
-[source,shell,subs=+quotes]
-----
-kubectl create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml
-----
-
-.Adding filters to the Topic Operator or User Operator
+. If updating the YAML file, apply the changes to the `ConfigMap` configuration.
 
-To add filters to the Topic Operator or User Operator, create or edit a logging ConfigMap.
+.Adding filters to the Topic or User Operator
 
-In this procedure a logging ConfigMap is created with filters for the Topic Operator.
-The same approach is used for the User Operator.
+To add filters to the Topic or User Operator, create or edit a logging `ConfigMap`. 
+The same method applies for both operators.
 
 .Procedure
 
-. Create the ConfigMap.
-+
-You can create the ConfigMap as a YAML file or from a properties file.
-+
-In this example, the filter properties return logs only for the `my-topic` topic:
+. Create the `ConfigMap` as a YAML file or from a properties file. 
 +
+.Example filter properties for `my-topic` topic
 [source,yaml,subs="+attributes"]
 ----
 kind: ConfigMap
@@ -111,38 +113,51 @@ apiVersion: v1
 metadata:
   name: logging-configmap
 data:
-  log4j2.properties:
-    rootLogger.level="INFO"
-    appender.console.filter.filter1.type=MarkerFilter
-    appender.console.filter.filter1.onMatch=ACCEPT
-    appender.console.filter.filter1.onMismatch=DENY
-    appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)
-----
-+
-If you are using a properties file, specify the file at the command line:
-+
-[source,shell]
-----
-kubectl create configmap logging-configmap --from-file=log4j2.properties
+  log4j2.properties: |
+    rootLogger.level = "INFO"
+    rootLogger.appenderRefs = console
+    rootLogger.appenderRef.console.ref = STDOUT
+
+    appender.console.type = Console
+    appender.console.name = STDOUT
+    appender.console.layout.type = PatternLayout
+    appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+
+    appender.console.filter.filter1.type = MarkerFilter
+    appender.console.filter.filter1.onMatch = ACCEPT
+    appender.console.filter.filter1.onMismatch = DENY
+    appender.console.filter.filter1.marker = KafkaTopic(my-namespace/my-topic)
 ----
 +
-The properties file defines the logging configuration:
+If you are using a properties file, define the logging configuration and specify the file at the command line when creating the `ConfigMap`.
 +
+.Properties file definition
 [source,text]
 ----
 # Define the logger
-rootLogger.level="INFO"
+rootLogger.level = "INFO"
+rootLogger.appenderRefs = console
+rootLogger.appenderRef.console.ref = STDOUT
+# Define the appenders
+appender.console.type = Console
+appender.console.name = STDOUT
+appender.console.layout.type = PatternLayout
+appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
 # Set the filters
-appender.console.filter.filter1.type=MarkerFilter
-appender.console.filter.filter1.onMatch=ACCEPT
-appender.console.filter.filter1.onMismatch=DENY
-appender.console.filter.filter1.marker=KafkaTopic(my-namespace/my-topic)
+appender.console.filter.filter1.type = MarkerFilter
+appender.console.filter.filter1.onMatch = ACCEPT
+appender.console.filter.filter1.onMismatch = DENY
+appender.console.filter.filter1.marker = KafkaTopic(my-namespace/my-topic)
 # ...
 ----
-
-. Define _external_ logging in the `spec` of the resource, setting the `logging.valueFrom.configMapKeyRef.name` to the name of the ConfigMap and `logging.valueFrom.configMapKeyRef.key` to the key in this ConfigMap.
 +
-For the Topic Operator, logging is specified in the `topicOperator` configuration of the `Kafka` resource.
+.Specifying the properties file
+[source,shell]
+----
+kubectl create configmap logging-configmap --from-file=log4j2.properties
+----
+
+. Define `external` logging in the `topicOperator` or `userOperator` configuration of the `Kafka` resource, specifying the `name` and `key` of the ConfigMap:
 +
 [source,shell,subs="+quotes,attributes"]
 ----
@@ -158,12 +173,7 @@ spec:
             key: log4j2.properties
 ----
 
-. Apply the changes by deploying the Cluster Operator:
-
-[source,shell,subs=+quotes]
-----
-create -f install/cluster-operator -n my-cluster-operator-namespace
-----
+. Apply the changes to the `Kafka` configuration.
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/documentation/modules/cruise-control/proc-configuring-deploying-cruise-control.adoc b/documentation/modules/cruise-control/proc-configuring-deploying-cruise-control.adoc
index a365be60386..828a85beea5 100644
--- a/documentation/modules/cruise-control/proc-configuring-deploying-cruise-control.adoc
+++ b/documentation/modules/cruise-control/proc-configuring-deploying-cruise-control.adoc
@@ -106,7 +106,7 @@ spec:
 <4> Optimization goals configuration, which can include configuration for default optimization goals (`default.goals`), supported optimization goals (`goals`), and hard goals (`hard.goals`).
 <5> CORS enabled and configured for read-only access to the Cruise Control API.
 <6> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
-<7> Cruise Control loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` key in the ConfigMap. Cruise Control has a single logger named `rootLogger.level`. You can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
+<7> Cruise Control loggers and log levels added directly (`inline`) or indirectly (`external`) through a `ConfigMap`. Custom Log4j configuration must be placed under the `log4j2.properties` key in the `ConfigMap`. You can set log levels to `INFO`, `ERROR`, `WARN`, `TRACE`, `DEBUG`, `FATAL` or `OFF`.
 <8> Template customization. Here a pod is scheduled with additional security attributes.
 <9> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <10> Prometheus metrics enabled. In this example, metrics are configured for the Prometheus JMX Exporter (the default metrics exporter).
diff --git a/documentation/modules/operators/ref-operator-cluster-logging-configmap.adoc b/documentation/modules/operators/ref-operator-cluster-logging-configmap.adoc
index 3ec86e1755c..ed036fec59f 100644
--- a/documentation/modules/operators/ref-operator-cluster-logging-configmap.adoc
+++ b/documentation/modules/operators/ref-operator-cluster-logging-configmap.adoc
@@ -7,11 +7,10 @@
 
 [role="_abstract"]
 Cluster Operator logging is configured through a `ConfigMap` named `strimzi-cluster-operator`.
-A `ConfigMap` containing logging configuration is created when installing the Cluster Operator.
-This `ConfigMap` is described in the file `install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`.
-You configure Cluster Operator logging by changing the `data.log4j2.properties` values in this `ConfigMap`.
+This `ConfigMap`, created with default values during installation, is described in the file `install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`.
+Configure Cluster Operator logging by changing `data.log4j2.properties` values in the file.
 
-To update the logging configuration, you can edit the `050-ConfigMap-strimzi-cluster-operator.yaml` file and then run the following command:
+To update the logging configuration, edit the `050-ConfigMap-strimzi-cluster-operator.yaml` file and then run the following command:
 [source,shell,subs=+quotes]
 kubectl create -f _install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml_
 
@@ -19,14 +18,22 @@ Alternatively, edit the `ConfigMap` directly:
 [source,shell,subs=+quotes]
 kubectl edit configmap strimzi-cluster-operator
 
-With this ConfigMap, you can control various aspects of logging, including the root logger level, log output format, and log levels for different components. 
-The `monitorInterval` setting, determines how often the logging configuration is reloaded. 
-You can also control the logging levels for the Kafka `AdminClient` or Netty.
-Netty is a framework used in Strimzi for network communication, and OkHttp is a library used for making HTTP requests.
-  
+With this `ConfigMap`, you can control the following aspects of logging:
+
+* Root logger level
+* Log output format
+* Log levels for different components
+* Kafka `AdminClient` logging levels
+* Netty logging Levels
+* How often logging configuration is loaded
+
+Netty is a framework used in Strimzi for network communication.
+The `monitorInterval` setting determines how often in seconds the logging configuration is dynamically reloaded.
+The default is 30 seconds.
+
 If the `ConfigMap` is missing when the Cluster Operator is deployed, the default logging values are used.
 
 If the `ConfigMap` is accidentally deleted after the Cluster Operator is deployed, the most recently loaded logging configuration is used.
 Create a new `ConfigMap` to load a new logging configuration.
 
-NOTE: Do not remove the `monitorInterval` option from the `ConfigMap`.
\ No newline at end of file
+WARNING: Do not remove the `monitorInterval` option from the `ConfigMap`.
\ No newline at end of file
diff --git a/documentation/shared/attributes.adoc b/documentation/shared/attributes.adoc
index d3d599e258c..de8be0f45c1 100644
--- a/documentation/shared/attributes.adoc
+++ b/documentation/shared/attributes.adoc
@@ -168,6 +168,7 @@
 :BookURLConfiguring: ./configuring.html
 :BookURLOverview: ./overview.html
 :BookURLBridge: https://strimzi.io/docs/bridge/latest/
+:DocArchive: https://strimzi.io/documentation/archive/
 
 // Link to resource on https://github.com/strimzi/strimzi-kafka-operator
 // Default `main`, specific version overriden when building the docs by `make`


Reviews:
user: login: fvaleri
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-11T16:33:16Z
user: login: scholzj
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-12T21:16:11Z
user: login: PaulRMellor
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T16:31:25Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-13T20:09:51Z
user: login: PaulRMellor
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-14T13:34:23Z
user: login: PaulRMellor
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-14T13:46:57Z
user: login: fvaleri
body: LGTM. Thanks.
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-14T15:59:49Z
user: login: scholzj
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-15T13:18:53Z
user: login: PaulRMellor
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-17T16:20:04Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-17T20:43:08Z
user: login: ppatierno
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T13:12:31Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T16:39:38Z
user: login: ppatierno
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-22T16:58:17Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-22T20:21:47Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-22T20:23:18Z
user: login: scholzj
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-22T20:25:43Z
user: login: ppatierno
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-24T05:21:02Z
user: login: scholzj
body: Sorry, being away from work, I do not have really enough time to focus on the PR all at once. So there is always a bunch of new things I notice with every pass. I imagine it must be hard to keep changing things again and again. Sorry :-(.
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-24T20:14:27Z
user: login: PaulRMellor
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-25T10:43:36Z
user: login: scholzj
body: Few more nits, but LGTM otherwise. I already approved it.
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-25T18:38:00Z
user: login: ppatierno
body: LGTM. Just a nit from me (and of course agree with the ones raised by Jakub)
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-26T01:04:42Z

Review comments:
diff_hunk: @@ -114,15 +107,13 @@ spec:
   logging:
     type: inline
     loggers:
-      connect.root.logger.level: INFO
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSourceTask: TRACE
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSinkTask: DEBUG
+      rootLogger.level: INFO
+      logger.org.apache.kafka.connect.runtime.WorkerSourceTask: TRACE
+      logger.org.apache.kafka.connect.runtime.WorkerSinkTask: DEBUG
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: fvaleri
body: ```suggestion
      logger.sourcetask.name = org.apache.kafka.connect.runtime.WorkerSourceTask
      logger.sourcetask.level = TRACE
      logger.sinktask.name = org.apache.kafka.connect.runtime.WorkerSinkTask
      logger.sinktask.level = DEBUG
```
created_at: 2025-03-11T16:18:08Z
author_association: MEMBER
diff_hunk: @@ -80,8 +80,8 @@ In this case, fix the configuration so that the Cluster Operator can roll out th
 = Logging
 Kafka Connect has its own configurable loggers:
 
-* `connect.root.logger.level`
-* `log4j.logger.org.reflections`
+* `rootLogger.level`
+* `logger.org.reflections`
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: fvaleri
body: ```suggestion
* `rootLogger.*`
* `logger.reflections.name = org.reflections`
  `logger.reflections.*`
```
created_at: 2025-03-11T16:21:39Z
author_association: MEMBER
diff_hunk: @@ -119,30 +119,21 @@ Be aware that if the configured image is not compatible with Strimzi images, it
 
 Kafka has its own configurable loggers, which include the following:
 
-* `log4j.logger.kafka`
-* `log4j.logger.org.apache.kafka`
-* `log4j.logger.kafka.request.logger`
-* `log4j.logger.kafka.network.Processor`
-* `log4j.logger.kafka.server.KafkaApis`
-* `log4j.logger.kafka.network.RequestChannel$`
-* `log4j.logger.kafka.controller`
-* `log4j.logger.kafka.log.LogCleaner`
-* `log4j.logger.state.change.logger`
-* `log4j.logger.kafka.authorizer.logger`
-
-Kafka uses the Apache `log4j` logger implementation.
-
+* `logger.kafka`
+* `logger.org.apache.kafka`
+* `logger.kafka.request.logger`
+* `logger.kafka.network.RequestChannel$`
+* `logger.org.apache.kafka.controller`
+* `logger.kafka.log.LogCleaner`
+* `logger.state.change.logger`
+* `logger.kafka.authorizer.logger`
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: fvaleri
body: I think this is not correct. See my previous comments and also the examples included in the following PR for each major component.

https://github.com/strimzi/strimzi-kafka-operator/pull/11176/files#diff-96dbf0bf20d7d83f0a33459b088dd6223e3c46f114c989e177c335505369d9f6
created_at: 2025-03-11T16:23:19Z
author_association: MEMBER
diff_hunk: @@ -154,18 +145,15 @@ spec:
     logging:
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
-        log4j.logger.kafka.coordinator.transaction: TRACE
-        log4j.logger.kafka.log.LogCleanerManager: DEBUG
-        log4j.logger.kafka.request.logger: DEBUG
-        log4j.logger.io.strimzi.kafka.oauth: DEBUG
-        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
+        rootLogger.level: INFO
+        logger.kafka.coordinator.transaction: TRACE
+        logger.kafka.log.LogCleanerManager: DEBUG
+        logger.kafka.request.logger: DEBUG
+        logger.io.strimzi.kafka.oauth: DEBUG
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: fvaleri
body: Same as previous comments.
created_at: 2025-03-11T16:23:46Z
author_association: MEMBER
diff_hunk: @@ -7,26 +7,32 @@
 
 [role="_abstract"]
 Cluster Operator logging is configured through a `ConfigMap` named `strimzi-cluster-operator`.
-A `ConfigMap` containing logging configuration is created when installing the Cluster Operator.
-This `ConfigMap` is described in the file `install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`.
-You configure Cluster Operator logging by changing the `data.log4j2.properties` values in this `ConfigMap`.
+This `ConfigMap`, created with default values during installation, is described in the file `install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml`.
+Configure Cluster Operator logging by changing `data.log4j2.properties` values in the file.
 
-To update the logging configuration, you can edit the `050-ConfigMap-strimzi-cluster-operator.yaml` file and then run the following command:
+To update the logging configuration, edit the `050-ConfigMap-strimzi-cluster-operator.yaml` file and then run the following command:
 [source,shell,subs=+quotes]
 kubectl create -f _install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml_
 
 Alternatively, edit the `ConfigMap` directly:
 [source,shell,subs=+quotes]
 kubectl edit configmap strimzi-cluster-operator
 
-With this ConfigMap, you can control various aspects of logging, including the root logger level, log output format, and log levels for different components. 
-The `monitorInterval` setting, determines how often the logging configuration is reloaded. 
-You can also control the logging levels for the Kafka `AdminClient` or Netty.
-Netty is a framework used in Strimzi for network communication, and OkHttp is a library used for making HTTP requests.
-  
+With this `ConfigMap`, you can control the following aspects of logging:
+
+* Root logger level
+* Log output format
+* Log levels for different components
+* Kafka `AdminClient` logging levels
+* Netty logging Levels
+* How often logging configuration is loaded
+
+Netty is a framework used in Strimzi for network communication.
+The `monitorInterval` setting determines how often in seconds the logging configuration is dynamically reloaded.
path: documentation/modules/operators/ref-operator-cluster-logging-configmap.adoc
user: login: fvaleri
body: Should we say that `monitorInterval` is set to 30 seconds by default? This is different from log4j2 default value of 0 (i.e. reloading disabled). 
created_at: 2025-03-11T16:31:58Z
author_association: MEMBER
diff_hunk: @@ -13,8 +13,8 @@ Configuration options relate to:
 
 Kafka Bridge has its own configurable loggers:
 
-* `rootLogger.level`
-* `logger.__<operation-id>__`
+* `rootLogger.*`
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: There is no `*`. There is `rootLogger`, and the `rootLogger` has a property which defines its log level.
created_at: 2025-03-12T21:02:32Z
author_association: MEMBER
diff_hunk: @@ -13,8 +13,8 @@ Configuration options relate to:
 
 Kafka Bridge has its own configurable loggers:
 
-* `rootLogger.level`
-* `logger.__<operation-id>__`
+* `rootLogger.*`
+* `logger.<operation_id>`
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: These loggers do not seem to be really defined in the Bridge log4j2 file. What seems to be there is:

```
logger.bridge.name = io.strimzi.kafka.bridge
logger.healthy.name = http.openapi.operation.healthy
logger.ready.name = http.openapi.operation.ready
```
created_at: 2025-03-12T21:04:00Z
author_association: MEMBER
diff_hunk: @@ -37,7 +37,7 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
 You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
+Each logger has to be configured assigning it a `name` as `http.openapi.operation.<operation_id>`.
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: Doesn't the above say the logger is configured as `logger.<operation_id>`? So is it `logger.<operation_id>`? Or `http.openapi.operation.<operation_id>`? Or `logger.http.openapi.operation.<operation_id>`?
created_at: 2025-03-12T21:04:44Z
author_association: MEMBER
diff_hunk: @@ -92,19 +93,12 @@ Use a curl request to get a complete list of Kafka Connect loggers running from
 curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
 ----
 
-Kafka Connect uses the Apache `log4j` logger implementation.
-
+Kafka Connect uses the Apache `log4j2` logger implementation.
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: Unfortunately, you need to be version specific here.
created_at: 2025-03-12T21:07:49Z
author_association: MEMBER
diff_hunk: @@ -80,8 +80,9 @@ In this case, fix the configuration so that the Cluster Operator can roll out th
 = Logging
 Kafka Connect has its own configurable loggers:
 
-* `connect.root.logger.level`
-* `log4j.logger.org.reflections`
+* `rootLogger.*`
+* `logger.reflections.name = org.reflections`
+* `logger.reflections.*`
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: Here, as well as for Kafka and MM2 you need to be version specific.

Also, there is nothing like `logger.reflections.*` or `rootLogger.*`. I think you will have to:
* List the actual loggers -> in this case it is `rootLogger` and `logger.reflections` (or `reflection` -> as the `logger.` part just suggests it is a logger)
* For these, users can just configure the level with the `.level` sufffix. E.g. `rootLogger.level` or `logger.reflections.level`
* For any other classes, they have to define the logger. E.g.:
  ```
  logger.mylogger.name = class.or.package
  logger.mylogger.level = WRN
  ```

This should e applied to all these files. But for the time being, we should keep the old Log4j1 information for Kafka 3.9.x as well.
created_at: 2025-03-12T21:13:37Z
author_association: MEMBER
diff_hunk: @@ -119,30 +119,30 @@ Be aware that if the configured image is not compatible with Strimzi images, it
 
 Kafka has its own configurable loggers, which include the following:
 
-* `log4j.logger.kafka`
-* `log4j.logger.org.apache.kafka`
-* `log4j.logger.kafka.request.logger`
-* `log4j.logger.kafka.network.Processor`
-* `log4j.logger.kafka.server.KafkaApis`
-* `log4j.logger.kafka.network.RequestChannel$`
-* `log4j.logger.kafka.controller`
-* `log4j.logger.kafka.log.LogCleaner`
-* `log4j.logger.state.change.logger`
-* `log4j.logger.kafka.authorizer.logger`
-
-Kafka uses the Apache `log4j` logger implementation.
-
+* `rootLogger.*`
+* `logger.kafka.name = kafka`
+* `logger.kafka.*`
+* `logger.orgapachekafka.name = org.apache.kafka`
+* `logger.orgapachekafka.*`
+* `logger.requestlogger.name = kafka.request.logger`
+* `logger.requestlogger.*`
+* `logger.requestchannel.name = kafka.network.RequestChannel$`
+* `logger.requestchannel.*`
+* `logger.controller.name = org.apache.kafka.controller`
+* `logger.controller.*`
+* `logger.logcleaner.name = kafka.log.LogCleaner`
+* `logger.logcleaner.*`
+* `logger.statechange.name = state.change.logger`
+* `logger.statechange.*`
+* `logger.authorizer.name = kafka.authorizer.logger`
+* `logger.authorizer.*`
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: Same as above for Connect, just the list of existing loggers would look a little bit diferently.
created_at: 2025-03-12T21:14:23Z
author_association: MEMBER
diff_hunk: @@ -97,7 +97,7 @@ spec:
   logging: # <12>
     type: inline
     loggers:
-      log4j.rootLogger: INFO
+      rootLogger.level: INFO
path: documentation/modules/configuring/con-config-kafka-connect.adoc
user: login: scholzj
body: I think in these files it is fine to keep only example for Kafka 4.0. But at least in some comment, you should clarify that. E.g.:

```suggestion
      # Valid for Kafka 4.0 and newer / Log4j2
      rootLogger.level: INFO
```
created_at: 2025-03-12T21:15:59Z
author_association: MEMBER
diff_hunk: @@ -80,8 +80,9 @@ In this case, fix the configuration so that the Cluster Operator can roll out th
 = Logging
 Kafka Connect has its own configurable loggers:
 
-* `connect.root.logger.level`
-* `log4j.logger.org.reflections`
+* `rootLogger.*`
+* `logger.reflections.name = org.reflections`
+* `logger.reflections.*`
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: PaulRMellor
body: Thanks @scholzj. Before I proceed, I just want to confirm how you see the presentation. Like this?

> Kafka Connect has its own configurable loggers:
> 
> * `rootLogger`
> * `reflections`

As an alternative to adding the log4j1 examples back, we don't want to add a note in the relevant logging sections of the API reference to say something like: this is for Kafka 4/log4j2, for Kafka 3.9/log4j1 go look at 0.45 doc?

Assuming, with the addition of a few comments (as suggested), we can keep the deploying content as is 

created_at: 2025-03-13T16:31:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -80,8 +80,9 @@ In this case, fix the configuration so that the Cluster Operator can roll out th
 = Logging
 Kafka Connect has its own configurable loggers:
 
-* `connect.root.logger.level`
-* `log4j.logger.org.reflections`
+* `rootLogger.*`
+* `logger.reflections.name = org.reflections`
+* `logger.reflections.*`
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: Yeah, I thikn just mentioning the Log4j1 and linking to 0.45.0 docs is fine.
created_at: 2025-03-13T20:09:51Z
author_association: MEMBER
diff_hunk: @@ -37,7 +37,7 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
 You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
+Each logger has to be configured assigning it a `name` as `http.openapi.operation.<operation_id>`.
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: PaulRMellor
body: I've refreshed this section. Made it more concise and clearer.
created_at: 2025-03-14T13:34:22Z
author_association: CONTRIBUTOR
diff_hunk: @@ -92,19 +93,12 @@ Use a curl request to get a complete list of Kafka Connect loggers running from
 curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
 ----
 
-Kafka Connect uses the Apache `log4j` logger implementation.
-
+Kafka Connect uses the Apache `log4j2` logger implementation.
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: PaulRMellor
body: I've added note, as discussed.
created_at: 2025-03-14T13:46:57Z
author_association: CONTRIBUTOR
diff_hunk: @@ -13,10 +13,10 @@ Configuration options relate to:
 
 Kafka Bridge has its own configurable loggers:
 
-* `rootLogger.*`
-* `logger.<operation_id>`
+* `rootLogger`
+* `bridge`
 
-You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to set log levels for specific operations:
+You can also log levels for specific operations based on endpoints:
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: fvaleri
body: ```suggestion
You can also set log levels for specific operations based on endpoints:
```
created_at: 2025-03-14T15:18:15Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: This is still a bit confusing. If these loggers are defined, you should not need to create them.

@ppatierno Can you please clarify it? Do these loggers really exist? Or how is it? They do not seem to be in the Log4j2 configuration file.
created_at: 2025-03-15T13:11:26Z
author_association: MEMBER
diff_hunk: @@ -92,19 +92,15 @@ Use a curl request to get a complete list of Kafka Connect loggers running from
 curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
 ----
 
-Kafka Connect uses the Apache `log4j` logger implementation.
-
+Kafka Connect uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+NOTE: For Strimzi 0.45 and earlier, log4j1 was used for Kafka components. 
+Refer to the Strimzi 0.45 documentation for loggers and logging configuration examples based on log4j1.
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: This is not a question of Strimzi version but Kafka version. So this needs ot be reworked here as well as in the other places. E.g.:

```suggestion
NOTE: Kafka 3.9 and earlier uses Log4j1 got logging. 
Refer to the Strimzi 0.45 documentation for loggers and logging configuration examples based on log4j1 that you can use with Strimzi 0.46 and Kafka 3.9.x: <LINK-TO-THE-DOCS>
```

**We should probably also mark it as IMPORTANT and not NOTE and move it to the top of the section. Ir is pretty lost here in the middle and for users it makes zero sense to start reading this chapter if they use Kafka 3.9 as none of it is valid for them.**
created_at: 2025-03-15T13:13:49Z
author_association: MEMBER
diff_hunk: @@ -154,18 +150,20 @@ spec:
     logging:
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
-        log4j.logger.kafka.coordinator.transaction: TRACE
-        log4j.logger.kafka.log.LogCleanerManager: DEBUG
-        log4j.logger.kafka.request.logger: DEBUG
-        log4j.logger.io.strimzi.kafka.oauth: DEBUG
-        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
+        rootLogger.level: INFO
+        logger.kafka.name: kafka
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: This line seems to be not needed really?
created_at: 2025-03-15T13:17:20Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: PaulRMellor
body: Thanks. I see them in strimzi-kafka-bridge/config
/log4j2.properties and strimzi-kafka-operator/cluster-operator/.../default-logging
/KafkaBridgeCluster.properties
Let's see what Paolo says

created_at: 2025-03-17T16:20:04Z
author_association: CONTRIBUTOR
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: These two yes, that would mean you can leave out the `.name` lines. But not the other ones - they do not exist there.
created_at: 2025-03-17T20:43:08Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: ppatierno
body: Not sure what you mean here.
The bridge defines loggers for the single operations here https://github.com/strimzi/strimzi-kafka-bridge/blob/main/src/main/java/io/strimzi/kafka/bridge/http/HttpOpenApiOperation.java#L30 and through the above lines you can set the verbosity level after creating the name by following the rules above.
created_at: 2025-03-21T13:12:26Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: That is getting the logger. Does it also define it? If so, does it define it only when the method is actually called? I'm not sure this realyl answers the question if the logger should be defined in the configuration or not (and just the log level can be configured).
created_at: 2025-03-21T16:39:38Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: ppatierno
body: I am pretty sure I am going to say something you already well know but I still get confused on what you are trying to say here.
The code I linked above is just for getting the logger as you said and using it. It's different for each endpoint (i.e. `http.openapi.operation.healthy` in the example but could be `http.openapi.operation.send` for the endpoint related to the `send` operation and so on).
The two lines we have in the properties file are for assigning a name to the logger related to the specific component in the code. With that name we can configure the logger, in this case just the log level.
I don't think we can get rid of any of them, if this is what you are suggesting and I am getting difficulties to understand :-)
created_at: 2025-03-22T16:58:17Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: So I guess we should maybe replace the lines 14-57 with something like this?

```
Kafka Bridge has its own preconfigured loggers:

* `rootLogger` (default logger for all classes)
* `bridge` (all classes in the `io.strimzi.kafka.bridge` package)
* `healthy` (The healthy endpoint `http.openapi.operation.healthy` - defaults to default: `WARN`)
* `ready` (The healthy endpoint `http.openapi.operation.ready` - defaults to default: `WARN`)

For the pre-configured loggers, you can directly configure the log level.
For example:

[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      rootLogger.level: INFO
      logger.ready.level: DEBUG
  # ...
----

You can also create custom loggers for the other operations based on HTTP API endpoints:

* `createConsumer`
* `deleteConsumer`
* `subscribe`
* `unsubscribe`
* `poll`
* `assign`
* `commit`
* `send`
* `sendToPartition`
* `seekToBeginning`
* `seekToEnd`
* `seek`
* `openapi`

Each operation has a corresponding API endpoint, defined according to the OpenAPI specification, allowing fine-grained logging of HTTP requests.
Configure each logger by assigning it a name as `http.openapi.operation.<operation_id>`. 
For example, to set the logging level for the send operation logger:

[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
    type: inline
    loggers:
      logger.send.name: "http.openapi.operation.send"
      logger.send.level: DEBUG
  # ...
----
```
created_at: 2025-03-22T20:21:47Z
author_association: MEMBER
diff_hunk: @@ -117,32 +117,28 @@ Be aware that if the configured image is not compatible with Strimzi images, it
 [id='property-kafka-logging-{context}']
 = Logging
 
-Kafka has its own configurable loggers, which include the following:
+WARNING: Kafka 3.9 and earlier versions use log4j1 for logging.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^]. 
 
-* `log4j.logger.kafka`
-* `log4j.logger.org.apache.kafka`
-* `log4j.logger.kafka.request.logger`
-* `log4j.logger.kafka.network.Processor`
-* `log4j.logger.kafka.server.KafkaApis`
-* `log4j.logger.kafka.network.RequestChannel$`
-* `log4j.logger.kafka.controller`
-* `log4j.logger.kafka.log.LogCleaner`
-* `log4j.logger.state.change.logger`
-* `log4j.logger.kafka.authorizer.logger`
+Kafka has its own configurable loggers, which include the following:
 
-Kafka uses the Apache `log4j` logger implementation.
+* `rootLogger`
+* `kafka`
+* `orgapachekafka`
+* `requestlogger`
+* `requestchannel`
+* `requestchannel`
+* `controller`
+* `logcleaner`
+* `statechange`
+* `authorizer`
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: Similarly to https://github.com/strimzi/strimzi-kafka-operator/pull/11254#discussion_r2008888734, we should clarify which packages / classes do these loggers cover as it is not completely obvious from their names.
created_at: 2025-03-22T20:23:18Z
author_association: MEMBER
diff_hunk: @@ -154,18 +150,19 @@ spec:
     logging:
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
-        log4j.logger.kafka.coordinator.transaction: TRACE
-        log4j.logger.kafka.log.LogCleanerManager: DEBUG
-        log4j.logger.kafka.request.logger: DEBUG
-        log4j.logger.io.strimzi.kafka.oauth: DEBUG
-        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
+        rootLogger.level: INFO
+        logger.transaction.name: logger.kafka.coordinator.transaction
+        logger.transaction.level: TRACE
+        logger.cleaner.name: logger.kafka.log.LogCleanerManager
+        logger.cleaner.level: DEBUG
+        logger.request.name: logger.kafka.request.logger
+        logger.request.level: DEBUG
+        logger.oauth.name: logger.io.strimzi.kafka.oauth
+        logger.oauth.level: DEBUG
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: The names should not the loggers. We should also use the predefined loggers here where possible.

```suggestion
        rootLogger.level: INFO
        logger.logcleaner.level: DEBUG
        logger.requestlogger.level: DEBUG
        logger.transaction.name: kafka.coordinator.transaction
        logger.transaction.level: TRACE
        logger.oauth.name: io.strimzi.kafka.oauth
        logger.oauth.level: DEBUG
```
created_at: 2025-03-22T20:25:43Z
author_association: MEMBER
diff_hunk: @@ -30,44 +30,38 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
+* `healthy` (default: `WARN`)
+* `ready` (default: `WARN`)
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+The healthy and ready loggers are set to `WARN` by default due to verbosity:
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+[source,properties]
+----
+logger.healthy.name = http.openapi.operation.healthy
+logger.healthy.level = WARN
+logger.ready.name = http.openapi.operation.ready
+logger.ready.level = WARN
+----
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: ppatierno
body: Yes I would agree.
created_at: 2025-03-24T05:21:02Z
author_association: MEMBER
diff_hunk: @@ -30,44 +54,32 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+Each operation maps to an API endpoint,  defined according to the OpenAPI specification, and supports fine-grained logging via `http.openapi.operation.<operation_id>`.
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+For example, to set the logging level for the `send` operation logger:
 
-```
-logger.send.name = http.openapi.operation.send
-logger.send.level = DEBUG
-```
+[source,yaml,subs="+quotes,attributes"]
+----
+apiVersion: {KafkaApiVersion}
+kind: KafkaBridge
+spec:
+  # ...
+  logging:
+    type: inline
+    loggers:
+      logger.send.name: "http.openapi.operation.send"
+      logger.send.level: DEBUG
+  # ...
+----
 
 Kafka Bridge uses the Apache `log4j2` logger implementation.
-Loggers are defined in the `log4j2.properties` file, which has the following default configuration for `healthy` and `ready` endpoints:
-
-```
-logger.healthy.name = http.openapi.operation.healthy
-logger.healthy.level = WARN
-logger.ready.name = http.openapi.operation.ready
-logger.ready.level = WARN
-```
-The log level of all other operations is set to `INFO` by default.
-
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration.
-The `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory.
-Default logging is used if the `name` or `key` is not set.
-Inside the ConfigMap, the logging configuration is described using `log4j.properties`.
-For more information about log levels, see {ApacheLoggers}.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: scholzj
body: Maybe we can improve this a bit more (here and in the other files):

```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:27:16Z
author_association: MEMBER
diff_hunk: @@ -92,19 +101,12 @@ Use a curl request to get a complete list of Kafka Connect loggers running from
 curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
 ----
 
-Kafka Connect uses the Apache `log4j` logger implementation.
-
+Kafka Connect uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
-
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: Same as above:

```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:27:57Z
author_association: MEMBER
diff_hunk: @@ -114,15 +116,28 @@ spec:
   logging:
     type: inline
     loggers:
-      connect.root.logger.level: INFO
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSourceTask: TRACE
-      log4j.logger.org.apache.kafka.connect.runtime.WorkerSinkTask: DEBUG
+      rootLogger.level: INFO
+      logger.reflections.level: DEBUG
   # ...
 ----
 
-NOTE: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+You can also define custom loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure logging for runtime tasks:
 
-.External logging
+[source,yaml]
+----
+# ...
+logger.sourcetask.name: org.apache.kafka.connect.runtime.WorkerSourceTask # <1>
+logger.sourcetask.level: TRACE # <2>
+logger.sinktask.name: org.apache.kafka.connect.runtime.WorkerSinkTask # <3>
+logger.sinktask.level: DEBUG # <4>
+----
+<1> Creates a logger for the runtime `WorkerSourceTask` class.
+<2> Sets the logging level for `WorkerSourceTask`.
+<3> Creates a logger for the runtime `WorkerSinkTask` class.
+<4> Sets the logging level for `WorkerSinkTask`.
+
+.Example external logging configuration
path: documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc
user: login: scholzj
body: I think this might be confusing. You use a YAML example for creating and configuring the source and sink task loggers, which looks fine. But it is directly followed up by the example for the external configuration - which is wrong - because the external configuration would need it in the properties format and it would need to have the full Log4j2 properties file (i.e. including the format or output configurations and so on). 

I'm not sure if it is intentional to suggests that these two should be used together. But even if it wasn't, I think many users might read it that way. Can we either replace the external configuration with internal configuration or make it more clear that this example is not related to the previous one?
created_at: 2025-03-24T19:33:35Z
author_association: MEMBER
diff_hunk: @@ -154,18 +154,26 @@ spec:
     logging:
       type: inline
       loggers:
-        kafka.root.logger.level: INFO
-        log4j.logger.kafka.coordinator.transaction: TRACE
-        log4j.logger.kafka.log.LogCleanerManager: DEBUG
-        log4j.logger.kafka.request.logger: DEBUG
-        log4j.logger.io.strimzi.kafka.oauth: DEBUG
-        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
+        rootLogger.level: INFO
+        logger.kafka.level: DEBUG 
+        logger.logcleaner.level: DEBUG 
+        logger.authorizer.level: TRACE
   # ...
 ----
 
-NOTE: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+You can also define custom loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to configure logging for OAuth components:
 
-.External logging
+[source,yaml]
+----
+# ...
+logger.oauth.name: io.strimzi.kafka.oauth # <1>
+logger.oauth.level: DEBUG # <2>
+----
+<1> Creates a logger for the `io.strimzi.kafka.oauth` package.
+<2> Sets the logging level for the OAuth package.
+
+.Example external logging configuration
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: Same as above, I think these two examples are confusing and need to either work together or be more clearly separated as unelated.
created_at: 2025-03-24T19:35:52Z
author_association: MEMBER
diff_hunk: @@ -117,32 +117,32 @@ Be aware that if the configured image is not compatible with Strimzi images, it
 [id='property-kafka-logging-{context}']
 = Logging
 
-Kafka has its own configurable loggers, which include the following:
-
-* `log4j.logger.kafka`
-* `log4j.logger.org.apache.kafka`
-* `log4j.logger.kafka.request.logger`
-* `log4j.logger.kafka.network.Processor`
-* `log4j.logger.kafka.server.KafkaApis`
-* `log4j.logger.kafka.network.RequestChannel$`
-* `log4j.logger.kafka.controller`
-* `log4j.logger.kafka.log.LogCleaner`
-* `log4j.logger.state.change.logger`
-* `log4j.logger.kafka.authorizer.logger`
-
-Kafka uses the Apache `log4j` logger implementation.
-
+WARNING: Kafka 3.9 and earlier versions use log4j1 for logging.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^]. 
+
+Kafka has its own preconfigured loggers:
+
+[cols="1m,2,1",options="header"]
+|===
+| Logger              | Description                                              | Default Level
+
+| rootLogger          | Default logger for all classes                           | INFO
+| kafka               | Logs Kafka node classes                                  | INFO
+| orgapachekafka      | Logs Kafka library classes                               | INFO
+| requestlogger       | Logs client request details                              | WARN
+| requestchannel      | Logs request handling in the broker                      | WARN
+| controller          | Logs controller activity, such as leadership changes     | INFO
+| logcleaner          | Logs log compaction and cleanup processes                | INFO
+| statechange         | Logs broker and partition state transitions              | INFO
+| authorizer          | Logs access control decisions                            | INFO
+|===
+
+Kafka uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc
user: login: scholzj
body: Same as earlier

```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:37:31Z
author_association: MEMBER
diff_hunk: @@ -301,22 +301,21 @@ For more information, refer to the xref:type-BrokerCapacity-reference[BrokerCapa
 [id='property-cruise-control-logging-{context}']
 = Logging
 
-Cruise Control has its own configurable logger:
+Cruise Control has its own preconfigured logger:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                        | Default Level
 
-Cruise Control uses the Apache `log4j2` logger implementation.
+| rootLogger | Default logger for all classes     | INFO
+|===
 
+Cruise Control uses the Apache `log4j2` logger implementation.
 Use the `logging` property to configure loggers and logger levels.
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc
user: login: scholzj
body: ```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:37:54Z
author_association: MEMBER
diff_hunk: @@ -329,20 +328,26 @@ spec:
       type: inline
       loggers:
         rootLogger.level: INFO
-        logger.exec.name: com.linkedin.kafka.cruisecontrol.executor.Executor # <1>
-        logger.exec.level: TRACE # <2>
-        logger.go.name: com.linkedin.kafka.cruisecontrol.analyzer.GoalOptimizer # <3>
-        logger.go.level: DEBUG # <4>
     # ...
 ----
+
+You can also define custom loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to add more detailed logging for Cruise Control:
+
+[source,yaml]
+----
+# ...
+logger.exec.name: com.linkedin.kafka.cruisecontrol.executor.Executor # <1>
+logger.exec.level: TRACE # <2>
+logger.go.name: com.linkedin.kafka.cruisecontrol.analyzer.GoalOptimizer # <3>
+logger.go.level: DEBUG # <4>
+----
 <1> Creates a logger for the Cruise Control `Executor` class.
 <2> Sets the logging level for the `Executor` class.
 <3> Creates a logger for the Cruise Control `GoalOptimizer` class.
 <4> Sets the logging level for the `GoalOptimizer` class.
 
-NOTE: When investigating an issue with Cruise Control, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
-
-.External logging
+.Example external logging configuration
path: documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc
user: login: scholzj
body: Same as in the other files about these two examples.
created_at: 2025-03-24T19:38:13Z
author_association: MEMBER
diff_hunk: @@ -3,23 +3,22 @@ Configures the Topic Operator.
 [id='property-topic-operator-logging-{context}']
 = Logging
 
-The Topic Operator has a configurable logger:
+The Topic Operator has its own preconfigured loggers:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                    | Default Level
 
-The Topic Operator uses the Apache `log4j2` logger implementation.
-
-Use the `logging` property in the `entityOperator.topicOperator` field of the Kafka resource `Kafka` resource to configure loggers and logger levels.
+| rootLogger | Default logger for all classes | INFO
+| jetty      | Logs HTTP server activity      | INFO
+|===
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j2.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+The Topic Operator uses the Apache `log4j2` logger implementation.
+Use the `logging` property to configure loggers and logger levels.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the root logger level.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc
user: login: scholzj
body: ```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:38:22Z
author_association: MEMBER
diff_hunk: @@ -38,21 +37,27 @@ spec:
         type: inline
         loggers:
           rootLogger.level: INFO
-          logger.top.name: io.strimzi.operator.topic # <1>
-          logger.top.level: DEBUG # <2> 
-          logger.toc.name: io.strimzi.operator.topic.TopicOperator # <3>
-          logger.toc.level: TRACE # <4>
+          logger.jetty.level: WARN
   # ...
 ----
+
+You can also define custom loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to add more detailed logging for the Topic Operator:
+
+[source,yaml]
+----
+# ...
+logger.top.name: io.strimzi.operator.topic # <1>
+logger.top.level: DEBUG # <2> 
+logger.toc.name: io.strimzi.operator.topic.TopicOperator # <3>
+logger.toc.level: TRACE # <4>
+----
 <1> Creates a logger for the `topic` package.
 <2> Sets the logging level for the `topic` package.
 <3> Creates a logger for the `TopicOperator` class.
 <4> Sets the logging level for the `TopicOperator` class.
 
-NOTE: When investigating an issue with the operator, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. 
-However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
-
-.External logging
+.Example external logging configuration
path: documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc
user: login: scholzj
body: Same as above for the two examples.
created_at: 2025-03-24T19:38:50Z
author_association: MEMBER
diff_hunk: @@ -3,23 +3,22 @@ Configures the User Operator.
 [id='property-user-operator-logging-{context}']
 = Logging
 
-The User Operator has a configurable logger:
+The User Operator has its own preconfigured loggers:
 
-* `rootLogger.level`
+[cols="1m,2,1",options="header"]
+|===
+| Logger     | Description                    | Default Level
 
-The User Operator uses the Apache `log4j2` logger implementation.
-
-Use the `logging` property in the `entityOperator.userOperator` field of the `Kafka` resource to configure loggers and logger levels.
+| rootLogger | Default logger for all classes | INFO
+| jetty      | Logs HTTP server activity      | INFO
+|===
 
-You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
-If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j2.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
-For more information about log levels, see {ApacheLoggers}.
+The User Operator uses the Apache `log4j2` logger implementation.
+Use the `logging` property to configure loggers and logger levels.
 
-Here we see examples of `inline` and `external` logging.
-The `inline` logging specifies the `rootLogger.level`.
-You can also set log levels for specific classes or loggers by adding them to the loggers property.
+You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define logging configurations using the `log4j2.properties` key.
path: documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc
user: login: scholzj
body: ```suggestion
You can set the log levels by specifying the logger and level directly (`inline`) or use a custom (`external`) `ConfigMap` to define your own Log4j2 configuration by providing the full `log4j2.properties` file.
```
created_at: 2025-03-24T19:39:35Z
author_association: MEMBER
diff_hunk: @@ -38,24 +37,27 @@ spec:
         type: inline
         loggers:
           rootLogger.level: INFO
-          logger.uop.name: io.strimzi.operator.user # <1>
-          logger.uop.level: DEBUG # <2> 
-          logger.abstractcache.name: io.strimzi.operator.user.operator.cache.AbstractCache # <3>
-          logger.abstractcache.level: TRACE # <4>
-          logger.jetty.level: DEBUG # <5>
-          
+          logger.jetty.level: WARN  
   # ...
 ----
+
+You can also define custom loggers by specifying the full class or package name using `logger.<name>.name`. 
+For example, to add more detailed logging for the User Operator:
+
+[source,yaml]
+----
+# ...
+logger.uop.name: io.strimzi.operator.user # <1>
+logger.uop.level: DEBUG # <2> 
+logger.abstractcache.name: io.strimzi.operator.user.operator.cache.AbstractCache # <3>
+logger.abstractcache.level: TRACE # <4>     
+----
 <1> Creates a logger for the `user` package.
 <2> Sets the logging level for the `user` package.
 <3> Creates a logger for the `AbstractCache` class.
-<4> Sets the logging level for the `AbstractCache` class.
-<5> Changes the logging level for the default `jetty` logger. The `jetty` logger is part of the logging configuration provided with Strimzi.
-By default, it is set to `INFO`.  
-
-NOTE: When investigating an issue with the operator, it's usually sufficient to change the `rootLogger` to `DEBUG` to get more detailed logs. However, keep in mind that setting the log level to `DEBUG` may result in a large amount of log output and may have performance implications.
+<4> Sets the logging level for the `AbstractCache` class. 
 
-.External logging
+.Example external logging configuration
path: documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc
user: login: scholzj
body: Same as above about the two examples.
created_at: 2025-03-24T19:39:51Z
author_association: MEMBER
diff_hunk: @@ -6,31 +6,46 @@
 = Configuring logging levels
 
 [role="_abstract"]
-Configure logging levels in the custom resources of Kafka components and Strimzi operators.
-You can specify the logging levels directly in the `spec.logging` property of the custom resource.
-Or you can define the logging properties in a ConfigMap that's referenced in the custom resource using the `configMapKeyRef` property.
 
-The advantages of using a ConfigMap are that the logging properties are maintained in one place and are accessible to more than one resource.
-You can also reuse the ConfigMap for more than one resource.
-If you are using a ConfigMap to specify loggers for Strimzi Operators, you can also append the logging specification to add filters.
+WARNING: Strimzi operators and Kafka components use log4j2 for logging.
+However, Kafka 3.9 and earlier versions rely on log4j1.
+For log4j1-based configuration examples, refer to the link:{DocArchive}[Strimzi 0.45 documentation^].
 
-You specify a logging `type` in your logging specification:
+Configure the logging levels of Kafka components and Strimzi operators through their custom resources.
+You can use either of these options:
+
+* Specify logging levels directly in the `spec.logging` property of the custom resource.
+* Define logging properties in a custom `ConfigMap` and reference it using the `configMapKeyRef` property.
+
+Advantages of using a `ConfigMap`:
+
+* Centralized maintenance
+* Reusable with multiple resources
+* For operators, the flexibility to append logging specifications to add filters
path: documentation/assemblies/configuring/assembly-logging-configuration.adoc
user: login: scholzj
body: I think the flexibility applies to all components. As an example, the custom Log4j2 properties file can for example allow changing of the layout to JSON as one of the more popular requests etc.
created_at: 2025-03-24T19:41:18Z
author_association: MEMBER
diff_hunk: @@ -39,29 +54,32 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: my-config-map
-      key: my-config-map-key
+      key: log4j2.properties
 # ...
 ----
 
-Values for the `name` and `key` of the ConfigMap are mandatory.
-Default logging is used if the `name` or `key` is not set.
+Default logging is used if logging is not specified in the resource using either method.
+Loggers that haven't been explicitly configured inherit settings from their parent loggers. 
+By default, any available loggers that are not configured have their level set to `OFF`.
path: documentation/assemblies/configuring/assembly-logging-configuration.adoc
user: login: scholzj
body: Not sure how this was meant, but I think it is not true. They should IMHO inherit from the `rootLogger`.
created_at: 2025-03-24T19:42:38Z
author_association: MEMBER
diff_hunk: @@ -39,29 +54,32 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: my-config-map
-      key: my-config-map-key
+      key: log4j2.properties
 # ...
 ----
 
-Values for the `name` and `key` of the ConfigMap are mandatory.
-Default logging is used if the `name` or `key` is not set.
+Default logging is used if logging is not specified in the resource using either method.
+Loggers that haven't been explicitly configured inherit settings from their parent loggers. 
+By default, any available loggers that are not configured have their level set to `OFF`.
 
-== Logging options for Kafka components and operators
+When a resource managed by the Cluster Operator is created, a `ConfigMap` with the specified logging configuration is also created. 
+For components managed by the Strimzi operators, changes to logging levels are applied dynamically.
 
-For more information on configuring logging for specific Kafka components or operators, see the following sections.
+WARNING: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.
path: documentation/assemblies/configuring/assembly-logging-configuration.adoc
user: login: scholzj
body: ```suggestion
WARNING: Setting a log level to `DEBUG` or `TRACE` may result in a large amount of log output and may have performance implications.
```
created_at: 2025-03-24T19:43:06Z
author_association: MEMBER
diff_hunk: @@ -130,6 +131,7 @@ spec:
       logging: # <23>
         type: inline
         loggers:
+          # Kafka 4.0+ uses Log4j2
path: documentation/modules/configuring/con-config-kafka-kraft.adoc
user: login: scholzj
body: I don't think we need this for the TO as it is independent on Kafka version. It will always use Log4j2. So I would remove this:

```suggestion
```
created_at: 2025-03-24T19:44:19Z
author_association: MEMBER
diff_hunk: @@ -146,6 +148,7 @@ spec:
       logging: # <24>
         type: inline
         loggers:
+          # Kafka 4.0+ uses Log4j2
path: documentation/modules/configuring/con-config-kafka-kraft.adoc
user: login: scholzj
body: I don't think we need this for the UO as it is independent on Kafka version. It will always use Log4j2. So I would remove this:

```suggestion
```
created_at: 2025-03-24T19:44:26Z
author_association: MEMBER
diff_hunk: @@ -6,59 +6,63 @@
 = Adding logging filters to Strimzi operators
 
 [role="_abstract"]
-If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi operators,
-you can also define logging filters to limit what's returned in the log.
+Use a `ConfigMap` to configure logging levels in Strimzi operators with Log4j2 and define filters to control log output.
 
-Logging filters are useful when you have a large number of logging messages.
-Suppose you set the log level for the logger as DEBUG (`rootLogger.level="DEBUG"`).
-Logging filters reduce the number of logs returned for the logger at that level, so you can focus on a specific resource.
-When the filter is set, only log messages matching the filter are logged.
+Filters are useful when too many logging messages are being produced. 
+For instance, if `rootLogger.level="DEBUG"`, filters reduce the number of logs to focus on a specific resource by logging only messages matching the filter.
 
-Filters use _markers_ to specify what to include in the log.
-You specify a kind, namespace and name for the marker.
-For example, if a Kafka cluster is failing, you can isolate the logs by specifying the kind as `Kafka`, and use the namespace and name of the failing cluster.
-
-This example shows a marker filter for a Kafka cluster named `my-kafka-cluster`.
+Markers specify what to include in the log using kind, namespace, and resource name values. 
+For example, to isolate the logs of a failing Kafka cluster, set the kind to `Kafka` and use the namespace and name of the cluster.
 
 .Basic logging filter configuration
 [source,yaml,subs="+attributes"]
 ----
 rootLogger.level="INFO"
-appender.console.filter.filter1.type=MarkerFilter <1>
-appender.console.filter.filter1.onMatch=ACCEPT <2>
-appender.console.filter.filter1.onMismatch=DENY <3>
-appender.console.filter.filter1.marker=Kafka(my-namespace/my-kafka-cluster) <4>
+rootLogger.appenderRefs = console
+rootLogger.appenderRef.console.ref = STDOUT
+
+appender.console.type = Console
+appender.console.name = STDOUT
+appender.console.layout.type = PatternLayout
+appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+
+appender.console.filter.filter1.type = MarkerFilter <1>
+appender.console.filter.filter1.onMatch = ACCEPT <2>
+appender.console.filter.filter1.onMismatch = DENY <3>
+appender.console.filter.filter1.marker = Kafka(my-namespace/my-kafka-cluster) <4>
 ----
-<1> The `MarkerFilter` type compares a specified marker for filtering.
-<2> The `onMatch` property accepts the log if the marker matches.
-<3> The `onMismatch` property rejects the log if the marker does not match.
-<4> The marker used for filtering is in the format __KIND(NAMESPACE/NAME-OF-RESOURCE)__.
+<1> The `MarkerFilter` compares a specified marker.
+<2> `onMatch` accepts logs if the marker matches.
+<3> `onMismatch` rejects logs if the marker does not match.
+<4> Marker format: `kind(namespace/resource_name)`.
 
-You can create one or more filters.
-Here, the log is filtered for two Kafka clusters.
+For multiple filters, define each one separately:
 
 .Multiple logging filter configuration
 [source,yaml,subs="+attributes"]
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: Not sure if we need to change this, but the format here is not YAML but properties.
created_at: 2025-03-24T19:46:37Z
author_association: MEMBER
diff_hunk: @@ -6,59 +6,63 @@
 = Adding logging filters to Strimzi operators
 
 [role="_abstract"]
-If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi operators,
-you can also define logging filters to limit what's returned in the log.
+Use a `ConfigMap` to configure logging levels in Strimzi operators with Log4j2 and define filters to control log output.
 
-Logging filters are useful when you have a large number of logging messages.
-Suppose you set the log level for the logger as DEBUG (`rootLogger.level="DEBUG"`).
-Logging filters reduce the number of logs returned for the logger at that level, so you can focus on a specific resource.
-When the filter is set, only log messages matching the filter are logged.
+Filters are useful when too many logging messages are being produced. 
+For instance, if `rootLogger.level="DEBUG"`, filters reduce the number of logs to focus on a specific resource by logging only messages matching the filter.
 
-Filters use _markers_ to specify what to include in the log.
-You specify a kind, namespace and name for the marker.
-For example, if a Kafka cluster is failing, you can isolate the logs by specifying the kind as `Kafka`, and use the namespace and name of the failing cluster.
-
-This example shows a marker filter for a Kafka cluster named `my-kafka-cluster`.
+Markers specify what to include in the log using kind, namespace, and resource name values. 
+For example, to isolate the logs of a failing Kafka cluster, set the kind to `Kafka` and use the namespace and name of the cluster.
 
 .Basic logging filter configuration
 [source,yaml,subs="+attributes"]
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: Not sure if we need to change this, but the format here is not YAML but properties.
created_at: 2025-03-24T19:46:40Z
author_association: MEMBER
diff_hunk: @@ -6,53 +6,44 @@
 = Creating a ConfigMap for logging
 
 [role="_abstract"]
-To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the `spec` of a resource.
+To use a `ConfigMap` to define logging properties, you create and then reference it as part of the logging definition in the `spec` of a resource.
+Place the configuration under `log4j2.properties` 
 
-The ConfigMap must contain the appropriate logging configuration.
-
-* `log4j.properties` for Kafka components and the Kafka Bridge
-* `log4j2.properties` for the Topic Operator and User Operator
-
-The configuration must be placed under these properties.
-
-In this procedure a ConfigMap defines a root logger for a Kafka resource.
+In this procedure a `ConfigMap` defines a root logger for a `Kafka` resource.
 
 .Procedure
 
-. Create the ConfigMap.
-+
-You can create the ConfigMap as a YAML file or from a properties file.
-+
-ConfigMap example with a root logger definition for Kafka:
+. Create the `ConfigMap` as a YAML file or from a properties file.
 +
+.Example ConfigMap for logging
 [source,yaml,subs="+attributes"]
 ----
 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: logging-configmap
 data:
-  log4j.properties:
-    kafka.root.logger.level="INFO"
+  log4j2.properties:
+    rootLogger.level="INFO"
 ----
 +
-If you are using a properties file, specify the file at the command line:
-+
-[source,shell]
-----
-kubectl create configmap logging-configmap --from-file=log4j.properties
-----
-+
-The properties file defines the logging configuration:
+If you are using a properties file, define the logging configuration and specify the file at the command line when creating the `ConfigMap`.
 +
+.Properties file definition
 [source,text]
 ----
 # Define the logger
-kafka.root.logger.level="INFO"
+rootLogger.level="INFO"
path: documentation/modules/configuring/proc-creating-configmap.adoc
user: login: scholzj
body: This would need to have at least some minimal Log4j2 properties file and not just the log level:

```suggestion
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n

rootLogger.level = INFO
rootLogger.appenderRefs = console
rootLogger.appenderRef.console.ref = STDOUT
rootLogger.additivity = false
```
created_at: 2025-03-24T19:59:15Z
author_association: MEMBER
diff_hunk: @@ -68,7 +72,15 @@ metadata:
   name: strimzi-cluster-operator
 data:
   log4j2.properties:
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: Without the `|` sign, the new lines might be removed and the configuration will be broken.

```suggestion
  log4j2.properties: |
```
created_at: 2025-03-24T20:00:11Z
author_association: MEMBER
diff_hunk: @@ -112,37 +114,50 @@ metadata:
   name: logging-configmap
 data:
   log4j2.properties:
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: ```suggestion
  log4j2.properties: |
```
created_at: 2025-03-24T20:00:20Z
author_association: MEMBER
diff_hunk: @@ -6,59 +6,63 @@
 = Adding logging filters to Strimzi operators
 
 [role="_abstract"]
-If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi operators,
-you can also define logging filters to limit what's returned in the log.
+Use a `ConfigMap` to configure logging levels in Strimzi operators with Log4j2 and define filters to control log output.
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: In general, I think we should avoid talking about `configure logging levels` with Config Maps. As I raised in many of the previous comments ... the Config Map needs to contain the full Log4j2 properties file (which can configure log levels), but it cannot just configure log levels.
created_at: 2025-03-24T20:08:44Z
author_association: MEMBER
diff_hunk: @@ -39,29 +54,32 @@ logging:
   valueFrom:
     configMapKeyRef:
       name: my-config-map
-      key: my-config-map-key
+      key: log4j2.properties
 # ...
 ----
 
-Values for the `name` and `key` of the ConfigMap are mandatory.
-Default logging is used if the `name` or `key` is not set.
+Default logging is used if logging is not specified in the resource using either method.
+Loggers that haven't been explicitly configured inherit settings from their parent loggers. 
+By default, any available loggers that are not configured have their level set to `OFF`.
path: documentation/assemblies/configuring/assembly-logging-configuration.adoc
user: login: PaulRMellor
body: I think it's safe to remove this.
created_at: 2025-03-25T10:43:36Z
author_association: CONTRIBUTOR
diff_hunk: @@ -6,53 +6,52 @@
 = Creating a ConfigMap for logging
 
 [role="_abstract"]
-To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the `spec` of a resource.
+To use a `ConfigMap` to define logging properties, you create and then reference it as part of the logging definition in the `spec` of a resource.
+Place the configuration under `log4j2.properties` 
 
-The ConfigMap must contain the appropriate logging configuration.
-
-* `log4j.properties` for Kafka components and the Kafka Bridge
-* `log4j2.properties` for the Topic Operator and User Operator
-
-The configuration must be placed under these properties.
-
-In this procedure a ConfigMap defines a root logger for a Kafka resource.
+In this procedure a `ConfigMap` defines a root logger for a `Kafka` resource.
 
 .Procedure
 
-. Create the ConfigMap.
-+
-You can create the ConfigMap as a YAML file or from a properties file.
-+
-ConfigMap example with a root logger definition for Kafka:
+. Create the `ConfigMap` as a YAML file or from a properties file.
 +
+.Example ConfigMap for logging
 [source,yaml,subs="+attributes"]
 ----
 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: logging-configmap
 data:
-  log4j.properties:
-    kafka.root.logger.level="INFO"
+  log4j2.properties: |
+    rootLogger.level="INFO"
+    appender.console.type = Console
+    appender.console.name = STDOUT
+    appender.console.layout.type = PatternLayout
+    appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
+    rootLogger.level = INFO
+    rootLogger.appenderRefs = console
+    rootLogger.appenderRef.console.ref = STDOUT
+    rootLogger.additivity = false
 ----
 +
-If you are using a properties file, specify the file at the command line:
-+
-[source,shell]
-----
-kubectl create configmap logging-configmap --from-file=log4j.properties
-----
-+
-The properties file defines the logging configuration:
+If you are using a properties file, define the logging configuration and specify the file at the command line when creating the `ConfigMap`.
 +
+.Properties file definition
 [source,text]
 ----
 # Define the logger
-kafka.root.logger.level="INFO"
+rootLogger.level="INFO"
path: documentation/modules/configuring/proc-creating-configmap.adoc
user: login: scholzj
body: We should use here the full properties file as in the previous example:

```suggestion
rootLogger.level = "INFO"
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
rootLogger.level = INFO
rootLogger.appenderRefs = console
rootLogger.appenderRef.console.ref = STDOUT
rootLogger.additivity = false
```
created_at: 2025-03-25T18:35:42Z
author_association: MEMBER
diff_hunk: @@ -6,53 +6,52 @@
 = Creating a ConfigMap for logging
 
 [role="_abstract"]
-To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the `spec` of a resource.
+To use a `ConfigMap` to define logging properties, you create and then reference it as part of the logging definition in the `spec` of a resource.
+Place the configuration under `log4j2.properties` 
 
-The ConfigMap must contain the appropriate logging configuration.
-
-* `log4j.properties` for Kafka components and the Kafka Bridge
-* `log4j2.properties` for the Topic Operator and User Operator
-
-The configuration must be placed under these properties.
-
-In this procedure a ConfigMap defines a root logger for a Kafka resource.
+In this procedure a `ConfigMap` defines a root logger for a `Kafka` resource.
 
 .Procedure
 
-. Create the ConfigMap.
-+
-You can create the ConfigMap as a YAML file or from a properties file.
-+
-ConfigMap example with a root logger definition for Kafka:
+. Create the `ConfigMap` as a YAML file or from a properties file.
 +
+.Example ConfigMap for logging
 [source,yaml,subs="+attributes"]
 ----
 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: logging-configmap
 data:
-  log4j.properties:
-    kafka.root.logger.level="INFO"
+  log4j2.properties: |
+    rootLogger.level="INFO"
path: documentation/modules/configuring/proc-creating-configmap.adoc
user: login: scholzj
body: MAybe for the sake of consistency we should use the same spacing

```suggestion
    rootLogger.level = "INFO"
```
created_at: 2025-03-25T18:36:55Z
author_association: MEMBER
diff_hunk: @@ -6,59 +6,63 @@
 = Adding logging filters to Strimzi operators
 
 [role="_abstract"]
-If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi operators,
-you can also define logging filters to limit what's returned in the log.
+Add logging filters to Strimzi operators by using a `ConfigMap` that contains a complete `log4j2.properties` file with your custom log4j2 configuration.
 
-Logging filters are useful when you have a large number of logging messages.
-Suppose you set the log level for the logger as DEBUG (`rootLogger.level="DEBUG"`).
-Logging filters reduce the number of logs returned for the logger at that level, so you can focus on a specific resource.
-When the filter is set, only log messages matching the filter are logged.
+Filters are useful when too many logging messages are being produced. 
+For instance, if `rootLogger.level="DEBUG"`, filters reduce the number of logs to focus on a specific resource by logging only messages matching the filter.
 
-Filters use _markers_ to specify what to include in the log.
-You specify a kind, namespace and name for the marker.
-For example, if a Kafka cluster is failing, you can isolate the logs by specifying the kind as `Kafka`, and use the namespace and name of the failing cluster.
-
-This example shows a marker filter for a Kafka cluster named `my-kafka-cluster`.
+Markers specify what to include in the log using kind, namespace, and resource name values. 
+For example, to isolate the logs of a failing Kafka cluster, set the kind to `Kafka` and use the namespace and name of the cluster.
 
 .Basic logging filter configuration
-[source,yaml,subs="+attributes"]
+[source,properties]
 ----
 rootLogger.level="INFO"
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: Same as above about the spacing

```suggestion
rootLogger.level = "INFO"
```
created_at: 2025-03-25T18:37:18Z
author_association: MEMBER
diff_hunk: @@ -67,8 +71,16 @@ apiVersion: v1
 metadata:
   name: strimzi-cluster-operator
 data:
-  log4j2.properties:
-    #...
+  log4j2.properties: |
+    rootLogger.level="INFO"
path: documentation/modules/configuring/proc-creating-logging-filters.adoc
user: login: scholzj
body: ```suggestion
    rootLogger.level = "INFO"
```
created_at: 2025-03-25T18:37:31Z
author_association: MEMBER
diff_hunk: @@ -30,44 +54,34 @@ You can replace `_<operation-id>_` in the `logger.__<operation-id>__` logger to
 * `seekToBeginning`
 * `seekToEnd`
 * `seek`
-* `healthy`
-* `ready`
 * `openapi`
 
-Each operation is defined according OpenAPI specification, and has a corresponding API endpoint through which the bridge receives requests from HTTP clients.
-You can change the log level on each endpoint to create fine-grained logging information about the incoming and outgoing HTTP requests.
+Each operation maps to an API endpoint,  defined according to the OpenAPI specification, and supports fine-grained logging via `http.openapi.operation.<operation_id>`.
 
-Each logger has to be configured assigning it a `name` as `http.openapi.operation.__<operation-id>__`.
-For example, configuring the logging level for the `send` operation logger means defining the following:
+For example, to set the logging level for the `send` operation logger:
 
-```
-logger.send.name = http.openapi.operation.send
-logger.send.level = DEBUG
-```
+[source,yaml,subs="+quotes,attributes"]
+----
+apiVersion: {KafkaApiVersion}
+kind: KafkaBridge
+spec:
+  # ...
+  logging:
+    type: inline
+    loggers:
+      logger.send.name: "http.openapi.operation.send"
path: documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc
user: login: ppatierno
body: just a nit but AFAICS we are not using the double quotes around the logger name in other logging configurations through the doc.
created_at: 2025-03-26T01:03:53Z
author_association: MEMBER

PR comments:
user: login: PaulRMellor
created_at: 2025-03-12T17:23:39Z
body: Thanks for the comments @fvaleri 
I've updated the examples as directed.
I've also updated the section on adding logging filters (appenders) based on your feedback.
author_association: CONTRIBUTOR
user: login: PaulRMellor
created_at: 2025-03-24T17:21:30Z
body: Thanks @scholzj 
I've returned to the logger sectiond in the API guide and made the preconfigured logger lists consistent with the change suggested for the bridge.
I've split the examples so the custom loggers are separate.
author_association: CONTRIBUTOR
user: login: PaulRMellor
created_at: 2025-03-25T11:43:36Z
body: Thanks for considering how to make the content clearer @scholzj 
I've separated the inline and external examples, moving the descriptions to introduce each separately
author_association: CONTRIBUTOR