Difference between revisions of "Pandora: Documentation ja: Server Management"

From Pandora FMS Wiki
Jump to: navigation, search
(メンテナンスツールの手動実行)
(データベースバックアップ)
Line 133: Line 133:
 
== データベースバックアップ==
 
== データベースバックアップ==
  
''mysqldump'' コマンドで、データベースをダンプすることができます。データをリストアするには、オリジナルと同じ名前の空のデータベース (通常は pandora) が必要です。
+
コマンド ''mysqldump'' は、テーブル構造とその内容の完全なデータベースダンプを行います。このコマンドには、バックアップを実行するためのいくつかのオプションがありますが、ここでは最も基本的な使用法に焦点をあてます。これは、データベースを実行しているのと同じホストから実行することを意味します。 バックアップが行われるデータベース名とそれにアクセスするための認証情報を指定します。
  
'''バックアップの実行'''
+
mysqldump -u <user> -p <data_base>
 +
 
 +
例えば、"pandora" データベースをバックアップし、ファイルにダンプを出力するには次のようにします。
  
 
  mysqldump -u root -p pandora > /backup/pandoradb_backup.sql
 
  mysqldump -u root -p pandora > /backup/pandoradb_backup.sql
  
'''バックアップからのリストア'''
+
結果として、''/backup/pandoradb_backup.sql'' にデータベースのコピーが作成されます。
  
mysql -u root -p
+
この方法でバックアップを実行するとデータベースを完全に復元できます。 復元処理は非常に簡単で、MySQL にログインし、データベースを作成して、そのデータベースにバックアップを復元およびロードします。 前のファイルを例にすると、次のように実行するだけです。
create database pandora;
 
use pandora;
 
