Log Aggregation Capabilities and Performance: Part I

today, it’s no question that we generate more logs than we ever have before. however, due to the large amount data that is constantly analyzing and resolving various issues, the process is becoming less and less straightforward.

essentially, log management helps to integrate all logs for analysis. an important preliminary phase is log aggregation, which is the act of collecting events logs from different systems and data sources. it includes the flow and tools necessary to gather all data into one single secure data repository. the log repository is then analyzed to generate and present the metrics and insights needed for the operations team.

today, the most popular tools for log aggregation are kafka and redis. both tools provide the functionality of data streaming and aggregation in their own respective ways. in this post, we are going to compare the two in regards to their various capabilities and performance tests.

capabilities

about kafka

kafka is a distributed, partitioned and replicated commit log service that provides a messaging functionality as well as a unique design. we can use this functionality for the log aggregation process.

the basic messaging terms that kafka uses are:

• topic: these are the categories in which messages are published.
• producer: this is the process of publishing messages into kafka’s topics.
• consumer: this process subscribes to topics and processes the messages. consumers are part of a consumer group which is composed of many consumer instances for scalability and fault tolerance.
• broker: each server in a kafka cluster is called a broker.

the logs fetched from different sources can be fed into the various kafka topics through several producer processes, which then get consumed by the consumer.

kafka provides various ways to push data into the topics:

in kafka, each topic has log data partitions that are managed by the server:

(source: kafka documentation )

kafka distributes the partitioned logs among several servers in a distributed system. each partition is replicated across a number of servers for fault tolerance. due to this partitioned system, kafka provides parallelism in processing. more than one consumer from a consumer group can retrieve data simultaneously, in the same order that messages are stored.

in addition, kafka allows the use of as many servers as needed. it uses a disk for its storage therefore might slow to load. however, due to the disk storage capacity, it can store a large amount of data (i.e., in terabytes) for a longer retention period.

about redis

redis is a bit different from kafka in terms of its storage and various functionalities. at its core, redis is an in-memory data store that can be used as a high-performance database, a cache, and a message broker. it is perfect for real-time data processing.

the various data structures supported by redis are strings, hashes, lists, sets, and sorted sets. redis also has various clients written in several languages which can be used to write custom programs for the insertion and retrieval of data. this is an advantage over kafka since kafka only has a java client. the main similarity between the two is that they both provide a messaging service. but for the purpose of log aggregation, we can use redis’ various data structures to do it more efficiently.

in a previous post , we described in detail how redis can support a production elk (elasticsearch, logstash, kibana) stack . in this example, we explained how redis can serve as an entry point for all logs. it’s used as a messaging service and buffers all data.  only when the logstash and the elasticsearch have the resources required does redis release the aggregated log data, ensuring no data leaks due to lack of resources.

stay tuned for part ii coming soon to a dzone near you!