Руководство по мониторингу Redis

Redis – это распространенное хранилище данных в памяти, обеспечивающее высокую производительность и низкую задержку для приложений. Расширенные структуры данных и программируемость делают его лучшим выбором для кэширования, аналитики в реальном времени и других вариантов использования, требующих быстрой и эффективной обработки данных.

В следующей статье мы делимся подробным руководством по эффективному мониторингу Redis. Мы начнем с ознакомления с Redis и некоторыми его альтернативами, после чего поделимся списком важных показателей производительности и обсудим, как их отслеживать с помощью различных команд и инструментов.

Что такое Redis?

Redis – это хранилище структур данных с открытым исходным кодом в памяти, которое также обеспечивает дополнительную сохраняемость. Поскольку Redis хранит данные в памяти, оно по своей сути быстрее традиционных дисковых баз данных. Кроме того, возможности Redis по репликации и кластеризации позволяют разработчикам создавать распределенные системы, способные обрабатывать высокий трафик и большие объемы данных.

Хранилище называется “структурой данных”, потому что оно изначально поддерживает несколько структур данных, включая строки, наборы, списки, хэши, растровые изображения, геопространственные индексы и отсортированные наборы. Это позволяет разработчикам хранить и обрабатывать широкий спектр типов данных в Redis.

Например, разработчики могут использовать отсортированные наборы для работы с данными, требующими сортировки или ранжирования, такими как таблицы лидеров или ограничители скорости. Они могут использовать тот же экземпляр Redis для хранения координат местоположения, используя тип геопространственных данных.

Как и традиционные системы баз данных, Redis поддерживает транзакции, которые позволяют пользователям выполнять несколько команд за один шаг. Разработчики также могут выполнять сценарии на стороне сервера, используя Lua, или писать хранимые процедуры, используя Redis Functions API.

Redis часто развертывается как распределенный кэш приложений, но также может использоваться как автономная база данных. Другой распространенный вариант использования Redis – как система обмена сообщениями для приложений реального времени. Его реализация публикации/подписки содержит множество полезных функций, таких как подписки на соответствие шаблону и сегментирование. Тип данных Redis stream можно использовать для масштабирования потоковой передачи данных и обмена сообщениями.

Альтернативы Redis – Redis против Memcached, Aerospike, Elasticsearch и MongoDB

При поиске хранилища данных в памяти вы можете обнаружить, что сравниваете Redis с альтернативами, такими как Memcached, Aerospike, Elasticsearch и MongoDB. Каждое хранилище данных обладает своими уникальными функциями, которые делают их хорошо подходящими для различных вариантов использования.

Redis против Memcached

Redis и Memcached – это хранилища ключей-значений, оптимизированные для кэширования. С точки зрения скорости чтения/записи и использования памяти, оба предлагают одинаковую производительность. Однако Redis поставляется с настраиваемой сохраняемостью, в то время как Memcached этого не делает.

Redis также поддерживает более широкий спектр структур данных, что делает его более гибким, чем Memcached, и предлагает больше функций, таких как постоянство, транзакции и атомарность, конвейерная обработка, pub-sub, сценарии Lua и кластеризация.

Redis против Aerospike

Aerospike – это база данных NoSQL в оперативной памяти, оптимизированная для больших объемов данных. Как и Redis, он предлагает богатый набор функций, включая создание сценариев на стороне сервера, гибкое масштабирование, дополнительную сохраняемость и поддержку нескольких облаков. Обе технологии обеспечивают схожие уровни производительности, доступности, атомарности и отказоустойчивости.

Хотя Redis поддерживает более широкий спектр структур данных, чем Aerospike, последний обеспечивает большую гибкость в отношении репликации и контроля доступа. Кроме того, поддержка клиентской библиотеки Aerospike ограничена по сравнению с Redis.

Redis против Elasticsearch

Elasticsearch – это полнотекстовая поисковая система, оптимизированная для быстрых и эффективных поисковых запросов. В то время как Redis, Aerospike и Memcached в основном используются для кэширования, Elasticsearch предназначен для поиска и анализа данных.

Расширенные возможности поиска Elasticsearch и поддержка структурированных и неструктурированных данных делают его идеальным выбором для таких случаев использования, как аналитика, нечеткий поиск и обработка документов. С учетом сказанного, при желании вы также можете использовать Elasticsearch в качестве кэша для вашего основного хранилища. Просто помните, что, поскольку по умолчанию он не оптимизирован для кэширования, вам придется вручную настроить кластер для лучшей индексации и параллелизма.

