# linkedin/kafka-monitor

Xinfra Monitor monitors the availability of Kafka clusters by producing synthetic workloads using end-to-end pipelines to obtain derived vital statistics - E2E latency, service produce/consume availability, offsets commit availability & latency, message loss rate and more.

Repository: https://github.com/linkedin/kafka-monitor
Canonical: https://ross.abutalabs.com/products/kafka-monitor
Homepage: https://engineering.linkedin.com/blog/2016/05/open-sourcing-kafka-monitor
Language: Java
License: Apache-2.0
License Family: permissive
Topics: kafka-monitor, kafka-cluster, monitor-topic, partition, broker, partition-count, leader, latency, cluster, metrics, kmf, kafka-broker, xinfra-monitor, monitor-single-clusters, reassigns-partition, jmx-metrics, clusters, xinfra, monitor, topic
Last push: 2025-03-09T04:22:39+00:00

## Health v2 (maintenance only)
Score: 27/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 10, release rhythm 8, longevity 100
- inputs: {"age_days": 3808, "days_push": 542, "days_rel": null, "gap_med": null, "n_releases_24m": 0}
- flags: none
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 2064, forks 446 (observed 2026-08-28T04:06:09.951115+00:00)

## What it is
Xinfra Monitor (formerly Kafka Monitor) is a Java framework for running long-running Kafka system tests and monitoring Kafka cluster health via synthetic end-to-end produce/consume pipelines. It emits vital metrics such as E2E latency, produce/consume availability, offset commit latency, and message loss rate via JMX without requiring application changes.

## Use cases
- monitor kafka cluster availability end to end
- measure kafka end-to-end produce-consume latency
- detect kafka message loss rate
- run long-running kafka system tests in a real cluster
- verify every broker handles monitor topic partitions
- export kafka health metrics to jmx or prometheus

## When to choose
- you operate kafka clusters and need continuous synthetic health checks
- you want to catch rare kafka regressions that only appear over long runs
- you need broker-level latency and availability metrics without touching your apps

## When to avoid
- you only need simple broker CPU/memory metrics rather than end-to-end pipeline checks
- you do not use Apache Kafka
- you need a hosted SaaS monitoring solution with dashboards out of the box

## Facets
- artifact type: framework
- maturity: active
- function: monitoring, testing, benchmarking, alerting
- domain: monitoring, microservices
- platform: jvm, self-hosted
- tags: kafka, synthetic-monitoring, end-to-end-latency, cluster-health, jmx-metrics, system-tests, devops, messaging

## Member repositories
- linkedin/kafka-monitor (main) score 27

## Provenance
- Observed fields: from GitHub, fetched 2026-08-28T04:06:09.951115+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-30T02:57:08.840739+00:00, confidence not recorded.
  - readme: https://github.com/linkedin/kafka-monitor (fetched 2026-08-28T04:06:09.951115+00:00, sha c46aa99850fa)
- Data as of 2026-08-30T08:39:29.467469+00:00.