Как я связываю under-replicated и offline partitions Kafka с ISR и доступностью брокеров

Сначала разделяю доступность, устойчивость и задержку чтения

Я начинаю не с графика consumer lag, а с трёх разных вопросов. Есть ли у каждой важной партиции активный лидер, сохраняется ли предусмотренный набор синхронных реплик и успевает ли прикладной consumer читать записи? Первое относится к доступности партиции, второе — к запасу устойчивости репликации, третье — к темпу обработки конкретной группы. Эти состояния могут расходиться: consumer отстаёт при полностью здоровом ISR, а после потери follower чтение может продолжаться без заметного lag. Я — Семёнов Евгений Сергеевич. Я основал IT Fresh, остаюсь его ведущим системным администратором и выполняю обязанности технического директора. В инженерной практике IT Fresh я сначала фиксирую перечень критичных topics, их replication factor, min.insync.replicas и владельцев, затем строю наблюдение по лидерам и репликам. Lag выбранных consumer groups оставляю рядом только как вторичный контекст. Он помогает понять прикладное влияние, но не подменяет метрики ReplicaManager. Так дежурный не принимает медленный обработчик за повреждение репликации и не пропускает ослабление ISR только потому, что потребители пока успевают. Для каждого сигнала я также сохраняю время получения: устаревшее значение не подтверждает текущее здоровье. В карточке наблюдения я явно подписываю уровень агрегации: кластер, broker, topic или partition. Иначе сумма по узлам легко выглядит как число уникальных партиций, хотя одна проблема видна с нескольких процессов. Точное происхождение значения делает дальнейшую проверку воспроизводимой.

Диагностический порядок для URP, offline и движения ISR

Верхний приоритет я отдаю OfflinePartitionsCount: offline partition не имеет активного лидера, поэтому клиентская операция для неё недоступна. Затем проверяю UnderReplicatedPartitions. URP означает, что размер ISR меньше числа назначенных реплик; это потеря предусмотренного запаса, но не обязательная недоступность, пока лидер работает. Отдельно читаю UnderMinIsrPartitionCount и никогда не называю его другим именем. Объяснение через ISR ниже min.insync.replicas и ошибки producer с acks=all относится к классической модели без Eligible Leader Replicas. Для кластера с ELR до трактовки ISR и min.insync.replicas я фиксирую факт и режим ELR и сверяюсь с документацией установленного выпуска; единого порога или исхода записи не предполагаю. В классической модели при ISR ниже min.insync.replicas producer с acks=all способен получить NotEnoughReplicas или NotEnoughReplicasAfterAppend. При этом acks=all ждёт подтверждений от текущего ISR, а не буквально от всех реплик replication factor. IsrShrinksPerSec и IsrExpandsPerSec показывают движение состава: shrink отмечает выход реплики, expand — возвращение догнавшей реплики. Я смотрю их парой и на одном временном участке с URP. Краткое симметричное движение после согласованной работы отличается от устойчивого URP или повторяющегося churn. Порядок остаётся таким: наличие лидера, глубина ослабления ISR, отношение к min ISR, затем динамика shrink/expand и сопутствующие факты. При разборе я сохраняю не только итоговый счётчик, но и список затронутых partitions из разрешённого описания metadata. Это позволяет увидеть общий broker или каталог хранения и отличить широкое событие от одной медленно восстанавливающейся реплики.

Связываю follower, лидера и broker без вывода по одному числу

Если follower перестал получать данные или заметно отстал, Kafka может вывести его из ISR, сохранив лидера и клиентскую доступность. Если недоступен broker, последствия зависят от размещённых на нём лидеров, наличия подходящих реплик и состояния metadata plane. Поэтому одно значение JMX не даёт готового диагноза. Я сопоставляю broker ID и его роль с лидерами затронутых партиций, составом ISR, replication fetcher lag, OfflineLogDirectoryCount, задержками диска, сетевыми ошибками и журналами Kafka. Рост ISR shrinks служит точкой начала расследования, но не ярлыком причины. Например, одинаковый churn возможен при нестабильной связи, перегруженном хранилище или восстановлении узла. Отдельно проверяю, что метрика пришла с ожидаемого процесса: broker, controller и совмещённый узел публикуют разные наборы. Доступность JMX endpoint и Zabbix Java gateway подтверждает только канал наблюдения. Она не доказывает, что Kafka listener доступен клиенту, что metadata запрос завершается и что produce либо fetch успешны. Обрыв JMX я обозначаю как отсутствие данных, а не записываю ноль и не закрываю прежнюю проблему. Временная линия особенно важна: сначала мог вырасти disk latency, позже follower вышел из ISR, а уже затем изменилось лидерство. Совпадение без порядка событий слабее такой последовательности, поэтому часы Zabbix, hosts и Kafka должны быть синхронизированы и подписаны одним часовым поясом.

