Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 11. Настройка интеграции Graphite в Icinga Web 2

03.04.2017 Автор:Алексей Максимов
7 437 Просмотров 3 комментария

В развёрнутой ранее конфигурации Icinga Web 2 по умолчанию отсутствует возможность просматривать исторические графики изменения показателей производительности объектов мониторинга. Однако фронтенд Icinga Web 2 имеет модуль расширения, который позволяет получать данные из Graphite. В этой заметке мы рассмотрим пример интеграции Graphite в Icinga Web 2.

Graphite - это система сбора метрических данных и отображения графиков в реальном времени на основе собранных данных. Graphite включает 3 основные компоненты:

  • Carbon - служба прослушивающая порт и принимающая метрические данные
  • Whisper - библиотека работающая с сохранением полученных из Carbon данных.
  • Graphite-Web – веб-приложение  основанное на Django, генерирующее графики с использованием библиотеки Cairo.

Для лучшего понимания взаимосвязей компонент, приведу схематичное изображение архитектуры Graphite, позаимствованное из FAQ:

Сначала мы установим и выполним базовую настройку Graphite и её составных компонент, затем произведём интеграцию Graphite с веб-консолью Icinga Web 2 и немного поговорим о дополнительной настройке отображения графиков под собственные нужды.

 

Установка пакетов в Debian Jessie

Список системных требований для установки Graphite можно найти в документе Installing Graphite.

Устанавливаем из официальных репозиториев Debian Jessie набор пакетов, необходимых для базовой работы Graphite (эти пакеты подтянут в систему ряд других пакетов, в том числе и Whisper):

# apt-get install graphite-web graphite-carbon libapache2-mod-wsgi

Модуль WSGI для Apache2 должен быть активирован в процессе установки. Проверим это:

# apache2ctl -M | grep wsgi

 wsgi_module (shared)

Если модуля нет в списке активных, выполним его активацию командой:

# a2enmod wsgi

 

 

Настройка Graphite

Внесём минимальные правки в конфигурационный файл /etc/graphite/local_settings.py:

  • Найдём и раскомментируем параметр SECRET_KEY, задав ему любое случайное значение.
  • Найдём и раскомментируем параметр TIME_ZONE, который определяет часовой пояс (по умолчанию установлен на 'America/Chicago'). Заменим значение этого параметра на свой часовой пояс.

Обратите внимание на значение параметра DEFAULT_CACHE_DURATION (время кэширования изображений графиков), которое по умолчанию равно 1 минуте.

В нашем случае результирующий файл принял следующий вид (вывод отображён без учёта имеющихся в файле комментариев):

SECRET_KEY = 'ljdw7WKjsd0s5z'
TIME_ZONE = 'Europe/Moscow'
LOG_RENDERING_PERFORMANCE = True
LOG_CACHE_PERFORMANCE = True
LOG_METRIC_ACCESS = True
GRAPHITE_ROOT = '/usr/share/graphite-web'
CONF_DIR = '/etc/graphite'
STORAGE_DIR = '/var/lib/graphite/whisper'
CONTENT_DIR = '/usr/share/graphite-web/static'
WHISPER_DIR = '/var/lib/graphite/whisper'
LOG_DIR = '/var/log/graphite'
INDEX_FILE = '/var/lib/graphite/search_index'
DATABASES = {
    'default': {
        'NAME': '/var/lib/graphite/graphite.db',
        'ENGINE': 'django.db.backends.sqlite3',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': ''
    }
}

 

Настройка Graphite-Web

Создаем базу данных Graphite-Web. На вопрос о создании супер-пользователя отвечаем утвердительно. Вводим произвольные имя пользователя и пароль, который в дальнейшем будут использоваться для управления Graphite (для простого просмотра метрик эти учётные данные не нужны):

# graphite-manage syncdb

Operations to perform:
  Synchronize unmigrated apps: account, dashboard, tagging, events
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Creating table account_profile
    Creating table account_variable
    Creating table account_view
    Creating table account_window
    Creating table account_mygraph
    Creating table dashboard_dashboard_owners
    Creating table dashboard_dashboard
    Creating table events_event
    Creating table tagging_tag
    Creating table tagging_taggeditem
  Installing custom SQL...
  Installing indexes...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying sessions.0001_initial... OK

You have installed Django's auth system, and don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'root'): graphiteadmin
Email address:
Password: {введём пароль для пользователя}
Password (again): {повторим ввод пароля}
Superuser created successfully.

