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必要です。巨大なシステムであれば、4GiB割り当てるというのもよいでしょう。メモリが十分あれば、利用されるインデックスの大半をメモリ上に置くことでインデックスの更新が高速化されるということを忘れてはいけません。

その他アドバイスとして、テーブルの転送を使っているかどうか不明であったり、大きなハードディスクを使っていて、長時間のファイルチェックを避けたいのであれば、UPS を使うと良いでしょう。これはシステム障害を回避するには良い考えです。また、特定のサーバにデータベースがあるようなシステムでは、1G のネットワークを使うべきです。遅延は、パフォーマンスにとって重要です。

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

GNU/Linux では、ディスクに対して一定時間に複数のセクタを読み書きするように、hdparm-m16 -d1 を起動時に設定してください。これにより、応答時間が 5-50% 改善します。別のアイデアとしては、ディスクのパラメータに async (事前設定) や noatime を設定するのも良いです。これらの設定では、ファイルの読み書き時にアクセス時間を更新しません。特定のアプリケーションでは、特定のテーブルに対して RAM ディスクを設定をするのも良い考えです。ただし、不揮発性ディスクに書き込まずに電源 OFF になった場合のリスクはあります。良く検討をお願いします。

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

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

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

  • レプリケーションを利用しない場合は、バイナリログを出力しない。
  • slowquery または debug ログを出力しない。
  • MySQL の設定ファイルを確認。デフォルトの値は *遅い* です。
1.2.1.1.1 MySQL のバージョンについて

何人かのユーザは、よりパフォーマンスの高い Percona 修正版の MySQL 使って、高負荷の Pandora FMS サーバを運用しています。

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 サーバを再起動します。

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

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

innodb_log_file_size = 64M

この値はデフォルトで 5M で、良いパフォーマンスが出ません。我々は 64M をお勧めしますが、このドキュメントの範囲を超えて、状況によっては 128M や 256M に増やすことも可能です。

稼働中のシステムで値を変更するには、フルバックアップ(SQL ダンプ)を行い、データベースを停止し、ib_logfile* (通常は /var/lib/mysql にあります) を削除します。my.cnf を編集し、サーバを再起動します。サーバは、新たなトランザクションログファイルを新たなサイズで再生成し、通常通り動きだします。

innodb_io_capacity = xxx

この設定は、"どれだけ早く" MySQL がディスクへの書き込みを行うかを定義します。通常の 7500 RPM ディスクは 100 IOPS で、15000 RPM ディスクでは 180 IOPS、SSD であれば 1500 IOPS で書き込むことができます。実際の値を設定すると、MySQL はそれよりも早く書き込もうとします。低く設定すると、パフォーマンスを得られません。つまり、ハードディスクの IOPS がどれくらいかを正確に知ることが重要です。良い方法がなければ、smartctl を使ってデバイスのモデルを確認し、その平均速度を google で検索してみてください。:-)

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


Reference: http://tag1consulting.com/InnoDB_Performance_Tuning

1.2.1.6 KeyBuffer の大きさ

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

key_buffer = 400M

1.2.1.7 他の重要なバッファ

いくつかの MySQL/Linux ディストリビューションでは、デフォルトで設定されていないいくつかのバッファがあります。これらのデフォルトパラメータの設定(設定が無い場合は追加)は、最終的なパフォーマンスにとても重要です。my.cnf ファイル内にこれらの設定があるかどうかをチェックすることが重要です。無ければ追加します。また、もちろん、(多くのメモリがあるなら増やす方向に)いくつかの値を変更します。

query_cache_size = 64M
query_cache_limit = 2M 
join_buffer_size = 16M

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 を 100倍高速にすることができます。パフォーマンスの問題がある場合は、MySQL の設定やデータベースに関する問題である可能性があります。

1.2.1.10.1 my.ini/cnf 設定の確認

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

key_buffer = 32M  # Keep it low, MySQL will not use it in InnoDB!
max_allowed_packet = 64M # 64MB is a good value, do not alter.
query_cache_size = 128M # Can raise a bit if you have lots of RAM
query_cache_limit = 48M # Can raise a bit if you have lots of RAM
innodb_buffer_pool_size = 400M # Set to 1GB if you have 4GB ram, 2GB for 5GB ram, 3GB for 6GB RAM...
innodb_additional_mem_pool_size = 62M # Set to 100M if you have 4GB RAM, 200M if you have 5GB RAM...
innodb_lock_wait_timeout = 50
innodb_file_per_table = 1  # If is not set and you add it, you need to restart MySQL and RECREATE database (dump, drop, create, import)
innodb_flush_log_at_trx_commit = 0 # This Speedup a lot the inserts/deletes/updates
innodb_flush_method = O_DIRECT 
innodb_log_file_size = 64M    # Do not set higher than 256M
innodb_log_buffer_size = 16M  # Do not set higher than 64M
#innodb_io_capacity = 100 # 100 for 7500RPM disk, 180 for 15K RPM disk, 1500 for SSD disks. SET THE PROPER VALUE, HIGHER IF HARDWARE IS FAST; THIS IS VERY VERY IMPORTANT. This is only valid on MySQL 5.6 or higher
thread_stack = 64K # I don't recommend to alter this
thread_cache_size = 8 # I don't recommend to alter this
max_connections = 500 # I don't recommend to alter this
table_cache = 64 # I don't recommend to alter this

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

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

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

