Интеграция Ubuntu Landscape с Opsview Enterprise

Недавно мы изучали инструменты Ubuntu, упомянутые в ключевой речи Openstack в этом году Марка Шаттлворта – особенно интересовал Ubuntu Landscape; их инструмент управления системами и серверами, который позволяет обновлять и управлять тысячами серверов Ubuntu из одной консоли.

Прелесть Landscape в том, что если у вас есть 1000 серверов Ubuntu, вы можете обновлять программное обеспечение и устанавливать патчи на ходу из одного представления, вы даже можете щелкнуть на каждом сервере, чтобы получить инвентаризацию аппаратного и программного обеспечения, увидеть отчеты о том, какие процессы используют ЦП и т. д., все это из одного инструмента.

Интересный момент с точки зрения Opsview заключается в том, что он содержит вкладку “мониторинг” для каждого устройства. Эта вкладка является элементарной, так как показывает только основы мониторинга (использование ресурсов, пропускная способность сети и т. д.), как показано ниже:

Предполагается, что эта информация собирается / опрашивается через клиент Landscape, работающий на сервере Ubuntu, и использует обычные выходные данные “нагрузки” и т. д., которые обрабатываются и редактируются. Эта деталь довольно базовая, однако, поэтому маловероятно, что многие люди будут использовать это как единственный инструмент для мониторинга, в отличие от Opsview – это скорее полезное дополнение, позволяющее вам проверить состояние ‘X’, пока вы находитесь в панели управления Landscape.

Однако это заставило нас задуматься – что если мы все же сможем использовать Opsview в качестве нашего основного инструмента мониторинга, который позволяет клиентам входить в систему, чтобы просматривать свои системы через панель управления, отправлять отчеты по электронной почте, отправлять SMS-уведомления и т. д., но интегрировать эти данные Opsview в панель управления Landscape – так что можно щелкнуть на “Server100” в Opsview и “Server100” в Landscape и увидеть одни и те же графики. Это позволит нам видеть состояние сервера, независимо от того, какой инструмент мы используем.

Чтобы сделать это в Landscape, на самом деле довольно просто (как только вы привыкнете к нюансам системы). Во-первых, из нашей главной консоли мы должны перейти к “Пользовательским графикам”, как показано ниже:

Далее мы должны щелкнуть на “Добавить пользовательский график”, что откроет страницу, как показано ниже (мы сэкономили время, уже заполнив поле):

Поскольку может быть трудно читать на изображении, “код” приведен ниже:

#!/bin/bash 
cd /usr/local/nagios/bin 
./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview' | grep value | sed -e 's/value => //g' | sed -e 's/,//g' | sed 's/ //g'

Это в основном использует команду opsview_rest для подключения к системе мониторинга Opsview и получения метрики “max_used_connections” с хоста “opsview”, а затем выполняет некоторые операции редактирования/фильтрации, чтобы предоставить нам значение, которое можно отобразить, т. е. “28”, а не “value=>28;21;s…”, что не нравится Ubuntu :)

Что это позволяет нам сделать, так это добавить нашу систему мониторинга Opsview в качестве хоста Landscape и позволить нам мониторить состояние системы мониторинга через Landscape, наряду с состоянием любого другого хоста, который мониторится системой Opsview – и любой проверки службы, выполняемой против него. Мы можем получить эту информацию, выполнив команду:

opsview_rest --username=admin --password=initial --pretty GET /rest/status/performancemetric/?hostname=opsview

Где “?hostname” – это хост, данные о производительности которого мы пытаемся просмотреть. После того как это настроено и сохранено в соответствии с предыдущим скриншотом, нам нужно установить “запускать от имени пользователя:” (либо root, либо другого пользователя) и “Название оси Y” (секунды, подключения к БД, температура и т. д.). После этого мы нажимаем “Сохранить”, и это будет применено ко всем хостам (если вы отметили этот флажок).

Затем, через день или около того, мы можем перейти к хосту и просмотреть вкладку “мониторинг” и увидеть наши пользовательские графики:

…и вот как мы можем интегрировать Opsview с Ubuntu Landscape.

Задача

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

./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

..что использует “opsview_rest” через bash и выполняется локально. Идеально было бы запускать это откуда угодно (т. е. с сервера, который мы управляем в Landscape), но все же запускать против нашей системы Opsview. Последнее легко; мы можем добавить префикс, как показано ниже:

./opsview_rest *--url-prefix=monitoringtool.company.com* --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

…но это все еще зависит от команды “opsview_rest”, которая, очевидно, должна быть доступна на локальной машине, так как пользовательские графики запускают скрипт локально на управляемой системе Ubuntu Landscape. И также это раскрывает имя пользователя и пароль на хост-сервере, т. е. ваш веб-сервер теперь имеет данные для входа в Opsview. Однако мы можем ограничить эту проблему, предоставив этой роли очень специфический доступ только для чтения и только к нескольким конкретным элементам.

Что нам нужно, так это возможность иметь хост, который мониторится Opsview и управляется Ubuntu Landscape, чтобы иметь возможность запрашивать Opsview через REST API о своем собственном состоянии – чтобы он мог предоставить эту информацию обратно в Landscape для графиков. Однако мы не можем распространять opsview_rest из-за проблем с Perl, зависимостями и т. д., так что же мы можем сделать?

Единственный элемент, который, похоже, работает или удовлетворяет нашим критериям, – это использовать check_nrpe “нетрадиционным способом”. Что я имею в виду под этим, так это то, что традиционно NRPE является клиентской программой, которую Opsview запрашивает для получения информации – т. е. “Насколько загружен ваш ЦП? Насколько полны ваши диски?”. Эти значения затем передаются обратно в Opsview и хранятся для отчетов, панелей управления и т. д. и используются для оповещения.

Что мы обнаружили в этом примере, так это то, что мы могли установить клиент NRPE (агент Opsview) на управляемом/мониторируемом хосте и использовать его для запроса NRPE, работающего на главном сервере Opsview.

На этом главном сервере Opsview мы укажем наши команды NRPE в “ /usr/local/nagios/etc/nrpe_local/overrides.cfg” (этого файла не существует, вам нужно создать его) и добавить строки, как показано ниже:

############################################################################
# Дополнительный файл конфигурации NRPE для Opsview
############################################################################
check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl $ARG1$ $ARG2$

Где “get_rest” – это команда, которую мы будем вызывать удаленно, а все, что “восточнее знака равенства”, – это фактическая команда, которая выполняется локально.

Как видно из вышеизложенного, мы запускаем что-то под названием “landscape_monitor.pl” – Perl-скрипт, который мы написали, чтобы взять аргумент хоста (т. е. $ARG1$ может быть “server00156” или “networkswitch-X624” в Opsview (имя хоста)). Это означает, что вместо того, чтобы создавать check_command для каждого, т. е.:

check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl server1 
check_command[get_rest2]=/usr/local/nagios/bin/landscape_monitor.pl server2 
check_command[get_rest3]=/usr/local/nagios/bin/landscape_monitor.pl server3

Мы можем просто использовать $ARG1$ и заставить наш Perl-скрипт ожидать его. Далее у нас есть сам скрипт (это использует JSON и IPC, поэтому нам нужно установить следующие пакеты на системе Opsview: libipc-run-perl libjson-any-perl)

#!/usr/bin/perl Shell
use strict;
use warnings;
use IPC::Run qw(run);
use JSON; 
my $hostname = $ARGV[0] || ''; 
my $perf_metric = $ARGV[1] || '';
my @cmd = qw(/usr/local/nagios/bin/opsview_rest --username admin --password initial --data-format json GET);
push @cmd, '/rest/status/performancemetric?order=metricname&order=hostname&metricname='. $perf_metric .'&hostname='. $hostname; 
run \\@cmd, \\undef, \\my $out;
my $data = decode_json($out);
print $data->{list}->[0]->{value};