Режим метаданных определяет проверку controller

До настройки порогов я выясняю версию Kafka, архитектуру кластера и process.roles каждого процесса. В кластере с ZooKeeper исторически применялось правило: ActiveControllerCount равен единице на активном controller-broker и нулю на остальных, а агрегат по кластеру интерпретируется с учётом полного и свежего набора узлов. Переносить это правило без проверки в KRaft нельзя. Там контроллеры образуют metadata quorum, могут работать отдельно от brokers или в совмещённой роли, а здоровье определяется наличием quorum leader, состоянием участников и актуальностью metadata. Я сверяю process.roles, quorum leader и состояние через подходящие выпуску средства, а также ActiveBrokerCount и FencedBrokerCount там, где эти показатели доступны для установленной версии. Потеря одной JMX-точки при этом не равна потере quorum. И наоборот, доступный JMX одного процесса не подтверждает согласованность metadata plane. В Zabbix роль и режим входят в host macros или inventory, чтобы выражение не применяло ZooKeeper-ожидание к KRaft controller. Любое имя MBean сначала проверяю на фактическом выпуске и роли. При обновлении Kafka этот preflight повторяется до включения новых items. Удалённый или переименованный MBean должен стать явной несовместимостью шаблона, а не молчаливым благополучием. Так миграция режима метаданных не оставляет старое выражение действующим по инерции.

Собираю JMX в Zabbix с явной границей доверия

Сбор я проектирую от ролей. На brokers нужны ReplicaManager, ReplicaFetcherManager, LogManager и сетевые ошибки; на контролирующих процессах — доступные этому режиму controller или quorum показатели. Перед привязкой шаблона выполняю preflight: версия Kafka и Java, ZooKeeper либо KRaft, process.roles, список ожидаемых broker ID, JMX object names и совместимость Zabbix server с Java gateway. JMX endpoint не публикую в недоверенную сеть. Включаю TLS и аутентификацию согласно принятой схеме, ограничиваю сетевой доступ адресами мониторинга и выдаю учётной записи только чтение необходимых MBeans. Логин и пароль размещаю в защищённых Zabbix macros; они не попадают в item key, журнал проверки или название problem. Разрешение на раскрытие macro value оставляю минимальному кругу ролей. Для каждого item фиксирую источник, broker ID, роль и время последней успешной выборки. Ошибки TLS, аутентификации, Java gateway, неизвестный MBean и stale data формируют отдельное состояние качества. До массового discovery проверяю один узел каждой роли и сопоставляю результат с локально видимым выпуском. Частоту опроса выбираю после измерения времени ответа и количества объектов. Короткий период не должен создавать дополнительную нагрузку или очередь в gateway. Параметры пересматриваю при росте кластера, чтобы свежесть оставалась измеряемым свойством, а не предположением.

Problem-сигнал строю как связанную картину

Я не назначаю одно число всем кластерам. Выражение учитывает длительность, число затронутых партиций, критичность topics, запланированные работы и полноту данных. Offline partitions дают самостоятельный высокий приоритет после подтверждения свежести controller или quorum данных. Устойчивый URP связываю с broker availability, ISR shrink, replication lag, offline log directories и журналами; краткое движение без потери лидера отмечаю мягче. UnderMinIsrPartitionCount усиливает сигнал отдельно, особенно если появляются ошибки produce NotEnoughReplicas или NotEnoughReplicasAfterAppend при acks=all. Эскалация сначала идёт владельцу Kafka с перечнем broker ID, topics, partitions, leaders, ISR и временной линией. Владелец приложения подключается при клиентских ошибках или прикладном влиянии. Consumer group lag добавляю в карточку только после этих фактов и не использую как условие здоровья репликации. Зависимости Zabbix подавляют каскад одинаковых событий при подтверждённой недоступности узла, но не скрывают offline partition. Если JMX stale, выражение сообщает о пробеле наблюдения и не делает вывод из последнего числа. Численные окна согласую по архитектуре и допустимой реакции конкретного сервиса. Для закрытия события требую свежую обратную последовательность фактов: лидер существует, ISR восстановлен согласно назначению, ошибки записи прекратились, сбор полноценен. Простое возвращение одного счётчика к нулю недостаточно, если часть hosts ещё не передаёт данные.

