Pandora:Documentation ja:Anexo Volumetría

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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



Pandora FMS is a quite complex distributed application that has several key elements, that could be a bottleneck if it is not measured and configured correctly. The main aim of this study is to detail the scalability of Pandora FMS regarding on an specific serial of parameters to know the requirements that it could have if it gets an specific capacity.

Pandora FMS は、正しく設定しないとボトルネックになりうる複数の要素がある複雑なアプリケーションです。ここでは、特定のキャパシティを得るための必要条件を知るために、特定のパラメータに関する Pandora FMS のスケーラビリティの詳細を見ていきます。

Load test were made in a first phase, aimed to a cluster based system, with an unique Pandora server centralized in a DDBB cluster. The load test are also useful to observe the maximum capacity per server. In the current architecture model (v3.0 or higher), with N independent servers and with one "Metaconsole", this scalability tends to be linear, while the scalability based on centralized models isn't (it would be of the kind shown in the following graph)

最初は、クラスタを使ったシステムを対象にしたロードテストです。データベースクラスタの中に一つの Pandora サーバがあります。ロードテストは、サーバ一台ごとの最大のキャパシティを見るのに便利です。現在(バージョン 3.0以降)のアーキテクチャでは、N台の個別のサーバと一つのメタコンソールでスケーラビリティはリニアに伸びますが、一台のサーバではそうはなりません。(次のグラフに示します。)

Estudio vol0.png


The fact that Pandora compact data in real time, it's very important related to calculate the size the data will occupy. An initial study was done that related the way that a classic system stored data with the Pandora FMS "asynchronous" way of storing data. This could be seen in the schema that is included in this section.

実際に Pandora は、リアルタイムでデータを圧縮しています。これは、保存されるデータ量を計算するためにはとても重要です。最初に、データの保存方法に関して従来のシステムと Pandora FMS の "非同期" のデータ保存方法の違いについてみてみます。以下に図を示します。

Estudio vol01.png

In a conventional system


For a check, with an average of 20 checks per day, we have a total of 5 MB per year in filled space. For 50 checks per agent, it is 250 MB per year.

チェックを一日平均20実施すると、1年で 5MB の容量が必要です。エージェントあたり 50チェックでは、1年 250MB になります。

In a non conventional system, asynchronous like Pandora FMS

従来とは異なる Pandora FMS のような非同期システム

For a check, with an average of 0.1 variations per day, we have a total of 12,3 KB per year in filled space. For 50 checks per agent, this results in 615 KB per year.

チェックにおいて 1日平均 0.1の状態変化では、1年で 12.3KBの容量になります。エージェントあたり 50チェックでは、1年で 615KB です。


Next is described a glossary of specific terms for this study, for a better comprehension.


  • Fragmentation of the information: the information that Pandora FMS manages could have different performances: it could change constantly (e.g a CPU percentage meter), or be very static ( for example, determine the state of one service). As Pandora FMS exploits this to "compact" the information in the DB, it's a critical factor for the performance and the study of the capacity, so the more fragmentation, the more size in the DB and more capacity of process will be necessary to use in order to process the same information.
  • 情報の断片化: Pandora FMS が扱う情報によりパフォーマンスは変化します。情報には、常に変化するもの(CPUの使用率など)や、固定(あるサービスの状態など)のものがあります。Pandora FMS は、これらをデータベースに圧縮して保存します。これはパフォーマンスおよびキャパシティに対して重要な要素となります。そこで、より断片化し、データベースにたくさん保存し、処理量を増やすことが、同じ情報を処理するために必要となります。
  • Module: is the basic piece of the collected information for its monitoring. In some environments is known as Event.
  • モジュール: モニタリングにおいて情報を収集する基本的な単位です。いくつかの環境では、イベントでもあります。
  • Interval: is the amount of time that pass between information collects of one module.
  • 間隔: 一つのモジュールで情報を収集する時間間隔です。
  • Alert: is the notification that Pandora FMS executes when a data is out of the fixed margins or changes its state to CRITICAL or WARNING.
  • アラート: データがしきい値を越えたり状態が障害状態や警告状態になったときに、Pandora FMS が実行する通知です。



The study has been done thinking about a deployment divided in three main phases:

次の 3種類のパターンで設定を行う場合を考えてみます。

  • Stage 1: Deployment of 500 agents.
  • ステージ1: 500エージェントでの設定
  • Stage 2: Deployment of 3000 agents.
  • ステージ2: 3000エージェントでの設定
  • Stage 3: Deployment of 6000 agents.
  • ステージ3: 6000エージェントでの設定

In order to determine exactly Pandora's FMS requisites in deployments of this data volume, you should know very well which kind of monitoring you want to do. For the following study we have taken into account in an specific way the environment characteristics of a fictitious client named "QUASAR TECNOLOGIES" that could be summarized in the following points:

このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。

  • Monitoring 90% based on software agents.
  • 90% のモニタリングをソフトウエアエージェントで実施。
  • Homogeneous systems with a features serial grouped in Technologies/policies.
  • 技術/ポリシーでグループ化できる似たようなシステムがある。
  • Very changeable intervals between the different modules /events to monitor.
  • モニタするモジュールやイベント間で、実行間隔が異なる。
  • Big quantity of asynchronous information (events, log elements).
  • 大量の非同期情報がある(イベントやログなど)。
  • Lot of information about processing states with little probability of change.
  • あまり変化がない状態を確認する処理がたくさんある。
  • Little information of performance with regard to the total.
  • 全体的にパフォーマンスに関する情報は少ない。

