Kafka performance relies on implementing continuous intelligence and real-time analytics. It is important to be able to ingest, check the data, and make timely business decisions.

Learn why Enterprise clients use Pepperdata products and Services: [ Ссылка ]

#kafkaperformancemonitoring #kafkacapacityplanning #pepperdata

Stream processing systems provide a unified, high-performance architecture. This architecture processes real-time data feeds and guarantees system health. But, performance and reliability are challenging. IT managers, system architects, and data engineers must address challenges with Kafka capacity planning to ensure the successful deployment, adoption, and performance of a real-time streaming platform. When something breaks, it can be difficult to restore service, or even know where to begin.

This webinar discusses best practices to overcome critical performance challenges for Kafka data streaming that can negatively impact the usability, operation, and maintenance of the platform, as well as the data and devices connected to it. Topics include Kafka data streaming architecture, key monitoring metrics, offline partitioning, broker, topics, consumer groups, and topic lag.

So, the topic today is Kafka performance monitoring, tactical performance, and improving Kafka performance. Our agenda is going to be as follows; I'll start off with a quick architectural overview of what Kafka is. This is by no means a deep dive into that architecture. I assume, you know, the folks on this call pretty much know what that is.

But, we'll also provide you with, you know, a bit of cover, a bit of an overview here as well as how to get more information if you would like. And then, talking about the big ideas when it comes to Kafka's performance. With any distributed system there are things you need to think about, and a way of thinking about performance and monitoring that I'd like to start off with so that we have some context for the rest of the steps that we'll go through.

And then, monitoring performance and then tuning the performance. So, in most cases what we're after is a performance system that we know is performing, and that when we need to improve the performance, or when things start to degrade in terms of performance, we can get them back to where we'd like them to be. So, we'll cover monitoring so that, you know, where you are as well as tuning so that you can get to where you want to be. So, for the architectural overview, Kafka is at its core a messaging system.

Messages need to move from point A to point B. Along the way, they start with producers. Producers will write a message and that message will go to a Kafka broker to then be read by consumers, so you have writers and readers essentially on either end of this messaging system. And then, Kafka has built-in data replication.

It is designed for very high throughput, very low latency, and is very scalable. And as we'll see along the way, you don't get all of these without, you know, some cost associated with which one you'd like to get the most of, so to speak.

So, with anything in a distributed system design, there are trade-offs that you have to take into account when you're architecting, managing, and tuning these systems. So, we'll make sure that we cover all of those things so that you understand what you're getting, based on the decisions you make along the way as you're managing these platforms.

So, when we take a look at the architecture, you know, sort of a top-down look at it. You've got producers that are producing messages. There are multiple producers in most cases for these deployments as soon as you get the Kafka environment up and running and you understand the capabilities of it. And when you need a messaging system, it's rarely ever for a single message to go from point A to point B.

It's normally for a lot of messages to go from point A to point B. So, when we're looking at a Kafka environment, it's multiple producers, many many brokers, brokers host topics, which are the way that producers and consumers understand which messages they are reading and writing. And the path that those messages will take, and then partitions are the lowest level unit that we're really looking at when we're talking about the Kafka infrastructure....

Learn why Enterprise clients use Pepperdata products and Services - [ Ссылка ]

Check out our blog: [ Ссылка ]
/////////////////////////////////////////////////////////////////////////////////////////
Connect with us:
Visit Pepperdata Website: [ Ссылка ]
Follow Pepperdata on LinkedIn: [ Ссылка ]
Follow Pepperdata on Twitter: [ Ссылка ]
Like Pepperdata on Facebook: [ Ссылка ]

свернуть