Pandora: Documentation ja: Optimization

From Pandora FMS Wiki
Jump to: navigation, search

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

Contents

1 Pandora FMS の最適化と問題解決

1.1 概要

Pandora FMS サーバは、約 2000のデバイスのモニタリングが可能です。そのためには、データベースの設定を調整する必要があります。

この章ではまた、Pandora FMS の問題発見および解決のためのテクニックについて説明します。

1.2 Pandora FMS の最適化

1.2.1 商用レベルのシステムのための MySQL チューニング

1.2.1.1 一般的に推奨する設定

まず最初に、2GiBを超えるテーブルを持つ巨大なシステムを必要とするのであれば、いくつかのガイドラインに従うべきです。MySQLは64Bit版の利用を推奨します。さらに、一般的な推奨項目として、よりよいパフォーマンスを得るために十分なメモリとCPUを用意すべきです。

われわれの経験によれば、CPUよりもメモリのほうが重要です。もし、DBサーバ用に割り当てるメモリ量を1GiB以下にしようと考えているのであれば、考え直してください。エンタープライズレベルであれば最低2GiB必要です。巨大なシステムであれば、8GiB割り当てるというのもよいでしょう。メモリが十分あれば、利用されるインデックスの大半をメモリ上に置くことでインデックスの更新が高速化されるということを忘れてはいけません。

障害が発生した場合にシステムを切り離すようにできるようにするのが良いでしょう。特定のサーバにデータベースがあるシステムの場合は、ギガビットイーサを利用すべきです。待ち時間はパフォーマンスにとって重要です。

ディスクの最適化は、とても大きなデータベースにとっては大変重要です。データベースおよび手ープルを異なるディスクに分割すべきです。MySQL では、シンボリックリンクを使うことができます。システムおよび、データベースで異なるディスクを使い、一つのハードディスクのアクセスを減らすようにすることが重要です。アプリケーションは、ディスクアクセスに左右され、データが増えていくと N log N で増加していきます。

Info.png

システムの応答時間を早めるために、SSD を利用することをお勧めします。

 


可能であれば、--skip-locking (いくつかのシステムでは事前設定で有効化します) を使ってください。これにより外部ロックを行わず、パフォーマンスが向上します。

もし、MySQLサーバとクライアントを同じマシン上で起動するなら、TCP/IPのかわりにsocketを使用してMySQLサーバへ接続しましょう(これにより7.5%性能が改善されます)。MySQLサーバに接続する際、ホスト名を指定しないかlocalhostと指定することでsocket経由で接続することができます。MySQLサーバを1台しか起動しないのであれば、binary logの出力とレプリケーションを無効にしましょう。

一般的なパフォーマンス向上のためのアドバイスとしては、以下を確認してください。

  • レプリケーションを利用しない場合は、バイナリログを出力しない。
  • slowquery または debug ログを出力しない。
1.2.1.1.1 MySQL のバージョンについて

よりパフォーマンスの高い、修正版の MySQL である Percona 使うことを強くお勧めします。デフォルトでは、プラグインは Percona 用に作成しています。

MySQL のパフォーマンスはまた、最新バージョン(5.5)で向上しています。バージョン 5.0 よりも約 20%ほどパフォーマンスが上がります。

1.2.1.2 MySQL の設定をチェックするためのツール

MySQL サーバの設定を "最適化" するためのツールはたくさんあります。

Mattew Montgomery の MySQL Tuning Primer は、MySQL のパフォーマンスをチェックする(コマンドライン)ツールです。そして、それを改善するためのちょっとした提案をしてくれます。https://bugs.launchpad.net/mysql-tuning-primer を確認してみてください。

1.2.1.3 バイナリログ出力の停止

多くの Linux ディストリビューションにおいてデフォルトで有効になっています。無効にするには、my.cnf ファイル (通常、/etc/my.cnf にあります) を編集し、次の行をコメントアウトします。

 # log-bin=mysql-bin
 # binlog_format=mixed

両方の行をコメントアウトし、MySQL サーバを再起動します。Pandora FMS を ISO からインストールした場合、デフォルトではこれらの行は設定されていません。

Template warning.png

これらのお勧めは、Pandora FMS を HA 構成にしていない場合です。HA 構成の場合はバイナリレプリケーションが必要です。

 


1.2.1.4 ディスク I/O パフォーマンス

ディスク I/O に直結し、考慮すべきとても重要な 2つの設定があります。MySQL において、不適切な I/O アクセスは、通常最も重要なボトルネックになります。

innodb_log_file_size = 64M

デフォルトではこの値が設定されていますが、問題が発生した場合の回復とディスク占有率が増えることを除いては、事前検証なしに高くすることができます(512Mでも)。 MySQ Lのデフォルト値は 5M です。これは、トランザクション量が多い本番環境では非常に低い値です。 稼働中のシステムで値を変更するには、フルバックアップ(SQL ダンプ)を行い、データベースを停止し、Innodb バイナリインデックスファイル(通常は /var/lib/mysql/ib* です)を削除します。my.cnf を編集し、サーバを再起動し、ダンプを読み込みます。サーバは、新たなトランザクションログファイルを新たなサイズで再生成し、通常通り動きだします。この処理は innodb_file_per_table トークンを有効化するのと同じであるため(以下で説明します。処理全体を同時に行うことをお勧めします)、my.cnf 全体を変更し、DB を 1回だけ再起動して復元します。 バックアップとリカバリの処理について詳細を知りたい場合は、こちら を参照してください。

innodb_io_capacity = 100

デフォルトでは、このパラメータの値は 100 です。ただし、事前にシステムのディスクの IOPS を知る必要があります。正確な IOPS およびハードディスクのモデルを(smartctlを使って)知ることができます。ここでのお勧めの値は、7500RPM -> 100 IOPS, 15000 RPM -> 190 IOPS, SSD -> 1500 IOPS です。

1.2.1.5 トランザクションごとのディスク書き込みの回避

デフォルトでは、MySQLは各接続開始時のautocommitの値を1にしています。MyISAMの場合、更新結果がディスクに保存されることを保証していないため、この設定はそんなに悪い設定ではありません。しかしInnoDBの場合、InnoDBテーブルへのあらゆるinsert/update/deleteによって、ディスクへの書き込みが発生するということを意味します。

