This article in English: Quick Operation Manual

В данном руководстве рассматриваются вопросы эксплуатации приложений, входящих в состав АСР «Гидра». С полной схемой их взаимодействия можно ознакомиться на странице с описанием взаимодействия приложений.

Веб-приложения

Офис оператора связи (hoper или arm_isp)
Личный кабинет абонента (hupo или arm_private_office)
«Миграция» (arm_migration)
Платежный портал (arm_payments)

Веб-приложения, работающие с АСР «Гидра», основаны на фреймворке Ruby on Rails (язык Ruby). Они функционируют под пользователем ОС rails с помощью веб-сервера Apache в связке с модулем passenger (или c помощью nginx + unicorn). Версии веб-приложений устанавливаются на сервере сотрудниками компании «Латера» собственными средствами.

Каждое приложение устанавливаются на сервере в отдельную директорию («Офис оператора связи» — в /opt/hydra/rails/arm_isp, «Личный кабинет абонента» — в /opt/hydra/rails/arm_private_office и т.д.), которая имеет следующее содержимое:

releases — директория с релизами (версиями) приложений. В данной директории хранятся все устанавливаемые на сервер версии заданного приложения для возможности отката к предыдущей версии в случае неудачного обновления.
current — символическая ссылка на директорию с текущей используемой версией приложения. На данную ссылку устанавливается путь до приложения в настройках виртуального хоста в настройках веб-сервера.
shared — директория с общими данными приложения, которые используются независимо от релизов. В данной директории, в частности, хранятся временные файлы и логи, которые генерирует приложение во время своей работы.

Эксплуатация

Ротация и архивация лога

В процессе своей работы веб-проложения сохраняет лог выполнения запросов в файл shared/log/production.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.
Удаление старых релизов

Со времением эксплуатации в директории releases может накопиться большое количество устаревших версий приложения, которые уже не совместимы с текущей установленной версией. Чтобы избежать заполненного дискового пространства, рекомендуется производить регулярное удаление старых релизов, например, спустя месяц с момента их последнего использования.
Сброс кэша

Для ускорения обработки запросов веб-приложения в ходе своей работы генерируют внутренний кэш в оперативной памяти. В некоторых случаях, например при изменении ссылки на текущий релиз приложения, кэш необходимо сбрасывать, чтобы избежать непредсказуемой работы приложения. Сброс кэша можно осуществить с помощью выполнения следующей команды из директории с приложением:
```
rails@server:~/arm_isp$ touch current/tmp/restart.txt
```
Запуск, остановка, перезапуск

Управление работой веб-приложений в общем случае осуществляется с помощью инит-скрипта веб-сервера Apache /etc/init.d/apache. Например, команда на перезапуск Apache имеет следующий вид:
```
root@server:~# /etc/init.d/apache2 restart
```
Перезапуск отдельного приложения может потребоваться, например, когда приложение перестает быть доступным для всех пользователей.

Приложения-агенты

Коллектор трафика (hcd)
Автономный RADIUS-демон (hard)
Менеджер активного оборудования (hamd)
Платежный шлюз (hpd)
Демон интерфейса (hid)

Все агенты написаны на языке Python и имеют одинаковые возможности по настройке и управлению выполнением. При промышленной эксплуатации они запускаются в режиме демона и управляются с помощью индивидуального инит-скрипта (например, для hcd — /etc/init.d/hcd). Для работы каждого приложения существует персональный конфигурационный файл, в котором задаются параметры запуска и логгирования. Например, для hard (файл /etc/hard/hard.conf):

# Уровень лог-сообщений
log level = debug
# Путь до лог-файла
log path = /var/log/hard/hard.log
# Максимальный размер лог-файла до создания нового, Кб
log rotate size = 10240
# Количество резервируемых лог-файлов
log rotate count = 25
# Путь до PID-файла приложения
pid path = /var/run/hydra/hard.pid

Эксплуатация

