ZooKeeper monitoring with okmeter

ZooKeeper это распределенное иерархическое key-value хранилище. В своей работе его используют такие продукты как Kafka, Hadoop, ClickHouse.

Okmeter поможет вам мониторить ваш ZooKeeper, чтобы вы всегда были уверены в его надежной работе.

В production среде, для обеспечения отказоустойчивости, настоятельно рекомендуется разворачивать ZooKeeper в режиме кластера - "ensemble" в терминах зукипер. От того насколько хорошо себя будет чувствовать кластер, напрямую зависит работоспособность приложений зависящих от него.

Так как ZooKeeper'у для работы требуется достаточное количество живых нод для формирования кворума, очень важно следить за их состоянием. Агент okmeter умеет собирать и показывать информацию о кластере: сколько нод живо, сколько недоступно, и в случае падения ZooKeeper ноды okmeter пришлет об этом алерт. Агент okmeter снимает метрику о том, сколько нод сконфигурировано. В случае если одна из нод содержит информацию только о части серверов кластера это потенциально опасная ситуация, так как может случится split brain. Чтоб такого не произошло, okmeter уведомит о том, что нода нуждается в конфигурировании. Если так случилось, что "живых" нод не хватает для кворума, то кластер ZooKeeper'а переходит в нерабочее состояние, но okmeter незамедлительно уведомит об этом.

zookeeper.leader_elections

Когда у ZooKeeper'a падает leader нода, то происходят “выборы” нового лидера, так называемый leader election. Если это случается слишком часто, то возможно есть какие-то проблемы в инфраструктуре на которой работает ZooKeeper. Okmeter покажет количество leader election'ов за последнее время и в какой момент они происходили на вот таком графике:

zookeeper.current_transaction_number.leader|follower

Для поддержания сохранности данных, ZooKeeper использует репликацию. В мире идеальных сетей, где нет задержек, репликация будет происходить мгновенно, однако в нашем мире, follower ноды узнают об изменениях от leader ноды с запозданием. Okmeter покажет отставание каждой реплики — replication lag. Если он постоянный и небольшой - нет повода для беспокойства, а если же он стал расти, то, возможно, стоит исследовать ситуацию подробнее.

zookeeper.outstanding_requests {source_hostname:"X"}

ZooKeeper рассчитан в основном на read операции, и если в какой-то момент write операций станет больше, чем ZooKeeper может обработать, то он начнет их класть в *outstanding requests* очередь, которая имеет лимит, по умолчанию — 1000. При превышении этого лимита ZooKeeper просто перестанет обрабатывать входящие запросы. Во избежании этого, при заполнении *outstanding requests* очереди на 75% okmeter пришлет алерт.

zookeeper.connection.packets.sent {client_ip:"X"}

В понимании того, какой клиент ZooKeeper'a шлет слишком много запросов поможет график **top 5 sent packet rate by client** Агент okmeter снимает информацию об отправленных пакетов в ZooKeeper в разрезе каждого соединения.

zookeeper.znodes.ephemerals {source_hostname:"X"}

В ZooKeeper'e есть так называемые эфемерные z-ноды: это данные, которые живут пока приложение их создавшее подключено к ZK. Когда приложение отключается по любой причине, все созданные им эфемерные ноды удаляются. По изменению количества эфемерных нод, можно судить о внезапном отключении какого-то приложения от Зукипера.

zookeeper.watchers {source_hostname:"X"}

ZK умеет уведомлять клиентов об изменениях в интересующих их данных. Вот этот график в okmeter позволяет отслеживать подписки клиентов ZooKeeper'a на такие изменения znode, а также их переключения между нодами:

В общем, okmeter поможет вам всегда иметь полноценную картину происходящего с кластером ZooKeeper, а также покажет некоторые аспекты поведения клиентов ZooKeeper'а. Все это okmeter агент соберет автоматически и okmeter будет постоянно проверять ситуацию на кластере и показывать ее вам на дашборде с графиками.