Установим права на файл вновь созданной базы данных:

# chown _graphite:_graphite /var/lib/graphite/graphite.db

Копируем конфигурационный файл для сайта Graphite-Web в Apache2:

# cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/graphite-web.conf

Так как на нашем сервере 80 порт уже используется для веб-консоли Icinga Web 2, нам потребуется повесить сайт Graphite-Web на какой-нибудь другой свободный порт, например 8000. Меняем номер порта в /etc/apache2/sites-available/graphite-web.conf:

<VirtualHost *:8000>

        WSGIDaemonProcess _graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120 user=_graphite group=_graphite
        WSGIProcessGroup _graphite
        WSGIImportScript /usr/share/graphite-web/graphite.wsgi process-group=_graphite application-group=%{GLOBAL}
        WSGIScriptAlias / /usr/share/graphite-web/graphite.wsgi

        Alias /content/ /usr/share/graphite-web/static/
        <Location "/content/">
                SetHandler None
        </Location>

        ErrorLog ${APACHE_LOG_DIR}/graphite-web_error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/graphite-web_access.log combined

</VirtualHost>

Дополнительно указываем Apache2 прослушивать 8000 порт в файле /etc/apache2/ports.conf, добавив соответствующую строку:

Listen 80
Listen 8000
<IfModule ssl_module>
        Listen 443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

Активируем сайт и перезапускаем конфигурацию Apache2:

# ( a2ensite graphite-web ) && ( service apache2 reload )

Откроем порт в iptables при необходимости:

# iptables -A INPUT -p tcp -m tcp --dport 8000 -m comment --comment "Graphite web-site" -j ACCEPT

Проверяем доступность веб-интерфейса Graphite-Web, пройдя по ссылке http://server:8000

 

Настройка Carbon

Рабочие конфигурационные файлы Carbon расположены в каталоге /etc/carbon. Примеры возможных конфигурационных файлов для настройки Carbon можно найти в каталоге /usr/share/doc/graphite-carbon/examples.

Основной конфигурационный файл /etc/carbon/carbon.conf оставляем с настройками по умолчанию. Единственное, что можно там изменить, это включить ротацию логов:

...
ENABLE_LOGROTATION = True
...

В конфигурации по умолчанию Carbon сохраняет ежеминутные показатели за период не более суток. Изменим срок хранения данных, добавив в конфигурационный файл /etc/carbon/storage-schemas.conf дополнительную секцию (перед секцией [default], относящейся к любым именам метрик, т.е. pattern = .*), описывающую схему хранения метрик для Icinga:

[carbon]
pattern = ^carbon\.
retentions = 60:90d

[icinga2_internals]
pattern = ^icinga2\..*\.icinga\.perfdata\.
retentions = 300s:7d

[icinga2_default]
pattern = ^icinga2\.
retentions = 60s:15d,300s:30d,900s:90d,1800s:180d

[default_1min_for_1day]
pattern = .*
retentions = 60s:1d

В данном примере метрики, поступающие от самой службы Icinga [icinga2_internals] будут сохраняться раз в пять минут и храниться всего 7 дней. Этих метрик много, они по сути являются служебными и не всегда нам интересны, поэтому мы и сокращаем срок их хранения.

Все прочие метрики, поступающие от Icinga и непосредственно относящиеся к интересующим нас объектам мониторинга [icinga2_default], будут сохраняться раз в минуту и хранится 15 дней. Из этих метрик будут собираться пятиминутные метрики, которые будут хранится 30 дней. Из пятиминутных метрик агрегируются метрики за 15 минут и хранятся в 90 дней. И последними будут агрегироваться 30-минутные метрики и будут храниться в течение полугода. В общем здесь схему сохранения и агрегации метрик можно настроить под свои нужды, как душе угодно.

Чтобы в процессе агрегации не происходило искажения объективной картины данных, воспользуемся советом из статьи Собираем метрики при помощи Graphite, StatsD и CollectD и создадим дополнительный конфигурационный файл для Carbon:

# nano /etc/carbon/storage-aggregation.conf

Наполним файл правилами агрегации, которые будут применять разные механизмы получения агрегированных значений в зависимости от имени метрик, вместо того, чтобы во всех случаях использовать вычисляемую среднюю величину:

[min]
pattern = \.min$
xFilesFactor = 0.1
aggregationMethod = min

[max]
pattern = \.max$
xFilesFactor = 0.1
aggregationMethod = max

