В ходе рассмотрения первого развёртывания системы мониторинга Icinga 2 мы затрагивали тему с базовой настройкой подсистемы сбора метрических данных и отображения графиков – Graphite. При этом в качестве составной компоненты Graphite для приёмки и первичной обработки метрических данных у нас использовался предлагаемый по умолчанию Carbon. Описанная конфигурация до определённого момента вполне успешно выполняла свои задачи, но по мере роста нагрузки на сервер мониторинга мы стали замечать тревожную тенденцию к существенному росту процессорной нагрузки.
В дни, когда мы начали активно подключать к системе мониторинга дополнительные наблюдаемые хосты и при этом прокачивать возможности системы дополнительными плагинами, расширяющими набор собираемых метрик, было обнаружено серьёзное повышение нагрузки на все процессорные ядра.
Было очевидно, что рост количества собираемых метрик и хостов прямо сопоставим с ростом процессорной нагрузки. При этом к мониторингу были подключены ещё далеко не все хосты и задействованы ещё не все интересующие нас метрики.
При подключении всё больших объектов стало очевидно, что очень скоро мы придём к полной утилизации процессорного ресурса. Увеличение количества ядер на ситуацию каким-то кардинальным образом не повлияло и стало понятно, что нужно искать способы оптимизации. На глаза попались две старые, но от этого не потерявшие для нас актуальности, довольно интересные статьи от автора Alexander Bulimov: "Заметка о Graphite" и "Замена carbon-cache на go-carbon = Счастье". Решили попробовать рецепт с заменой carbon-cache на go-carbon и, практически, это действительно очень помогло и ощутимо поправило нашу ситуацию.
Далее кратко о том, что было сделано и какого результата удалось достичь. Обратите внимание на то, что в представленном далее примере используется не самая актуальная версия go-carbon, так как черновик этой записи делался давно. Поэтому применительно к более новым версиям go-carbon могут присутствовать свои нюансы, которые в нашим примере не учтены.
Так как carbon-cache и go-carbon - это два разных инструмента, которые выполняют одни и те же задачи с одними и теми же метриками, то вместе они работать не смогут. Нам потребуется в конфигурации Graphite деактивировать carbon-cache и запустить go-carbon.
Отключаем carbon-cache:
# systemctl stop carbon-cache
# systemctl disable carbon-cache
В файле /etc/default/graphite-carbon комментируем строку включения автозагрузки carbon-cache:
# Change to true, to enable carbon-cache on boot
#CARBON_CACHE_ENABLED=true
Скачиваем и устанавливаем go-carbon (заменить ссылку и имя пакета на актуальную версию):
# mkdir ~/packages
# cd ~/packages
# wget https://github.com/lomik/go-carbon/releases/download/v0.14.0/go-carbon_0.14.0_amd64.deb
# dpkg -i ~/packages/go-carbon_0.14.0_amd64.deb
Настраиваем конфигурацию go-carbon.conf:
# nano /etc/go-carbon/go-carbon.conf
На какие параметры конфигурации стоит обратить внимание:
[common]
# Run as user. Works only in daemon mode
#user = "carbon"
user = "_graphite"
...
# Increase for configuration with multi persister workers
max-cpu = 4
[whisper]
data-dir = "/var/lib/graphite/whisper"
...
[cache]
...
# Capacity of queue between receivers and cache
# Strategy to persist metrics. Values: "max","sorted","noop"
# "max" - write metrics with most unwritten datapoints first
# "sorted" - sort by timestamp of first unwritten datapoint.
# "noop" - pick metrics to write in unspecified order,
# requires least CPU and improves cache responsiveness
#write-strategy = "max"
write-strategy = "noop"
...
[udp]
listen = ":2003"
#enabled = true
enabled = false
...
[tcp]
#listen = ":2003"
listen = "127.0.0.1:2003"
enabled = true
...
Настраиваем storage-schemas.conf по аналогии с ранее настроенным /etc/carbon/storage-schemas.conf
# mv /etc/go-carbon/storage-schemas.conf /etc/go-carbon/storage-schemas_default.conf
# cp /etc/carbon/storage-schemas.conf /etc/go-carbon/
Настраиваем storage-aggregation.conf по аналогии с ранее настроенным /etc/carbon/storage-aggregation.conf
# mv /etc/go-carbon/storage-aggregation.conf /etc/go-carbon/storage-aggregation_default.conf
# cp /etc/carbon/storage-aggregation.conf /etc/go-carbon/
Добавляем в sysctl.conf модификации в соответствии с рекомендацией разработчиков:
# nano /etc/sysctl.conf
# Go-Carbon recommendations
#
# percentage of your RAM which can be left unwritten to disk. MUST be much more than
# your write rate, which is usually one FS block size (4KB) per metric.
vm.dirty_ratio=80
# percentage of yout RAM when background writer have to kick in and
# start writes to disk. Make it way above the value you see in `/proc/meminfo|grep Dirty`
# so that it doesn't interefere with dirty_expire_centisecs explained below
vm.dirty_background_ratio=50
# allow page to be left dirty no longer than 10 mins
# if unwritten page stays longer than time set here,
# kernel starts writing it out
vm.dirty_expire_centisecs=60000
Заставляем систему перечитать настройки sysctl.conf:
# sysctl -p
vm.dirty_ratio = 80
vm.dirty_background_ratio = 50
vm.dirty_expire_centisecs = 60000
Включаем автозагрузку службы go-carbon, запускаем службу и проверяем её статус:
# systemctl enable go-carbon
# systemctl start go-carbon
# systemctl status go-carbon
● go-carbon.service - Golang implementation of Graphite/Carbon server.
Loaded: loaded (/lib/systemd/system/go-carbon.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-11-28 17:00:46 MSK; 31s ago
Docs: https://github.com/lomik/go-carbon
Main PID: 50404 (go-carbon)
CGroup: /system.slice/go-carbon.service
└─50404 /usr/bin/go-carbon -config /etc/go-carbon/go-carbon.conf -pidfile /var/run/go-carbon.pid -daemon
Nov 28 17:00:46 KOM-MON20 systemd[1]: Starting Golang implementation of Graphite/Carbon server....
Nov 28 17:00:46 KOM-MON20 systemd[1]: Started Golang implementation of Graphite/Carbon server..
В результате мы получили возможность безболезненно увеличить количество собираемых метрик и хостов и при этом получили относительно невысокую и стабильную процессорную нагрузку с хорошим запасом дальнейшей расширяемости.
RSS - Записи
Добавить комментарий