которые позволяют на регулярной основе накапливать информацию о различных метриках производительности BIEE
(кол-во активных сессий; среднее время выполнения аналитического запроса; кол-во неудачных попыток аутентификации; средняя пропускная способность пулов соединений с БД и т.д.);
а также данные о доступности (работоспособности) критически важных узлов стека BIEE (наличие процессов BIServer/BIPresentationServer; активность листенеров на портах; статус веб-приложений WLS и т.д.).
В первую очередь эти настройки необходимы для проактивного реагирования на возникающие проблемы (проблемы начинают решаться в момент их наступления, а не в момент получения звонка от разгневанных пользователей).
Во вторую очередь система мониторинга удобна для решения задач оптимизации BIEE (позволяет анализировать в ретроспективе производительность системы в привязке к различным действия: правкам метаданных BI, тюнингу параметров BI и т.д.).
Настройка наблюдаемого сервера
Наблюдаемый сервер должен содержать установленное ПО агента zabbix.
Предварительные настройки
1. Для корректной работы большинства скриптов мониторинга необходимо наличие установленной программы zabbix_sender
sudo yum install zabbix-sender
2. Для корректной работы python-скрипта по сбору и трансформации метрик производительности компонент BI необходимо наличие установленного модуля lxml
sudo yum install python-lxml
3. Для возможности получения метрик работы nginx следует в конфиг-файле nginx задать путь доступа до html-страницы со значениями метрик (т.к. предполагается обращение к странице с локального адреса, то разрешения выдаются только для 127.0.0.1)
location = /nginx_stat {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
Конфигурация агента zabbix
Предполагается, что директория с конфиг-файлами zabbix-агента находится в папке /etc/zabbix
И сам конфигурационный файл - /etc/zabbix/zabbix_agentd.conf
1. Необходимо задать адрес сервера zabbix в параметре Server
2. Для обеспечения выполнения сравнительно долгих скриптов (используемых для низкоуровневного обнаружения - LLD) следует задать значение параметра Timeout равным 30 (также рекомендую выставить это значение и для сервера zabbix)
3. Следует перечислить следующие скрипты в разделе UserParameter (либо напрямую в конфиге агента, либо в дочернем конфиге - /etc/zabbix/zabbix_agentd.d/userparameter_bi.conf):
UserParameter=nginx[*],sudo /usr/local/scripts/zabbix/bi/nginx_stat.sh "$1" UserParameter=bi_check_opmn_alive[*],sudo /usr/local/scripts/zabbix/bi/bi_check_opmn_alive.sh "$1" UserParameter=bi_collect_metrics[*],sudo /usr/local/scripts/zabbix/bi/bi_collect_metrics.sh "$1" "$2" "$3" UserParameter=wls_get_servers[*],sudo /usr/local/scripts/zabbix/bi/wls_get_servers.sh "$1" "$2" "$3" "$4" UserParameter=wls_get_apps[*],sudo /usr/local/scripts/zabbix/bi/wls_get_apps.sh "$1" "$2" "$3" "$4" UserParameter=wls_get_data_sources[*],sudo /usr/local/scripts/zabbix/bi/wls_get_data_sources.sh "$1" "$2" "$3" "$4" UserParameter=wls_check_server[*],sudo /usr/local/scripts/zabbix/bi/wls_check_server.sh "$1" "$2" "$3" "$4" "$5" UserParameter=wls_check_apps[*],sudo /usr/local/scripts/zabbix/bi/wls_check_apps.sh "$1" "$2" "$3" "$4" "$5" "$6" UserParameter=wls_check_data_sources[*],sudo /usr/local/scripts/zabbix/bi/wls_check_data_sources.sh "$1" "$2" "$3" "$4" "$5" "$6"
bash-скрипты мониторинга
Как видно из предыдущего пункта - все скрипты мониторинга находятся в папке /usr/local/scripts/zabbix/bi
Если этой папки нет - ее следует создать. И скопировать в нее все файлы их архива zabbix_scripts.zip
Затем следует выдать привилегии на исполнение скриптов:
cd /usr/local/scripts/zabbix/bi chmod a+x ./*.sh
Далее приводится список скриптов и описание их предназначения:
| Скрипт |
Назначение |
Параметры |
nginx_stat.sh |
Bash-скрипт получения основных метрик nginx |
METRIC – значение метрики nginx (active|accepts|handled|requests|reading|writing|waiting) |
bi_check_opmn_alive.sh |
Bash-скрипт проверки существования и доступности процесса OPMN, используемого BIEE |
BI_OPMNCTL_PATH - путь до opmnctl стека BI (/opt/oracle/product/obiee/instances/instance1/bin/opmnctl) |
bi_collect_metrics.sh |
Bash-скрипт, вызывающий python-скрипт bi_collect_metrics.py и отправляющий с помощью zabbix_sender сформированный текстовый файл со значениями метрик производительности компонент BI |
BI_OPMNCTL_PATH - путь до opmnctl стека BI (/opt/oracle/product/obiee/instances/instance1/bin/opmnctl) ZBX_AGENT_HOSTNAME - имя наблюдаемого сервера zabbix (для сопоставления метрик с хостом сервера ZAbbix) ZBX_SERVER - сервер zabbix, следует указывать явно для работы zabbix_sender |
bi_collect_metrics.py |
Python-скрипт, вызывающий BI OPMN с опцией дампа значений метрик производительности. Полученные метрики записываются в текстовый файл. |
|
wls_check_apps.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_check_apps.py и отправляющий с помощью zabbix_sender данные о текущем статусе всех веб-приложений WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) ZBX_AGENT_HOSTNAME - - имя наблюдаемого сервера zabbix (для сопоставления метрик с хостом сервера ZAbbix) ZBX_SERVER - сервер zabbix, следует указывать явно для работы zabbix_sender |
wls_check_apps.py |
Jython(WLST)-скрипт, формирующий файл со статусами всех веб-приложений WLS. |
|
wls_check_data_sources.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_check_data_sources.py и отправляющий с помощью zabbix_sender данные о текущем статусе всех источников данных WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) ZBX_AGENT_HOSTNAME - - имя наблюдаемого сервера zabbix (для сопоставления метрик с хостом сервера ZAbbix) ZBX_SERVER - сервер zabbix, следует указывать явно для работы zabbix_sender |
wls_check_data_sources.py |
Jython(WLST)-скрипт, формирующий файл со статусами всех JNDI/JDBC источников данных WLS. |
|
wls_check_server.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_check_servers.py и отправляющий данные о текущем статусе заданного домена WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) SERVER_NAME - имя проверяемого домена (AdminServer/bi_server1) |
wls_check_server.py |
Jython(WLST)-скрипт, проверяющий статус заданного домена WLS. |
|
wls_get_apps.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_get_apps.py и возвращающий JSON с данными о всех веб-приложениях WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) |
wls_get_apps.py |
Jython(WLST)-скрипт, используемый для низкоуровневого обнаружения zabbix, и формирующий список всех веб-приложений WLS. |
|
wls_get_data_sources.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_get_data_sources.py и возвращающий JSON с данными обо всех источниках данных WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) |
wls_get_data_sources.py |
Jython(WLST)-скрипт, используемый для низкоуровневого обнаружения zabbix, и формирующий список всех источников данных WLS. |
|
wls_get_servers.sh |
Bash-скрипт, вызывающий wlst-скрипт wls_get_servers.py и возвращающий JSON с данными о доменах WLS. |
FMW_HOME - путь до базового каталога BI Fusion Middleware (/opt/oracle/product/obiee) WLS_USER - логин администратора WLS (weblogic) WLS_PW - пароль администратора WLS WLS_URL - URL доступа к основному серверу WLS (t3://localhost:7001) |
wls_get_servers.py |
Jython(WLST)-скрипт, используемый для низкоуровневого обнаружения zabbix, и формирующий список всех доменов WLS. |
Привилегии sudo
Для корректной работы скриптов необходим их запуск с привилегиями root'а.
Так как чаще всего процессы агента zabbix выполняются под учетной записью zabbix,
то необходимо настроить привилегии вызова этих скриптов в файле /etc/sudoers
Также следует учитывать, что для пользователя zabbix должна быть задана возможность работы без вывода на экран и без ввода пароля.
Далее приводится часть файла /etc/sudoers:
## Zabbix monitoring Defaults:zabbix !requiretty zabbix ALL=(root) NOPASSWD: /usr/local/scripts/zabbix/bi/*.sh
Если процессы агента zabbix работают под учетной записью root,
то следует изменить код вызова скриптов в разделе UserParameters конфига агента - убрать sudo
Настройка сервера zabbix
Импорт шаблонов мониторинга
Сбор метрик производительности и доступности компонент разбит логически на несколько шаблонов zabbix.
Это связано с тем, что потенциально одна среда BI может быть разнесена на несколько физических серверов.
А также для упрощения доступа к большому объему метрик.
Template BI alive - Шаблон с метриками доступности основных процессов (в точ числе доступности прослушиваемых портов) критически важных компонентов BI
Template BI perf - Шаблон с метриками производительности компонентов BI (BIServer, BIPresentationServer)
Template WLS alive - Шаблон с метриками доступности доменов, веб-приложений и источников данных WeblogicServer
Template Nginx - Шаблон с метриками производительности работы веб-сервера nginx
Перед импортом шаблонов на сервер zabbix следует создать новую Host group с названием OBIEE Servers - именно в эту группу будут импортироваться шаблоны.
Привязка шаблонов к наблюдаемым серверам
Импортированные шаблоны следует связать с наблюдаемым сервером(/ами) BIEE.
Причем если одна среда BI расположена на 2-х физических серверах - WLS на одном сервере, а компоненты BI на другом - то и шаблоны нужно назначать соответственно на каждый отдельный физический сервер.
Задание макросов для шаблонов и хостов
Для унификации работы скриптов, осуществляющих мониторинг на наблюдаемых серверах, часть настроек вынесена в параметры скриптов.
И в качестве параметров скриптов выступают макросы zabbix. Все используемые макросы заданы в свойствах шаблонов.
Но возможны ситуации, когда шаблон назначается на несколько различных наблюдаемых серверов BI, настройки которых различаются (например, путь до opmnctl BI).
В этом случае необходимо создать макрос на уровне хоста с тем же именем, что и макрос на уровне шаблона.
Приоритет при выполнении отдается макросу на уровне хоста.
Далее приводится список макросов в разрезе шаблонов:
Шаблон |
Макрос |
Значение по умолчанию |
Template BI alive |
{$BI_NQSCHEDULER_PORT} |
9705 |
{$BI_NQSCLUSTER_PORT} |
9706 |
|
{$BI_NQSSERVER_PORT} |
9703 |
|
{$BI_SAWSERVER_PORT} |
9710 |
|
{$BI_OPMNCTL_PATH} |
/opt/oracle/product/obiee/instances/instance1/bin/opmnctl |
|
Template BI perf |
{$BI_OPMNCTL_PATH} |
/opt/oracle/product/obiee/instances/instance1/bin/opmnctl |
{$BI_ZBX_SERVER} |
zabbix-server-ip |
|
Template WLS alive |
{$FMW_HOME} |
/opt/oracle/product/obiee |
{$WLS_USER} |
weblogic |
|
{$WLS_PW} |
Admin123 |
|
{$WLS_URL} |
t3://localhost:7001 |
|
{$WLS_ZBX_SERVER} |
zabbix-server-ip |
|
Template Nginx |
{$NGINX_CON_NUM} |
100 |
{$NGINX_REQ_NUM} |
500 |
Настройка частоты мониторинга
За частоту мониторинга всех метрик шаблонов отвечает ограниченного кол-во активных элементов данных zabbix:
Template BI alive - все элементы данных запускаются самостоятельно - каждые 60 секунд.
Template BI perf - за запуск отвечает элемент данных BI: Start collect metrics приложения BI: !START! - каждые 60 секунд.
Template WLS alive - за запуск сбора состояний веб-приложений и источников данных отвечают элементы данных WLS: Start applications checks и WLS: Start data sources checks (приложение WLS: !START!) - каждые 300 секунд;
Частота сбора состояний наблюдаемых доменов WLS задается в прототипе элемента данных WLS: Server "{#WLS_SERVER}" status правила обнаружения Discovery WLS servers - каждые 300 секунд.
При необходимости изменения частоты мониторинга можно использовать функцию mass update элементов данных zabbix.
Скрины мониторинга
Используемые шаблоны содержат следующие скрины:
Шаблон |
Скрин |
Template BI alive |
BI availability |
Template BI perf |
BI nqsserver performance |
BI sawserver performance |
|
BI processes performance |
|
Template Nginx |
Nginx performance |
Для шаблона Template WLS alive скрины не созданы, так как элементы данных шаблона формируются с помощью низкоуровневого обнаружения.
Что не позволяет отображать их значения на одном графике.
Если нет активных триггеров, оповещающих администратора Zabbix о каких-либо нарушениях, то нет возможности отобразить все скрины, полученные из шаблонов, для хоста.
Поэтому целесообразно вручную создать нужные скрины. Либо импортировать готовые предварительно отредактировав их в "Блокноте".
XML-представление набора готовых скринов под конкретный хост - biserver_screens.xml
В данном файле следует заменить все вхождения biserver на имя того хоста, скрины к которому нужно создать. Затем импортировать его.
Триггеры и уведомления
Используемые шаблоны содержат следующие триггеры:
Шаблон |
Триггер |
Уровень |
Примечание |
Template BI alive |
BI: nqscheduler is not running on {HOST.NAME} |
Disaster |
|
BI: nqscheduler port ({$BI_NQSCHEDULER_PORT}) is not listening on {HOST.NAME} |
Disaster |
||
BI: nqsclustercontroller is not running on {HOST.NAME} |
Disaster |
||
BI: nqsclustercontroller port ({$BI_NQSCLUSTER_PORT}) is not listening on {HOST.NAME} |
Disaster |
||
BI: nqsserver is not running on {HOST.NAME} |
Disaster |
||
BI: nqsserver port ({$BI_NQSSERVER_PORT}) is not listening on {HOST.NAME} |
Disaster |
||
BI: OPMN is not running on {HOST.NAME} |
Disaster |
||
BI: sawserver is not running on {HOST.NAME} |
Disaster |
||
BI: sawserver port ({$BI_SAWSERVER_PORT}) is not listening on {HOST.NAME} |
Disaster |
||
Template WLS alive |
WLS: Server "{#WLS_SERVER}" not running |
Disaster |
Триггер-прототип, создается для каждого найденного домена WLS |
WLS: Application "{#WLS_APP}" not running |
Average |
Триггер-прототип, создается для каждого найденного веб-приложения WLS |
|
WLS: Data source "{#WLS_DS}" not running |
Average |
Триггер-прототип, создается для каждого найденного источника данных WLS |
|
На все триггеры с уровнем Disaster следует создать уведомления с рассылкой на емейл администраторам серверов BI.
Комментариев нет:
Отправить комментарий