[count]
pattern = \.count$
xFilesFactor = 0
aggregationMethod = sum

[lower]
pattern = \.lower$
xFilesFactor = 0.1
aggregationMethod = min

[upper]
pattern = \.upper$
xFilesFactor = 0.1
aggregationMethod = max

[sum]
pattern = \.sum$
xFilesFactor = 0
aggregationMethod = sum

[default]
pattern = .*
xFilesFactor = 0.1
aggregationMethod = average

Чтобы изменения вступили в силу, перезагрузим службу carbon-cache:

# service carbon-cache restart

В файле /etc/default/graphite-carbon изменяем строку включения автозагрузки carbon-cache:

# Change to true, to enable carbon-cache on boot
CARBON_CACHE_ENABLED=true

 

Проверка работы Graphite

Отправим для теста какие-нибудь данные в Carbon, чтобы убедиться в том, что они в конечном итоге доступны в Graphite-Web. Например, возьмём текущее значение загрузки системы из /proc/loadavg, вычленим из него первое значение и, добавив к нему метку времени, отправим этот набор данных в TCP-прослушиватель Carbon на локальный порт 2003. Всё это дело завернём в цикл с тактом в 30 секунд, так, чтобы получилась команда в одну строку:

# for i in {1..20}; do echo "local.LoadAverage $(cat /proc/loadavg | awk '{print $1}') `date +%s`" | nc -q0 127.0.0.1 2003; sleep 30; done

Если система во время теста не особо нагружена, то можем сымитировать дополнительную нагрузку (чтобы график загрузки получился показательней), запустив в дополнительной консоли сервера что-нибудь типа:

$ cat /dev/urandom > /dev/null

Пока команды выполняются, перейдём на веб-консоль Graphite-Web. В дереве навигации развернём появившийся контейнер local и выберем созданную нами метрику LoadAverage. В панели инструментов Graphite Composer изменим диапазон отображения  информации на графике, например, за последние 10 минут. Для обновления графика в реальном режиме времени нажмём Auto-Refresh.

Теперь понятно, что Graphite успешно получает и сохраняет отправляемые нами данные. Можем переходить к настройке интеграции Graphite в Icinga Web 2.

 

Интеграция Graphite в Icinga Web 2

Подготовим Icinga 2, разрешив использование необходимых расширений:

# icinga2 feature enable perfdata
# icinga2 feature enable graphite

Настроим конфигурацию расширения graphite в соответствии с рекомендациями авторов модуля icingaweb2-module-graphite README, откорректировав файл /etc/icinga2/features-available/graphite.conf. Раскомментируем строки, в которых указан адрес TCP-прослушивателя Carbon. В итоге файл примет следующий вид:

library "perfdata"

object GraphiteWriter "graphite" {
  host = "127.0.0.1"
  port = 2003
  enable_send_thresholds = true
}

Дополнительный параметр enable_send_thresholds позволит отправлять вместе с метриками текущие значения установленных границ срабатывания "алертов" в Icinga. Это может быть полезно для построения некоторых графиков, если требуется, чтобы на графике была чётко видна позиция текущего значения метрики относительно предельных значений по Y-оси.

После этого перезапустим службу icinga2:

# service icinga2 restart

Теперь нужно заполучить сам модуль icingaweb2-module-graphite. На GitHub данный модуль представлен в виде некоторого количества вариаций. Одним из самых распространённых и часто-упоминаемых в разных инструкциях и статьях на эту тему git-проектов является проект findmypast - icingaweb2-module-graphite. Как я понял, зачастую выбирают этот проект по той причине, что его проще настроить и работать он будет с любыми метриками, которые активы в Icinga, то есть из-за его реализации по принципу - для всех метрик – единый шаблон отображения. Я же выбрал проект, который, как я думаю, является более родным для Icinga - Icinga - icingaweb2-module-graphite. Во первых данный проект имеет более свежие "коммиты", что является некоторым свидетельством того, что что проект жив и поддерживается. Во вторых, основным преимуществом этого проекта является бОльшая гибкость, так как он позволяет настраивать индивидуальные шаблоны построения графиков для разных Служб Icinga, вплоть до построения отдельных графиков для любой отдельно взятой метрики. Соответственно приведённое далее описание настройки модуля относится к конкретному проекту Icinga - icingaweb2-module-graphite.

Клонируем модуль с GitHub:

# apt-get install git -y
# mkdir /usr/share/icingaweb2/modules/graphite   
# git clone --depth=1 https://github.com/Icinga/icingaweb2-module-graphite.git /usr/share/icingaweb2/modules/graphite

Создаём каталог для хранения конфигурационных файлов модуля:

# mkdir -p /etc/icingaweb2/modules/graphite

Копируем пред-настроенные шаблоны отображения графиков для разных Служб Icinga и конфигурационный файл модуля из папки клона проекта в ранее созданный каталог:

# cd /usr/share/icingaweb2/modules/graphite
# cp -r ./sample-config/icinga2/* /etc/icingaweb2/modules/graphite

Переписываем права доступа на каталог с конфигурационными файлами:

# chown -R www-data:icingaweb2 /etc/icingaweb2/modules/graphite
# chmod -R 2750 /etc/icingaweb2/modules/graphite

В конфигурационном файле /etc/icingaweb2/modules/graphite/config.ini изменим URL Graphite-Web

[graphite]
web_url = http://127.0.0.1:8000

Затем переходим в веб-консоли Icinga Web 2 в Configuration > Modules и активируем модуль (graphite > enable):


После этого в областях отображения информации о Хосте/Службе в разделе Problem handling > Actions появится дополнительная ссылка Graphite:

Ссылки данного типа будут вести на оперативный график с настроенными метриками, зарегистрированными для соответствующего объекта мониторинга за последний час:

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

Основным режимом просмотра исторических данных может являться отдельная страница, доступная в веб-консоли через меню History > Graphite. Здесь у нас появляется возможность отображения сразу на одной странице сразу нескольких графиков одного типа. Режим отображения задаётся фильтрами в заголовочной части страницы.

Обратите внимание на то, что первым полем в фильтре используется шаблон графиков – Template. Далее поговорим о том, как можно настраивать данные шаблоны под свои предпочтения.

 

Настройка шаблонов графиков модуля icingaweb2-module-graphite

Как уже было замечено ранее, используемый нами модуль Icinga Web 2 интересен тем, что позволяет нам самостоятельно настраивать имеющиеся шаблоны построения графиков, или вообще создавать собственные дополнительные шаблоны. Шаблоны отображения графиков хранятся в каталоге /etc/icingaweb2/modules/graphite/templates/icinga2/

# ls /etc/icingaweb2/modules/graphite/templates/icinga2/

disk.conf  hostalive.conf  http-size.conf  http-time.conf  icinga.conf  load.conf  ping4.conf  procs.conf  ssh.conf  swap.conf  templateset.ini

Представленные на скриншотах выше графики представляют собой результат самостоятельной правки имеющихся шаблонов под свои предпочтения. Например в шаблоне load.conf, поставляемом вместе с модулем, я добавил отображение сетки (так мне легче сопоставлять график с осями), изменил временную зону (по умолчанию используется GMT), изменил формат отображения времени, немного изменил цвета метрик. В результате файл шаблона принял следующий вид:

title = Load
filter = $icingaService.load.perfdata
areaMode = first
areaAlpha = 0.3
hideGrid = false
tz = Europe/Moscow
xFormat = %d.%m/%H:%M

load1.value : color=#FFAC59, alias=Load average last 1 min.
load5.value : color=#B87272, alias=Load average last 5 min.
load15.value: color=red, alias=Load average last 15 min.

Как я понял, внутри шаблонов идёт простое определение ряда параметров и их значений, которые могут использоваться в API Graphite. Сами параметры и порядок указания их значений были подсмотрены в документе Graphite Docs - The Render URL API.

 

Создание собственного шаблона графиков

Если возникает необходимость отображения в веб-консоли Icinga Web 2 графика для Службы, шаблона которой нет, то мы можем самостоятельно создать нужный шаблон в каталоге /etc/icingaweb2/modules/graphite/templates/icinga2. Например, для ранее созданного Шаблона Службы для мониторинга загрузки процессора, создадим в этом каталоге файл с именем, например, cpu.conf, и наполним его содержимым:

title = CPU Load %
filter = $icingaService.check_cpu.perfdata
#areaMode = first
areaAlpha = 0.3
hideGrid = false
min=0
#max=100
tz = Europe/Moscow
xFormat = %d.%m/%H:%M

cpu_sys.value : color=#B87272, alias=System CPU Load %
cpu_user.value : color=#FFAC59, alias=Users CPU Load %
cpu_iowait.value : color=#6464FF, alias=IO Wait CPU %