Контролируемая проверка остаётся вне production

Проверку выполняю исключительно в изолированном непроизводственном контуре, который не имеет общих topics, credentials и клиентских маршрутов с production. Сначала подтверждаю версии, роли, исходный ISR, свежесть Zabbix, а также факт и режим ELR. ELR нельзя включать или выключать ради проверки. Если ELR уже включён, ожидаемые результаты и безопасную границу сверяю с документацией конкретного выпуска и владельцем платформы. Затем создаётся отдельный test-topic; replication factor 3, min.insync.replicas 2 и producer acks=all здесь служат примером устойчивой конфигурации, а не гарантией. Разрешённым штатным средством контура временно ограничиваю доступность одного тестового broker только по заранее утверждённому плану платформенной команды. Наблюдаю переход тестовой реплики из ISR, URP, отсутствие offline partition при сохранённом лидере и поведение записи. После возврата узла жду, пока follower догонит лидера, ISR expand завершится, а URP исчезнет. Отдельная проверка отказа JMX выполняется блокировкой только тестового канала мониторинга: ожидаю missing data, не ноль. Я не предлагаю воздействовать на production broker или controller, включать unclean leader election, удалять log directories, править metadata либо ZooKeeper вручную, запускать массовый reassignment под нагрузкой или отключать min.insync.replicas. Все шаги имеют владельца, окно и условие немедленного прекращения. До начала фиксирую ожидаемые наблюдения для каждого этапа и критерии остановки. Если исходный ISR неполон, metadata нестабильна или мониторинг уже stale, проверка не начинается. Неожиданное отсутствие лидера означает прекращение воздействия и немедленный возврат контура владельцем.

Возвращаю штатный режим и сохраняю evidence

Возврат считаю завершённым, когда тестовый broker снова доступен по штатным каналам, follower догнал лидера, полный ожидаемый ISR восстановлен, URP и offline partitions отсутствуют, а Zabbix получил новые значения без ошибок Java gateway, TLS и аутентификации. Я сохраняю временную линию, снимки значений до и после, broker ID, роли, состав ISR, команды только чтения, версии и ссылки на журналы без секретов. Тестовые доступы отзываются, временные правила изоляции снимаются владельцем контура, test-topic удаляется только по отдельному согласованному регламенту после сохранения evidence. Итоговую запись проверяет второй инженер: он сверяет timestamps, источник каждой метрики и отсутствие скрытых stale items. Полезно приложить карту размещения реплик, поскольку она объясняет общий отказовый домен без домыслов. Материалы хранятся по принятому сроку и с ограниченным доступом. Ограничение подхода принципиально: JMX и metadata описывают состояние Kafka, но не доказывают клиентскую доступность и корректность приложения; а нормальный ISR не исключает проблем listener, квот или producer. Если вам нужно связать репликацию Kafka, роли и Zabbix в проверяемую картину без рискованных действий, команда IT Fresh поможет разобрать архитектуру и подготовить безопасный контур наблюдения. Связаться можно через https://itfresh.ru/, написать в https://t.me/ITfresh_Boss или позвонить: tel:+79037296241.

Отвергнутые альтернативы

• Считать любой UnderReplicatedPartitions аварией доступностиURP означает, что ISR меньше набора назначенных реплик; лидер может оставаться активным и обслуживать запросы, поэтому доступность проверяется отдельно через offline partitions, metadata и клиентские ошибки.
• Смешать UnderReplicatedPartitions с UnderMinIsrPartitionCountПервый показатель сравнивает ISR со всеми назначенными репликами, второй — с min.insync.replicas; их операционный смысл и влияние на produce с acks=all различаются.
• Объявить ISR shrink готовой первопричинойИзменение состава ISR фиксирует событие, но не объясняет его; причину приходится искать по роли узла, сети, диску, журналам, размещению и текущим работам.
• Применить ActiveControllerCount как единый порог к любому кластеруИсторическое правило относится к архитектуре ZooKeeper, тогда как KRaft использует metadata quorum и требует иных проверок с учётом process.roles и версии.
• Проверять тревогу остановкой производственного brokerТакое воздействие способно лишить партиции лидеров и нарушить запись; проверка допустима только в изолированном непроизводственном контуре с тестовыми данными.