Redis против MongoDB

Хотя MongoDB в первую очередь является традиционной дисковой базой данных, она также предлагает встроенный в память механизм для более быстрых операций чтения и записи. Этот встроенный в память механизм оптимизирован для запроса больших объемов данных в режиме реального времени.

И MongoDB, и Redis обеспечивают высокоуровневый параллелизм, транзакции и гибкую архитектуру развертывания. Однако, по сравнению с Redis, поддержка структур данных и расширенных функций кэширования в MongoDB ограничена.

Короче говоря, при сравнении Redis, Aerospike, Memcached, Elasticsearch и MongoDB нет однозначного победителя. Тот, который вы в конечном итоге выберете, будет зависеть от ваших индивидуальных бизнес-потребностей и предпочтений разработчика.

Важные показатели производительности Redis для мониторинга

Redis предоставляет несколько показателей, связанных с его состоянием, производительностью, доступностью и репликацией. Администраторы могут использовать эти показатели для мониторинга работоспособности, прогнозирования сбоев, устранения узких мест и определения путей улучшения.

Показатели кластеров и узлов

Мониторинг показателей, относящихся к отдельным узлам и кластеру в целом, важен для обеспечения ожидаемой работы Redis. Вы можете использовать конечную точку GET/v1/nodes/stats Redis REST API для получения следующей статистики узла в режиме реального времени:

• available_memory: общая доступная оперативная память на узле, в байтах. Аномальное повышение значения этого показателя должно быть немедленно расследовано, особенно если вы не храните данные в кэше в течение длительного времени.
• avg_latency: Средняя задержка всех запросов, обрабатываемых этим узлом Redis, в микросекундах. Слишком высокое значение этого показателя может привести к возникновению узких мест в более крупной системе.
• conns: Общее количество клиентов, подключенных к этому узлу. Стремитесь свести значение этого показателя к минимуму; т. Е. Выявляйте и удаляйте все “зомби-соединения”.
• ingress_bytes: скорость в байтах в секунду, с которой узел получает сетевой трафик.
• total_req: частота запросов в операциях в секунду, обработанных этим узлом.
• free_memory: Общая свободная память на узле, в байтах. Экспоненциальное увеличение значения этого показателя обычно указывает на плохое управление памятью.
• available_flash: доступная флэш-память, в байтах.
• cpu_idle: значение с плавающей точкой, представляющее, сколько времени процессор провел в режиме ожидания. Умножение этого значения на 100 дает процент времени простоя процессора.
• cpu_system: значение с плавающей точкой, представляющее, сколько времени процессор провел в пространстве ядра. Умножение этого значения на 100 дает процентное время системного процессора.
• cpu_user: значение с плавающей запятой, представляющее, сколько времени ЦП потратил на обработку пользовательских запросов. Умножение этого значения на 100 дает процентное время работы ЦП пользователя.
• persistent_storage_avail: общее дисковое пространство в байтах, доступное корпоративным процессам Redis.
• persistent_storage_free: общее свободное место на диске, в байтах.
• ephemeral_storage_free: общее свободное дисковое пространство в байтах на настроенном временном диске.
• ephemeral_storage_avail: Общее доступное дисковое пространство на настроенном временном диске, доступное Redis.

Чтобы получить ту же статистику (что и выше) на уровне кластера, все, что вам нужно сделать, это изменить конечную точку, чтобы GET /v1/cluster/stats.

Показатели базы данных и сегментов

Показатели базы данных дают четкое представление о том, насколько хорошо экземпляр Redis обрабатывает данные. Конечная точка GET /v1/bdbs/stats Redis API возвращает в своем ответе следующую ключевую статистику:

