Ceph Object Gateway (RadosGW): performance monitoring (Zabbix)

Про доступные метрики производительности RadosGW(RGW) я писал отдельную заметку.
В этот раз я опишу как мы у себя собираем эти метрики в Zabbix.

Скрипт сбора метрик, user_parameters.conf и собственно шаблон для Zabbix — https://github.com/FATruden/rgw-monitoring

На серверах выполняющих роль RGW, метрики собираются простым скриптом на Python. Скрипт прописан в cron хитрым образом, что бы метрики собирались раз в 30 сек.:

* * * * * /etc/zabbix/zabbix_agentd.d/scripts/get-rgw-perf.py
* * * * * sleep 30; /etc/zabbix/zabbix_agentd.d/scripts/get-rgw-perf.py

В процессе своей работы, скрипт парсит JSON, пересчитывает latency и записывает значение каждой метрики в отдельный, одноименный текстовый файл с префиксом ‘rgw.’ в каталоге /tmp

В user_parameters.conf на сервере с zabbix agent’ом нужно добавить:

### RGW perf counters ###
UserParameter=rgw.[*],cat /tmp/rgw.$1
UserParameter=rgw.state, service ceph-radosgw status > /dev/null ; echo $?

Ну, и собственно импортировать сам шаблон доступный в репозитории выше, и назначить его нужных хостам. Далее настроить Screen по вкусу)

Зачем cron? Почему в текстовые файлы? Почему просто не парсить оформленный вывод Python-скрипта при запросе каждого айтема?

Есть три причины.

1. В данном случае у нас примерно 10 интересных нам метрик. Если на забор данных каждой метрики мы будем дергать Python а тот в свою очередь rgw через сокет, то время забора значения одной метрики будет примерно раз в 20 больше чем таковое при выполнение cat /tmp/rgw.{metric_name}. Это важно если ваш Zabbix-сервер или proxy собирают сотни тысяч метрик. Нужно помогать им делать сбор каждой метритами как можно быстрее.

2. Нагрузка на сам RGW. В моем случае делается два запроса в минуту. В случае дерганья каждой метрики по отдельности с частотой в 30 сек. — получится примерно 20 вызовов RGW.

3. В случае с cron, все метрики получаются одновременно и в файлах они находятся в синхронизированном друг с другом состоянии, что полезнее для поиска корреляций между их значениями.  

  • rbetra

    Здравствуйте, Александр.

    Извините, что не по теме, но с письмом к вам как то не задалось( smtp; 550 Unknown user)

    Можете посоветовать, что выбрать Ceph или GlusterFS в качестве отказоустойчивого хранилища.

    Попытаюсь описать для чего нам нужно хранилище:

    СХД для VM ( на данный момент мы используем vmware и
    подключенный по SAS сторадж, кажется ceph и vmware напрямую не
    работают, про GlusterFS даже не знаю);

    отказоустойчивость (тут вроде оба кандидата на высоте);

    хранение данных большого объема ( наши астрономы накапливают
    сотни ТБ данных, в основном они удаляются, но что-то требует
    длительного хранения.

    Думаю уровень 1 ПБ реален, а возможность горизонтального
    масштабирования это ради чего все и задумывается. Размеры файлов
    10-ки ГБ.)

    Файлопомойка для linux/windows клиентов ( не уверен, что это
    требование к хранилищу, так как это организовывается средствами
    VM, но опять же вопрос удобства организации доступа к данным.);

    Доступ к данным — на данный момент основной способ
    взаимодействия с данными это классический POSIX через NFS.

    PS: Думаю есть еще масса нюансов работы с распределенными системами, но
    тут нужен опыт, которого у нас пока нет, в общем, если у вас будет
    время и желание напишите, в какую сторону нам копать, а я пока
    почитаю ваши статьи.

    • fatruden

      Здравствуйте.

      У меня довольно богатый, местами очень негативный опыт эксплуатирования Ceph в проде, с большими данными и массой клиентов. Мы используем Ceph как S3-совместимое объектное хранилище. Больше всего я работал с hammer(0.94.x), сейчас тестируем переход на luminous но за него я пока ничего сказать не могу.
Так вот, я бы не рекомендовал использовать Ceph как блочное хранилище в серьезном проекте где важна стабильность и высокая доступность данных. При больших нагрузках кластер ведет себя крайне не стабильно, особенно если нагрузка приходится на то время когда идет скраббинг(scrubbing). Я могу описать очень много проблем с которыми мы сталкивались и сталкиваемся, и то как мы с ними боремся, но тогда получится целая статья)
Второй момент это производительность Ceph. Она очень низкая в сравнении с тем же GlusterFS. И третий момент это потребление CPU с которым у Ceph тоже беда.

      
С GlusterFS у меня сильно меньше опыта в проде но мы его тестировали как блочное хранилище для qemu-kvm через libgfapi который поддерживает qemu-kvm и gluester был гораздо интереснее в плане производительности и потребления ресурсов + он поддерживает RDMA, что нам тоже было интересно. Но я ничего не могу сказать про надежность и стабильность Gluster т.к. опять же не было серьезного опыта в проде.

      • rbetra

        Спасибо за пояснения, задумался. Печально, что к Ceph столько претензий, была надежда, что вот она серебряная пуля:) Объектный доступ к данным, нас пока не интересует, как раз больше потребность в блочном для VM( думаю около 1-2% СХД) и хорошо масштабируемом файловом хранилище для большого количества данных. Буду поднимать стенд и обкатывать оба решения.

        • fatruden

          На этапе тестирования и даже в течении нескольких лет эксплуатации мы не испытывали каких либо проблем с Ceph, все началось когда 2 Tb диски наполнелись более чем на половину и нагрузка стала высокой и постоянной. Сейчас активно тестируем обновление в надежде на улучшение)
          В качестве блочного доступа я могу порекомендовать вам EMC ScaleIO — прекрасный блочный SDS c REST API, отличной производительностью и управляемостью.

          • arsen

            Здравствуйте, Александр!

            А не могли бы вы и правда написать
            статью о вашем опыте работы с Ceph? Очень заинтересовали комментарии про
            его нестабильность. В нашем проекте Ceph предполагается использовать для долговременого
            хранения данных (5 лет и более).