RadosGW или RGW он же Ceph Object Gateway позволяет работать с хранилищем RADOS(он же Ceph) через REST API совместимый с S3 и Swift. RGW является прослойкой между пользователем использующим REST и хранилищем RADOS взаимодействие с которым осуществляется по алгоритму CRUSH.
У всех компонентов Ceph есть метрики позволяющие мониторить производительность и понимать, что происходит в кластере. У RGW тоже есть такие метрики и они нам сильно помогают понимать состояние системы в целом и находить проседающие места.
Получение метрик
ceph --admin-daemon /var/run/ceph/ceph-client.radosgw.ss10.asok perf dump
Метрики запрашиваются через сокет конкретного экземпляра RGW. И это метрики именно этого экземпляра.
Путь к сокету формируется обычно примерно так: /var/run/ceph/ceph- + rgw_name + .asok где rgw_name это уникальное имя экземпляра RGW из ceph.conf:
[client.radosgw.ss10]_x000D_
pid file = /var/run/ceph/client.radosgw.ss10.pid_x000D_
host = ss10_x000D_
keyring = /etc/ceph/ceph.client.ss10.keyring_x000D_
… Наиболее интересные метрики:
"client.radosgw.ss10": {_x000D_
"req": 70715,_x000D_
"failed_req": 41737,_x000D_
"get": 9,_x000D_
"get_b": 1048572,_x000D_
"get_initial_lat": {_x000D_
"avgcount": 4,_x000D_
"sum": 0.019146922_x000D_
},_x000D_
"put": 168,_x000D_
"put_b": 44040192,_x000D_
"put_initial_lat": {_x000D_
"avgcount": 168,_x000D_
"sum": 8.006931290_x000D_
},_x000D_
"qlen": 0,_x000D_
"qactive": 0,_x000D_
"cache_hit": 20832,_x000D_
"cache_miss": 36936,_x000D_
"keystone_token_cache_hit": 0,_x000D_
"keystone_token_cache_miss": 0_x000D_
},_x000D_
... Значения метрик
req — все хапросы, что пришли, совершенно любые, в том числе, например сurl без параметров,
failed_req — в исходном коде RGW подписана как “Aborted requests”, что довольно не однозначно. По моим наблюдениям сюда попадают запросы завершившиеся не с “положительным” http-кодом, например с 404 (Not Found, NoSuchBucket и т.д.),
get — количество запросов типа HEAD/GET,
get_b — суммарный объем данных в get-запросах. Сколько данных скачано через этот RGW с момента начала его работы,
get_initial_lat — сложная метрика. Точнее ее сложно обсчитывать для мониторинга. Тут есть avgcount, что является числом именно get-запросов и sum, что является суммарным временем выполнения этих запросов. Что бы получить примерное время обработки одного запроса нужно делить sum на avgcount. При этом, это нужно брать не текущие значения за все время которые всегда растут а с дельту которая появляется между забором метрик. То есть на каждой новой проверке нужно где то брать предыдущие значения этих метрик, что бы получить дельту за время с последней проверки и уже значения дельт делить(sum_delta / avgcount_delta). Тогда получится среднее время запроса за период проверки,
put — все put-запросы?
put_b — Сколько данных загружено через этот RGW
put_initial_lat — тоже самое как и get_initial_lat, высчитывать так же,
qactive — один из самых интересных параметров. В исходном коде отмечен как “Active requests queue”. Число потоков которые использованы в настоящий момент. По умолчанию у каждого инстанса RGW может быть максимум 100 потоков. Соответственно когда все потоки будут задействованы, RGW не сможет принимать новые запросы. Если вы наблюдаете периодическую утилизацию всех потоков RGW то возможно есть две проблемы. Кластер Ceph не справляется с нагрузкой и очень долго выполняет запросы RGW. Если у вас нет мониторинга Ceph, что бы это понять, то можно посмотреть на метрики get_initial_lat,put_initial_lat и в таких случаях должна расти latency. Второй случай когда с самим Ceph все хорошо и запросов просто слишком много. В такой ситуации нужно добавлять инстансы RGW или увеличивать число потоков.
qlen — В исходном коде подписан как «Queue length”. В теории все понятно, но на практике, мне лично нет. Когда все потоки(qactive) RGW утилизированы, то начинает расти счетчик qlen, что логично, но я не понимаю, почему он растет только до 12. В общем не нужно допускать роста значения этого счетчика)
cache_hit — попадания в cache метаданных. RGW кеширует метаданеые объектов запросы к которым он обработал и тем самым ускоряет отработку последующих операций с этими объектами. По умолчанию размер кеша равен 10000 записей. Я пока не могу сказать увеличивать его значение или нет и в каких случаях. По логике, если ваш кластер Ceph не справляется с текущей нагрузкой, увеличение размера кеша приведет к еще большей нагрузке. С другой стороны RGW будет меньше читать индекс бакетов, что по идее снизит немного нагрузку. Тут нужны эксперименты, которые я еще не проводил.
cache_miss — промахи в cache метаданных.
Еще интересный момент. Например метод S3 API copy-object не увеличивает счетчики get, put только счетчики req. Данные через RGW фактически не проходят но при этом в самом кластере ceph данные копируются, что может создавать серьезную нагрузку при этом в мониторинге RGW может например начать рости lanency хотя нет никаких тяжелых get/put запросов.
Сброс счетчиков
Счетчики сбрасываются при рестарте rgw или это можно сделать вручную:
ceph --admin-daemon /var/run/ceph/ceph-client.radosgw.ss10.asok perf reset all
Можно сбросить счетчики отдельных метрик, см help:
ceph --admin-daemon /var/run/ceph/ceph-client.radosgw.ss10.asok help_x000D_
{_x000D_
"config diff": "dump diff of current config and default config",_x000D_
"config get": "config get <field>: get the config value",_x000D_
"config set": "config set <field> <val> [<val> ...]: set a config variable",_x000D_
"config show": "dump current config settings",_x000D_
"get_command_descriptions": "list available commands",_x000D_
"git_version": "get git sha1",_x000D_
"help": "list available commands",_x000D_
"log dump": "dump recent log entries to log file",_x000D_
"log flush": "flush log entries to log file",_x000D_
"log reopen": "reopen log file",_x000D_
"objecter_requests": "show in-progress osd requests",_x000D_
"perf dump": "dump perfcounters value",_x000D_
"perf reset": "perf reset <name>: perf reset all or one perfcounter name",_x000D_
"perf schema": "dump perfcounters schema",_x000D_
"version": "get ceph version"_x000D_
} Собственно, все. Мониторить описанные метрики вы можете любым удобным для вас способом. Мы используем Zabbix и в следующей статье, покажу как мы это делаем у себя.
Отдельно хочу заметить для нуждающихся в настройке контекстной рекламы уфа, пригодится ссылка на проверенных специалистов.
Помогла ли вам статья?