source /backup/pandoradb_backup.sql
 
  
おそらく、ユーザの権限も以下のように設定する必要があります。
+
[[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';
 
  grant all privileges on pandora.* to [email protected] identified by 'mypassword';
  
システム全体のバックアップを行いたい場合は、エージェントとサーバの設定情報を保存するために、''/etc/pandora'' ディレクトリ全体のバックアップも忘れないようにしてください。
+
{{warning|これは、データベースのバックアップ/リカバリを実行するのみであり、サーバの設定などの他のファイルに対するものではないことに注意してください。}}
 
 
上記は、データベースのみのバックアップとリストアであることに注意してください。
 
  
 
== Pandora FMS のバックアップとリカバリ ==
 
== Pandora FMS のバックアップとリカバリ ==

Revision as of 05:10, 14 December 2019

Pandora FMS ドキュメント一覧に戻る

1 Pandora FMS サーバ管理

1.1 データベース管理

Pandora FMS インフラストラクチャは外部メンテナンスを必要としませんが、古いデータを削除し、データベースをできるだけコンパクトに維持することが非常に重要です。 これらのタスクの実行を担当する Pandora FMS に不可欠なツールが以下にあります。

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

Pandora FMS Enterprise 版の場合は以下です。

/usr/bin/pandora_db

このツール(以降 pandora_db.pl)は、Pandora FMS サーバパッケージに含まれているため、Pandora FMS サーバがインストールされているシステムから実行する必要があります。 コンソール用とサーバ用で 2つのシステムがある場合、Pandora FMSサーバがホストされている方で pandora_db を実行する必要があります。 Pandora_db は、Pandora FMS が適切に動作するための重要なツールです。そのため、システムの cron タスクで一時間ごとに実行するように設定されています。 以下のファイルで設定されています。

 /etc/cron.hourly/pandora_db

このツールは、データベースの全てのメンテナンスを自動的に実行します。

  • 古いデータの削除をします。
  • 既存のデータを圧縮し、いくつかの間隔を補間します。これにより、グラフは同じですが、それらを保存するために必要なスペースははるかに小さくなります(これが、Pandora FMS が大量の情報を処理できる理由の 1つです)。
  • 存在しないモジュールのデータベースでの整合性や、初期化されていないために利用されていないモジュール (これらのモジュールは、未初期化モジュールとして表示されます) をチェックします。
  • エージェントの一日の接続情報を削除します。Pandora FMS は、24時間を越えるエージェント接続情報は必要としません。もし、それが増えると、データベースのアクセス速度が低下します。
  • エンタープライズ版では、全ての古いデータをスタンバイデータベースに移動します。

前述したように、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

Pandora FMS Enterprise 版では以下の通りです。

"/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

1.2 メンテナンスツールの手動実行

必要に応じて、前のセクションで説明した pandora_db を手動で実行できます。 シェルコンソールからコマンドを実行します。

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

Pandora FMS Enterprise 版では次の通りです。

/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

Template warning.png

負荷が高いシステムでは数時間かかる場合があるため、バックグラウンドでプロセスを実行することをお勧めします。

 


手動でメンテナンスツールをバックグラウンド実行するには、次のようにします。

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

Pandora FMS Enterprise 版では次の通りです。

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

バックグラウンドでプロセスの実行には少々時間がかかります。プロセスの実行中でも、シェルこのソールを閉じることができます。

Info.png

インストールの状況によっては、ツールのディレクトリが変わります。ほとんどの場合は以下の通りです。

/usr/share/pandora_server/util/

Pandora FMS の以前のバージョンでは以下にあります。

/usr/share/pandora/util/

 


Template warning.png

古いバージョンではなく、新しいバージョンのツールを使用していることを確認することが非常に重要です。 引数なしでプログラムを実行すると、メッセージの先頭にツールのバージョンが表示され、サーバにインストールしたバージョンが一致している必要があります。

 


1.3 データベースバックアップ

コマンド mysqldump は、テーブル構造とその内容の完全なデータベースダンプを行います。このコマンドには、バックアップを実行するためのいくつかのオプションがありますが、ここでは最も基本的な使用法に焦点をあてます。これは、データベースを実行しているのと同じホストから実行することを意味します。 バックアップが行われるデータベース名とそれにアクセスするための認証情報を指定します。

mysqldump -u <user> -p <data_base>

例えば、"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';

Template warning.png

これは、データベースのバックアップ/リカバリを実行するのみであり、サーバの設定などの他のファイルに対するものではないことに注意してください。

 


1.4 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 Sancho Lerena <[email protected]>, Artica Soluciones Tecnologicas

Syntax:
		-c Path to Pandora FMS console, p.e: /srv/www/htdocs/pandora_console
		-d Destination path for backup file. p.e: /tmp
		-s Source filename for backup restore. p.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!

このスクリプトは、次のコンポーネントのコピーとリストアをするように設計されています。

  • サーバ設定ファイル
  • 処理待ちのファイルおよび、エージェントのリモート設定ファイル
  • DB 全体
  • ウェブコンソール全体

コピー元とコピー先オプション

このスクリプトは、ウェブコンソールの設定ファイルに設定されている DB のアクセス情報を利用します。そのため、ウェブコンソールの設定ファイルのパスを -c オプションで指定する必要があります。 このパラメータは、ウェブコンソールのバックアップを取得するためにも利用されます。

パックアップは、-d オプションで指定します。バックアップファイルが pandorafms_backup_xxxxxxx.tar.gz というファイル名で圧縮されて置かれます。

オリジナルのリストア先は、このツールで生成されたバックアップファイルに保存された、名前とパスになります。

ファイルのおよびデータのリストア

-f オプションを指定することにより、ファイルおよびデータベースのデータをリストアすることができます。(同じファイルは上書きされます) ファイルが上書きされるため、問題が発生する可能性があります。-f オプションの利用は、Pandora の全ファイル (コンソールおよびサーバ) のバックアップからのリストアの時にのみ利用してください。

ファイルのリストア

上記のオプションと同じですが、ファイルのみをリストアします。データはリストアしません。この場合は、-b オプションを利用します。

データのリストア

デフォルトのオプションです。これを行うには、-b および -f オプション共に指定しないでください。

1.4.1 利用例

バックアップの作成

root で以下を実行します。

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

次のようなメッセージが表示されます。

Backup completed and placed in /tmp//pandorafms_backup_2009-10-10-01-35-31.tar.gz

これは、バックアップが /tmp//pandorafms_backup_2009-10-10-01-35-31.tar.gz にできたことを意味します。

バックアップからのリストア

自動でバックアップからリストアするために、コマンドラインからデータベースへアクセスできる権限が設定されていると仮定します。

root 権限で次のように実行します。

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

次のような表示がされます。

Detected Pandora FMS backup at /tmp/pandorafms_backup_2009-10-10-01-35-31.tar.gz, please wait...
Dropping current database
Restoring backup database
Restoring files and configuration
Done. Backup in /tmp/pandorafms_backup_2009-10-10-01-35-31.tar.gz restored

障害時におけるバックアップからのリストア

Pandora FMS コンソールが障害により異常状態になった場合、このツールでバックアップを取得していれば、コンソールをリストアすることができます。そのためには、次のようにバックアップファイルを手動で展開します。

cd /tmp
tar xvzf pandorafms_backup_2009-10-10-0

これより、ウェブコンソールのファイルが /tmp ディレクトリに展開されます。上記の例のバックアップの場合、次のようなディレクトリが作成されます。

/tmp/var/www/pandora3/

このディレクトリ内の全てのファイルをウェブコンソールのディレクトリ (利用しているディストリビューションにより異なります) にコピーしてください。

cp -R var/www/pandora3 /var/www

以上でバックアップからリストアされ使えるようになります。

1.5 Pandora FMS サーバの手動起動・停止

Pandora FMS サーバの手動での起動・停止は、コマンドラインから次のように実行します。

デーモンの停止:

/etc/init.d/pandora_server stop

デーモンの起動:

/etc/init.d/pandora_server start

デーモンの再起動:

/etc/init.d/pandora_server restart

1.6 Pandora FMS の Watchdog 実装

リポジトリには、"watchdog" として使える小さなスクリプトがあります。このスクリプトは Pandora をモニタリングします。Pandora がダウンした場合、それを起動させ、通知することができます。

1.6.1 /usr/bin/pandora_watchdog

#!/bin/bash
# Copyright (c) 2005-2012 Artica ST
# Author: Sancho Lerena <[email protected]> 2009
# Licence: GPL2
#
# daemon_watchdog
#
# Generic watchdog to detect if a daemon is running. If cannot restart, execute
# a custom-user defined command to notify daemon is down and continues in
# standby (without notifying / checking) until daemon is alive again.

# Default configuration is for Pandora FMS Server daemon

# =====================================================================
# Configuration begins here. Please use "" if data contain blank spaces

export DAEMON_WATCHDOG=pandora_watchdog.sh
# DAEMON_WATCHDOG: Name of this script. Used to check if its running already

export DAEMON_CHECK="/usr/bin/pandora_server /etc/pandora/pandora_server.conf"
# DAEMON_CHECK: Daemon monitored, please use full path and parameters like
#               are shown doing a ps aux of ps -Alf

export DAEMON_RESTART="/etc/init.d/pandora_server restart"
# DAEMON_RESTART: Command to try to restart the daemon

export DAEMON_DEADWAIT=90
# DAEMON_DEADWAIT: Time this script checks after detect that
#                  daemon is down before to consider is really down. 

export DAEMON_ALERT="/usr/bin/pandora_alert"
# DAEMON_ALERT: Command/Script executed if after detecting daemon is down,
#               and waiting DAEMON_DEADWAIT, and daemon continues down.

export DAEMON_LOOP=7
# DAEMON_LOOP: Interval within daemon_wathdog checks if daemon is alive.
#              DO NOT use values under 3-5 seconds or could be CPU consuming.
#              NEVER NEVER NEVER use 0 value or gets 100% CPU!.

# Configuration stop here
# =====================================================================

# Check if another instance of this script

RUNNING_CHECK=`ps aux | grep "$DAEMON_WATCHDOG" | grep -v grep |wc -l`
if [ $RUNNING_CHECK -gt 2 ]
then
        echo "Aborting, seems that there are more '$DAEMON_WATCHDOG' running in this system"
        logger $DAEMON_WATCHDOG aborted execution because another watchdog seems to be running
        exit -1
fi


# This value always must be 0 at start. Do not alter
export DAEMON_STANDBY=0

# This function replace pidof, not working in the same way in different linux distros
function pidof_daemon () (
        # This sets COLUMNS to XXX chars, because if command is run
        # in a "strech" term, ps aux don't report more than COLUMNS
        # characters and this will not work.
        COLUMNS=300
        DAEMON_PID=`ps aux | grep "$DAEMON_CHECK" | grep -v grep | tail -1 | awk '{ print $2 }'`
        echo $DAEMON_PID
)

# Main script

if [ ! -f `echo $DAEMON_CHECK | awk '{ print $1 }'` ]
then
        echo "Daemon you want to check is not present in the system. Aborting watchdog"
        exit
fi

while [ 1 ]
do

        DAEMON_PID=`pidof_daemon`
        if [ -z "$DAEMON_PID" ]
        then

echo "Checkpoint #1 $DAEMON_PID "

                if [ $DAEMON_STANDBY == 0 ]
                then

                        # Daemon down, first detection
                        # Restart it !

                        logger $DAEMON_WATCHDOG restarting $DAEMON_CHECK
                        $DAEMON_RESTART 2> /dev/null > /dev/null

                        # Just WAIT another DAEMON_DEADWAIT before consider it DEAD

echo "Going to DAEMON_DEADEWAIT"

                        sleep $DAEMON_DEADWAIT
                        DAEMON_PID=`pidof_daemon`

                        if [ -z "$DAEMON_PID" ]
                        then

                                # Is dead and can't be restarted properly. Execute alert

echo "I cannot startup again the process"

                                logger $DAEMON_WATCHDOG $DAEMON_CHECK is dead, alerting !
                                $DAEMON_ALERT  2> /dev/null > /dev/null

                                # Watchdog process puts in STANDBY mode until process get alive again
                                logger $DAEMON_WATCHDOG "Entering in Stabdby mode"

                                DAEMON_STANDBY=1
                        fi
                fi
        else

echo "Checkpoint #1B $DAEMON_PID "

                DAEMON_STANDBY=0
        fi

        sleep $DAEMON_LOOP
done

1.6.2 /usr/bin/pandora_alert

このスクリプトは、watchdog プロセスがモニタリングしているプロセス (pandora) を起動できなかった場合に実行されます。我々の場合、SMS でアラートを発信し Tentacle を停止するようにしています。

パーミッションは、chmod 750 /usr/bin/pandora_alert のように設定します。

#!/bin/bash
sendsms +34458474843 "Pandora FMS Server stopped and can't be started"
/etc/init.d/tentacle_serverd stop

1.6.3 Watchdog 起動

nohup /usr/bin/pandora_watchdog &

1.6.4 注意点

watchdog が動作している場合は、それが動いているということを認識しておく必要があります。例えば、Pandora をメンテナンスのために停止したい場合でも、停止すると watchdog が自動的に再起動してしまいます。そのため、このような時は watchdog を先に停止しておく必要があります。

1.7 ヒストリデータベース

ヒストリデータベースは、メインの Pandora FMS データベースの応答を良くするために、そこから古いモジュールデータを移動させ保存しておくためのものです。データは、レポートやモジュールグラフの参照時に Pandora FMS コンソールでシームレスに利用できます。

1.7.1 ヒストリデータベースの設定

ヒストリデータベースを設定するには、それを格納する(メインのデータベースとは異なる)新たなサーバが必要です。MySQL をインストールしたサーバを準備したら、以下の手順を実行します。

  • 新たなヒストリデータベースを作成します。
[[email protected] ~]# mysql -u root -p
mysql> create database pandora_history;
  • Pandora FMS データベーススキーマを作成します。Pandora FMS コンソールと共に提供されている /var/www/html/pandora_console/pandoradb.sql が利用できます。それをヒストリデータベースサーバへコピーします。
cat pandoradb.sql | mysql -u user -p -D history_db
  • ヒストリデータベースにアクセスできるように Pandora FMS サーバとコンソールで利用するユーザのパーミッションを設定します。
GRANT ALL PRIVILEGES ON pandora_history.* TO 'user'@'%' IDENTIFIED BY 'password';
  • Pandora FMS コンソールにて、設定(setup) -> ヒストリデータベース(History database) を選択し、データベースのホスト名、ポート番号、データベース名、ユーザ名、パスワードを入力します。


History db.png


このフォームの最後のフィールド(Days, step, delay)は、どのデータをヒストリデータベースへ送るかを定義します。Days に指定した日より古いデータを、Step に指定した行ブロックごとにヒストリデータベースに移動します。高負荷になることを防ぐために、一つのブロックを処理したあとは、次の処理までに Delay に指定した時間待ちます。

同じ画面で、イベント日数(Event days) に指定するイベントの履歴をヒストリデータベースに送信するかどうかを設定することもできます。ただし、イベントを含めるとヒストリデータベースが大幅に大きくなることを考慮する必要があります。また、このデータはイベント表示ではなく、レポートの生成時にのみ参照されます。

Info.png

ヒストリデータベースの機能は Enterprise 版の機能で、データを転送するのに /usr/bin/pandora_db バイナリを用います。

 


1.7.2 ヒストリデータベースの削除と圧縮設定

ヒストリデータベースは、"過去の全データ" を保存することを想定しています。しかし、古いデータを削除したり圧縮したい場合は、pandora_db スクリプトを通常の DB に対する動作に見せかけて実行する必要があります。そのためには、ヒストリデータベースに何らかのデータが入っている必要があります。

最初に、pandora_db ツールによって利用できるように、tconfig テーブルを適切な値を入れた状態で用意する必要があります。pandora_db の実行に必要な最小限の設定を行うために、ヒストリデータベースに対して以下の SQL を実行します。まずは、mysql の CLI を利用して、データベースに接続する必要があります。

以下が例です。値は必要に応じて書き換えてください。(ただし、history_db_enabled は 0 にしてください)

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');

これは、ヒストリデータベースに(現在からさかのぼること) 6ヶ月間データを保存し、4ヶ月前のデータを圧縮することを意味します。メインのデータベースに 1ヶ月間のデータがあるとしても、トータルで 6ヶ月間のデータとなります。なぜなら、直近 1ヶ月のデータはメインデータベースから読まれ、それ以外はヒストリデータベースから読まれるためです。これらには任意の値を設定できます。ヒストリデータベースにはデータ量の上限はありません。ただし、ヒストリデータベースは、メインデータベースおよび Pandora FMS サーバやコンソールが動作しているマシンとは物理的に異なるマシンに配置しなければいけないことを理解してください。

次に、追加の pandora_server.conf ファイルを作成する必要があります。以下に示す簡単な例を利用して(各値は実際のヒストリデータベースに合わせて書き換えてください) /etc/pandora/pandora_server_history_db.conf として作成してください。

dbengine mysql
dbname pandora4_history
dbuser pandora4_history
dbpass 1234
dbhost 192.168.50.23
log_file /var/log/pandora/pandora_db_history.log


以上で、通常の DB に対する処理に見せかけた設定を使って pandora_db を実行することができます。

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

また、設定値は以下に説明しているようにコンソールからも入力できます。ヒストリデータベースメンテナンスオプション

Info.png

この処理は、メインのデータベースには影響しません。なぜなら、異なるサーバの異なるデータベースに対して行っているためです。ただし、ヒストリデータベースにおいて大量のデータ処理をしようとしている場合には、通常よりも応答が遅くなる可能性があります。