Deux packs d'un coup. Le mode libre achève son échelle de topologies avec les clusters étirés 3-DC et 2,5-DC à témoin, et 19 nouveaux scénarios couvrent le cycle de vie du log — rétention, compaction, stockage hiérarchisé — plus le plan de contrôle KRaft et les opérations sur un cluster vivant.
Exactly-once, read_committed et le last stable offset, begin/commit/abort et la boucle consume–process–produce. Le module transactions rend l'EOS — le sujet le plus difficile de Kafka — parcourable pas à pas. Le mode libre gagne aussi un nouveau type de cluster : actif/actif.
Monedula GitOps gère les topics Kafka, les accès, les quotas, les schémas, les utilisateurs et le RBAC Confluent à partir de manifestes versionnés, via une CLI ou un opérateur Kubernetes.
Le module de réplication arrive : mécanique de l'ISR, high watermark, acks=all et min.insync.replicas, élection du leader et ce qu'une élection unclean fait réellement perdre. Douze scénarios sur les garanties qui ont fait la réputation de Kafka.
Groupes de consommateurs, stratégies d'affectation, appartenance statique et les deux timeouts qui décident du moment où un membre a disparu. Dix nouveaux scénarios qui font du rééquilibrage — le moment le plus mal compris de Kafka — quelque chose que l'on peut observer plutôt que deviner.
Kafka Simulator v1.1 ajoute dix scénarios couvrant le batching du producer, le partitionnement, la compression, la contre-pression, les réessais et l'idempotence.
KIP-714 permet aux clients Kafka d'envoyer leurs propres métriques aux brokers via OTLP. monedula-metrics-reporter transmet désormais ces métriques lui aussi, aux côtés des métriques du SPI broker et de Yammer.
Les leçons les plus importantes de Kafka se nichent dans les transitions : avant et après la panne d'un broker, avant et après le rétrécissement de l'ISR. Nous avons construit un simulateur dans le navigateur pour que vous puissiez casser un cluster sans danger et observer exactement pourquoi il réagit comme il le fait.
Faire passer un parc Kafka existant des ACL au RBAC Confluent est un exercice de gestion des risques, pas une simple conversion de syntaxe. Voici un workflow de migration sûr, auditable et reproductible — ainsi que l'outil que nous avons construit pour cela.
Pourquoi les métriques Kafka sont pénibles, pourquoi les dashboards JMX n'affichent souvent aucune donnée, et comment exporter nativement les métriques Kafka via OTLP.