トランザクションログを削除し、サーバをもう一度再起動します。

rm /var/lib/mysql/ib_logfile*
/etc/init.d/mysqld restart

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.2 各テーブルごとに分割されたデータファイルがアクティブであるか確認
ls -lah /var/lib/mysql/pandora/*.ibd | wc -l

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

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

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

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 |
+--------+-------------------------+-------------+--------------+-----------+------------+
1.2.1.10.4 システム負荷

より一般的な事として、システムの(ディスク) 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 -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3279346
Server version: 5.0.67-Max SUSE MySQL RPM

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

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モジュールからなるシステムで、この処理全体で10~30分かかります。もし、システムが巨大だったり、ハードウェアの性能が劣っている場合は、それ以上かかるでしょう。この処理は自動化可能ですが、細心の注意が必要なため、毎月もしくは半月に一度、手動で実行することをお勧めします。

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

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
 chmod 777 / 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_thread_sleep_delay = 1000
innodb_concurrency_tickets = 250

これは、高負荷のシステムに影響し、キューの管理と参照が早くなります。

innodb_lock_wait_timeout = 180

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

1.2.1.17 設定例1

このサンプル設定は4CPU、4GiBメモリのサーバに2個のInnoDBデータベース(どちらも頻繁にアクセスされる)を作成したシステムで利用する想定で作成しました。 各変数に割り当てたメモリの合計がシステム全体のメモリ量の80%を超えないよう注意してください。 起動したMySQLサーバの状況を確認し、インストールしたシステムにあわせて調整してください。

パフォーマンスを評価するための一般的な見方として、以下の事項がパフォーマンスに大きく影響することに注意しましょう。

  • MySQLサーバでレプリケーション設定を使用する予定がないのであれば、binary logを出力しない
  • 一般クエリログやスロークエリーログを出力しない
# Sample configuration for a MySQL with ~3GB RAM dedicated to MySQL Process

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql

# -------------------------
# Innodb specific tokens
# -------------------------

# You need to create the tables AFTER using this parameters 
innodb_file_per_table

# Beware, you cannot change this two following parameters
# in an already running system or the database will be corrupted!
#innodb_log_files_in_group            = 2
#innodb_log_file_size                 = 200M

# This parameter gives about a 150% more performance, but in case of
# power failure, you will loss about 1-2 secs of data.
innodb_flush_log_at_trx_commit       = 0

innodb_buffer_pool_size              = 2G
innodb_additional_mem_pool_size      = 4M

innodb_flush_method                   = O_DIRECT
innodb_open_files                     = 700
innodb_thread_sleep_delay             = 1000
innodb_concurrency_tickets            = 250

# This will avoid some "MySQL gone away" shutdowns on long locking
innodb_lock_wait_timeout              = 180

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

# -------------------------
# Performance Parameters
# -------------------------

key_buffer 			     = 512M
max_allowed_packet                   = 64M
max_connections                      = 500
max_heap_table_size                  = 512M
read_buffer_size 		     = 16M
read_rnd_buffer_size 		     = 32M
join_buffer 			     = 2M
record_buffer 			     = 1M
table_cache                          = 128
sort_buffer_size                     = 4M
query_cache_min_res_unit             = 1K
query_cache_limit                    = 2M
query_cache_size                     = 100M
thread_stack                         = 128K
thread_cache_size                    = 8
skip-external-locking
max_delayed_threads                  = 25

# -------------------------
# Other parameters
# -------------------------

max_connections                      = 500
# OS Buffer to let connections waiting for Mysql thread.
back_log                             = 100
# Print warnings to the error log file.
log_warnings

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

################# /etc/my.cnf ###################

1.2.1.18 参考情報

参考:

1.2.2 MySQL Percona XTraDB

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

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

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

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

Pandora FMS は、1つのサーバでデータベース、コンソール、サーバを動かした場合、2000エージェントに対応できるように設定されています。推奨するエージェント数は、だいたい 1200 から 1500 くらいです。しかし、この数は、XML エージェントの割合、リモートモジュールの割合、監視間隔、システムのメモリ量に応じて変化します。これらの全ての要素が、1つのシステムで管理できるエージェント数に関わります。

1.2.4 incoming ディレクトリでの RAM ディスク (tmpfs) の利用

エージェントから大量の XML が送られてくるような環境では、/var/spool/pandora/data_in ディレクトリの大量の読み書きが発生します。このファイルシステムをメモリ上に置くと、XML 処理のパフォーマンスが 25% 上昇します。

/var/spool/pandora/data_in_RAM パーティションを作成するするには、次のコマンドを実行します。

mount -t tmpfs -o size=100M,nr_inodes=10k,mode=770 tmpfs /var/spool/pandora/data_in_RAM

/etc/inittab で設定すれば、システム起動時にこのパーティションが作成されます。なおディレクトリは作成済で空である必要があります。

tmpfs /var/spool/pandora/data_in_RAM tmpfs size=100M,nr_inodes=10k,mode=770 0 0

もちろん、これは 100MB の容量制限があります。いっぱいになると処理が停止します。ポリシーやリモート設定を使っている場合は、/data_in ディレクトリの下にそれらに必要なディレクトリ (collections, md5, conf およびその他) が存在します。これらも次のようなコマンドで、パスを調整する必要があります。

mv /var/spool/pandora/data_in /var/spool/pandora/data_in_old
ln -s /var/spool/pandora/data_in /var/spool/pandora/data_in_RAM
ln -s /var/spool/pandora/data_in_old/md5 /var/spool/pandora/data_in_RAM/md5
ln -s /var/spool/pandora/data_in_old/conf /var/spool/pandora/data_in_RAM/conf
ln -s /var/spool/pandora/data_in_old/collections /var/spool/pandora/data_in_RAM/collections

1.2.5 同一システムにおける多くのリクエスト

複数プロセッサ (2つ以上の物理コア) のサーバにおいて多くの処理を実行する必要がある場合、Pandora のいくつかのサーバの複数インスタンスを同一マシン上で上げることにより実現できます。これは、サーバのスレッド数を増やすということではなく、Linux kernel および Perl の仮想マシンの設計を使って、同一のプロセスで多くのスレッドを使うのではなく、複数のプロセスで多くのコアを使うという考えです。

Pandora FMS が遅延なく全ての情報を処理できないような場合にこの技術を使うことができます。この方法では、別の Pandora FMS サーバを別のディレクトリにインストールする必要があることを意味しています。もちろん、それぞれ別々のサーバ名で別々の pandora_server.conf があります。また、サーバの起動スクリプト等を若干修正する必要もあります。

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

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

1.2.6.1 my.cnf

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

# Mysql optimizations for Pandora FMS Example server 12GB RAM
# Please check the documentation in http://pandorafms.com for better results

max_allowed_packet = 64M
innodb_buffer_pool_size = 5G
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    = 128K
max_connections = 200

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 = 16M
query_cache_limit = 32M

sql_mode=""

1.2.6.2 pandora_server.conf

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

verbose 1
server_threshold 15
dataserver_threads 5
max_queue_files 1000

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

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

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

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

1.2.7.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.7.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.7.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.7.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.7.1.3.1 RANDOM

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

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

Numeric

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

Boleans

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

String

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

1.2.7.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.7.1.3.3 SCATTER

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

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

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

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

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

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

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

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

1.2.7.3 Pandora FMS の DB 負荷

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

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

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

  • random_1
  • curve_other

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


1.2.7.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_diag.php

これは、ウェブ診断ツールです。このリソースを利用するためには、アクティブなセッションを確保する必要があります。これにより、Pandora FMS データベースの利用状況、いくつかの設定値およびバージョンのデータを取得できます。このツールへは、次の URL を使ってコンソールからアクセスできます。

http://localhost/pandora_console/extras/pandora_diag.php

もし、Pandora FMS コンソールが別の URL であれば、その URL に /extras/pandora_diag.php を追加してください。

出力例

Pandora FMS Build	PC090512
Pandora FMS Version	v3.0-dev
Homedir	/var/www/pandora_console
HomeUrl	/pandora_console
tagente	2385
tagent_access	20049
tagente_datos	4342323
tusuario	19
Update Key	PANDORA-FREE
Updating code path	/var/www/pandora_console
Keygen path	/usr/share/pandora/util/keygen
Current Update #	0

このツールはまた、コマンドラインからも起動することができます。その場合、次のように Pandora FMS コンソールディレクトリのフルパスを記載する必要があります。

php /var/www/pandora_console/extras/pandora_diag.php /var/www/pandora_console

すると、スクリプトの実行結果が標準出力に出されます。

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