• avg_latency: средняя задержка всех операций с базой данных в микросекундах. В работоспособном экземпляре Redis значение этого показателя должно оставаться низким. Если вы испытываете высокую среднюю задержку, используйте функцию Redis Slow Log для выявления любых медленно выполняющихся запросов.
• avg_read_latency: средняя задержка всех операций чтения, выполняемых в базе данных.
• avg_write_latency: средняя задержка всех операций записи, выполняемых в базе данных.
• avg_other_latency: Средняя задержка всех других операций (не чтения и записи), выполняемых с базой данных.
• conns: Общее количество клиентских подключений к конечным точкам, предоставляемым базой данных. Стремитесь свести значение этого показателя к минимуму; т. Е. Выявляйте и удаляйте все резервные подключения.
• egress_bytes: скорость в байтах в секунду, с которой трафик утекает из базы данных.
• ingress_bytes: скорость в байтах в секунду, с которой трафик поступает в базу данных.
• expired_objects: количество ключей с истекшим сроком действия в базе данных в секунду.
• evicted_objects: скорость, с которой ключи удаляются из базы данных в секунду.
• last_res_time: Время, в которое база данных сгенерировала последний ответ.
• last_req_time: время, в которое база данных получила последний запрос.
• no_of_expires: общее количество ключей, которые будут удалены по истечении срока действия.
• no_of_keys: Общее количество ключей в базе данных.
• pubsub_channels: общее количество шаблонов публикации и подписки в базе данных.
• total_req: скорость в операциях в секунду, с которой база данных получает запросы.
• total_res: скорость в операциях в секунду, с которой база данных генерирует ответы.
• write_req: скорость в операциях в секунду, с которой база данных получает запросы на запись.
• write_res: скорость в операциях в секунду, с которой база данных генерирует ответы на запись.
• read_req: скорость в операциях в секунду, с которой база данных получает запросы на чтение.
• read_res: скорость в операциях в секунду, с которой база данных генерирует ответы на чтение.

Чтобы просмотреть показатели, относящиеся к сегментированию, вы можете использовать конечную точку GET/v1/shards/stats. Некоторые из возвращаемых ею показателей следующие:

• aof_rewrite_inprog: общее количество перезаписей файлов только для добавления (AOF), выполняемых одновременно.
• avg_ttl: среднее время действия (TTL) случайного ключа.
• blocked_clients: количество клиентов, ожидающих блокирующий вызов. Слишком большое количество блокирующих вызовов может существенно повлиять на производительность кластера.
• connected_clients: подсчет количества подключенных клиентов к сегменту.
• shard_cpu_system: Процент использования ядра процесса Redis shard в системном режиме.
• shard_cpu_user: Процент использования ядра процесса shard в пользовательском режиме.
• main_thread_cpu_system: Процент использования ядра основного потока сегмента в системном режиме.
• main_thread_cpu_user: Процент использования ядра основного потока shard в пользовательском режиме.
• fork_cpu_system: Процент использования ядра дочернего процесса shard fork в системном режиме.
• fork_cpu_user: Процент использования ядра дочернего процесса shard fork в пользовательском режиме.
• last_save_time: время последнего сохранения файла резервной копии Redis (RDB).
• read_req: общий объем памяти, который использовал этот сегмент, в байтах.
• used_memory_peak: максимальный объем памяти в байтах, который использовал этот сегмент с момента его инициализации.

Показатели памяти

Команда Redis INFO выводит следующий список статистических данных, связанных с памятью, которые могут сыграть ключевую роль в обнаружении проблем и оптимизации пропускной способности.

• mem_allocator: распределитель памяти, выбранный при компиляции ядра Redis.
• used_memory: общий объем памяти в байтах, выделенный ядром Redis. Этот показатель должен показывать равномерный рост с течением времени. Неожиданные колебания обычно указывают на критические проблемы.
• used_memory_startup: объем памяти в байтах, который Redis использовала при запуске.
• used_memory_peak: максимальный объем памяти в байтах, который экземпляр Redis использовал с момента запуска.
• total_system_memory: общий объем памяти в байтах, доступный хосту Redis.
• used_memory_lua: общий объем памяти, который использовал механизм Lua, в байтах.
• mem_clients_slaves: общий объем памяти, используемый клиентами-репликами, в байтах.
• mem_clients_normal: общий объем памяти, используемый обычными клиентами, в байтах.
• mem_aof_buffer: общий объем временной памяти в байтах, который используется AOF.
• mem_replication_backlog: общий объем памяти, используемый резервом репликации, в байтах.

Показатели репликации

Выходные данные команды Redis INFO содержат несколько показателей, связанных с репликацией. Некоторые из наиболее важных показателей::

• role: Если экземпляр не является точной копией какого-либо другого узла, это поле возвращает “master”. В противном случае возвращается ”slave”.
• master_failover_state: Если выполняется какой-либо переход на другой ресурс, этот показатель вернет состояние этого перехода на другой ресурс.
• repl_backlog_size: общий размер буфера невыполненной репликации в байтах.
• total_net_repl_input_bytes: общее количество входящих байт для целей репликации.
• total_net_repl_output_bytes: общее количество исходящих байт для целей репликации.
• instantaneous_input_repl_kbps: скорость, с которой данные считываются из сети для целей репликации, измеряется в КБ/сек.
• instantaneous_output_repl_kbps: скорость, с которой данные записываются в сеть для целей репликации, измеряется в КБ/сек.
• master_replid: идентификатор репликации экземпляра Redis.
• repl_backlog_active: логическое значение (true/false), указывающее, активен ли бэклог репликации.

