major
minor
major
minor
Challenge
The DiFa systems within a network architecture make extensive use of Kafka interfaces, whether via TL-Sync or custom-implemented protocols (e.g., JSON).
With HTTP servers, it is common practice to log all communication on the server side, such as request logs that record the metadata of all requests. These logs make it possible to trace communication across systems and various network components. In the event of an error, it is also possible to see at which point communication breaks down or which components are refusing to process the request further.
Communication via Kafka, on the other hand, cannot be traced in the current situation for several reasons:
- Producers do not adequately log the sending of messages
- Consumers do not log the receipt of messages
- Recipients do not adequately log the processing of messages
- Log files are flooded with message content
- Log information is retained for only about 20 minutes; after that, log entries are overwritten due to the sheer volume; file sizes and rolling file numbers are insufficient
- Message contents are encrypted and therefore cannot be located or inspected using Daimler tools such as Lenses.
Solution Approach
Our Kafka implementation generates a communication log. The sending and receiving of every single message is logged before further business-logic processing and regardless of the processing result (exception save/finally). The logs contain the necessary metadata to trace a message’s path from the producer to the consumer.
The log format is standardized and largely symmetrical between the send log and the receive log to facilitate analysis.
The log has two log levels:
- INFO: Metadata for a message per line
- DEBUG: Metadata + message content, possibly multiple lines
There is a send log for all producers and a receive log for all consumers (it is unclear whether this is sufficient, or whether each producer and consumer generates its own log (its own file)).
The metadata must include (obda):
- Timestamp of the send/receive
- Topic
- Message ID
- Chunk information (if available)
- Offset (if possible)
- Application server (IP, hostname, cluster node ID, etc.)
- Kafka server (IP, hostname, etc.)
- Name/ID/Class of the producer or consumer
- TBD...
The log settings are configured sufficiently to track communication at the INFO level for at least 1 week.
This solution is not limited to EPP but applies equally to all ASCon systems in the DiFa landscape.
Implementation
I would just ask that we review the implementation together before final completion, particularly regarding the log information.
Code Migration
- Kafka senders and receivers have a new mandatory configuration option: CommonClientConfig.getLogWriter()
- The tl:KafkaLogWriter is used to log the metadata and content from Kafka messages in a usable format.
- The tl:TLSyncRecordLogWriter and the tl:KafkaStringLogWriter can be used as templates for your own implementations.
- To find all instances where a tl:KafkaLogWriter must be specified, search for KafkaProducerService and KafkaConsumerService in all .config.xml files.
- As an example configuration, you can use the file com.top_logic.kafka/src/main/webapp/WEB-INF/conf/kafkaConf.config.xml, which contains both the tl:KafkaProducerService and the tl:KafkaConsumerService.
- The constructor of the tl:ProducerProxy class now requires a tl:KafkaLogWriter as an argument.
- The classes `tl:CommonClientConfig` and `tl:KafkaCommonClient` now have an additional type parameter specifying the type of the value being sent or received.
Test
Start the Kafka demo once with log level DEBUG and once with INFO. Create at least one object in each case. Then check whether the expected amount of data for the Kafka messages is present in the log.
- INFO: Only the metadata.
- DEBUG: The entire content as well.
The data must be logged by both the sender and the receiver.