docs(logging): log4j2 support updates

[PaulRMellor]

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
• 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

[PaulRMellor]

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.

[fvaleri]

LGTM. Thanks.

[scholzj]

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.

[PaulRMellor]

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

[scholzj]

These two yes, that would mean you can leave out the .name lines. But not the other ones - they do not exist there.

[ppatierno]

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.

[scholzj]

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).

[ppatierno]

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 :-)

[scholzj]

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
  # ...
----

[scholzj]

Similarly to #11254 (comment), we should clarify which packages / classes do these loggers cover as it is not completely obvious from their names.

[scholzj]

The names should not the loggers. We should also use the predefined loggers here where possible.

Suggested change

	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
	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