ZooKeeper monitoring with Odarix
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 будет постоянно проверять ситуацию на кластере и показывать ее вам на дашборде с графиками.