さて, なぜディスクへの書き込みがよくないのでしょうか? そんなことはありません。ディスクへの書き込みは何らかのcommitment後、データベースが障害後再起動したときもデータが存在することを保障します。問題は、DBのパフォーマンスがディスクの物理的な速度によって制限を受けることです。書き込みを確認する前にデータをディスクに書き込まなければならないことを考えると、少し時間がかかるでしょう。

ディスクの書き込みに平均9msかかるとすると、おおよそ1秒当たり67コミットに制限されます。これは非常に遅いです。そして、ディスクのあるセクタに書き込み中は、そのセクタを読み込むことはできません。InnoDBはこれらの制限のいくつかを複数の書き込みを同時に実行することで回避しています。しかしそれでも制約が存在します。

システムによる“自動”書き込み(およそ1秒ごとに書き込みを行う)を利用することで、各トランザクションが完了するたびにディスクへ書き込むことを回避することができます。問題が発生した場合、最近1秒のデータが失われますが、パフォーマンス向上を得ようとしていることを考慮すれば、許容できる範囲でしょう。

innodb_flush_log_at_trx_commit = 0

デフォルトでは、上記の設定になっています。

1.2.1.6 KeyBuffer の大きさ

システムに搭載された物理メモリ量に依存しますが、非常に重要なグローバル変数であり、これを設定することでDELETEおよびSELECTの実行速度が改善されます。

key_buffer = 4M

上記は、デフォルトの設定値です。

1.2.1.7 他の重要なバッファ

いくつかのディストリビューションでは、デフォルトで設定されていないいくつかのバッファがあります。これらのパラメータを設定することによりデフォルトより高いパフォーマンスを得ることができます。これらのトークンが MySQL の設定ファイルに存在するかどうかを確認することが重要です。

query_cache_size = 64M
query_cache_limit = 2M 
join_buffer_size = 4M

1.2.1.8 InnoDB の同時実行スレッド

Pandora の MySQL サーバパフォーマンスを向上に有効なパラメータがあります。そのパラメータは、'innodb_thread_concurrency です。このパラメータは、MySQL で "同時実行スレッド" をいくつにするのかを設定するのに利用します。このパラメータがうまく設定されていない場合、デフォルトよりも遅くなることがあります。そのため、次のような情報に注意を払うことが特に重要です。

  • MySQL バージョン。異なるバージョンの MySQL では、このパラメータはとても異なる動作をします。
  • 物理プロセッサ数。

MySQL の公式ドキュメントは、こちら [1] です。

お勧めの値は、(物理的な)CPU数の2倍に、InnoDB が置かれているディスクの数を足した数です。MySQL の最近のバージョン (> 5.0.21) では、デフォルトは 8 です。0 に設定すると、"可能な限り多くのスレッドを開きます"。

他に [2] [3] によると、古いバージョンの MySQL でテストを行ったところ、大きい値にしたときに複数の物理 CPU のあるサーバでパフォーマンスの問題があったとのことです。(2008年の情報です)

1.2.1.9 それぞれのテーブルでのテーブルスペースの利用

( MySQLのマニュアル http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html より )

MySQL 5.0では、各InnoDBテーブルとそのインデックスごとにデータファイルを生成し保存することができます。各テーブルがそれぞれテーブルスペースを持つことから、この特徴は「multiple tablespace」と呼ばれています。

multiple tablespaceを使用することで、特定のテーブルを別の物理ディスクに移動したり、他のInnoDBテーブルの利用を妨げることなくあるテーブルをバックアップから復元したりするのに役に立ちます。

my.cnfのmysqldセクションに以下の行を追加することで、multiple tablespaceを有効にすることができます。

[mysqld]
innodb_file_per_table

サーバ再起動後、InnoDBは新規に作成されたテーブルをそのテーブルが属するデータベースディレクトリ内にあるname_table.ibdという名前のファイルに保存します。これはMyISAMストレージエンジンの動きと似ていますが、MyISAMはテーブルをデータファイルtbl_name.MYDとインデックスファイルtbl_name.MYIに分割して保存します。InnoDBのデータとインデックスは.ibdファイル内に一緒に保存されます。tbl_name.frmファイルは通常通り作成されます。

my.cnf中のinnodb_file_per_tableの行をコメントアウトし、サーバを再起動すると、InnoDBは再び共有テーブルスペースファイルにテーブルを作成します。

innodb_file_per_tableはテーブル作成にのみ影響します。このオプションを有効にしてサーバを起動すると、新規テーブルは.ibdファイルを使用する状態で作成されますが、共有テーブルスペース内にあるテーブルにアクセスすることも可能です。このオプションを無効にすると、新規テーブルは共有テーブルスペース内に作成されますが、multiple tablespaceを使用しているテーブルにアクセスすることも可能です。

1.2.1.10 MySQL フラグメンテーション

ファイルシステムのように、データベースもフラグメンテーションが発生しシステム全体の速度が低下します。Pandora のように高いパフォーマンスを必要とするシステムでは、高速で信頼性の高いデータベースが必要です。高負荷なシステムでは、監視システムが停止する可能性があります。

Pandora FMS で良いパフォーマンスを得るには、MySQL の設定がとても重要です。強力なハードウエアや小規模な環境では関係はありません。MySQL で良い設定ができると、Pandora FMS を高速にすることができます。パフォーマンスの問題がある場合は、MySQL の設定やデータベースに関する問題である可能性があります。

1.2.1.10.1 my.ini/cnf 設定の確認