Конфигурация и сбор

Выделенная JMX-учётная запись имеет только чтение согласованных MBeans; endpoint ограничен сетью мониторинга, защищён TLS и аутентификацией. Секреты находятся в защищённых Zabbix macros с минимальным доступом, а Java gateway не получает административных прав Kafka.

• Зафиксировать версию Kafka и Java, режим ZooKeeper или KRaft, process.roles, broker ID, controller topology, фактически доступные MBeans и факт и режим ELR на одном процессе каждой роли; при ELR не переносить классическую трактовку ISR ниже min.insync.replicas и acks=all и не предполагать единый порог или исход записи.
• Проверить TLS trust, имя endpoint, аутентификацию, сетевой allowlist и свежесть ответа через Zabbix Java gateway без вывода секретов.
• Собрать UnderReplicatedPartitions, UnderMinIsrPartitionCount, ISR shrinks/expands, OfflineLogDirectoryCount и broker-local контекст; controller и quorum показатели получать только с подходящих ролей.
• Связать значения с inventory ролей, metadata mode, topics, partitions и broker ID; ошибки сбора и stale data хранить отдельно от числовых метрик.
• Проверить expressions на сохранённых обезличенных значениях и согласовать окна с владельцами, не задавая универсальный порог для разных кластеров.

Контролируемая проверка и свидетельство

Только в изолированном непроизводственном кластере используется отдельный test-topic с примером replication factor 3, min.insync.replicas 2 и producer acks=all. ELR нельзя включать или выключать ради проверки; если ELR уже включён, результаты и безопасная граница сверяются с документацией конкретного выпуска и владельцем платформы. По утверждённому плану владелец контура временно ограничивает доступность одного тестового broker, проверяет shrink ISR, URP, сохранение или потерю лидера и клиентские ошибки, затем восстанавливает узел и дожидается полного ISR. Отдельно прерывается лишь тестовый JMX-канал, чтобы подтвердить missing data. Любое воздействие на production запрещено.

Фрагмент рабочего регламента

• Сначала проверить версию Kafka, process.roles, режим ZooKeeper или KRaft и права учётной записи; синтаксис каждой команды сверить через --help установленного выпуска.
• <KAFKA_BIN>/kafka-topics.sh --bootstrap-server <BOOTSTRAP_HOST:PORT> --describe --topic <TOPIC> — только чтение описания leaders, replicas и ISR при разрешённых ACL.
• <KAFKA_BIN>/kafka-metadata-quorum.sh --bootstrap-server <BOOTSTRAP_HOST:PORT> describe --status — только для совместимого KRaft-выпуска и разрешённых прав, без изменения quorum.
• <KAFKA_BIN>/kafka-consumer-groups.sh --bootstrap-server <BOOTSTRAP_HOST:PORT> --describe --group <GROUP> — вторичный контекст lag, не проверка репликации.
• В Zabbix проверить last clock, error item, Java gateway, TLS и аутентификацию; stale или unsupported item трактовать как отсутствие данных, не как ноль.
• Сопоставить broker ID, leaders, replicas, ISR, URP, UnderMinIsrPartitionCount, ISR churn, offline log directories и журналы; ничего не перезапускать и не менять.

Откат

В непроизводственном контуре владелец возвращает доступность тестового broker и снимает только временное правило изоляции, затем подтверждает его штатную регистрацию, догон follower, полный ISR и отсутствие URP/offline partitions. Настройки Zabbix возвращаются из сохранённого экспорта: endpoint, защищённые macros, item prototypes, preprocessing, role filters, dependencies и expressions. После свежей выборки закрываются лишь тестовые события; удаление test-topic выполняется отдельно по согласованному регламенту.

Ограничения вывода

JMX, Java gateway и metadata-команды дают наблюдаемость, но не доказывают клиентскую доступность listener, успешность produce/fetch или корректность приложения. Набор MBeans зависит от версии, роли и архитектуры. URP не равен offline partition, ISR churn не раскрывает первопричину, а consumer lag относится к обработке. RF=3, min ISR=2 и acks=all — пример, не гарантия; объяснение через текущий ISR и min.insync.replicas относится к классической модели без ELR. Для кластера с Eligible Leader Replicas до трактовки фиксируются факт и режим ELR; универсальный порог или исход записи не заявляется. Универсальные пороги без профиля topics, размещения, нагрузки и времени реакции не задаются.