Ротация и архивация лога
В процессе своей работы приложения ведут лог в индивидуальном файле, путь к которому задается в конфиге (например, для hard — /var/log/hard/hard.log). Все агенты имеют встроенную функциональность по ротации лог-файла. При настройке параметров, отвечающих за ротацию (log rotate size и log rotate count) важно уделить внимание интенсивности заполнения лог-файла во время эксплуатации системы, на основе которой выставить подходящие значения в конфиге. Лог-файл должен содержать данные минимум за последнюю неделю работы приложения.
Ротация лога MongoDB

Агент hard для своей работы использует объектную БД MongoDB, которая в процессе своей работы формирует лог в файле /var/log/mongodb/mongodb.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.
/etc/logrotate.d/mongodb-server
```
/var/log/mongodb/mongodb.log {
   daily
   missingok
   rotate 7
   compress
   delaycompress
   notifempty
   create 640 mongodb mongodb
   sharedscripts
# find в скриптах удаляет log files, которые mongodb ротирует встроенным механизмом.
   postrotate
      killall -SIGUSR1 mongod
      find /var/log/mongodb/ -type f -regex ".*\.$log.[0-9].*-[0-9].*$" -exec rm {} \;
   endscript
}
```
Очистка кэша hard
В некоторых случаях при работе агента hard (Автономный RADIUS-демон) необходима очистка кэша внутренней объектной БД MongoDB, используемой для кэширования данных. Осуществить очистку кэша можно с помощью следующих команд:
```
root@server:~# mongo
MongoDB shell version: 1.4.4
url: test
connecting to: test
type "help" for help
> use hard_cache
switched to db hard_cache
> db.dropDatabase()
{ "dropped" : "hard_cache.$cmd", "ok" : 1 }
```
Запуск, остановка, перезапуск
Управление работой приложений-агентов осуществляется с помощью индивидуального инит-скрипта (например, для hpd — /etc/init.d/hpd). Команда на перезапуск имеет следующий вид:
```
root@server:~# /etc/init.d/hpd restart
```

SNMP-коллектор данных (hsnmp)

SNMP-коллектор данных аналогично агентам имеет собственный конфигурационный файл /etc/hsnmp/hsnmp.conf, в котором задаются параметры его работы и логгирования.

Эксплуатация

Ротация и архивация лога
В процессе своей работы коллектор ведет лог в индивидуальном файле, путь к которому задается в конфиге. Аналогично агентам hsnmp имеет встроенную функциональность по ротации лог-файла. При настройке параметров, отвечающих за ротацию (log rotate size и log rotate count) важно уделить внимание интенсивности заполнения лог-файла во время эксплуатации системы, на основе которой выставить подходящие значения в конфиге. Лог-файл должен содержать данные минимум за последнюю неделю работы приложения.
Архивация датафайлов

Во время работы коллектор генерирует датафайлы, которые удаляются после загрузки в систему (режим load, см. описание работы коллектора). Однако в некоторых случаях загружаемые датафайлы могут потребоваться для анализа причин появления трафика у абонентов. Чтобы иметь такую возможность, перед загрузкой рекомендуется производить копирование готовых к загрузке датафайлов в отдельное хранилище, где они будут храниться в течение длительного времени.

Ядро (БД Oracle 11g)

Файлы с данными БД располагаются на сервере, как правило, в директории /var/oradata. В данной директории находятся файлы табличного пространства (основные — HYDRA и HYDRA_INDEX), redo-логи и вспомогательные датафайлы. В процессе работы БД СУБД создает файлы журналы работы и трассировки в директориях /opt/oracle/admin и /opt/oracle/diag/rdbms.

Эксплуатация

Мониторинг свободного табличного пространства

Для предупреждения внезапной нехватки свободного табличного пространства в процессе эксплуатации системы настоятельно рекомендуется произвести настройку мониторинга свободного табличного пространства, подробнее о котором отдельно можно узнать на отдельной странице.
Контроль выполнения заданий системы

