This article in English Monitoring Hydra's Database and Applications
Введение
Перед запуском АСР «Гидра» в промышленную эксплуатацию необходимо в обязательном порядке настроить мониторинг её работы.
Контроль должен отслеживать следующие группы параметров:
- Базовые параметры сервера АСР (load avg, использование CPU и RAM, I/O массива, количество процессов, свободное пространство на дисковом массиве).
- Показатели экземпляра БД (количество сессий, текущая нагрузка, состояние SGA и т.д.).
- Состояние заданий АСР «Гидра».
- Контроль количества нетарифицированных CDR и дату последней загрузки.
- Количество строк в жизненноважных таблицах EX_CALL_DATA_REC, EX_DATA_COLLECT, EX_TRAFFIC_COLLECT_C, SD_GOOD_MOVES.
Для мониторинга АСР «Гидра» можно использовать любую распространенную систему, которая позволяет получать данные с помощью скриптов, запускаемых из командной строки. Наиболее популярными системами мониторинга среди российских операторов связи являются бесплатные Zabbix и Nagios.
Для мониторинга показателей экземпляра БД можно использовать скрипты (раздел Oracle), разработанные для Zabbix.
Контроль выполнения заданий системы
Чтобы настроить контроль выполнения заданий АСР «Гидра», можно воспользоваться одним из специально разработанных скриптов (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.
Перечень заданий и их идентификаторы следует брать со страницы АСР Администрирование -> Задания - Назначенные задания.
Контроль рекомендуется вести по всем заданиям системы.
Для мониторинга создания новых сеансов выполнения заданий, можно использовать следующий запрос:
SELECT COUNT(*) FROM ss_v_job_seances WHERE d_start > SYSDATE - 15/24/60 AND c_reason = 'A'
Данный запрос проверяет наличие новых сеансов за последние 15 минут.
Если сеансы отсутствуют, значит системные задания не выполняются и запрос будет возвращать "0".
Контроль табличных пространств
Необходимо мониторить состояние табличных пространств (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, TS.ALLOCATED_MB - NVL(FS.FREE_MB, 0) USED_MB, NVL(FS.FREE_MB, 0) FREE_MB, TS.ALLOCATED_MB TOTAL_MB, TS.MAX_MB TOTAL_MAX_MB, TS.MAX_MB - (TS.ALLOCATED_MB - NVL(FS.FREE_MB, 0)) FREE_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", FREE_MAX_MB "Free Max MB", ROUND(100*(FREE_MAX_MB/TOTAL_MAX_MB)) "Pct. Free" FROM TBLSP_USED ORDER BY TABLESPACE_NAME;
В результате запроса получится таблица приблизительно следующего вида:
# | TABLESPACE | Used MB | Free MB | Total MB | Total Max MB | Free Max MB | Pct. Free |
---|---|---|---|---|---|---|---|
1 | HYDRA | 22903 | 27555 | 50458 | 61492 | 38589 | 63 |
2 | HYDRA_INDEX | 40621 | 6781 | 47402 | 94292 | 53671 | 57 |
3 | SYSAUX | 1829 | 321 | 2150 | 32768 | 30939 | 94 |
4 | SYSTEM | 14413 | 67 | 14480 | 32768 | 18355 | 56 |
5 | TOOLS | 1 | 31 | 32 | 32 | 31 | 97 |
6 | UNDOTBS1 | 8445 | 29078 | 37523 | 65536 | 57091 | 87 |
7 | USERS | 1 | 4 | 5 | 32768 | 32767 | 100 |
Значения полей:
- TABLESPACE — название табличного пространства
- Used MB — объем несвободных блоков в занятом объеме на диске
- Free MB — объем свободных блоков в занятом объеме на диске
- Total MB — занятый объем на диске
- Total Max MB — максимально возможный объем на диске, который разрешено захватить СУБД с ростом данных. Может быть больше объема доступного дискового пространства.
- Free Max MB — максимально возможный объем, на который может разрешено увеличиться с ростом данных. Может быть больше объема доступного дискового пространства.
- Pct. Free — процент свободного объема. Расчитывается как отношение Free Max MB к Total Max MB.
Здесь особое внимание нужно уделить показателю 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]
Контроль нетарифицированных телефонных звонков
Приведенный ниже запрос возвращает количество нетарифицированных телефонных звонков за последний час:
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 >= SYSDATE - 1/24;
Нормой считается 0, т.е. полное отсутствие ошибок и предупреждений.
Проверка корректности репликации
Для проверки репликации необходимо выполнить следующий запрос на обеих БД от пользователя с правами SYSDBA (иначе на standby сервере он не выполнится).
SELECT SEQUENCE# FROM V$LOG_HISTORY WHERE RECID = (SELECT MAX(RECID) 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 SEQUENCE# FROM V\$LOG_HISTORY WHERE RECID = (SELECT MAX(RECID) 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
В данной таблице содержатся данные о сессиях по работе с системой, которые создаются с помощью процедуры SS_AUTHENTICATION_PKG.LOGIN
. При превышении порогового значения, необходимо обратиться в техподдержку для очистки старых записей о сессиях.
Контроль работы приложений системы
Веб-приложения
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 и PID-файла.
- Для версии 3.3 расположение указывается в конфигурационном файле, обычно это /var/run/hydra/hdd/hdd_default.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
Агенты
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.q* GRANT SELECT ON SS_V_EVENTS_QUEUE 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;