Управление и администрирование серверами

Обслуживание серверов Pandora FMS

Управление базами данных

Инфраструктура Pandora FMS не нуждается во внешнем обслуживании, но очень важно очищать и отлаживать старые данные, а также поддерживать базу данных как можно более компактной. По этой причине для хорошего функционирования Pandora FMS существует важный инструмент, отвечающий за выполнение этих задач, который находится по адресу:

/usr/share/pandora_server/util/pandora_db.pl

Или для версии Enterprise для Pandora FMS в:

/usr/bin/pandora_db

Этот инструмент, далее pandora_db, включен в пакет сервера Pandora FMS, поэтому он должен выполняться из системы, где установлен сервер Pandora FMS. Если, например, у вас есть две системы, на одной из которых находится сервер, а на другой - консоль, pandora_db должен выполняться с системы, на которой размещен сервер Pandora FMS.

Pandora_db является важнейшим инструментом для правильного функционирования Pandora FMS, поэтому его выполнение запрограммировано в cron-задачах системы с часовой периодичностью. Его выполнение настраивается в файле:

/etc/cron.hourly/pandora_db

Этот инструмент выполняет все задачи по обслуживанию базы данных автоматически:

  • Удалите старые данные.
  • Он уплотняет существующие данные, интерполируя их через несколько интервалов, так что графики остаются теми же, но места для их хранения требуется гораздо меньше (это одна из причин, по которой Pandora FMS способна обрабатывать так много информации).
  • Проверьте согласованность базы данных на наличие несуществующих модулей или модулей, которые не используются из-за невозможности их инициализации (эти модули отображаются в статическом представлении как неинициализированные модули).
  • Исключает ежедневную контактную информацию агента. Pandora FMS не требует более 24 часов истории контактов на одного агента, а если она накапливается, то это сильно замедляет доступ к базе данных.
  • В версии Enterprise все старые данные перемещаются во вспомогательную базу данных истории.

Как мы уже говорили, выполнение pandora_db настраивается в cron-задачах системы, и хотя при установке сервера Pandora FMS это выполнение включается автоматически, удобно проверить, так ли это. Для этой цели файл /etc/cron.hourly/pandora_db должен существовать и содержать строку:

"/usr/share/pandora_server/util/pandora_db.pl" "/etc/pandora/pandora_server.conf">/dev/null 2>&1

Или в Enterprise-версии Pandora FMS:

"/usr/bin/pandora_db" "/etc/pandora/pandora_server.conf">/dev/null 2>&1

Также важно посмотреть на разрешения и на владельца файла. Соответствующие права доступа к файлам будут равны 755, которые можно назначить с помощью выполнения:

chmod 755 /etc/cron.hourly/pandora_db

Что касается владельца, то он должен быть «root» как для пользователя, так и для группы, чего можно добиться, выполнив команду:

chown root:root /etc/cron.hourly/pandora_db

Ручное управление инструментом для технического обслуживания

При необходимости можно запустить выполнение pandora_db вручную, как мы видели в предыдущем разделе. Просто выполните команду из консоли shell:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

Или в Enterprise-версии Pandora FMS:

/usr/bin/pandora_db /etc/pandora/pandora_server.conf

Должен появиться вывод, подобный этому:

Pandora FMS DB Tool 7.0NG.719 PS180221 Copyright (c) 2004-2015 Artica ST
This program is Free Software, licensed under the terms of GPL License v2
You can download latest versions and documentation at http://www.pandorafms.org

Pandora DB now initialized and running (PURGE=7 days, COMPACT=0 days, STEP=1) .

 [*] Pandora FMS Enterprise module loaded.

Starting at 2018-03-12 12:40:54
12:40:55 [PURGE] Deleting old extended session data.
12:40:55 [PURGE] Deleting old inventory data.
12:40:55 [PURGE] No data in tagente_datos_inventory.
12:40:55 [PURGE] No data to purge in tagente_datos.
12:40:55 [PURGE] Deleting old export data from tserver_export_data