Для предотвращения нарушения логики работы системы крайне важно настроить мониторинг выполнения встроенных заданий, который необходимо адаптировать под конкретно используемые для инсталляции задания.
Ротация и архивация файлов журналов и трассировки

В процессе своей работы БД может создавать большое количество файлов журналов и трассировки в директориях /opt/oracle/admin и /opt/oracle/diag/rdbms, которые могуг занимать большое количество дискового пространства. Чтобы этого не произошло рекомендуется производить регулярное удаление старых файлов, например, спустя месяц с момента их создания. В случае, если установлен резервный (standby) сервер, то также необходимо проводить ротацию файла /opt/hydra/oracle/logs/update.log
Ротация и архивация логов работы с внешними таблицами

При работе с внешними таблицами Oracle пишет данные о результатах работы в отдельные для каждой таблицы файлы. Внешние таблицы используются, например, для загрузки в основную БД данных аккаунтинга агентом HARD (начиная с версии 4.0). Рекомендуется настроить ротацию этих логов и периодически удалять старые файлы. Например, ротацию выполнять ежедневно, и удалять те файлы, с момента изменения которых прошло более месяца.

Путь к директории с файлами может быть получен с помощью запроса:
```
SELECT DIRECTORY_PATH
FROM   DBA_DIRECTORIES
WHERE  DIRECTORY_NAME = 'HYDRA_TMP_DIR'
```
При работе с директорией HYDRA_TMP_DIR следует учитывать, что логи работы с внешними таблицами хранятся только в файлах *.log: удаление или изменение других файлов может привести к некорректной работе системы.
Запуск, остановка, перезапуск

Управление работой установленных на сервере БД осуществляется с помощью инит-скрипта /etc/init.d/ora.database. Например, команда на перезапуск имеет следующий вид:
```
root@server:~# /etc/init.d/ora.database restart
```
Удаление данных о неучтенном трафике
При появлении в системе большого количества данных о неучтенном трафике (таблица EX_TRAFFIC_COLLECT_C, число строк — более 2 млн.), необходимо производить очистку данных с помощью следующего SQL-запроса:
```
 SQL> TRUNCATE TABLE EX_TRAFFIC_COLLECT_C;
```
Запрос необходимо выполнять от имени пользователя AIS_NET.

Большое количество записей в данной таблице свидетельствует о наличии больших объемов неучтенного трафика. Рекомендуется разобраться с этим (в руководстве пользователя имеется соответствующая инструкция), либо увеличить порог количества неучтенного трафика, который регистрируется за один сеанс работы задания по сбору данных с коллектора.

Возможные проблемы

Ошибка «ORA-01555: snapshot too old» в задании по анализу схемы БД
В ходе эксплутации системы при работе задания по анализу схемы БД может возникать ошибка, связанная с недостаточным размером rollback-сегментом БД. Например:
```
ORA-01555: snapshot too old: rollback segment number 8 with name "_SYSSMU8_2372141723$" too small
```
Для решения проблемы необходимо узнать текущую величину rollback-сегмента при помощи запроса:
```
select p.value                            undo_retention,
       max(maxquerylen)                   maxquerylen,
       (max(maxquerylen) * 1.2)           undo_retention_optimal,
       (p.value - max(maxquerylen) * 1.2) delta
from   v$undostat s,
       v$parameter p
where  p.name = 'undo_retention' 
group by p.value;
```
Если значение undo_retention_optimal сильно отличается от undo_retention в большую сторону (параметр delta отрицательный), необходимо выполнить следующую команду:
```
SQL> alter system set undo_retention=$undo_retention_optimal scope=both;
```
где вместо переменной $undo_retention_optimal следует указать значение из соответствующего поля выборки, которую получили выше.
Запрос необходимо выполнять от имени пользователя AIS_NET.

Page tree

Краткое руководство по эксплуатации

Веб-приложения

Эксплуатация

Приложения-агенты

Эксплуатация

SNMP-коллектор данных (hsnmp)

Эксплуатация

Ядро (БД Oracle 11g)

Эксплуатация

Возможные проблемы