MySQL サーバの "基本設定" である my.ini から確認します。このファイルは以下のような設定ファイルになっています(この例は、メモリ 4GB の 2013 年の平均的なサーバハードウエアです)。

 [mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock
 user=mysql
 character-set-server=utf8
 skip-character-set-client-handshake

 max_allowed_packet = 64M
 innodb_buffer_pool_size = 800M
 innodb_lock_wait_timeout = 90
 innodb_file_per_table
 innodb_flush_log_at_trx_commit = 0
 innodb_flush_method = O_DIRECT
 innodb_log_file_size = 64M
 innodb_log_buffer_size = 16M
 innodb_io_capacity = 100
 thread_cache_size = 8
 thread_stack    = 256K
 max_connections = 100

 key_buffer_size=4M
 read_buffer_size=128K
 read_rnd_buffer_size=128K
 sort_buffer_size=128K
 join_buffer_size=4M

 query_cache_type = 1
 query_cache_size = 64M
 query_cache_min_res_unit = 2k
 query_cache_limit = 256K

 sql_mode="" 

 [mysqld_safe]
 log-error=/var/log/mysqld.log
 pid-file=/var/run/mysqld/mysqld.pid

.cnf ファイルを変更した場合は、MySQL を再起動する必要があります。エラーの確認には /var/log/mysqld.log の最後を見てください。

1.2.1.10.2 データベースのリストア

.cnf ファイルを変更する場合の共通の問題としては、トランザクションログの値があります。 ログに次のようなエラーが出た場合は、

 InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
 InnoDB: than specified in the .cnf file 0 67108864 bytes!

以前の設定をリストアするには、データベースのバックアップを生成し次の手順を実行します。

1. バックアップを作成したら、MySQL サービスを停止します。

systemctl stop mysql

2. MySQL データファイルがあるフォルダ(デフォルトは /var/lib/mysql)へ行きます。

cd /var/lib/

3. フォルダを他の場所へ移動します。(/var/lib/mysql -> /var/lib/mysql_backup)

mv mysql mysql_old

4. 新たなフォルダを作成します。(/var/lib/mysql)

mkdir mysql

5. フォルダのオーナーを設定します。

chown -R mysql. mysql.

6. MySQL データでフォルダを初期化します。

mysql_install_db --datadir=/var/lib/mysql

7. サービスを開始します。

systemctl start mysql

8. 設定プログラムを起動し、ウィザードに従います。

mysql_secure_installation

9. データベースを再構築します。

mysql> create database pandora;

10. ユーザに権限を割り当てます。

mysql> grant all privileges on pandora.* to [email protected]'localhost' identified by 'pandora';
mysql> grant all privileges on pandora.* to [email protected]'127.0.0.1' identified by 'pandora';

11. バックアップを読み込みます。

mysql> source /path/to/your/backup.sql

Template warning.png

時々、MySQL/Percona システムは my.cnf の設定を正しく読み込みません。(通常、[mysqld] セクションの外にトークンがある場合です)

 


mysql を再起動したのち、設定が反映されて動作しているかを確認する必要があります。それには、SHOW VARIABLES コマンドを用います。

mysql> show variables like 'innodb%';
+-----------------------------------------+------------------------+
| Variable_name                           | Value                  |
+-----------------------------------------+------------------------+
| innodb_adaptive_hash_index              | ON                     |
| innodb_additional_mem_pool_size         | 1048576                |
| innodb_autoextend_increment             | 8                      |
| innodb_autoinc_lock_mode                | 1                      |
| innodb_buffer_pool_size                 | 8388608                |
| innodb_checksums                        | ON                     |
| innodb_commit_concurrency               | 0                      |
| innodb_concurrency_tickets              | 500                    |
| innodb_data_file_path                   | ibdata1:10M:autoextend |
| innodb_data_home_dir                    |                        |
| innodb_doublewrite                      | ON                     |
| innodb_fast_shutdown                    | 1                      |
| innodb_file_io_threads                  | 4                      |
| innodb_file_per_table                   | OFF                    |
| innodb_flush_log_at_trx_commit          | 1                      |
| innodb_flush_method                     |                        |
| innodb_force_recovery                   | 0                      |
| innodb_lock_wait_timeout                | 50                     |
| innodb_locks_unsafe_for_binlog          | OFF                    |
| innodb_log_buffer_size                  | 1048576                |
| innodb_log_file_size                    | 5242880                |
| innodb_log_files_in_group               | 2                      |
| innodb_log_group_home_dir               | ./                     |
| innodb_max_dirty_pages_pct              | 90                     |
| innodb_max_purge_lag                    | 0                      |
| innodb_mirrored_log_groups              | 1                      |
| innodb_open_files                       | 300                    |
| innodb_rollback_on_timeout              | OFF                    |
| innodb_stats_method                     | nulls_equal            |
| innodb_stats_on_metadata                | ON                     |
| innodb_support_xa                       | ON                     |
| innodb_sync_spin_loops                  | 20                     |
| innodb_table_locks                      | ON                     |
| innodb_thread_concurrency               | 8                      |
| innodb_thread_sleep_delay               | 10000                  |
| innodb_use_legacy_cardinality_algorithm | ON                     |
+-----------------------------------------+------------------------+
1.2.1.10.3 各テーブルごとに分割されたデータファイルがアクティブであるか確認
ls -lah /var/lib/mysql/pandora/*.ibd | wc -l

"innodb_file_per_table" トークンを有効化した場合、それぞれのテーブルに対応した ".ibd" ファイルが 100以上(Pandoraのバージョンに依存)存在します。このようなファイルが無い場合は、全データが大きなファイルに記録されます。これは、テーブルのフラグメンテーションが全テーブル共通して発生し、毎週パフォーマンスが劣化することを意味します。

すでに単一のデータベースで実行している場合は、設定を変更し MySQL を再起動したあとにデータベースを再作成する必要があります。

1.2.1.10.4 テーブルごとのフラグメンテーションを確認

MySQL の CLI を使って、以下のクエリを実行します。

Select ENGINE, TABLE_NAME,Round( DATA_LENGTH/1024/1024) as data_length , round(INDEX_LENGTH/1024/1024) as index_length, round(DATA_FREE/ 1024/1024) as data_free, (data_free/(index_length+data_length)) as frag_ratio from information_schema.tables  where  DATA_FREE > 0 order by frag_ratio desc;

フラグメンテーションのあるテーブルが次のように表示されます。

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagent_module_inventory |           0 |            0 |         6 |    25.6000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+

10% 以上フラグメンテーションがあるテーブルに対してのみ対応します。

Template warning.png

10% 以上のフラグメンテーションがあるテーブルのみを対象とします。大きなテーブル(tagente_datos など)は、フラグメンテーションが大きいと最適化に長時間かかります。本番システムでは大きなインパクトとなりますので、注意してください。

 


"tagent_module_inventory" テーブルを最適化するには次のようにします。

optimize table  tagent_module_inventory;

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

"Table does not support optimize, doing recreate + analyze instead".

再度確認すると、フラグメンテーションが無くなっていることがわかります。

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+

Template warning.png

最適化を実行するには、操作を実行できるだけのディスクの空き容量が必要です。そうでないとエラーとなり処理が実行されません。

 


1.2.1.10.5 システム負荷

より一般的な事として、システムの(ディスク) I/O がボトルネックになっていないことを確認する必要があります。システムの状態を取得するのに、vmstat コマンドを実行します。

vmstat 1 10

最後のカラム (CPU WA) を見て、10より大きい値であればディスク I/O の問題があり、解決する必要があります。CPU US が高いのは通常です。CPU SY は 10~15 を超えないようにすべきです。swap si/so はゼロであるべきです。そうでなければシステムがスワップメモリを使っていることを意味し、パフォーマンスを落とします。メモリを増やすか、アプリケーションが使うメモリを減らす(Pandora サーバのスレッド、MySQL のバッファの調整など)必要があります。

以下は、"正常" なシステムの出力サンプルです。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  46248  78664 154644 576800    0    0     2   147    0    9  7 10 83  0  0	
 0  0  46248  78656 154644 576808    0    0     0     0   49   37  0  0 100  0  0	
 2  0  46248  78904 154648 576740    0    0     0   184  728 2484 63  6 31  0  0	
 0  0  46248  79028 154648 576736    0    0    16   616  363  979 21  0 79  0  0	
 1  0  46248  79028 154648 576736    0    0     0    20   35   37  0  1 98  1  0	
 0  0  46248  79028 154648 576736    0    0     0     0   28   22  0  0 100  0  0	
 1  0  46248  79028 154648 576736    0    0     0  3852  141  303  0  0 98  2  0	
 2  0  46248  78904 154660 576660    0    0     0   188  642 2354 56  4 40  0  0	
 1  0  46248  78904 154660 576680    0    0     0    88  190  634 13  0 86  1  0	
 1  0  46248  78904 154660 576680    0    0     0    16   35   40  0  0 100  0  0	
 1  0  46248  78904 154660 576680    0    0     0     0   26   21  0  0 100  0  0	
 0  0  46248  78904 154660 576680    0    0     0     0   27   27  0  0 100  0  0	
 1  0  46248  78904 154724 576616    0    0   112   192  608 2214 52  4 44  0  0	
 0  0  46248  78904 154724 576616    0    0     0    76  236  771 16  0 84  0  0	
 0  0  46248  78904 154724 576616    0    0     0    20   38   38  0  0 100  0  0	
 0  0  46248  78904 154724 576616    0    0     0     0   31   21  0  0 100  0  0	
 0  0  46248  78904 154740 576608    0    0     0  3192  187  322  1  0 96  3  0	
 1  0  46248  79028 154756 576544    0    0    16   192  632 2087 53  5 42  0  0	
 0  0  46248  79028 154760 576568    0    0     0    56  255  927 19  2 79  0  0	
 0  0  46248  79028 154768 576564    0    0     0    20   33   44  0  0 100  0  0

1.2.1.11 テーブルパーティショニングの利用

MySQLのテーブルパーティショニングを使う場合、上述の「multiple tablespace」も使用して下さい。

MySQL 5.1 では、巨大なテーブルを小さい複数の論理的なテーブルに分割することができるテーブルパーティショニングを行えるようになりました。 (詳細は MySQL のマニュアルを参照して下さい: http://dev.mysql.com/doc/refman/5.1/ja/partitioning-overview.html)

もし Pandora FMS データベースに大量のデータがあり、グラフ描画のようなデータを参照する処理がとても遅いと感じるなら、テーブルパーティショニングを行うことでパフォーマンスを改善できるでしょう。

例えば、巨大になりがちな tagente_datos をモジュールIDに応じて100のパーティションに分割するには、次のクエリを実行します:

ALTER TABLE tagente_datos PARTITION BY HASH(id_agente_modulo) PARTITIONS 100;

この処理はとても時間がかかります。一例として、約7,500モジュールの100日分 (合計5千万件以上) のデータを保持しているテーブルの分割には1時間半程度かかりました:

mysql> ALTER TABLE tagente_datos
    ->  PARTITION BY HASH(id_agente_modulo)
    -> PARTITIONS 100;
Query OK, 53391880 rows affected (1 hour 35 min 3.41 sec)
Records: 53391880  Duplicates: 0  Warnings: 0

このテーブルの場合、以下のクエリを実行するのに、パーティショニングを行う前には8分以上かかっていましたが、パーティショニング後は1秒程度になりました。

SELECT datos,utimestamp FROM tagente_datos  WHERE `id_agente_modulo` = '6332' AND utimestamp > 1322838000 AND utimestamp < 1338390000 ORDER BY utimestamp ASC

1.2.1.12 データベースの再構成

1.2.1.12.1 部分的再構成

MySQLは他のデータベースシステム、たとえばOracle (tm)と同様、時間がたつにつれ、性能が劣化していきます。これは大きなテーブルに対してデータの削除と追加を続けることによって発生するデータのフラグメンテーションによるものです。大量のトラフィックが発生する大きな環境において、性能の改善および劣化を防ぐ非常に簡単な方法があります。それは定期的にデータベースの再構築を実施することです。

そのために、1時間程度のサービス停止を計画すべきです。

計画的なサービス停止時に、Pandora FMS Webコンソールとサーバも停止すべきです (注意! tentacleサーバはデータを受け取れるようにしておき、サーバが復旧次第データを処理できるようにします)

サービス停止後、データベースのダンプを取得(エクスポート)します。

mysqldump -u root -p pandora3 > /tmp/pandora3.sql
Enter password:

データベースを削除します。

mysql> drop database pandora3;
Query OK, 87 rows affected (1 min 34.37 sec)

データベースを作成し、先ほどエクスポートしたデータをインポートします。

mysql> create database pandora3;
Query OK, 1 row affected (0.01 sec)

mysql> source /tmp/pandora3.sql

巨大でハードウエア性能があまり高くないシステムでは、この処理全体で数分かかります。たとえば、1500エージェントおよび 100,000モジュールのシステムなどです。この処理は自動化可能ですが、細心の注意が必要なため、毎月もしくは半月に一度、手動で実行することをお勧めします。

1.2.1.12.2 全体の再構築

この節の説明は、Innodb データベースのみ該当します。Pandora FMS は、Innodb データベースを利用しています。

時間ともに MySQL のパフォーマンスが落ちると、システム全体のパフォーマンスに影響します。この場合は、すべてのデータベーススキーマをゼロから再構築する以外に解決策はありません。MySQL がデータの保存に利用しているバイナリファイルを利用し、またそれを再構築します。

/var/lib/mysql ディレクトリを見ると、常に同じ名前で状態に応じて以下のような 3つのファイルがあります。

-rw-rw----  1 mysql mysql 4.8G 2012-01-12 14:00 ibdata1
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile0
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile1


ibdata1 は、すべての Innodb データを保存する先です。非常に断片化されたシステムでは、再構築やインストールをした効率の良いシステムと比べると非常に処理時間を要します。前に言及した innodb_file_per_table パラメータは、このパフォーマンスを調整します。

それぞれのデータベースは /var/lib/mysql ディレクトリにあり、一つのディレクトリで構造が定義されています。それを削除します。

手順はとても簡単です。

  1. (mysqldump にて)全スキーマをディスクにダンプします。
  mysqldump -u root -p -A > all.sql
  1. MySQL を停止します。
  2. ibdata1, ib_logfile0, ib_logfile1 および InnoDB データベースディレクトリを削除します。
  3. MySQL を再起動します。
  4. バックアップファイル(all.sql)をインポートします。
 mysql -u root -p
 mysql> source all.sql;

システムが高速化します。

1.2.1.13 インデックスオプション

他のシステムリソースを犠牲にして、MySQL パフォーマンスを最適化できるいくつかの場合があります。

以下のインデックスの最適化はグラフ生成を(とても)高速化しますが、多くのディスクスペースを必要とします。また、インデックスのオーバーヘッドにより、若干 INSERT/DELETE 処理が遅くなります。

ALTER TABLE `pandora`.`tagente_datos`  ADD  INDEX  `id_agente_modulo_utimestamp`  (  `id_agente_modulo`  , `utimestamp`  );

Info.png

現在、MySQL の Pandora FMS の最も重いテーブルでは、この最適化がデフォルトになっています。MySQL テーブルを最適化する前に専門家に相談するのが良いです。

 


1.2.1.14 スロウクエリ

いくつかのシステムでは保持している情報によって、通常よりもシステムのパフォーマンスが悪いスロウクエリが見られることがあります。テーブルを最適化するために、(システムのパフォーマンスに影響する)一定時間を超えたこのタイプのクエリをログに記録するようにできます。これを有効にするには次のようにします。

my.cnf を編集し、次の設定を加えます。

 slow_query_log = 1
 long_query_time = 2
 slow_query_log_file = / var / log / mysql_slow.log

コマンドラインから次のように設定します。

touch /var/log/mysql_slow.log
chown mysql:mysql /var/log/mysql_slow.log
chmod 640 /var/log/mysql_slow.log

mysql を再起動します。

1.2.1.15 特定のテーブルのオプティマイズ

他のあまり“過激”ではないフラグメンテーションの問題を解決する方策として、Pandora FMSのテーブルのいくつかに対してMYSQL OPTIMIZEツールを使用するというのがあります。

OPTIMIZE table tagente_datos;
OPTIMIZE table tagente;
OPTIMIZE table tagente_datos_string;
OPTIMIZE table tagent_access;
OPTIMIZE table tagente_modulo;
OPTIMIZE table tagente_estado;

この作業によって、パフォーマンスが改善されるでしょう。この作業は 1週間に複数回実行する必要はありません。システムの稼働中にさっと完了するでしょう。 巨大な環境においては、OPTIMIZE コマンドがブロックされるかもしれません。このような場合、一番よい代替案はDBの再構築です。

これらの作業を実施した後、以下のコマンドを実行すべきです。

FLUSH TABLES;

MySQLのマニュアルから、

InnoDB のテーブルに対しては OPTIMIZE TABLE は ALTER TABLE にマップされており、インデックス統計の更新とクラスタされたインデックス内の使用されていないスペースを解放するためにテーブルが再構築されます。

Info.png

7.0 OUM715 以降のインストールでは、デフォルトで以下の設定が適用されます。

 


注意: Pandora FMS バージョン 7.0 OUM 715 より前では、データベース(通常の DB とヒストリ DB 共)に以下の対応をすることをお勧めします。

alter table tagente_datos add index (id_agente_modulo,utimestamp);

この操作は、tagente_data テーブルにインデックスを追加します。以前よりも、レポートシステム、データのクエリ、モジュール、カスタムグラフで大幅に処理が短縮されます。

1.2.1.16 MySQL の特別なトークン

MySQL には、いくつかの "特別な" トークンがあります。これらは、パフォーマンスを良くしたり悪くしたりできます。"決まった"ルールは存在せず、それぞれの環境で確認する必要があります。しかし、通常は、システムを悪化させるよりも良くする手助けになるでしょう。

# Set to 0 in mysql 5.1.12 or higher
innodb_thread_concurrency            = 20

この innodb_thread_concurrency というパラメータは、5.1.12 以降のバージョンに存在し、0 の場合、平行処理の制限がなくなります。しかし、以前のバージョンでは、20を設定すると同様の意味になります。

innodb_flush_method = O_DIRECT

この重要なパラメータは、ディスクにデータをどう書くかに影響します。O_DIRECT に設定すると良いです。

innodb_lock_wait_timeout = 90

これは、データベースが長いトランザクションによりロックし"スタック"状態になったとき(mysqlはメッセージを出力しません)に有効です。ただし、もし、90以上のロックがあるのであれば、それは本当に何らかの問題がある場合です。

1.2.1.17 参考情報

参考:

1.2.2 MySQL Percona XTraDB

Percona は、MySQL の "ハイパフォーマンス" 版で、スケーラビリティ改善およびシステムの全 CPU を利用した高速化、また、ディスクのアクセス改善がされています。

percona サーバを設定するには、/etc/my.cnf を生成する、それ用のよくできた次の設定ウィザードを利用することができます。Percona 設定ウィザード

1.2.3 Pandora FMS のキャパシティ計測

この章では、高いキャパシティが必要な環境での Pandora FMS を設定するための異なる手法を説明します。また、処理を実行する環境を調整するのに便利な負荷テストを行うためのツールについても説明します。

Pandora FMS は、1つのサーバでデータベース、コンソール、サーバを動かした場合、2500エージェントに対応できるように設定されています。推奨するエージェント数は、1システムあたり 2500 です。しかし、この数は、XML エージェントの割合、リモートモジュールの割合、監視間隔、システムのメモリ量に応じて変化します。これらの全ての要素が、1つのシステムで管理できるエージェント数に関わります。テスト環境では、通常のハードウエアの 1台のサーバで 10000 エージェントを実行できましたが、高度な最適化をしています。

1.2.4 高キャパシティサーバの設定例

例えば、16GB の RAM および 4 CPU のマシンで、データサーバが最大のパフォーマンス (XML 処理) を出すように最適化したいと思います。

1.2.4.1 my.cnf

(重要なパラメータのみを示しています)

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
character-set-server=utf8
skip-character-set-client-handshake
# Disabling symbolic-links is recommended to prevent assorted    security risks
symbolic-links=0
# Mysql optimizations for Pandora FMS
# Please check the documentation in http://pandorafms.com for  better results
max_allowed_packet = 64M
innodb_buffer_pool_size = 800M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
thread_stack    = 256K
max_connections = 100
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 64M
query_cache_min_res_unit = 2k
query_cache_limit = 256K
sql_mode=""
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

1.2.4.2 pandora_server.conf

(重要なパラメータのみを示しています)

verbose 3
server_threshold 5
dataserver_threads 1
max_queue_files 5000

以下の点を認識しておく必要があります。

  • verbose の数は、どの程度の情報をログに書くかで、10を超える数字にはしないでください。数字を大きくすると、ログに多くの情報を書くため、Pandora FMS のパフォーマンスが下がります。
  • とても多くのスレッド (+5) は、ネットワークサーバやプラグインサーバのような、大きなキューの処理にのみ有効です。データサーバの場合、常に処理を実行しており、パフォーマンスを低下させる可能性があります。そのために、ここでは 5 に設定しています。DB が遅いシステムでは、スレッドを少なくするべきです。1 から 10 の間を試してみてください。ネットワークサーバの最適化の場合は、数は大きく、10 と 30 の間を試してみてください。
  • サーバの threshold が大きい (15) と、DB への影響が少なくなり、処理できる最大ファイル数が増加します。それにより、サーバは常にファイルを読み込むことができ、バッファに蓄えます。これらの 2つの設定要素は関連があります。ネットワークサーバの最適化では、threshold を低めの 5 か 10 にすると良いでしょう。
  • agent_access (コンソールから設定できます) のようないくつかの設定パラメータは、Pandora FMS のパフォーマンスに多くの影響を与えます。

1.2.5 キャパシティ分析ツール (Capacity)

Pandora FMS には、ハードウエアおよびソフトウエアで、取得可能なデータ量を適切に計測できるいくつかのツールがあります。一つは、ダミーデータで直接データベースへアクセスするもの (dbstress)、もう一つは、ダミーの XML ファイルを生成するもの (xml_stress) です。

1.2.5.1 Pandora FMS の XML 負荷

Pandora FMS エージェントから送られるような XML データファイルを生成する小さなスクリプトが /usr/share/pandora_server/util/pandora_xml_stress.pl にあります。

このスクリプトは、エージェント名をテキストファイルから読み込み、テンプレートでモジュールが定義されている設定ファイルに基づいて、各エージェントの XML データファイルを生成します。

モジュールの値はランダムな値になります。モジュールデータの初期値および変化率は設定可能です。

スクリプトは次のように実行します。

./pandora_xml_stress.pl <configuration file>

設定ファイルの例を示します。

# Maximum number of threads, by default 10.
max_threads 10

# File containing a list of agent names (one per line).
agent_file agent_names.txt

# Directory where XML data files will be placed, by default /tmp.
temporal /var/spool/pandora/data_in

# Pandora FMS XML Stress log file, logs to stdout by default.
log_file pandora_xml_stress.log

# XML version, by default 1.0.
xml_version 1.0

# XML encoding, by default ISO-8859-1.
encoding ISO-8859-1

# Operating system (shared by all agents), by default Linux.
os_name Linux

# Operating system version (shared by all agents), by default 2.6.
os_version 2.6

# Agent interval, by default 300.
agent_interval 300

# Data file generation start date, by default now.
time_from 2009-06-01 00:00:00

# Data file generation end date, by default now.
time_to 2009-06-05 00:00:00

# Delay after generating the first data file for each agent to avoid
# race conditions when auto-creating the agent, by default 2.
startup_delay 2

# Address of the Tentacle server where XML files will be sent (optional).
# server_ip 192.168.50.1

# Port of the Tentacle server, by default 41121.
# server_port 41121

# Module definitions. Similar to pandora_agent.conf.

module_begin
module_name Module_1
module_type generic_data
module_descripcion Module 1 description.
module_max 100
module_min 0
# Probability of the module data changing, by default 100%
module_variation 100
module_end

module_begin
module_name Module_2
module_type generic_data_string
module_descripcion Module 2 description.
# Maximum string length, by default 0.
module_max 20
# Minimum string length, by default 0
module_min 10
module_end

module_begin
module_name Module_3
module_type generic_proc
module_descripcion Module 3 description.
# Initial data.
module_data 1
module_end
1.2.5.1.1 エージェントのローカル設定の送受信

"pandora_xml_stress.conf" で、"get_and_send_agent_conf" を 1 に設定して実行した場合、テスト負荷エージェントで、通常のエージェントのように設定ファイルおよび md5 を送ることができます。エンタープライズ版の Pandora コンソールでは、pandora_xml_stress で次に何を実行するのか、リモートでの設定変更を行うことができます。pandora_xml_stress.conf ではなく、エンタープライズ版の Pandora コンソールから行った設定を利用するようになります。

ほかにも、"pandora_xml_stress.conf" 内の "directory_confis" にて、テストエージェントの設定をどこに保存するかをい設定できます。

1.2.5.1.2 設定ファイル
  • max_threads スクリプトの実行スレッド数。処理率を改善します。
  • agent_file 行ごとに名前を書いたファイルのパス。
  • temporal 架空の XML データファイルを生成するディレクトリのパス。
  • log_file スクリプトの実行について情報を出力するログのパス。
  • xml_version XML データファイルのバージョン。(デフォルトは 1.0)
  • encoding XML データファイルのエンコーディング。(デフォルトは ISO-8859-1)
  • os_name 仮想エージェントの OS 名。(デフォルトは Linux)
  • os_version 仮想エージェントの OS バージョン。(デフォルトは 2.6)
  • agent_interval 仮想エージェントの実行秒間隔。(デフォルトは 300)
  • time_from 仮想 XML データの開始時間。"年-月-日 時間:分:秒" というフォーマットにて。
  • time_to 仮想 XML データの終了時間。"年-月-日 時間:分:秒" というフォーマットにて。
  • get_and_send_agent_conf 0 または 1 の値です。有効な場合、仮想エージェントは、リモート設定により、より新しいエージェントの設定ファイルをダウンロードしようとします。Pandora FMS Enterprise のコンソールから編集可能になります。
  • startup_delay それぞれのエージェントがファイル生成を開始するまでの時間を秒で指定します。競合を回避するために利用します。
  • timezone_offset タイムゾーンのオフセット値です。
  • timezone_offset_range ランダムに指定した範囲でタイムゾーンを生成します。
  • latitude_base 数値です。仮想エージェントを表示する緯度です。
  • longitude_base 数値です。仮想エージェントを表示する経度です。
  • altitude_base 数値です。仮想エージェントを表示する高度です。
  • position_radius 数値です。指定した半径内の円に仮想エージェントがランダムに表示されます。
1.2.5.1.3 モジュール定義

スクリプト設定の中に一つのモジュール定義があり、リモート設定を有効にした場合も一緒で、次の通りです。

module_begin
module_name <モジュール名>
module_type <タイプ, 例: generic_data>
module_description <説明>
module_exec type=<タイプ>;<; 区切りの他のオプション>
module_unit <ユニット>
module_min_critical <値>
module_max_critical <値>
module_min_warning <値>
module_max_warning <値>
module_end

それぞれの項目は次のように設定可能です。

  • <タイプ>: RANDOM,SCATTER,CURVEのいずれかを設定できます。
  • module_attenuation <値>: モジュールの値を指定した値で掛け合わせます。通常 0.1 と 0.9 の間です。
  • module_attenuation_wdays <値> <値> ... <値>: 指定した日にのみモジュールの値を計算します。日曜(0) から土曜(6) を指定できます。例えば、以下のモジュールでは、土曜と日曜にネットワークトラフィックを 50% にします。
module_begin
module_name Network Traffic
module_type generic_data
module_description Incoming network traffic (Kbit/s)
module_exec type=RANDOM;variation=50;min=0;max=1000000
module_unit Kbit/s
module_min_critical 900000
module_attenuation 0.5
module_attenuation_wdays 0 6
module_end
  • module_incremental <値>: 1に設定すると、モジュールの以前の値を常に新たな値に加えます。値が増え続ける機能です。
  • その他: 実効タイプに依存して、どのようなオプションがあるかは以下を確認してください。

min/max_critical および min/max_warning は、バージョン 5.0 以上にのみであることに注意してください。

1.2.5.1.3.1 RANDOM

次のオプションがあります。

  • variation 前回の値から変化が発生する可能性を % で指定します。
  • min 値の最小値を指定します。
  • max 値の最大値を指定します。

Numeric

minmax の間の数値をランダムに生成します。

Boleans

0 または 1 の値を生成します。

String

minmax の間の長さの文字列を生成します。文字は、A から Z の間のランダムで、大文字、小文字を含み、また数字や記号を含みます。

1.2.5.1.3.2 外部データソース (SOURCE)

データのソースとしてプレーンテキストファイルを利用することができます。次のオプションがあります。

  • src: ソースデータファイル

ファイルは、1行に1データを含む形式で、行数に制限はありません。例えば次の通りです。

4
5
6
10

二種類のデータ(数値と文字列)を扱うことができます。これらのモジュールは、ファイルのデータ順番に読み込んで、Pandora でのモジュールデータを生成します。上記のデータの例では、次のように表示されます。

4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10
1.2.5.1.3.3 SCATTER

数値データの場合のみ有用で、ハートビートのようなグラフを生成します。これは通常の値で、ある時間に "beat" を出します。

次のオプションがあります。

  • min とりうる最小の値。
  • max とりうる最大の値。
  • prob "beat" を生成する頻度を % で指定します。
  • avg "beat" が無い場合に、デフォルトで表示する平均値。
1.2.5.1.3.4 CURVE

三角関数を使った曲線でモジュールデータを生成します。 次のオプションがあります。

  • min とりうる最小の値。
  • max とりうる最大の値。
  • time_wave_length 山が出現する時間。
  • time_offset モジュールの値が 0 の時の波形の開始タイミングを秒で指定します。(正弦波に似ています)
Curve module xml stress.v2.png
1.2.5.1.4 注意事項

開始日時(time_from)と終了日時(time_to)の間に生成されるファイルの量と、エージェントの実行間隔(agent_interval)には十分注意してください。長い期間で短い実行間隔の場合、スクリプトは大量の XML ファイルを生成します。

1.2.5.2 データサーバの処理能力の計測方法

"pandora_count.sh" というスクリプトが Pandora FMS サーバパッケージの /util ディレクトリにあります。このスクリプトは、データサーバの XML ファイル処理率を計測するのに利用します。このツールは、/var/spool/pandora/data_in に残っているファイルを利用します。そのため、未処理の数千のファイルを用意しておく (もしくは前述のツールで生成しておく) 必要があります。このスクリプトは、現在存在するファイルをカウントし、10秒前に処理したものを除外し、結果を 10 で割ることによって、1秒間の処理率を求めています。これは初歩的なソリューションですが、サーバの設定を修正するための情報を提供します。

1.2.5.3 Pandora FMS の DB 負荷

データベースパフォーマンスを確認するためのツールがあります。これはまた、架空のデータを定期的もしくは不定期に生成するためにも利用できます。エージェントを作成し、このツールを使って自動的にデータを挿入するためのモジュールを作成しておく必要があります。

  • random: 不定期データを生成します。
  • curve: 三角関数を利用して曲線データを生成します。異なる間隔で補完を見るのに便利です。
  • boolean: ランダムな boolean データを生成します。

random, curve および boolean という語を含む任意の名前を使うことができます。

  • random_1
  • curve_other

data_server モジュールのみ選択することができます。


1.2.5.3.1 Pandora FMS の DB 負荷 ツールの調整

このツールは、すべてのエージェントから、randomcurve または boolean という名前がついかモジュールを検索するようにあらかじめ設定されています。また、実行間隔は 300秒から 30日の間を指定できます。

もしこの設定を変更したい場合は、pandora_dbstress スクリプトを編集し、ファイルの先頭にあるいくつかの変数を変更する必要があります。

# Configure here target (AGENT_ID for Stress)
my $target_module = -1; # -1 for all modules of that agent
my $target_agent = -1;
my $target_interval = 300;
my $target_days = 30;

最初の行の target_module の設定では、対象のモジュールを指定するか -1 を指定すると全てが対象になります。 2行目の target_agent は、エージェントの指定です。 3行目の target_interval は、秒単位で実行間隔を指定します。 4行目の target_days は、現在日時から何日後までかを表します。

1.3 Pandora FMS の診断ツール

時々、ユーザが問題に遭遇し、Pandora の開発者もユーザのシステムについての詳細情報が無くて手助けできないことがあります。バージョン 3.0 では、ユーザの問題を解決する手助けとなる 2つの小さなツールを作成しました。

1.3.1 診断情報

Pandora FMS の最新バージョンには、Pandora FMS のインストールに関する診断情報を取得する機能があります。

それは、管理ツール(Admin tools) -> 診断情報(Diagnostic Info) にあります。

Diagnostic Info.png

このウインドウでは、Pandora FMS と MySQL の設定情報を見ることができるのに加えて、自己監視システムのグラフを見ることができます。

1.3.2 pandora_diagnostic.sh

/usr/share/pandora_server/util にあるツールで、システムの多くの情報を取得します。

  • CPU 情報
  • Uptime および CPU ロードアベレージ
  • Memory 情報
  • Kernel/Release 情報
  • mysql 設定ファイルの内容
  • PandoraFMS サーバ設定ファイルの内容 (パスワードはフィルタリングされます)
  • Pandora FMS ログ情報 (ただし、全ログではありません)
  • Disk 情報
  • Pandora FMS プロセス情報
  • kernel ログ情報 (dmesg)

すべての情報は、.txt ファイル内に生成されるので、この情報を手助けしてくれる人に送信することができます。たとえば、Pandora FMS ユーザフォーラムや Pandora FMS public メーリングリストなどです。この情報には、機密情報は含まれません。pandora_server.conf および my.cnf ファイルの内容を取得したい場合は、root 権限で実行する必要があることに注意してください。

以下に実行例を示します。

$ ./pandora_diagnostic.sh 
 
Pandora FMS Diagnostic Script v1.0 (c) ArticaST 2009
http://pandorafms.org. This script is licensed under GPL2 terms
 
Please wait while this script is collecting data
  
Output file with all information is in '/tmp/pandora_diag.20090601_164511.data'

また、出力ファイルの例を示します。

Information gathered at 20090601_164511
Linux raz0r 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009 i686 GNU/Linux
=========================================================================
-----------------------------------------------------------------
CPUINFO
-----------------------------------------------------------------
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
.
.
-----------------------------------------------------------------
Other System Parameters
-----------------------------------------------------------------
Uptime:  16:45:11 up  5:27,  2 users,  load average: 0.11, 0.12, 0.09
-----------------------------------------------------------------
PROC INFO (Pandora)
-----------------------------------------------------------------
slerena  11875  0.9  2.1 114436 44336 pts/0    Sl   13:14   1:56 gedit pandora_diagnostic.sh
slerena  24357  0.0  0.0   4452  1524 pts/0    S+   16:45   0:00 /bin/bash ./pandora_diagnostic.sh
-----------------------------------------------------------------
MySQL Configuration file
-----------------------------------------------------------------
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
.
.
.
-----------------------------------------------------------------
Pandora FMS Logfiles information
-----------------------------------------------------------------
total 3032
drwxr-xrwx  2 root    root       4096 2009-04-30 20:00 .
drwxr-xr-x 17 root    root       4096 2009-06-01 11:24 ..
-rw-r-----  1 root    sys      377322 2009-04-06 00:12 pandora_agent.log
-rw-r--r--  1 root    root          0 2009-04-06 00:15 pandora_agent.log.err
-rw-r--r--  1 root    root      13945 2009-04-02 21:47 pandora_alert.log
-rw-r--r--  1 slerena slerena 2595426 2009-04-30 20:02 pandora_server.error
-rw-rw-rw-  1 root    root       9898 2009-04-30 20:02 pandora_server.log
-rw-rw-rw-  1 root    root      65542 2009-04-30 20:00 pandora_server.log.old
-rw-r--r--  1 root    root         94 2009-04-06 00:19 pandora_snmptrap.log
-rw-rw-rw-  1 root    root          4 2009-04-03 14:16 pandora_snmptrap.log.index
-----------------------------------------------------------------
System disk
-----------------------------------------------------------------
S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda6              91G   49G   37G  58% /
tmpfs                1003M     0 1003M   0% /lib/init/rw
varrun               1003M  260K 1002M   1% /var/run
varlock              1003M     0 1003M   0% /var/lock
udev                 1003M  184K 1002M   1% /dev
tmpfs                1003M  480K 1002M   1% /dev/shm
lrm                  1003M  2,4M 1000M   1% /lib/modules/2.6.28-12-generic/volatile
-----------------------------------------------------------------
Vmstat (5 execs)
-----------------------------------------------------------------
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0      0 684840 119888 619624    0    0    15    10  258  474  3  1 95  0
 0  0      0 684768 119888 619640    0    0     0     0  265  391  0  0 100  0
 0  0      0 684768 119892 619636    0    0     0    56  249  325  1  1 99  0
 0  0      0 684768 119892 619640    0    0     0     0  329  580  0  0 100  0
 0  0      0 684776 119892 619640    0    0     0     0  385 1382  1  0 99  0
-----------------------------------------------------------------
System dmesg
-----------------------------------------------------------------
[    0.000000] BIOS EBDA/lowmem at: 0009f000/0009f000
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.28-12-generic ([email protected]) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) )   #43-Ubuntu SMP Fri May 1 
19:27:06 UTC 2009 (Ubuntu 2.6.28-12.43-generic)
.
.
-----------------------------------------------------------------
END OF FILE
-----------------------------------------------------------------
560e8fa02818916d4abb59bb50d91f6a  /tmp/pandora_diag.20090601_164511.data