12:40:55 [PURGE] Deleting old session data from tsessions_php

12:40:55 [PURGE] No data in tagente_datos_log4x.
12:40:55 [PURGE] No data in tagente_datos_string.
12:40:55 [PURGE] Deleting old event data at tevento table (More than 7 days).
12:40:55 [PURGE] Deleting old audit data (More than 7 days).
12:40:55 [PURGE] Deleting old SNMP traps (More than 7 days).
12:40:55 [ENTERPRISE] Deleting old policy queue entries (More than 7 days)...
12:40:55 [ENTERPRISE] Deleting invalid service elements...
12:40:55 [PURGE] Deleting old GIS data (More than 7 days).
12:40:55 [PURGE] Deleting pending delete modules (data table).
12:40:55 [PURGE] Deleting pending delete modules (status, module table).
12:40:55 [PURGE] Deleting old access data (More than 24hr)
12:40:55 [PURGE] No agent access data to purge.
12:40:55 [PURGE] Delete contents in report that have some deleted modules.
12:40:55 [PURGE] Delete contents in report that have some deleted agents.
12:40:55 [PURGE] Delete empty contents in report (like SLA or Exception).
12:40:55 [PURGE] Delete autodisabled agents where last contact is bigger than 30 days.
12:40:55 [PURGE] Deleting old netflow data.
12:40:55 [PURGE] Deleting old log data.
12:40:55 [PURGE] Deleting log data older than 90 days.
12:40:55 [PURGE] Deleting old special days.
12:40:55 [CHECKDB] Ignoring not-init data.
12:40:55 [CHECKDB] Checking database consistency (Missing status).
12:40:55 [CHECKDB] Checking database consistency (Missing module).
12:40:55 [CHECKDB] Updating empty aliases.
12:40:55 [INTEGRITY] Cleaning up group stats.
12:40:55 [INTEGRITY] Deleting orphan alerts.
12:40:55 [INTEGRITY] Deleting orphan modules.
[HISTORYDB] Moving data older than 5 days to the history DB...
[HISTORYDB] Moving events older than 5 days to the history DB...
12:40:55 [ENTERPRISE] Moving SNMP modules back to the Enterprise SNMP Server.
12:40:55 [ENTERPRISE] Dynamically updating critical min and max values.
Ending at 2018-03-12 12:40:55

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

Чтобы вручную запустить инструмент обслуживания и оставить его в фоновом режиме, необходимо выполнить:

nohup /usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

Или в Enterprise-версии Pandora FMS:

nohup /usr/bin/pandora_db /etc/pandora/pandora_server.conf

Процессу потребуется некоторое время для полной загрузки в фоновом режиме, после чего окно консоли shell можно без проблем закрыть, а процесс продолжит выполняться.

В некоторых установках каталог инструментов может отличаться, наиболее распространенным является:

/usr/share/pandora_server/util/

В предыдущих версиях Pandora FMS его можно найти в:

/usr/share/pandora/util/

Важно убедиться, что вы используете текущую версию инструмента, а не более старую. Если вы запустите программу без аргументов, версия инструмента будет отображена в заголовке сообщения, и она должна соответствовать версии установленного сервера.

Резервное копирование (Backup) базы данных

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

mysqldump -u <usuario> -p <base_de_datos>

Например, для создания резервной копии базы данных «pandora» и сброса результата в файл, мы могли бы выполнить:

mysqldump -u root -p pandora> /backup/pandoradb_backup.sql

Таким образом, у нас будет копия нашей базы данных в файле /backup/pandoradb_backup.sql.

Из резервной копии, сделанной таким образом, мы можем полностью восстановить нашу базу данных. Процесс прост, достаточно войти в MySQL, создать базу данных для восстановления и загрузить резервную копию в эту базу данных. Следуя приведенному выше примеру, достаточно выполнить эти команды:

[[email protected] ~]# mysql -u root -p
mysql> create database pandora;
mysql> use pandora;
mysql> source /backup/padnoradb_backup.sql