В итоге после обновления соответствующей веб-страницы мы сможем лицезреть нужный график:

  

Изменяем периоды отображения графиков по умолчанию

По умолчанию набор шаблонов периодов построения графиков на странице History\Graphite выглядит скудновато:

Текущая реализация модуля не позволяет через какие-то переменные конфигурационного файла модуля настраивать эти периоды, поэтому для расширения этого предопределённого перечня периодов воспользуемся небольшим хаком. Отредактируем содержимое скрипта:

/usr/share/icingaweb2/modules/graphite/application/views/scripts/show/overview.phtml

Найдём в скрипте строки, определяющие перечень интервалов времени:

...
    '-15min' => '15 minutes',
    '-60min' => '1 hour',
    '-2hour' => '4 hours',
    '-1day' => '1 day',
...

И заменим их на то, что нам требуется, например так:

...
    '-15min' => '15 minutes',
    '-30min' => '30 minutes',
    '-60min' => '1 hour',
    '-2hour' => '2 hours',
    '-3hour' => '3 hours',
    '-6hour' => '6 hours',
    '-9hour' => '9 hours',
    '-1day' => '1 day',
    '-3day' => '3 days',
    '-7day' => '7 days',
    '-10day' => '10 days',
...

Кстати, тем самым мы дополнительно исправим имеющуюся в оригинальном наборе ошибку (2hour <> 4 hours). Обновим веб-страницу и убедимся, в том, что список расширился и графики успешно строятся за настроенные периоды времени

Обратите внимание на то, что сделанные изменения могут исчезнуть после очередного обновления через git fetch/checkout.

Если же требуется посмотреть графики за более длительные периоды времени или за интервалы времени, которые не описаны представленными шаблонами, то мы всегда можем перейти на ранее упомянутый веб-сайт Graphite-Web и выполнить построение любых графиков там. 

 

Изменяем размер графиков по умолчанию

Размер по умолчанию для всех графиков, на мой взгляд, слишком маленький, - 300*150. Это приводит к "слипанию" дат X-оси на графиках в случае выбора некоторых шаблонных периодов. Например так будет выглядеть график за период 2 часа:

Согласитесь, это не очень информативно.

Текущая реализация модуля не позволяет через какие-то переменные конфигурационного файла модуля настраивать размер формируемых графиков, поэтому для исправления ситуации воспользуемся ещё одним небольшим хаком. Отредактируем содержимое скрипта:

/usr/share/icingaweb2/modules/graphite/application/controllers/ShowController.php

Найдём с крипте функцию handleGraphParams()…

...
    protected function handleGraphParams()
    {
        if ($this->handledGraphParams === false) {
            $this->handledGraphParams = true;
            $view = $this->view;
            $view->start  = $this->params->shift('start', '-1hours');
            $view->width  = $this->params->shift('width', '300');
            $view->height = $this->params->shift('height', '150');
        }

        return $this;
    }
...

Заменим в этой функции значения width и height, на что-то более подходящее нам, например так:

...
            $view->width  = $this->params->shift('width', '400');
            $view->height = $this->params->shift('height', '200');
...

После этого обновим соответствующую веб-страницу на консоли Icinga Web 2 и проверим результат:

Ну вот, теперь уже график выглядит более вменяемо.

И опять же, обратите внимание на то, что сделанное изменение может исчезнуть после очередного обновления через git fetch/checkout. 

 

Манипуляции с хранимыми данными метрик

Хранится данные метрик будут в wsp-файлах в каталоге /var/lib/graphite/whisper (определяется параметром STORAGE_DIR в /etc/graphite/local_settings.py). После интеграции Graphite в Icinga Web 2 в указанном каталоге создан подкаталог icinga2, внутри которого метрики разложены по подкаталогам, соответствующим именам Хостов Icinga. Заглянем туда и посмотрим сколько Graphite зарезервировал места под хранимые данные метрик:

# du -shc /var/lib/graphite/whisper/icinga2/*

54M     /var/lib/graphite/whisper/icinga2/KOM-AD01-APP30_holding_com
49M     /var/lib/graphite/whisper/icinga2/KOM-AD01-APP31_holding_com
...
57M     /var/lib/graphite/whisper/icinga2/KOM-AD01-VM33_holding_com
57M     /var/lib/graphite/whisper/icinga2/KOM-AD01-VM34_holding_com
1.1G    total