After doing an exhaustive study of all technologies and determine the reach of the implementation (identifying the systems and its monitoring profiles), we have come to the following conclusions:


  • There is an average of 40 modules/events per system.
  • 1システムあたり、平均して 40個のモジュールやイベントが存在する。
  • The average monitoring interval is of 1200 seconds (20 min).
  • 平均モニタリング間隔は、1200秒(20分)である。
  • There are modules that reports information every 5 minutes and modules that does it once per week.
  • 5分ごとに情報を送ってくるモジュールもあれば、1週間に一度だけのモジュールもある。
  • From all the group of total modules (240,000), it has been determined that the possibility of change of each event for each sample is the 25%
  • 全グループの全モジュール (240,000) のうち、確認のたびに変更が発生する可能性があるのは 25% である。
  • It has been determined that the alert rate per module is 1,3 (that is: 1,3 alerts per module/event).
  • モジュールごとのアラート比率は 1.3 (モジュール/イベントごとに 1.3 アラート) である。
  • It is considered (in this case it's an estimation based on our experience) that an alert has 1% probabilities of being fired.
  • アラートの発生率は、1% と仮定する。(これは我々の経験上の予測です)

These conclusions are the basis to prepare the estimation, and are codified in the Excel spreadsheet used to do the study:

この結論は、予測を策定するための基本となります。理解しやすいように Excel シートにまとめてみます。

Estudio vol1.png

With these start up data, and applying the necessary calculations, we can estimate size in DDBB, nº of modules per second that are necessary to process and other essential parameters:


Estudio vol2.png


Once we've known the basic requirements for the implementation in each phase ( modules/second rate), nº of total alerts, modules per day, and MB/month, we're going to do a real stress test on a server quite similar to the production systems ( the test couldn't have been done in a system similar to the production ones).

それぞれのフェーズで実装のための基本的な要求事項 (秒あたりのモジュール実行数)、アラートの数、日ごとのモジュール実行数、月ごとの容量がわかったら、本番に近いシステムで実際にサーバの負荷テストを行います。(ここでのテストは、本番に近いシステムでは実行できていません。)

These stress tests will inform us of the processing capacity that Pandora FMS has in a server, and what is its degradation level with time. This should be useful for the following aims:

これらの負荷テストでは、Pandora FMS の処理能力がわかり、どの程度で性能劣化するかがわかります。これは、次のような目的において便利です。

  1. Through an extrapolation, know if the final volume of the project will be possible with the hardware given to do that.
  2. 対象のハードウエアで最大どれくらいの規模まで対応できるかを推定する場合。
  3. To know which are the "online" storage limits and which should be the breakpoints from which the information moves to the historic database.
  4. ストレージの限界および、ヒストリー DB へ情報を移すポイントを知りたい場合。
  5. To known the answer margins to the process peaks, coming from problems that could appear ( service stop, planned stops) where the information expecting for being processed would be stored.
  6. サービス停止や計画停止により、処理する情報がたまった場合の最大処理量に対する余裕を知りたい場合。
  7. To know the impact in the performance derived of the different quality (% of change) of the monitoring information.
  8. モニタ対象の情報の変化率が変わった場合のパフォーマンスに与える影響を知りたい場合。
  9. To know the impact of the alert process in big volumes.
  10. 大量のアラート処理の影響を知りたい場合。

The tests have been done on a DELL server PowerEdge T100 with 2,4 Ghz Intel Core Duo Processor and 2GB RAM. This server, working on an Ubuntu Server 8.04, has given us the base of our study for the tests on High Availability environments. The tests have been done on agent configurations quite similar to that of the QUASAR TECHNOLOGIES project, so we can't have available the same hardware, but replicate a high availability environment, similar to the QUASAR TECHNOLOGIES to evaluate the impact in the performance as times goes on and set other problems ( mainly of usability) derived from managing big data volume.

テストは、Intel Core Duo プロセッサ 2.5GHz および、メモリ 2GB を積んだ DELL のサーバ PowerEdge T100 にて実施しました。このサーバでは、Ubuntu Server 8.04 が動いており、HA 環境のテストに使っています。テストは、QUASAR TECHNOLOGIES プロジェクトに似たエージェント設定で実施しました。同じハードウエアではありませんが、同じような HA 環境で、WUASAR TECHNOLOGIES と似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。

Estudio vol3.png

The obtained results are very positives, so the system, though very overload, was able to process an information volume quite interesting (180,000 modulos, 6000 agentes, 120,000 alertas). The conclusions obtained from this study are these:


1. You should move the "real time" information to the historical database in a maximum period of 15 days, being the best thing to do it for more than one week data. This guarantee a more quick operation.

1. リアルタイムの情報は、最大 15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。

2. The maneuver margin in the best of cases is nearly of the 50% of the process capacity, higher than expected, taken into account this information volume.

2. 情報量を考慮して、処理の余裕は想定能力よりも高い最大能力の 50% ほどである。

3. The fragmentation rate of the information is vital to determine the performance and the necessary capacity for the environment where we want to deploy the system

3 システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。