logo

19 июн. 2015 г.

BI 11g: мониторинг доступности и производительности с помощью Zabbix

Данная статья содержит описание настроек на серверах с установленным Oracle BIEE, а также на сервере мониторинга zabbix,
которые позволяют на регулярной основе накапливать информацию о различных метриках производительности 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.

Комментариев нет:

Отправить комментарий