При увеличении количества собираемых метрик и/или глубины их хранения стоит заранее побеспокоиться о дополнительном дисковом пространстве, используемом данным каталогом.

***

В процессе настройки и подгонки системы "под себя" может получиться так, что первично указанные сроки хранения метрик (значения retention в /etc/carbon/storage-schemas.conf) могут претерпеть изменения. Это не приведёт к тому, что в wsp-файлы, в которых хранятся метрики, начнут использовать новые периоды хранения, ибо, как я понял, информация о сроках хранения записываться в wsp-файл при его создании и потом не меняется. В системе можно найти целый ряд утилит с именами типа /usr/bin/whisper-*, которые позволяют проделывать с wsp-файлами разные фокусы. Например, с помощью утилиты whisper-info можно посмотреть с какими настройками работает тот или иной файл хранения метрик:

# whisper-info /path/to/metric/storage/file/value.wsp

Также есть возможность и явно задавать нужные значения retention непосредственно в wsp-файле. Однако учитывая то, что таких файлов множество и для них мы, скорей всего, будем использовать агрегацию, более правильным будет использовать пересоздание этих файлов (если конечно вопрос исторически накопленных данных не стоит принципиально). Эксперименты показали, что удалять wsp-файлы можно и на горячую, и при этом вроде бы никакая из служб не сходит с ума. Но думаю, что лучше всё же сделать это через остановку carbon-cache:

# service carbon-cache stop
# rm -R /var/lib/graphite/whisper/icinga2/*
# service carbon-cache start

После удаления структура каталогов и файлов будет воссоздана автоматически при записи свежих метрик.

 

Ограничение доступа к веб-сайту Graphite-Web

Оставлять веб-узел с метриками Graphite в открытом виде не самая лучшая идея, поэтому ограничим доступ хотя бы простой Basic аутентификацией. Сгенерируем файл с пользователем и паролем: 

# htpasswd -c /etc/graphite/web-access secretruser

New password: {зададим пароль пользователя secretruser}
Re-type new password: {повторим ввод пароля}
Adding password for user secretruser

При создании пароля желательно не увлекаться спецсимволами, так как в дальнейшем нам потребуется использовать этот пароль в составе URL.

Ограничим права доступа к файлу с учётными данными:

# chown www-data:www-data /etc/graphite/web-access
# chmod 440 /etc/graphite/web-access

Изменим файл конфигурации сайта Graphite-Web /etc/apache2/sites-available/graphite-web.conf, добавив фрагмент требования аутентификации в самом начале секции VirtualHost: 

<VirtualHost *:8000>
   <Location "/">
      AuthType Basic
      AuthName "Private Area"
      AuthUserFile /etc/graphite/web-access
      Require valid-user
   </Location>
...
</VirtualHost>

Перезагружаем конфигурацию веб-сервера: 

# service apache2 reload

Перейдём к веб-сайту Graphite-Web и убедимся в том, что подключиться к нему теперь можно только указав учётные данные ранее созданного пользователя secretruser.

Теперь нам только остаётся подправить конфигурационный файл модуля /etc/icingaweb2/modules/graphite/config.ini, в котором мы ранее указывали расположение Graphite-Web, добавив в URL имя пользователя и пароль:

[graphite]
web_url = http://secretruser:Pr1vatePass0rD@127.0.0.1:8000

После этого перейдём в веб-консоль Icinga Web 2 и убедимся в том, что графики отображаются на веб-страницах без проблем.

***

На этом пока всё. Позже в отдельной заметке рассмотрим процесс пристраивания новомодного веб-интерфейса Grafana к созданной нами конфигурации Graphite.

 

Дополнительные источники информации:

Опубликовано в :  Debian , Free software , Icinga , Linux , Open Source
Метки :  , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Всего комментариев: 3 Комментировать

  1. Олег /

    при попытке graphite-manage syncdb следует ошибка команда не обнаружена
    в интернетах утверждают , что с django 1.7 команды syncdb больше нет и надо использовать migration
    с migration я не смог разобраться пока. в любом случае не создается пользователь и нет запросов от бд

    Ответить
    1. Алексей Максимов / Автор записи

      Я от модуля graphite отказался в пользу модуля grafana. Есть отдельная статься про этот модуль. Правда она уже тоже немного устарела.

      Ответить
    2. Вячеслав /

      Установите старую версию django:

      # apt-get install -y python-pip python-mysqldb python-pymysql

      # pip install "django==1.4"

      Ответить

Добавить комментарий