Наконец, необходимо снова установить права доступа настроенного пользователя как в консоли Pandora FMS, так и на сервере, чтобы оба имели полный доступ к базе данных:

grant all privileges on pandora.* to [email protected] identified by 'mypassword';

Важно помнить, что это ТОЛЬКО резервное копирование/восстановление базы данных, а не других файлов, таких как конфигурация сервера.

Полное резервное копирование и восстановление Pandora FMS

В предыдущем разделе мы рассмотрели, как сделать полную резервную копию базы данных Pandora FMS, а в этом разделе мы рассмотрим шаги по созданию полной резервной копии всей Pandora FMS и ее восстановлению.

В дистрибутиве сервера Pandora FMS есть скрипт, который используется для создания резервной копии и полного восстановления всех Pandora FMS. Этот скрипт предназначен для резервного копирования и восстановления в системах, где сервер и консоль расположены на одной машине. Если в вашей среде присутствуют различные компоненты, вам следует использовать инструмент с наиболее подходящими для данной ситуации параметрами или изменить их в соответствии с вашими обстоятельствами.

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

Этот скрипт находится в:

/usr/share/pandora_server/util/pandora_backup.sh

Если мы выполним его без настройки параметров, он окажет помощь:

Pandora FMS Command line backup tool. http://www.pandorafms.org
(c) 2009-2015 Sancho Lerena <[email protected]>, Artica Soluciones Tecnologicas

Syntax:
                -c Path to Pandora FMS console, i.e.: /srv/www/htdocs/pandora_console
                -d Destination path for backup file. i.e.: /tmp
                -s Source filename for backup restore. i.e.: /tmp/pandorafms
                -f Restore also files
                -q Quiet. No output message (used for scripts/cron)
                -b No database backup/restore

Please BE SURE TO USE RESTORE (-s) option. This will OVERWRITE ALL your
PandoraFMS install, including files, configuration and data. Please backup first!

Этот сценарий предназначен для резервного копирования и восстановления следующих компонентов:

  • Файла(ов) конфигурации сервера.
  • Файлов, ожидающих выполнения, а также файлов конфигурации удаленного агента.
  • Полной базы данных.
  • Полной WEB-консоли.

Параметры источника и места назначения копирования

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

Место назначения резервного копирования указывается с помощью параметра -d. В этом пути оставьте сжатый файл резервной копии с именем, подобным на pandorafms_backup_xxxxxxx.tar.gz.

Таким образом, с помощью следующей команды можно создать резервную копию всей среды:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/

С помощью параметра -b можно указать, что резервное копирование базы данных не производится, выполнение будет следующим:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/ -b

Восстановление базы данных

Чтобы восстановить базу данных с помощью скрипта, просто замените параметр -d на -s, указывающий в данном случае путь к резервной копии:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz

Это восстановление по умолчанию, без включения файлов.

Восстановление базы данных и файлов

Опция -f также позволяет восстановить файлы (перезаписав текущие) из резервной копии. Поскольку перезапись текущих конфигурационных файлов может иметь серьезные последствия, необходимо использовать -f, если мы хотим перейти к восстановлению резервной копии и хотим восстановить все файлы Pandora (консоль и сервер).

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz -f

Не забудьте восстановить права доступа пользователей к базе данных с помощью команды grant.

Восстановление только файлов (без базы данных)

Как и в первом случае, мы можем восстановить только файлы, не включая базу данных. Сюда входит вариант -b к предыдущему выполнению:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz -f -b

Примеры использования

Crear backup

Как мы уже видели, для создания полной резервной копии Pandora FMS достаточно выполнить:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/

В ответ вы должны получить строку, подобную этой:

Backup completed and placed in /tmp//pandorafms_backup_2018-03-12-15-33-13.tar.gz

Указание точного местоположения резервной копии (в этом случае /tmppandorafms_backup_2018-03-12-15-33-13.tar.gz).

Восстановление резервной копии

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

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz -f

Должен вернуться результат, подобный этому:

 Detected Pandora FMS backup at /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz, please wait...
 Dropping current database
 Restoring backup database
 Restoring files and configuration
 Done. Backup in /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz restored

