Введение
После запуска АСР «Гидра» в промышленную эксплуатацию необходимо в обязательном порядке настроить мониторинг экземпляра БД АСР «Гидра».
Контроль должен отслеживать следующие группы параметров:
- Базовые параметры сервера АСР (load avg, использование CPU и RAM, I/O массива, количество процессов, свободное пространство на дисковом массиве).
- Показатели экземпляра БД (количество сессий, текущая нагрузка, состояние SGA и т.д.).
- Состояние заданий АСР «Гидра».
- Контроль количества нетарифицированных CDR и дату последней загрузки.
- Количество строк в жизненноважных таблицах EX_CALL_DATA_REC, EX_DATA_COLLECT, EX_TRAFFIC_COLLECT_C, SD_GOOD_MOVES.
Для мониторинга АСР «Гидра» можно использовать любую распространенную систему, которая позволяет получать данные с помощью скриптов, запускаемых из командной строки. Наиболее популярными системами мониторинга среди российских операторов связи являются бесплатные Zabbix и Nagios.
Контроль выполнения заданий системы
Чтобы настроить контроль выполнения заданий АСР «Гидра», можно воспользоваться одним из специально разработанных скриптов (1) либо hydra_monitoring.sh
Различаются 7 состояний:
Код | Состояние | Норма |
---|---|---|
1034 | В ожидании | Д |
2034 | Выполняется | Д |
3034 | К запуску | Д |
4034 | Блокировано | Н |
5034 | Удалено | Н |
6034 | Ошибка запуска | Н |
7034 | Не запущено | Д |
Не нормальными являются состояния, помеченные буквой Н. Исключение: задание, заблокированное принудительно.
Перечень заданий и их идентификаторы следует брать со страницы АСР Администрирование -> Задания - Назначенные задания.
Контроль рекомендуется вести по всем заданиям системы.
Контроль за сеансами выполнения заданий
Помимо мониторинга состояния заданий, описанного выше, важно следить за состоянием выполнения сеансов (запусков) задания. С помощью данного мониторинга возможно отслеживать не нормальные состояния завершения, а также длительное время выполнения заданий. Для получения информации по 10 последним сеансам задания следует использовать следующий SQL-запрос:
WITH JOB_SEANCES AS ( SELECT N_JOB_STATUS, VC_JOB_STATUS, D_START, D_FINISH, ROW_NUMBER() OVER (ORDER BY D_START DESC) N_ROW FROM SS_V_JOB_SEANCES WHERE N_JOB_ID = <num_N_JOB_ID>) SELECT * FROM JOB_SEANCES WHERE N_ROW <= 10;
где:
num_N_JOB_ID
— идентификатор задания.
Различаются 5 результатов выполнения (N_JOB_STATUS
в SQL-запросе выше):
Код | Состояние | Норма |
---|---|---|
-2 | Прервано | Н |
-1 | Выполняется | Д |
0 | Успех | Д |
1 | Предупреждение | Н |
2 | Ошибка | Н |
Не нормальными являются состояния, помеченные буквой Н.
В полях D_START
и D_FINISH
SQL-запроса возвращается дата начала и дата окончания запуска. Для выполняющихся заданий D_FINISH — NULL.
Перечень заданий и их идентификаторы следует брать со страницы АСР Администрирование -> Задания - Назначенные задания.
Контроль рекомендуется вести по всем заданиям системы.
Контроль табличных пространств
Необходимо мониторить состояние табличных пространств (tablespaces) БД. Нужную информацию даёт следующий SQL-запрос:
WITH TBLSP_TOTAL AS ( SELECT TABLESPACE_NAME, ROUND(SUM(BYTES)/(1024*1024)) ALLOCATED_MB, ROUND(SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES))/(1024*1024)) MAX_MB FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME UNION ALL SELECT TABLESPACE_NAME, ROUND(SUM(BYTES)/(1024*1024)) ALLOCATED_MB, ROUND(SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES))/(1024*1024)) MAX_MB FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME), TBLSP_FREE AS ( SELECT TABLESPACE_NAME, ROUND(SUM(BYTES)/(1024*1024)) FREE_MB FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME UNION ALL SELECT TABLESPACE_NAME, ROUND(FREE_SPACE/(1024*1024)) FREE_MB FROM DBA_TEMP_FREE_SPACE), TBLSP_USED AS ( SELECT TS.TABLESPACE_NAME TABLESPACE_NAME, NVL((TS.ALLOCATED_MB-FS.FREE_MB), 0) USED_MB, NVL(FS.FREE_MB, 0) FREE_MB, TS.ALLOCATED_MB TOTAL_MB, TS.MAX_MB TOTAL_MAX_MB FROM TBLSP_TOTAL TS, TBLSP_FREE FS WHERE FS.TABLESPACE_NAME(+) = TS.TABLESPACE_NAME) SELECT TABLESPACE_NAME "TABLESPACE", USED_MB "Used MB", FREE_MB "Free MB", TOTAL_MB "Total MB", TOTAL_MAX_MB "Total Max MB", ROUND(100*((TOTAL_MAX_MB-USED_MB)/TOTAL_MAX_MB)) "Pct. Free" FROM TBLSP_USED ORDER BY TABLESPACE_NAME;
В результате запроса получится таблица приблизительно следующего вида:
# | TABLESPACE | Used MB | Free MB | Total MB | Total Max MB | Pct. Free |
---|---|---|---|---|---|---|
1 | HYDRA | 22903 | 27555 | 50458 | 61492 | 63 |
2 | HYDRA_INDEX | 40621 | 6781 | 47402 | 94292 | 57 |
3 | SYSAUX | 1829 | 321 | 2150 | 32768 | 94 |
4 | SYSTEM | 14413 | 67 | 14480 | 32768 | 56 |
5 | TOOLS | 1 | 31 | 32 | 32 | 97 |
6 | UNDOTBS1 | 8445 | 29078 | 37523 | 65536 | 87 |
7 | USERS | 1 | 4 | 5 | 32768 | 100 |
Здесь особое внимание нужно уделить показателю Pct. Free для пространств HYDRA
и HYDRA_INDEX
. При слишком малых значениях его (менее 20%) необходимо автоматически информировать администратора о проблеме со свободным местом. В противном случае в БД, например, могут остановиться важные системные задания с такой подобной ошибкой:
Ошибка при запуске JB_DATA_COLLECT_PKG.EX_DATA_COLLECT_ACCOUNTING [ORA-01654: unable to extend index AIS_NET.EX_TRAFFIC_COL_C_FIRM_IDX by 8192 in tablespace HYDRA_INDEX]
Значение Total MB показывает фактически выделенное место под табличное пространство, а Total Max MB показывает максимально возможное место, которое СУБД разрешено захватить под данное пространство при его автоматическом расширении с ростом данных. Следует учитывать, что значение Total Max MB может быть больше объема доступного дискового пространства. Процент свободного места (Pct. Free) расчитывается на основании использованого места (Used MB) и максимально возможного (Total Max MB).
Контроль нетарифицированных телефонных звонков
Приведенный ниже запрос возвращает количество нетарифицированных телефонных звонков за последний час:
SELECT COUNT(*) FROM EX_V_CDR WHERE N_CDR_TYPE_ID = SYS_CONTEXT('CONST', 'CDR_TYPE_PhoneCall') AND N_CDR_STATE_ID = SYS_CONTEXT('CONST', 'CDR_Status_Finished') AND D_END >= SYSDATE - 1/24 AND (N_SUM_A IS NULL AND N_SUM_B IS NULL) AND N_DURATION_SEC != 0;
Нормой считается 0, т.е. полное отсутствие нетарифицированных звонков.
Мониторинг даты последней загрузки CDR
Следующий запрос показывает в какое время была произведена последняя загрузка CDR в АСР (его удобно использовать для анализа человеком):
SELECT DECODE(MAX(D_LOG_CREATE), NULL, 'Never', TO_CHAR(MAX(D_LOG_CREATE), 'DD.MM.YYYY HH24:MI:SS')) VC_LAST_LOAD_DATE FROM EX_V_CDR WHERE N_CDR_TYPE_ID = SYS_CONTEXT('CONST', 'CDR_TYPE_PhoneCall');
В результате выполнения запроса может быть либо точная дата в следующем виде:
LAST_DATE_LOAD ------------------- 29.01.2013 11:05:54
либо строка «Never», если в БД нет CDR:
LAST_DATE_LOAD ------------------- Never
В следующем запросе в качестве результата выводится либо время, когда была произведена последняя загрузка CDR (в секундах от даты загрузки до текущего момента времени), либо «-1», если в БД нет CDR. Данный запрос удобно применять для обработки в системах мониторинга:
SELECT DECODE(MAX(D_LOG_CREATE), NULL, -1, TO_CHAR((SYSDATE-MAX(D_LOG_CREATE))*(60*60*24), 'FM99999999999999990')) N_LAST_LOAD_SEC FROM EX_V_CDR WHERE N_CDR_TYPE_ID = SYS_CONTEXT('CONST', 'CDR_TYPE_PhoneCall');
Триггер для мониторинга следует настраивать в зависимости от интервала загрузки CDR или RADIUS-аккаунтинга.
Мониторинг даты последнего обновления сессий по передаче данных
Следующий запрос показывает дату последнего обновления сессий по передаче данных абонентов в АСР (его удобно использовать для анализа человеком):
SELECT DECODE(MAX(D_END), NULL, 'Never', TO_CHAR(MAX(D_END), 'DD.MM.YYYY HH24:MI:SS')) VC_LAST_UPDATE FROM EX_V_CDR WHERE N_CDR_TYPE_ID IN (SYS_CONTEXT('CONST', 'CDR_TYPE_PPP_WithCharging'), SYS_CONTEXT('CONST', 'CDR_TYPE_PPP_WOCharging'));
В результате выполнения запроса может быть либо точная дата в следующем виде:
LAST_DATE_LOAD ------------------- 26.11.2013 10:01:38
либо строка «Never», если в БД нет интернет-сессий:
LAST_DATE_LOAD ------------------- Never
В следующем запросе в качестве результата выводится либо время, когда было произведено последнее обновление сессий (в секундах от даты последнего обновления до текущего момента времени), либо «-1», если в БД нет сессий. Данный запрос удобно применять для обработки в системах мониторинга:
SELECT DECODE(MAX(D_END), NULL, -1, TO_CHAR((SYSDATE-MAX(D_END))*(60*60*24), 'FM99999999999999990')) N_LAST_UPDATE_SEC FROM EX_V_CDR WHERE N_CDR_TYPE_ID IN (SYS_CONTEXT('CONST', 'CDR_TYPE_PPP_WithCharging'), SYS_CONTEXT('CONST', 'CDR_TYPE_PPP_WOCharging'));
Триггер для мониторинга следует настраивать в зависимости от интервала загрузки RADIUS-аккаунтига.
Мониторинг даты последней успешной загрузки платежа
Следующий запрос показывает дату последней успешной загрузки платежа из внешних систем в АСР (его удобно использовать для анализа человеком):
SELECT DECODE(MAX(D_LOAD), NULL, 'Never', TO_CHAR(MAX(D_LOAD), 'DD.MM.YYYY HH24:MI:SS')) VC_LAST_LOAD FROM EX_V_PAYMENTS WHERE N_RATING = 100;
В результате выполнения запроса может быть либо точная дата в следующем виде:
LAST_DATE_LOAD ------------------- 25.03.2014 08:09:43
либо строка «Never», если в БД нет успешных платежей из внешних систем:
LAST_DATE_LOAD ------------------- Never
Для получения даты последней успешной загрузки в разрезе платежной системы необходимо пользоваться следующим запросом:
SELECT DECODE(MAX(D_LOAD), NULL, 'Never', TO_CHAR(MAX(D_LOAD), 'DD.MM.YYYY HH24:MI:SS')) VC_LAST_LOAD FROM EX_V_PAYMENTS WHERE N_RATING = 100 AND N_TO_ACCOUNT_ID = <num_N_TO_ACCOUNT_ID>;
где:
num_N_TO_ACCOUNT_ID
— идентификатор счета платежной системы у юридического лица оператора связи.
В следующем запросе в качестве результата выводится либо время, когда была произведена последняя успешная загрузка платежа (в секундах от даты последней загрузки до текущего момента времени), либо «-1», если в БД нет успешных платежей из внешних систем. Данный запрос удобно применять для обработки в системах мониторинга:
SELECT DECODE(MAX(D_LOAD), NULL, -1, TO_CHAR((SYSDATE-MAX(D_LOAD))*(60*60*24), 'FM99999999999999990')) N_LAST_LOAD_SEC FROM EX_V_PAYMENTS WHERE N_RATING = 100;
Аналогичный запрос в разрезе платежной системы:
SELECT DECODE(MAX(D_LOAD), NULL, -1, TO_CHAR((SYSDATE-MAX(D_LOAD))*(60*60*24), 'FM99999999999999990')) N_LAST_LOAD_SEC FROM EX_V_PAYMENTS WHERE N_RATING = 100 AND N_TO_ACCOUNT_ID = <num_N_TO_ACCOUNT_ID>;
где:
num_N_TO_ACCOUNT_ID
— идентификатор счета платежной системы у юридического лица оператора связи.
Триггер для мониторинга следует настраивать в зависимости от интенсивности поступления платежей.
Контроль выполнения событий
Приведенный ниже запрос возвращает количество ошибок и предупреждений в очереди событий за текущий час:
SELECT COUNT(*) FROM SS_V_EVENTS_QUEUE WHERE N_EVENT_STATE_ID IN (SYS_CONTEXT('CONST', 'EVENT_QUE_STATE_Warning'), SYS_CONTEXT('CONST', 'EVENT_QUE_STATE_Error')) AND D_ACK >= TRUNC(SYSDATE, 'HH');
Нормой считается 0, т.е. полное отсутствие ошибок и предупреждений.
Проверка корректности репликации
Для проверки репликации необходимо выполнить следующий запрос на обеих БД от пользователя с правами SYSDBA (иначе на standby сервере он не выполнится).
select max(sequence#) from v$log_history;
Результат на обоих серверах должен быть одинаковым. Допускается отличие на 1-2 версии, из-за задержки с копированием.
Для настройки мониторинга репликации в /etc/sudoers необходимо добавить возможность пользователя hzabbix выполнять oracle скрипт, который будет подключаться к БД под SYSDBA.
zabbix ALL=(oracle) NOPASSWD:/etc/zabbix-agent/monrep.sh
Запуск скрипта
zabbix@hydra ~ $ sudo -u oracle /etc/zabbix-agent/monrep.sh
Скрипт monrep.sh с запросом на получения max(sequence#)
#!/bin/bash . /etc/profile . /etc/environment export ORAENV_ASK=NO . oraenv > /dev/null sql="select max(sequence#) from v\$log_history;" echo -e $sql | sqlplus -s / as sysdba
Контроль количества строк в таблицах
Контроль количества строк в таблицах следует осуществлять в обязательном порядке, т.к. при разрастании количества строк в некоторых таблиц в системе могут возникнуть серьезные проблемы с производительностью. При этом проблемы обнаруживаются, как правило, уже когда в следствие некорректной настройки АСР число строк в таблицах сильно переваливает за допустимые пределы, и произвести удаление избыточных данных в короткие сроки физически невозможно.
Пример запроса на получение количества строк в таблице:
SQL> SELECT COUNT(*) FROM SD_GOOD_MOVES;
Таблица пороговых значений
Таблица | Назначение | Порог |
---|---|---|
EX_CALL_DATA_REC | CDR и PPP-сессии | 15 миллионов |
EX_DATA_COLLECT | Трафик по PPP-сессиям | среднее количество завершенных PPP-сессий в месяц, умноженное на количество классов трафика. Например, для 500 тыс. сессий в месяц и 4-х классов трафика, участвующих в сборе статистики (локальный трафик вх. и исх., интернет-трафик вх. и исх.), порог будет равен: |
EX_TRAFFIC_COLLECT_C | Неучтенный трафик | 2 миллиона |
SD_GOOD_MOVES | Состав инвойсов и счетов | 15 миллионов |
SS_SESSION_LOGS | Сессии по работе с системой | 5 миллионов |
Для определения количества завершенных РРР-сессий в месяц можно использовать следующий запрос:
SELECT COUNT(*) FROM EX_V_CDR WHERE N_SERVICE_ID = 40223001 -- Идентификатор службы AND D_END BETWEEN TO_DATE('01.05.2013 00:00:00', 'DD.MM.YYYY HH24:MI:SS') AND TO_DATE('31.05.2013 23:59:59', 'DD.MM.YYYY HH24:MI:SS') -- Задаём период AND N_CDR_STATE_ID IN (SYS_CONTEXT('CONST', 'CDR_Status_Finished'), SYS_CONTEXT('CONST', 'CDR_Status_FinForced'));
SD_GOOD_MOVES
В данной таблице содержатся строки состава инвойсов и счетов.
При превышении порогового значения необходимо настроить в системе агрегацию и архивацию данных. См. руководство пользователя: раздел "Работа с системой" -> "Администрирование" -> "Задания" -> "Стандартные задания" -> "Архивация инвойсов".
EX_DATA_COLLECT
В данной таблице содержится статистика по трафику PPP-сессий. При превышении порогового значения в настройках заданий по удалению старых CDR необходимо уменьшить значение параметра Срок давности для удаления отработанных записей EX_DATA_COLLECT с кумулятивным обновлением.
EX_CALL_DATA_REC
В данной таблице содержатся данные о CDR и PPP-сессиям.
Определить, с помощью следующего скрипта, данных какого типа большинство
SQL> SELECT SI_REF_PKG_S.GET_NAME_BY_ID(N_CDR_TYPE_ID) VC_CDR_NAME, COUNT(*) FROM EX_CALL_DATA_REC GROUP BY N_CDR_TYPE_ID; VC_CDR_NAME COUNT(*) ------------------------------------------------------------------------ Телефонный звонок 107552 PPP-сессия (без тарификации) 3774012
- В случае большого количества CDR (телефонный звонок) обратиться в техподдержку для выгрузки CDR в файл.
- В случае большого количества PPP-сессий необходимо уменьшить значение параметра Таймаут удаления старых CDR на форме редактирования сетевых служб, по которым создаются PPP-сессии.
SS_SESSION_LOGS
В данной таблице содержатся данные о сессиях по работе с системой, которые создаются с помощью процедуры MAIN.INIT
. При превышении порогового значения, необходимо обратиться в техподдержку для очистки старых записей о сессиях.
Контроль работы приложений системы
Веб-приложения
HOPER
При запуске процесса создается PID-файл.
- Для версии 3.3 и выше его расположение указывается в конфигурационном файле, обычно это /var/run/hydra/hoper/unicorn.pid.
- Для версии ниже 3.3 его расположение нельзя изменить. Он находится в shared/unicorn.pid от корня установки приложения.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hoper/unicorn.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
HUPO
При запуске процесса создается PID-файл.
- Для версии 3.3 его расположение указывается в конфигурационном файле, обычно это /var/run/hydra/hupo/unicorn.pid .
- Для версии ниже 3.3 его расположение нельзя изменить. Он находится в shared/pids/unicorn.pid от корня установки приложения.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hupo/unicorn.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
HDD
При запуске создается два процесса - hdd_default , hdd_default_monitor и два PID-файла.
- Для версии 3.3 расположение указывается в конфигурационном файле, обычно это /var/run/hydra/hdd/hdd_default.pid , /var/run/hydra/hdd/hdd_default_monitor.pid.
- Для версий ниже 3.3 расположение нельзя изменить. Они находятся в tmp/ от корня установки приложения.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса hdd_default не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hdd/hdd_default.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса hdd_default_monitor не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hdd/hdd_default_monitor.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Агенты
hamd
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (/etc/hamd/hamd.conf). Как правило PID-файл располагается по пути /var/run/hydra/hamd.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@server:~# PIDFILE="/var/run/hydra/hamd.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту. Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@server:~# PORT=8889; lsof -i :$PORT -n > /dev/null ; echo $?
hard
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (/etc/hard/hard.conf). Как правило PID-файл располагается по пути /var/run/hydra/hard.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hard.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту. Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@sever:~# PORT=11080; lsof -i :$PORT -n > /dev/null ; echo $?
hcd
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (/etc/hcd/hcd.conf). Как правило PID-файл располагается по пути /var/run/hydra/hcd.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hcd.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту. Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@sever:~# PORT=8888; lsof -i :$PORT -n > /dev/null ; echo $?
hid
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (/etc/hid/hid.conf). Как правило PID-файл располагается по пути /var/run/hydra/hid.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hid.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту. Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@sever:~# PORT=10080; lsof -i :$PORT -n > /dev/null ; echo $?
hpd
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (/etc/hpd/hpd.conf). Как правило PID-файл располагается по пути /var/run/hydra/hpd.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/hydra/hpd.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту. Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@sever:~# PORT=9080; lsof -i :$PORT -n > /dev/null ; echo $?
FreeRADIUS
При запуске процесса создается PID-файл, расположение которого задается в конфигурационном файле (как правило, /etc/freeradius/radiusd.conf). Обычно PID-файл располагается по пути /var/run/radiusd/radiusd.pid.
Следующий код возвращает 0, если процесс существует, и 1, если не существует или если PID-файл процесса не найден (под пользователем root):
root@sever:~# PIDFILE="/var/run/radiusd/radiusd.pid" ; if [ -f $PIDFILE ] ; then kill -0 `cat $PIDFILE` > /dev/null 2>&1 ; echo $? ; else echo "1" ; fi
Также рекомендуется проверять наличие процесса на порту (для авторизации чаще всего используется UDP-порт 1812). Следующий код возвращает 0, если процесс слушает необходимый порт, и 1, если нет:
root@sever:~# PORT=1812; lsof -i :$PORT -n > /dev/null ; echo $?
Приложение: скрипт для создания пользователя БД с необходимыми правами
Следующий скрипт содержит в себе команды по созданию пользователя с необходимыми правами для мониторинга системы и Oracle, его необходимо выполнять под пользователем SYS:
CREATE USER &&username PROFILE DEFAULT IDENTIFIED BY &&password DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP ACCOUNT UNLOCK; / GRANT SELECT ON V_$LOG_HISTORY TO &&username; GRANT SELECT ON V_$PARAMETER TO &&username; GRANT CONNECT TO &&username; GRANT RESOURCE TO &&username; GRANT SELECT ON SS_V_JOBS TO &&username; GRANT SELECT ON SI_V_USERS TO &&username; GRANT SELECT ON SS_V_JOB_SEANCES TO &&username; GRANT SELECT ON SS_V_MANAGER_JOBS TO &&username; GRANT EXECUTE ON SI_SUBJECTS_PKG_S TO &&username; GRANT EXECUTE ON SI_OBJECTS_PKG_S TO &&username; GRANT EXECUTE ON SI_REF_PKG_S TO &&username; -- count.dbc GRANT SELECT ON V_$DATABASE_BLOCK_CORRUPTION TO &&username; -- count.uretenop GRANT SELECT ON V_$UNDOSTAT TO &&username; -- count.cdr; count.lastcdr GRANT SELECT ON EX_V_CDR TO &&username; -- count.gm GRANT SELECT ON SD_GOOD_MOVES TO &&username; -- count.ecrd GRANT SELECT ON EX_CALL_DATA_REC TO &&username; -- count.edc GRANT SELECT ON EX_DATA_COLLECT TO &&username; -- count.etcc GRANT SELECT ON EX_TRAFFIC_COLLECT_C TO &&username; -- count.active GRANT SELECT ON SI_SUBJ_GOODS TO &&username; -- tblspace.discovery GRANT SELECT ON DBA_SEGMENTS TO &&username; -- tblspace.pcf GRANT SELECT ON DBA_DATA_FILES TO &&username; GRANT SELECT ON DBA_FREE_SPACE TO &&username; GRANT SELECT ON DBA_TEMP_FILES TO &&username; GRANT SELECT ON DBA_TEMP_FREE_SPACE TO &&username; -- checkactive GRANT SELECT ON V_$INSTANCE TO &&username; -- rcachehit GRANT SELECT ON V_$SYSSTAT TO &&username; -- activeusercount GRANT SELECT ON V_$SESSION TO &&username; -- dbsize GRANT SELECT ON DBA_FREE_SPACE TO &&username; GRANT SELECT ON DBA_TABLESPACES TO &&username; -- lastarclog GRANT SELECT ON V_$LOG TO &&username; -- freebufwaits GRANT SELECT ON V_$SYSTEM_EVENT TO &&username; GRANT SELECT ON V_$EVENT_NAME TO &&username; GRANT SELECT ON EX_V_PAYMENTS TO &&username; GRANT SELECT ON SS_SESSION_LOGS TO &&username; / QUIT;