Если экземпляр является репликой, возвращаются некоторые дополнительные поля, в том числе:

• master_sync_in_progress: Это поле указывает, синхронизируется ли master с этим экземпляром реплики.
• slave_priority: приоритет этого экземпляра, который будет повышен как ведущий в случае аварийного переключения.
• slave_read_only: Логическое значение, указывающее, работает ли slave-устройство в состоянии только для чтения.
• master_last_io_seconds_ago: Количество секунд, прошедших с момента последнего взаимодействия этой реплики с главным узлом.
• master_link_status: состояние соединения с главным узлом.
• slave_repl_offset: Смещение репликации этого узла реплики.

Мониторинг задержек

Группа команд с задержкой может использоваться для выполнения мониторинга задержки кластера Redis. Команда LATENCY LATEST выводит самое последнее зарегистрированное событие задержки. Выходные данные включают название события, временную метку, в которую произошел последний всплеск, последнюю задержку (в миллисекундах) и самую высокую задержку за все время для события.

Команда “LATENCY HISTORY” отображает временные ряды задержек для события. Это удобно, когда вы хотите проанализировать исторические тенденции задержки события. Если вы хотите сбросить временные ряды для события, вы можете использовать команду LATENCY RESET.

Если вы хотите визуализировать тенденции события с задержкой, используйте команду LATENCY GRAPH. Она возвращает график в формате ASCII. Наконец, если вам нужен подробный, понятный человеку анализ проблем с задержкой и потенциальных решений, вы можете выполнить команду LATENCY DOCTOR.

Отслеживайте Redis с помощью консоли администратора

Консоль администратора Redis – это веб-приложение, которое показывает показатели, связанные с кластером, узлами, базами данных, сегментами, репликацией и памятью. Для входа в консоль администратора необходимо получить учетные данные для входа, хранящиеся в секретном файле Kubernetes, и перенаправить локальный порт на порт службы пользовательского интерфейса (порт по умолчанию 8443).

Консоль администратора – отличное место для получения целостного обзора экземпляра Redis. В ней отображается информация, относящаяся к подключениям, загрузке процессора, входящему и исходящему трафику, дисковому пространству, оперативной памяти, задержке, ограничению памяти и многому другому. В нем также показаны несколько показателей для конкретной базы данных, таких как количество удаляемых объектов в секунду, коэффициент попадания, задержка команд, фрагментация оперативной памяти и общее количество ключей.

Отслеживайте Redis с помощью команды MONITOR

Команда MONITOR в Redis обеспечивает непрерывный поток всех команд, которые выполняются сервером Redis. Он может выступать в качестве мощного инструмента отладки, позволяя пользователям наблюдать и понимать, что происходит с действующим сервером Redis.

Например, если вы отлаживаете приложение, вы можете ввести MONITOR, чтобы увидеть, какие команды приложение выполняет на Redis. Или, если вы сталкиваетесь с исключительно высокой частотой запросов, вы можете использовать команду MONITOR, чтобы увидеть характер входящих запросов.

Вы можете выполнить команду MONITOR через Redis CLI или telnet. Используйте Ctrl + C, чтобы остановить поток MONITOR, запущенный через CLI. Чтобы закрыть поток telnet, необходимо ввести команды RESET или QUIT. MONITOR не регистрирует административные команды и редактирует конфиденциальные данные. Важно отметить, что непрерывная потоковая передача MONITOR в производственном экземпляре может повлиять на производительность.

Заключение

Redis – популярное хранилище данных в оперативной памяти, которое отличается производительностью, устойчивостью, масштабируемостью и долговечностью. Простой в использовании интерфейс запросов, поддержка нескольких структур данных, встроенные функции репликации и кластеризации, а также сохраняемость данных делают его основным элементом нескольких распределенных ИТ-инфраструктур. Независимо от того, создаете ли вы для облака или локально, вы можете использовать Redis для кэширования, управления сеансами или потоковой передачи данных в реальном времени.

(1 оценок, среднее: 5,00 из 5)

Загрузка...