Kafka est une plateforme de diffusion en continu qui agit comme une file d'attente de messagerie avec publication et abonnement en recevant des données de divers systèmes sources et en les rendant disponibles à divers systèmes et applications en temps réel. Les principaux avantages de l'utilisation de Kafka sont qu'il offre un stockage pérenne, ce qui signifie que les données qui y sont stockées ne peuvent pas être facilement altérées, et qu'il est très évolutif, de sorte qu'il peut gérer une forte augmentation des utilisateurs, de la charge de travail et des transactions lorsque cela est nécessaire.
Comme Kafka peut traiter de gros volumes de données, de nombreuses organisations qui s'occupent de données et d'événements importants, telles que Netflix et Microsoft, utilisent Kafka. Pour garantir des performances optimales du serveur middleware Kafka et un fonctionnement sans faille des diverses applications critiques qui en dépendent, il est essentiel d'utiliser une solution de surveillance.
ManageEngine Applications Manager assure une surveillance proactive de Kafka et vous aide à identifier et à résoudre rapidement les problèmes, avant qu'ils n'aient un impact sur vos applications. Kafka rapporte des mesures cruciales qui sont directement liées aux performances de votre serveur Kafka. Laissez-nous vous présenter les principales mesures de performance Kafka que vous devez surveiller pour gérer efficacement vos serveurs Kafka.
Utilisation de la mémoire
Kafka, contrairement aux autres technologies de middleware, fonctionne entièrement sur la mémoire vive. Comme le bloc d'outils d'analyse des utilisateurs nécessite une grande quantité de mémoire dans la RAM, la mémoire du bloc est allouée de manière dynamique en fonction du nombre de requêtes entrantes sur le serveur. Dans un cas Kafka, il est crucial de toujours s'assurer que la taille du bloc de la machine virtuelle Java (JVM) n'est pas supérieure à la mémoire vive disponible afin d'éviter les échanges.
L'outil de surveillance Kafka du gestionnaire d'applications vous permet de surveiller les paramètres de la mémoire tels que la mémoire physique, l'utilisation de la mémoire virtuelle et l'utilisation de l'espace d'échange. Le suivi de l'utilisation de l'espace de pagination permet d'éviter les temps d'attente et de prévenir les interruptions d'exploitation.
La MJC de Kafka comporte deux segments : la heap-memory et la non-heap memory. Alors que laheap-memory stocke les objets de données réels, la non heap-memory garde la trace des métadonnées et des objets chargés. Le moniteur Kafka du gestionnaire d'applications garde une trace de l'utilisation de votre pile pour vous aider à détecter facilement les fuites de mémoire.
Détails des threads
Toutes les demandes dans un serveur sont traitées par des processus qui sont décomposés en plusieurs threads qui s'exécutent simultanément pour aider à traiter les demandes entrantes plus rapidement. Cela permet de réduire le temps de réponse et d'améliorer la réactivité du serveur.
Les fonctionnalités de surveillance du serveur Kafka du gestionnaire d'applications vous permettent de suivre les threads de la JVM dans votre instance Kafka et de fournir des détails sur les différents threads:
-
Daemon Threads: Ce sont des threads qui n'empêchent pas la JVM de sortir lorsque le programme se termine alors qu'ils fonctionnent encore en arrière-plan.
-
Live Threads: Voici les threads qui sont actuellement actifs.
-
Peak Threads: C'est le nombre maximum de threads exécutés dans la JVM.
La surveillance des fils de discussion dans la JVM peut s'avérer utile à bien des égards. En cas de pic soudain dans l'utilisation du CPU, vous pouvez analyser les détails des threads pour identifier le thread qui en est la cause. La surveillance du nombre de fils de discussion actifs vous aide principalement à déterminer si l'utilisation actuelle d'un pool est proche de son maximum. Vous pouvez identifier les fils de discussion inactifs et les supprimer, ce qui permet d'éviter que les demandes soient rejetées.
Taux de nettoyage du journal de bord
Les enregistrements de Kafka sont publiés dans un flux d'enregistrements appelés topics. Chaque topic a un journal partitionné désigné qui demande des détails en annexe chaque fois que des données doivent être stockées. Chaque partition est un journal de commit structuré qui comporte une séquence d'enregistrements étiquetés et dotés d'un identifiant séquentiel à des fins d'identification.
Ces enregistrements sont écrits sur le disque après une période déterminée, après quoi ils sont effacés des partitions. Le taux de vidange, c'est-à-dire le temps qu'il faut pour vider le journal sur le disque, est une mesure importante à surveiller et constitue un indicateur direct des performances de votre instance Kafka.
Le gestionnaire des applications surveille le taux de vidange du journal et vous informe si la valeur franchit un seuil déterminé. Une valeur élevée du taux de vidange du journal peut entraîner le maintien des demandes dans la file d'attente, ce qui se traduit par une latence et une dégradation des performances de votre serveur middleware Kafka. Cela indique que vous devrez peut-être vérifier si votre matériel ne présente pas de goulots d'étranglement ou adapter votre serveur en conséquence.
Broker topic metrics
Un serveur efficace traite toujours les demandes rapidement, sans aucune latence. La surveillance des paramètres des broker peut donner une visibilité sur les performances globales de votre serveur Kafka.
Le gestionnaire des applications surveille diverses mesures de supervision Kafka, y compris les mesures des broker topics, pour vous aider à comprendre le débit et les fluctuations des messages. La surveillance des octets in/min aide à identifier les gros messages, tandis que les messages in/min servent d'indicateur de la charge sur le serveur. La surveillance des échecs des requêtes de récupération (Fetch Requests/Min) et des échecs des requêtes de production (Produce Requests/Min) peut aider à détecter la dégradation des performances de votre serveur.
Réplication
La réplication dans Kafka implique la création de copies des données afin de garantir leur disponibilité en cas d'indisponibilité d'un broker. Cela peut entraîner une dégradation des performances car le broker ne sera pas en mesure de traiter les demandes si celui-ci n'est pas disponible, ce qui augmente le nombre de Partitions répliquées.
Un des grands défis de la réplication à Kafka consiste à maintenir le nombre de réplications synchronisées en accord avec le nombre total de réplications. Les répliques qui ne sont pas synchronisées sont les partitions qui se trouvent derrière le leader, et sont retirées du pool de répliques synchronisées (ISR), augmentant ainsi la valeur des IsrShrinks/Min.
Le gestionnaire d'applications garde un œil sur les mesures de surveillance critiques d'Apache Kafka telles que IsrShrinks/Min et IsrExapsnds/Min, Under Replicated Partitions, et vous informe également des dépassements de seuil afin de garantir des performances optimales de votre serveur middleware Kafka.
Détails du réseau
Kafka gère un grand nombre d'événements. Il est impératif de surveiller le nombre de requêtes par seconde pour avoir une visibilité sur le débit du réseau et la charge du serveur.
Le gestionnaire des demandes surveille le taux de traitement des demandes et vous informe des pics. Cela peut vous aider à analyser la largeur de bande du broker qui a été affectée afin que vous puissiez augmenter le nombre de brokers utilisés si nécessaire. Il vous aide également à détecter les temps de latence du serveur.
Informations sur le contrôleur
Dans un cluster Kafka, l'un des brokers agit en tant que contrôleur et est responsable du maintien de l'état des partitions et des répliques. Lorsqu'une partition principale expire, l'élection d'une nouvelle autorité est déclenchée. Toute réplique synchronisée disponible pour la partition est éligible pour devenir la nouvelle autorité. L'élection du référent entraîne un léger retard dans la réponse aux demandes de partition. Gardez un œil sur la mesure du taux d'élection des autorités.
Les élections de mauvais référents sont causées par l'incapacité de trouver une autorité qualifiée pour la partition parmi les brokers de Kafka. Lorsqu'un broker qui est le référent pour une partition se met hors ligne, un nouveau référent est élu parmi l'ensemble des ISR pour la partition. L'élection d'un référent non conforme est un cas particulier dans lequel aucune réplique disponible n'est synchronisée. Le gestionnaire d'applications vous permet de suivre le nombre d'élections de référents non conformes par seconde et de comprendre s'il y a eu une perte de données.
Le décompte des partitions hors ligne vous aide à suivre le nombre de partitions qui ne sont pas inscriptibles ou lisibles car elles n'ont pas de référent actif. Vous pouvez configurer les paramètres de manière à être alerté si cette valeur dépasse 0, car une partition sans référent actif sera absolument injoignable. Cela signifie que les utilisateurs et les propriétaires de cette partition seront bloqués, ce qui entraînera des retards inutiles dans le traitement des demandes sur le serveur, jusqu'à ce qu'un référent soit disponible.
Surveiller les mesures du ZooKeeper en même temps que Kafka
ZooKeeper stocke des métadonnées sur les brokers de Kafka, les rubriques, les partitions et la coordination du système. Une panne ou une lenteur de ZooKeeper peut affecter les clusters de Kafka. Vous devez également surveiller les paramètres de ZooKeeper pour maintenir un cluster Kafka sain.
Si vous commencez tout juste à utiliser la surveillance Kafka, voici quelques mesures qui montrent comment la surveillance de votre instance Kafka peut vous aider à obtenir de meilleures performances de l'application. Pour savoir comment Applications Manager peut améliorer encore plus vos capacités de surveillance Kafka, téléchargez immédiatement une version d'essai gratuite de 30 jours !
Priya Praburam, Content Writer