Восстановление резервной копии в случае потери консоли

Если вы потеряли консоль Pandora FMS, но сохранили резервную копию, созданную этим инструментом, сначала вам придется заново создать каталог консоли. Для этого вручную распакуйте резервную копию:

 cd /tmp
 tar zxvf pandorafms_backup_2018-03-12-15-33-13.tar.gz

Это распакует в /tmp весь каталог вашей WEB-консоли; в случае резервной копии, созданной в примере выше, создается каталог с именем:

/tmp/var/www/html/pandora_console

Скопируйте содержимое всего каталога в каталог веб-публикаций, который может отличаться в зависимости от используемого дистрибутива:

cp -R /tmp/var/www/html/pandora_console /var/www/html

Затем восстановите резервную копию обычным способом.

Ручные запуск и остановка серверов Pandora FMS

Чтобы вручную запустить и/или остановить сервер Pandora FMS, необходимо выполнить следующее в консоли shell:

  • Остановить демона:
/etc/init.d/pandora_server stop
  • Запустить демона:
/etc/init.d/pandora_server start
  • Перезапустить демона:
/etc/init.d/pandora_server restart

Версия NG 756 или более поздняя.

Начиная с версии NG 756, приведенные выше инструкции также запускают службу pandora_ha.

Чтобы запустить и/или остановить вручную только сервер Pandora FMS, необходимо выполнить следующее в консоли shell:

  • Остановить демона:
/etc/init.d/pandora_server stop-server
  • Запустить демона:
/etc/init.d/pandora_server start-server
  • Перезапустить демона:
/etc/init.d/pandora_server restart-server

Вы можете отслеживать состояние pandora_ha через systemd с помощью:

 systemctl status pandora_ha.service

Сторожевая программа для серверов Pandora FMS

В репозитории кода есть небольшой скрипт, используемый в качестве «Сторожевой программы» (Watchdog), которая отслеживает состояние Pandora FMS. Таким образом, в случае падения сервера будет выполнена автоматическая операция восстановления (попытка поднять Pandora), а если это не удастся, вы сможете получить уведомление об этом событии. Этот инструмент можно найти в /usr/share/pandora_server/util/pandora_watchdog.sh .

Сценарий для генерации предупреждений

Сценарий pandora_watchdog.sh ищет файл в /usr/bin/pandora_alert с инструкциями по генерации предупреждения. В этом файле должен быть создан скрипт, определяющий код, который будет выполняться, когда процесс watchdog не сможет поднять сервер Pandora FMS. В нашем примере, в дополнение к SMS-предупреждению, он останавливает сервер Tentacle:

 #!/bin/bash
 sendsms +34458474843 "Сервер Pandora FMS столкнулся с проблемой и не может запуститься."
 /etc/init.d/tentacle_serverd stop

Потребуется предоставить разрешения на выполнение этого сценария:

chmod 750 /usr/bin/pandora_alert

Запуск watchdog

Чтобы запустить watchdog и позволить ему работать в фоновом режиме, мы можем выполнить следующее:

nohup /usr/share/pandora_server/util/pandora_watchdog.sh &

При запуске watchdog учитывайте, что если по причинам технического обслуживания вы захотите вручную остановить сервер Pandora FMS, вам придется предварительно остановить процесс watchdog, чтобы избежать того, что он автоматически попытается запустить службу непрерывно.

Историческая база данных

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

Настройка базы данных истории

Для создания базы данных истории потребуется новый сервер, на котором она будет размещена (отличный от основной базы данных). Как только мы установили MySQL на этом сервере, просто выполните следующие шаги:

  • Создайте новую базу данных истории:
[[email protected] ~]# mysql -u root -p
mysql> create database pandora_history;
  • Создайте схему базы данных Pandora FMS. Вы можете использовать скрипт /var/www/html/pandora_console/pandoradb.sql включенный в консоль Pandora FMS, скопировав его на сервер базы данных истории:
cat pandoradb.sql | mysql -u root -p -D pandora_history
  • Предоставьте права пользователю, который будет использоваться с сервера и консоли Pandora FMS для отправки и просмотра данных истории:
GRANT ALL PRIVILEGES ON pandora_history.* TO 'user'@'%' IDENTIFIED BY 'password';
  • В консоли Pandora FMS перейдите в Setup & Setup & History database и настройте хост, порт, базу данных, пользователя и пароль для доступа к базе данных истории.

Последние поля этой формы (Days, step и delay) определяют способ, которым данные будут отправляться в базу данных истории, т.е. данные старше n дней, (Days) перейдут в базу данных истории в блоках с n рядов (Step), ожидая n секунд (Delay) между блоками, чтобы избежать перегрузок.

На этом же экране можно решить, отправлять ли в базу данных истории события старше n дней (Event days), хотя следует учитывать, что включение таких событий значительно увеличит скорость роста базы данных истории, и что они будут использоваться только при создании отчетов, а не при просмотре событий.

База данных истории - это функция версии Enterprise, которая использует двоичный файл /usr/bin/pandora_db для передачи данных.

Настройка управления очисткой и уплотнением базы данных истории

База данных истории может содержать «все данные» системы (без ограничений), но если вы хотите удалить данные или уплотнить их из базы данных истории, вам необходимо использовать определенные данные в базе данных, которые учитывает скрипт pandora_db при выполнении с узла.

Первым шагом будет ввод некоторых данных в таблицу tconfig вашей базы данных истории. Используйте эти SQL-запросы для создания минимальной конфигурации и настройки поведения pandora_db при работе с базой данных истории. Сначала необходимо подключиться к базе данных с помощью MySQL CLI.

Это только пример, вы должны заменить значения в соответствии с вашими критериями (но оставьте history_db_enabled равным нулю):

 INSERT INTO `tconfig` VALUES (1,'days_purge','180');
 INSERT INTO `tconfig` VALUES (2,'history_db_enabled','0');
 INSERT INTO `tconfig` VALUES (3,'days_compact','120');
 INSERT INTO `tconfig` VALUES (4,'step_compact','1');
 INSERT INTO `tconfig` VALUES (5,'event_purge','180');
 INSERT INTO `tconfig` VALUES (6,'string_purge','180');
 INSERT INTO `tconfig` VALUES (7,'MR','0');

В данном примере база данных истории хранится в общей сложности шесть месяцев (180 дней) с даты выполнения, а компиляция данных составляет более 4 месяцев (120 дней). Если у вас есть один месяц в основной БД, то в целом у вас будут данные за шесть месяцев, так как последний месяц не имеет данных в исторической БД, но имеет данные в основной БД. Вы можете поместить сюда любое значение, хранение базы данных истории не ограничено свободным пространством машины. Помните, что база данных истории должна находиться на физическом сервере, независимом от основной базы данных и Pandora.

В предыдущих версиях до Pandora FMS 753 необходимо выполнить скрипт pandora_db на собственном историческом сервере, используя данные, указанные ранее в базе данных, и дополнительно создать файл конфигурации, как описано далее, чтобы иметь возможность использовать скрипт обслуживания, как если бы мы использовали обычную базу данных.


В предыдущих версиях до Pandora FMS 753 необходимо создать дополнительный файл pandora_server.conf. Используйте эту сокращенную версию для создания своей собственной и назовите ее /etc/pandora/pandora_server_history_db.conf:

 dbengine mysql
 dbname pandora_history
 dbuser user
 dbpass password
 dbhost 192.168.70.140
 log_file /var/log/pandora/pandora_db_history.log

Теперь вы можете запустить инструмент pandora_db с конфигурацией базы данных истории и запланировать его периодический запуск:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server_history_db.conf

Значения INSERT также можно вводить в консоли, как описано в следующей ссылке: историческая база данных обслуживания опции (на английском языке).

Этот процесс не должен влиять на основную работу, так как он работает с другой БД на другом сервере.

Вернуться в оглавление Документации Pandora FMS