Как мы видим выше, мы берем переменную (имя хоста) и добавляем ее к команде opsview_rest, которую мы строим. Мы также берем производственную метрику, и после выполнения построенной команды мы выводим вывод команды в формате JSON – “23” в нашем примере. Это избавляет нас от необходимости фильтровать и обрабатывать его, чтобы получить фактическое значение, которое может использовать Landscape.

Итак, как только вы добавили свой скрипт “landscape_monitor.pl” в /usr/local/nagios/bin/, и установили права доступа / владельца – вы можете создать файл overrides.cfg и добавить строку, как указано выше.

Наконец, запустите NRPE на мониторируемом/управляемом устройстве – и мы готовы к REST, как показано ниже.

Сценарий

Этап 1: У нас есть стандартная среда мониторинга; Opsview мониторит “Сервер A” и запрашивает информацию, такую как статистика БД, статистика apache и т. д., и отображает эту информацию на панелях управления для пользователей через GUI, отправляет электронные письма/текстовые сообщения, оповещения и т. д., когда возникают проблемы.

Этап 2: Теперь, когда Opsview собирает тысячи метрик и статистики с наших серверов, мы можем использовать REST API, чтобы запрашивать эти статистические данные с мониторируемого сервера, т. е. “Сервер A”, используя вышеупомянутый perl-скрипт. Для этого мы просто выполняем команды, как показано ниже:

./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections

ubuntu@serverA:/usr/local/nagios/libexec$ ./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections  
23  
ubuntu@serverA:/usr/local/nagios/libexec$

Используя check_nrpe на ServerA и передавая наше имя хоста, т. е. “ServerA”, мы можем увидеть значение max_db_connections, которое Opsview имеет для нас.

Этап 3: Поскольку теперь у нас есть возможность для мониторируемого устройства знать свои собственные метрики – возможности того, что мы можем сделать, безграничны. В нашем примере мы просто хотим использовать Landscape для графического отображения наших метрик, собранных Opsview, чтобы мы могли иметь доступ к графикам “с одного взгляда” в нашей системе Landscape, а также иметь возможность углубиться в Opsview, чтобы увидеть отчеты / панели управления и более специфические элементы мониторинга. Однако ничто не мешает нам использовать эту технологию для интеграции Opsview с другими инструментами графического отображения и т. д.

Чтобы интегрировать это с Landscape, это очень просто. Нам просто нужно создать еще один “Пользовательский график”, как мы описали ранее в документе, и в текстовом поле добавить:

#!/bin/bash
cd /usr/local/nagios/bin
./check_nrpe –H opsviewserver –c get_rest -a servername max_used_connections

Наконец, мы применяем этот график к тому хосту, который мы хотим – и вуаля, теперь мы мониторим “максимальные подключения к БД“ сервера через Landscape. Затем мы можем на этом построить, изменить метрику и т. д., так что по сути вы можете видеть все метрики, собранные Opsview, из Ubuntu Landscape, RH Satellite и т. д.

Последний взгляд

Таким образом, теоретически у нас теперь есть следующий сценарий:

100 серверов Ubuntu, управляемых и обновляемых и т. д. Ubuntu Landscape.
100 серверов Ubuntu, мониторируемых и оповещаемых и т. д. Opsview Enterprise.

У нас будут хосты, добавленные как в Landscape, так и в Opsview, и мы будем использовать Opsview для более детального мониторинга, оповещения, отчетов, панелей управления, NetFlow и т. д., а затем извлекать особенно интересные метрики “с одного взгляда” на страницу этого хоста в Landscape.

Хост в Opsview

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

Хост в Landscape

У нас также есть хост в Landscape – из этого представления мы можем видеть актив (аппаратное обеспечение и т. д.), обновлять пакеты, видеть отчеты о состоянии системы и т. д. Мы также можем щелкнуть на “Мониторинг” и увидеть нашу информацию, собранную Opsview, “с одного взгляда”, из Landscape, как показано ниже:

(хотя это довольно малоиспользуемый сервер Apache! ^_^ ).

Попробуйте Opsview Enterprise ›

Попробуйте Ubuntu Landscape ›