| 両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン |
| ja:documentation:pandorafms:technical_annexes:03_capacity_planning [2024/08/16 03:29] – [データストレージと圧縮] junichi | ja:documentation:pandorafms:technical_annexes:03_capacity_planning [2024/10/14 06:48] (現在) – [概要] junichi |
|---|
| ===== 概要 ===== | ===== 概要 ===== |
| |
| [[en:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] is a complex distributed application that has different key elements, susceptible to represent a bottleneck if it is not sized and configured correctly. The purpose of this chapter is to help to carry out a capacity study, **to analyze the //scalability// of Pandora FMS according to a specific set of parameters**. This study will help to know the requirements that the installation should have to be able to support a certain capacity. | [[:en:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] is a complex distributed application that has different key elements, susceptible to represent a bottleneck if it is not sized and configured correctly. The purpose of this chapter is to help to carry out a capacity study, **to analyze the //scalability// of Pandora FMS according to a specific set of parameters**. This study will help to find out the requirements that the installation should have to be able to support a certain capacity. |
| |
| [[:ja:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] は、さまざまな主要要素を持つ複雑な分散アプリケーションであり、サイズと設定が適切でない場合、ボトルネックになりやすくなります。この章の目的は、キャパシティ スタディの実行、**Pandora FMS の //スケーラビリティ// を特定のパラメータ セットに従って分析する** ことです。このスタディは、特定のキャパシティをサポートするために必要なインストール要件を知るのに役立ちます。 | [[:ja:documentation:pandorafms:introduction:01_introduction|Pandora FMS]] は、さまざまな主要要素を持つ複雑な分散アプリケーションであり、サイズと設定が適切でない場合、ボトルネックになりやすくなります。この章の目的は、キャパシティ スタディの実行、**Pandora FMS の //スケーラビリティ// を特定のパラメータ セットに従って分析する** ことです。このスタディは、特定のキャパシティをサポートするために必要なインストール要件を知るのに役立ちます。 |
| |
| The load tests are also used to observe the maximum capacity per server. In the current architecture model ([[en:documentation:pandorafms:technical_reference:10_versions|version 3.0 or later]]), with "N" independent servers and a **[[en:documentation:pandorafms:command_center:01_introduction|Command Center (Metaconsole)]]** installed, this //scalability //tends to be of linear order, while //scalability// based on centralized models is exponential. | Load tests are also used to see the maximum capacity per server. In the current architecture model ([[:en:documentation:pandorafms:technical_reference:10_versions|version 3.0 or later]]), with "N" independent servers and a **[[:en:documentation:pandorafms:command_center:01_introduction|Command Center (Metaconsole)]]** installed, this //scalability //tends to be of linear order, while //scalability// based on centralized models is exponential. |
| |
| 負荷テストは、サーバあたりの最大容量を観察するためにも使用されます。現在のアーキテクチャモデル ([[ja:documentation:pandorafms:technical_reference:10_versions|バージョン 3.0 以降]]) では、"N" 台の独立したサーバと **[[ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター (メタコンソール)]]** がインストールされている場合、この //スケーラビリティ // は線形になる傾向がありますが、単一サーバモデルでの //スケーラビリティ// は指数関数的になります。 | 負荷テストは、サーバあたりの最大容量を観察するためにも使用されます。現在のアーキテクチャモデル ([[ja:documentation:pandorafms:technical_reference:10_versions|バージョン 3.0 以降]]) では、"N" 台の独立したサーバと **[[ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター (メタコンソール)]]** がインストールされている場合、この //スケーラビリティ // は線形になる傾向がありますが、単一サーバモデルでの //スケーラビリティ// は指数関数的になります。 |
| ==== 用語の定義 ==== | ==== 用語の定義 ==== |
| |
| Next is described a [[:en:documentation:01_understanding:03_glossary|glossary]] of **specific** terms for this study, for a better comprehension. | A [[en:documentation:pandorafms:introduction:03_glossary|glossary]] of terms specific to this study is described below: |
| |
| 次に、より理解を深められるように、ここで使われている[[:ja:documentation:01_understanding:03_glossary|用語]]について説明します。 | より理解を深められるように、ここで使われている[[:ja:documentation:pandorafms:introduction:03_glossary|用語]]について説明します。 |
| |
| * **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 static ( for example, determine the state of one service). As Pandora FMS exploits this to "//compact//" the information in the database (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. | * **Information fragmentation**: The information that Pandora FMS manages can have different behavior, either constantly changing (for example a CPU percentage meter) or being static (for example the status of a service). Since Pandora FMS takes advantage of this to //compact// the information in the database (DB), it is a critical factor for the performance and the capacity study, since the more fragmentation, the more size in the DB and the more processing capacity will be necessary to use to process the same information. |
| * **Module**: is the basic piece of the collected information for its monitoring. In some environments is known as Event, in others as a monitor and in others as a metric.. | * **Module**: This is the basic piece of information collected for monitoring. In some environments it is known as an Event, in others as a monitor and in others as a metric. |
| * **Interval**: is the amount of time that pass between information collects of one module. It is usually expressed in minutes or seconds. The "average" value is usually 5 minutes. | * **Interval**: The amount of time that elapses between data collections from a module. It is usually expressed in minutes or seconds. The "average" value is usually 5 minutes. |
| * **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''. | * **Alert**: This is the notification that Pandora FMS executes when a data goes out of established margins or changes its status to ''CRITICAL'' or ''WARNING''. |
| |
| * **情報の断片化**: Pandora FMS が扱う情報によりパフォーマンスは変化します。情報には、常に変化するもの(CPUの使用率など)や、固定(あるサービスの状態など)のものがあります。Pandora FMS は、これらをデータベースに圧縮して保存します。これはパフォーマンスおよびキャパシティに対して重要な要素となります。そこで、より断片化し、データベースにたくさん保存し、処理量を増やすことが、同じ情報を処理するために必要となります。 | * **情報の断片化**: Pandora FMS が扱う情報によりパフォーマンスは変化します。情報には、常に変化するもの(CPUの使用率など)や、固定(あるサービスの状態など)のものがあります。Pandora FMS は、これらをデータベースに圧縮して保存します。これはパフォーマンスおよびキャパシティに対して重要な要素となります。そこで、より断片化し、データベースにたくさん保存し、処理量を増やすことが、同じ情報を処理するために必要となります。 |
| * **間隔**: 一つのモジュールで情報を収集する時間間隔です。通常、分または秒で表されます。 "平均" 値は通常 5分です。 | * **間隔**: 一つのモジュールで情報を収集する時間間隔です。通常、分または秒で表されます。 "平均" 値は通常 5分です。 |
| * **アラート**: データがしきい値を越えたり状態が ''障害'' や ''警告'' になったときに、Pandora FMS が実行する通知です。 | * **アラート**: データがしきい値を越えたり状態が ''障害'' や ''警告'' になったときに、Pandora FMS が実行する通知です。 |
| | |
| | <wrap #ks2 /> |
| |
| ===== 容量考察の例 ===== | ===== 容量考察の例 ===== |
| |
| {{ :wiki:pfms-performance-optimization.png?nolink& }} | <wrap #ks2_1 /> |
| |
| ==== これまでの考察と対象範囲 ==== | ==== スコープの定義 ==== |
| |
| 次の 3種類のパターンで設定を行う場合を考えてみます。 | 次の 3種類のパターンで設定を行う場合を考えてみます。 |
| |
| * ステージ1: 500エージェントでの設定 | * Phase 1: Deployment of 500 agents. |
| * ステージ2: 3000エージェントでの設定 | * Phase 2: Deployment of 3000 agents. |
| * ステージ3: 6000エージェントでの設定 | * Phase 3: Deployment of 6,000 agents. |
| | |
| | * フェーズ1: 500エージェントでの設定 |
| | * フェーズ2: 3000エージェントでの設定 |
| | * フェーズ3: 6000エージェントでの設定 |
| |
| このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。 | このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。 |
| * アラートの発生率は、1% と仮定する。(これは我々の経験上の予測です) | * アラートの発生率は、1% と仮定する。(これは我々の経験上の予測です) |
| |
| この結論は、予測を策定するための基本となります。理解しやすいように Excel シートにまとめてみます。 | <wrap #ks2_2 /> |
| | |
| {{ :wiki:pfms-volumetric_and_capacity_studies-estimation.png }} | |
| | |
| これらの初期データに対して必要な計算をあてはめます。データベースのサイズおよび、モニタリングに必要となる一秒間あたりのモジュール実行数、その他パラメータを予測できます。 | |
| | |
| {{ :wiki:pfms-volumetric_and_capacity_essential_parameters.png?direct& }} | |
| |
| ==== キャパシティの考察 ==== | ==== キャパシティの考察 ==== |
| - 大量のアラート処理の影響を知りたい場合。 | - 大量のアラート処理の影響を知りたい場合。 |
| |
| The tests have been done on a **DELL server PowerEdge T100®** with 2,4 Ghz **Intel Core Duo®** Processor and 2 GB 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 is not 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. | The tests were performed on a **DELL PowerEdge T100®** server with an **Intel Core Duo**® 2.4 GHz processor and 2 GB of RAM. This server, running on a **Ubuntu Server** 8.04, has provided the study base for the tests in High Capacity environments. The tests have been performed on agent configurations relatively similar to those of the QUASAR TECHNOLOGIES project. The intention of the tests is not to replicate exactly the same volume of information that QUASAR TECHNOLOGIES is going to have, since the same hardware is not available, but to replicate a high capacity environment, similar to QUASAR TECHNOLOGIES to evaluate the impact on performance over time and to determine other issues (mainly performance) arising from handling large volumes of data. |
| |
| テストは、**Intel Core Duo** プロセッサ 2.5GHz および、メモリ 2GB を積んだ **DELL のサーバ PowerEdge T100** にて実施しました。このサーバでは、Ubuntu Server 8.04 が動いており、HA 環境のテストに使っています。テストは、QUASAR TECHNOLOGIES プロジェクトに似たエージェント設定で実施しました。同じハードウエアではありませんが、同じような HA 環境で、WUASAR TECHNOLOGIES と似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。 | テストは、**Intel Core Duo** プロセッサ 2.4GHz および、メモリ 2GB を積んだ **DELL のサーバ PowerEdge T100** にて実施しました。このサーバでは、Ubuntu Server 8.04 が動いており、HA 環境のテストに使っています。テストは、QUASAR TECHNOLOGIES プロジェクトに似たエージェント設定で実施しました。同じハードウエアではありませんが、同じような HA 環境で、WUASAR TECHNOLOGIES と似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。 |
| |
| {{ :wiki:pfms-volumetric_and_capacity_probability_of_change.png }} | {{ :wiki:estudio_vol3.png }} |
| |
| 得られた結果はとても良く、システムは非常に過負荷にもかかわらず、非常に興味深い情報量を処理することができました(180,000モジュール、6000エージェント、120,000アラート）。これから得られた結論は次の通りです。 | 得られた結果はとても良く、システムは非常に過負荷にもかかわらず、非常に興味深い情報量を処理することができました(180,000モジュール、6000エージェント、120,000アラート）。これから得られた結論は次の通りです。 |
| |
| 1. リアルタイムの情報は、最大 15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。 | - The "real time" information should be moved to the historical database within a maximum of 15 days, optimally for data older than one week. This guarantees a faster operation. |
| | - The margin of maneuver in the optimal case is almost 50% of processing capacity, higher than expected considering this volume of information. |
| | - The information fragmentation rate is key to determine the performance and capacity required for the environment where the system needs to be deployed. |
| |
| 2. 情報量を考慮して、処理の余裕は想定能力よりも高い最大能力の 50% ほどである。 | - リアルタイムの情報は、最大 15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。 |
| | - 情報量を考慮して、処理の余裕は想定能力よりも高い最大能力の 50% ほどである。 |
| | - システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。 |
| |
| 3 システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。 | <wrap #ks3 /> |
| |
| ===== 詳細方法論 ===== | ===== 詳細方法論 ===== |
| |
| 次のステップは、監視のタイプまたは情報の出所に基づいて、システム容量を計算する方法です。 | 次のステップは、監視のタイプまたは情報の出所に基づいて、システム容量を計算する方法です。 |
| | |
| | <wrap #ks3_1 /> |
| |
| ==== データサーバ ==== | ==== データサーバ ==== |
| |
| Based on the achievement of certain targets, as we have seen in the previous point, we suppose that the estimated target, is to see how it works wiht a load of 100,000 modules, distributed between a total of 3000 agents, that is, an average of 33 modules per agent. | Based on some objectives, calculated according to the previous point, it will be assumed that the estimated objective is to see how it behaves with a load of 100,000 modules, distributed among a total of 3,000 agents, that is, an average of 33 modules per agent. |
| |
| 前のポイントで見たように、特定の目的に基づいて考えます。合計 3000 のエージェントに分散された 100,000 モジュールの負荷、つまり平均でエージェントあたり 33モジュールでどのような負荷で動作するかを確認したいと想定します。 | 前のポイントで見たように、特定の目的に基づいて考えます。合計 3000 のエージェントに分散された 100,000 モジュールの負荷、つまり平均でエージェントあたり 33モジュールでどのような負荷で動作するかを確認したいと想定します。 |
| |
| A [[:en:documentation:05_big_environments:08_optimization|task will be created]] of ''pandora_xmlstress'' , executed through **cron** or manual script, that has 33 modules, distributed with a configuration similar to this one: | It [[en:documentation:pandorafms:complex_environments_and_optimization:08_optimization#ks2_2_1|will create a task]] of ''pandora_xmlstress'' executed by **cron** or script) manually, containing 33 modules, distributed with a configuration similar to this one: |
| |
| ''pandora_xmlstress'' の[[:en:documentation:05_big_environments:08_optimization|タスクを作成]]し、**cron** または手動スクリプトを介して実行します。33個のモジュールがあり、次のような設定で展開されます。 | ''pandora_xmlstress'' の[[:ja:documentation:pandorafms:complex_environments_and_optimization:08_optimization#ks2_2_1|タスクを作成]]し、**cron** または手動スクリプトを介して実行します。33個のモジュールがあり、次のような設定で展開されます。 |
| |
| * 1 module type string. | * 1 chain type modules. |
| * 17 modules type ''generic_proc''. | * 17 modules of type ''generic_proc''. |
| * 15 modules type ''generic_data''. | * 15 modules of type ''generic_data''. |
| |
| * 文字列タイプの 1モジュール | * 文字列タイプの 1モジュール |
| * ''generic_data'' タイプの 15モジュール | * ''generic_data'' タイプの 15モジュール |
| |
| We will configure the thresholds of the 17 modules of ''generic_proc'' type this way: | The thresholds of the 17 modules of type ''generic_proc'' will be configured in this way: |
| |
| ''generic_proc'' タイプの 17個のモジュールのしきい値を次のように設定します。 | ''generic_proc'' タイプの 17個のモジュールのしきい値を次のように設定します。 |
| |
| <file> | <file> |
| |
| module_begin | module_begin |
| module_name Process Status X | module_name Process Status X |
| </file> | </file> |
| |
| In the 15 modules of ''generic_data'' type, we should define thresholds. The procedure to follow is the following: | Thresholds must be established in the 15 modules of type ''generic_data''. The procedure to be followed is as follows: |
| |
| ''generic_data'' タイプの 15個のモジュールでは、しきい値を定義する必要があります。 手順は次の通りです。 | ''generic_data'' タイプの 15個のモジュールでは、しきい値を定義する必要があります。 手順は次の通りです。 |
| |
| We should configure the thresholds of the 15 modules of ''generic_data'' type so data of this type will be generated: | The thresholds of the 15 modules of type ''generic_data'' will be configured to generate type data: |
| |
| このタイプのデータが生成されるように、''generic_data'' タイプの 15個のモジュールのしきい値を設定する必要があります。 | このタイプのデータが生成されるように、''generic_data'' タイプの 15個のモジュールのしきい値を設定する必要があります。 |
| |
| <file> | <file> |
| module_exec type=SCATTER;prob=20;avg=10;min=0;max=100 | module_exec type=SCATTER;prob=20;avg=10;min=0;''m''ax=100 |
| |
| </file> | </file> |
| |
| Then, we configure the thresholds for these 15 modules, so they have this pattern: | The thresholds for these 15 modules will be configured to have this pattern: |
| |
| これらの 15個のモジュールのしきい値を設定すると、次のパターンになります。 | これらの 15個のモジュールのしきい値を設定すると、次のパターンになります。 |
| |
| <file> | <file> |
| 0-50 normal | 0-50 normal |
| 50-74 warning | 50-74 warning |
| 75- critical | 75- critical |
| |
| </file> | </file> |
| |
| We add to the configuration file of our ''pandora_xml_stress'' some new tokens, to could define the thresholds from the XML generation. Attention: Pandora FMS only "adopts" the definition of thresholds in the creation of the module, but not in the update with new data. | New tokens will be added to the ''pandora_xml_stress'' configuration file to be able to define the thresholds from the XML generation. Attention: this because Pandora FMS only "adopts" the thresholds definition in the module creation, **but not in the update with new data**. |
| |
| ''pandora_xml_stress'' の設定ファイルにいくつかの新しいトークンを追加して、XML 生成からのしきい値を定義できるようにします。 重要: Pandora FMS は、モジュールの作成時にしきい値の定義を採用するだけで、新しいデータの更新には利用されません。 | ''pandora_xml_stress'' の設定ファイルにいくつかの新しいトークンを追加して、XML 生成からのしきい値を定義できるようにします。 重要: Pandora FMS は、モジュールの作成時にしきい値の定義を採用するだけで、新しいデータの更新には利用されません。 |
| ''pandora_xml_stress'' を実行します。 | ''pandora_xml_stress'' を実行します。 |
| |
| Should let it running at least for 48 hours without any kind of interruption and we should monitor (with a Pandora FMS agent) the following parameters: | It should be left running for at least 48 hours without any kind of interruption and should monitor (with a Pandora FMS agent) the following parameters: |
| |
| 中断することなく少なくとも 48時間実行し、次のパラメーターを(Pandora FMS エージェントを使用して)監視する必要があります。 | 中断することなく少なくとも 48時間実行し、次のパラメーターを(Pandora FMS エージェントを使用して)監視する必要があります。 |
| |
| Number of queued packages: | * Number of glued packages: |
| |
| キューに入っているデータ数: | * キューに入っているデータ数: |
| |
| <file> | <code bash> |
| find /var/spool/pandora/data_in | wc -l | find /var/spool/pandora/data_in | wc -l |
| |
| </file> | </code> |
| |
| <font inherit/inherit;;inherit;;rgb(251, 250, 249)>PFMS server</font>CPU: | * ''pandora_server'' CPU: |
| |
| Pandora FMS サーバ CPU 使用率: | * ''pandora_server'' CPU 使用率: |
| | |
| <file> | |
| |
| | <code bash> |
| ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $3}' | ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $3}' |
| |
| </file> | </code> |
| |
| ''pandora_server'' total Memory: | * Total memory of **PFMS server**: |
| |
| ''pandora_server'' トータルメモリ: | * ''pandora_server'' トータルメモリ: |
| |
| <code> | <code bash> |
| | ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $4}' |
| ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $4}' | |
| |
| </code> | </code> |
| |
| CPU used by **mysqld** (check syntax of the execution, it depends of the MySQL distro) | * CPU of **mysqld** (check execution syntax which depends on the **MySQL** distribution used): |
| |
| **mysqld** による CPU 使用率(実行の構文を確認してください。MySQL ディストリビューションによって異なります。) | * **mysqld** による CPU 使用率(実行の構文を確認してください。MySQL ディストリビューションによって異なります。) |
| | |
| <file> | |
| |
| | <code bash> |
| ps aux | grep "sbin/mysqld" | grep -v grep | awk '{print $3}' | ps aux | grep "sbin/mysqld" | grep -v grep | awk '{print $3}' |
| |
| </file> | </code> |
| | |
| Pandora FMS DDBB response average time: | |
| |
| Pandora FMS データベース平均応答時間: | * Average response time of Pandora FMS DB: |
| |
| <code> | * Pandora FMS データベース平均応答時間: |
| |
| | <code bash> |
| /usr/share/pandora_server/util/pandora_database_check.pl /etc/pandora/pandora_server.conf | /usr/share/pandora_server/util/pandora_database_check.pl /etc/pandora/pandora_server.conf |
| |
| </code> | </code> |
| |
| Number of monitors in unknown state: | * Number of monitors in unknown status (''unknown''): |
| |
| 不明状態の監視項目数: | * 不明状態の監視項目数: |
| |
| <code> | <code bash> |
| echo "select SUM(unknown_count) FROM tagente;" | mysql -u pandora -p<password> -D pandora | tail -1 | echo "select SUM(unknown_count) FROM tagente;" | mysql -u pandora -p < password > -D pandora | tail -1 |
| |
| </code> | </code> |
| |
| (''<password>'' for ''pandora'' user.) | (where ''< password >'' is the password of the user ''pandora'') |
| |
| (''<password>'' は ''pandora'' ユーザのパスワードです。) | (''<password>'' は ''pandora'' ユーザのパスワードです。) |
| |
| The first executions should be useful to "tune" the server and the MySQL configuration. | The first executions should be used to tune the server and the **MySQL** configuration. |
| |
| 最初の実行は、サーバと MySQL 設定を "調整" するのに役立つはずです。 | 最初の実行は、サーバと MySQL 設定を "調整" するのに役立つはずです。 |
| |
| Use the script ''/usr/share/pandora_server/util/pandora_count.sh'' to count (if are XML files pending to process) the rate of package proccessing. The aim is to make possible that all the packages generated (3000) could be processed in an interval below the 80% of the limit time (5 minutes). This implies that 3000 packages should be processed in 4 minutes, so: | The script ''/usr/share/pandora_server/util/pandora_count.sh'' will be used to count (when there are XML files pending to process) the packet processing rate. The objective is to achieve that all the generated packets (3000) can be "processed" in an interval less than 80 % of the time limit (5 minutes). This implies that 3000 packets have to be processed in 4 minutes, then: |
| |
| スクリプト ''/usr/share/pandora_server/util/pandora_count.sh'' を使用して、データの処理速度をカウントします(XML ファイルの処理が保留されている場合)。 目的は、生成されたすべてのデータ(3000)を、制限時間(5分)の 80% 未満の間隔で処理できるようにすることです。これは、3000個のデータを 4分で処理する必要があることを意味します。 | スクリプト ''/usr/share/pandora_server/util/pandora_count.sh'' を使用して、データの処理速度をカウントします(XML ファイルの処理が保留されている場合)。 目的は、生成されたすべてのデータ(3000)を、制限時間(5分)の 80% 未満の間隔で処理できるようにすることです。これは、3000個のデータを 4分で処理する必要があることを意味します。 |
| |
| <file> | <file> |
| | 3000 / (4 x 60) = 12.5 |
| 3000 / (4x60) = 12.5 | |
| |
| </file> | </file> |
| |
| It should get a processing rate of 12.5 packages minimum to be reasonably sure that Pandora FMS could process this information. | A processing rate of at least 12.5 packets must be achieved to be reasonably sure that Pandora FMS can process that information. |
| |
| Pandora FMS がこの情報を処理できることを合理的に確認するには、最低 12.5 個のデータ処理速度が必要です。 | Pandora FMS がこの情報を処理できることを合理的に確認するには、最低 12.5 個のデータ処理速度が必要です。 |
| |
| Elements for adjust: | Elements to be adjusted: |
| |
| 調整要素: | 調整要素: |
| |
| * Number of threads. | * Number of threads. |
| * Number maximum of items in intermediate queue (''max_queue_files''). | * Maximum number of elements in intermediate queue (''max_queue_files''). |
| * Of course, all the parameters of MySQL that are applicable (very important). | * Of course, all relevant **MySQL** parameters (very important). |
| |
| * スレッド数 | * スレッド数 |
| * もちろん、適用可能な MySQL のすべてのパラメーター(非常に重要) | * もちろん、適用可能な MySQL のすべてのパラメーター(非常に重要) |
| |
| <WRAP center round tip 60%>Importance of this: One Pandora with a GNU/Linux server installed "by default" in a powerful machine, could not exceed from 5-6 packages by second, in a powerful machine well "optimized" and "tuned" it could perfectly reach 30-40 packages by second. **It also depends a lot of the number of modules that would be in each agent**.</WRAP> | <WRAP center round tip 90%> |
| |
| <WRAP center round tip 60%>これの重要性：強力なマシンに "デフォルト" でインストールされた GNU/Linux サーバ 1台で、Pandora は、毎秒 5〜6 データを超えることはできませんが、十分に "最適化" および "調整" された強力なマシンでは、毎秒 30-40 データまで処理することができます。**また、各エージェントに含まれるモジュールの数にも依存します**。</WRAP> | An installation of Pandora FMS with a GNU/Linux server installed "by default" in a powerful machine, can not pass from 5 to 6 packets per second, in a powerful machine well "optimized" and "conditioned" it can reach 30 to 40 packets per second. **This also depends a lot on the number of modules in each agent**. |
| |
| Configure the system in order that the DDBB maintenance script at ''/usr/share/pandora_server/util/pandora_db.pl'' will be executed every hour instead of every day: | </WRAP> |
| | |
| | <WRAP center round tip 90%> |
| | |
| | これの重要性：強力なマシンに "デフォルト" でインストールされた GNU/Linux サーバ 1台で、Pandora は、毎秒 5〜6 データを超えることはできませんが、十分に "最適化" および "調整" された強力なマシンでは、毎秒 30-40 データまで処理することができます。**また、各エージェントに含まれるモジュールの数にも依存します**。 |
| | |
| | </WRAP> |
| | |
| | The system is configured so that the database maintenance script in ''/usr/share/pandora_server/util/pandora_db.pl'' is executed every hour instead of every day: |
| |
| ''/usr/share/pandora_server/util/pandora_db.pl'' にあるデータベースメンテナンススクリプトが毎日ではなく 1時間ごとに実行されるように、システムを設定します。 | ''/usr/share/pandora_server/util/pandora_db.pl'' にあるデータベースメンテナンススクリプトが毎日ではなく 1時間ごとに実行されるように、システムを設定します。 |
| |
| <file> | <code bash> |
| mv /etc/cron.daily/pandora_db /etc/cron.hourly | mv /etc/cron.daily/pandora_db /etc/cron.hourly |
| |
| </file> | </code> |
| |
| We leave the system working, with the package generator a minimum of 48 hours. Once this time has passed, we should evaluate the following points: | The system is left running with the packet generator for a minimum of 48 hours. Once this time has elapsed, the following points are evaluated: |
| |
| データジェネレーターを最低 48時間動かして、システムを動作させたままにします。 この時間が経過したら、次の点を評価する必要があります。 | データジェネレーターを最低 48時間動かして、システムを動作させたままにします。 この時間が経過したら、次の点を評価する必要があります。 |
| |
| - Is the system stable?, Is it down? If there are problems, check the logs and graphs of the metrics that we have got (mainly memory). | - ¿Is the system stable, has it crashed? If there are problems, look at logs and graphs of the metrics obtained (mainly memory). |
| - Evaluate the tendency of time of the metric "Number of monitors in unknown state". **There should be not tendencies neither important peaks**. They should be the exception: If they happen with a regularity of one hour, is because there are problems withe the concurrency of the DDBB management process. | - Evaluate the time trend of the metric "number of monitors in unknown state". **There should be no significant trends or spikes**. They should be the exception. If they happen with a regularity of one hour, it is because there are problems with the concurrency of the DB management process. |
| - Evaluate the metric "Average time of response of the pandora DDBB". **It should not increase with time but remain constant**. | - Evaluate the metric "Average response time of Pandora FMS DB". **It should not grow over time but remain constant**. |
| - Evaluate the metric "pandora_server CPU" , should have many peaks, but with a constant tendency, **not rising**. | - Evaluate the metric "CPU of ''pandora_server''": it should have frequent peaks, but with a constant trend, **not increasing**. |
| - Evaluate the metric "MYSQL server CPU"; should be constant with many peaks, but with a constant tendency , **not rising**. | - Evaluate the metric "MySQL server CPU", it should remain constant with frequent peaks, but with a constant, **not increasing** trend. |
| |
| - システムは安定しているか?、ダウンしていないか? 問題がある場合は、取得したメトリック(主にメモリ)のログとグラフを確認してください。 | - システムは安定しているか?、ダウンしていないか? 問題がある場合は、取得したメトリック(主にメモリ)のログとグラフを確認してください。 |
| - メトリック "pandora_server CPU使用率" を評価します。多くのピークがあるはずですが、一定の傾向があり、**上昇していないこと**です。 | - メトリック "pandora_server CPU使用率" を評価します。多くのピークがあるはずですが、一定の傾向があり、**上昇していないこと**です。 |
| - メトリック "MYSQL サーバ CPU使用率" を評価します。 多くのピークがありますが、一定の傾向で、**上昇していないこと**です。 | - メトリック "MYSQL サーバ CPU使用率" を評価します。 多くのピークがありますが、一定の傾向で、**上昇していないこと**です。 |
| | |
| | <wrap #ks3_1_1 /> |
| |
| === アラートの影響の評価 === | === アラートの影響の評価 === |
| |
| If all was right, now will evaluate the impact of the alert execution performance. | If everything went well, you should now evaluate the performance impact of the alert execution. Apply an alert to five specific modules of each agent (of type ''generic_data''), for the ''CRITICAL'' condition. Something that is relatively lightweight, such as creating an event or writing to **syslog** (to avoid the impact that something with high latency such as sending an email message could have). |
| |
| すべてが問題なければ、アラート実行パフォーマンスの影響を評価します。 | すべてが問題なければ、アラート実行パフォーマンスの影響を評価します。''障害(CRITICAL)'' 状態の場合、各エージェントの 5つの特定のモジュール(''generic_data'' タイプ)に 1つのアラートを適用します。イベントの作成や **syslog**への書き込みなど、それほど重要ではないもの(高い遅延の影響を回避するため、待ち時間が長いもの、たとえば電子メールメッセージを送信するようなものは避ける)を利用します。 |
| |
| Apply one alert to five specific modules of each agent (''generic_data'' type ), for the ''CRITICAL'' condition.Something not really important, like creating an event or writting to **syslog** (to avoid the impact that something with hight latency could have like for example sending an email message). | You can optionally create an event correlation alert to generate an alert for any critical condition of any agent with one of these five modules. |
| | |
| ''障害(CRITICAL)'' 状態の場合、各エージェントの 5つの特定のモジュール(''generic_data'' タイプ)に 1つのアラートを適用します。イベントの作成や **syslog**への書き込みなど、それほど重要ではないもの(高い遅延の影響を回避するため、待ち時間が長いもの、たとえば電子メールメッセージを送信するようなものは避ける)を利用します。 | |
| | |
| Optionally create one event correlation alert to generate one alert for any critical condition of any agent with one of these five modules. | |
| |
| オプションで、1つのイベント相関アラートを作成して、これら 5つのモジュールのいずれかを使用するエージェントの障害状態に対して 1つのアラートを生成します。 | オプションで、1つのイベント相関アラートを作成して、これら 5つのモジュールのいずれかを使用するエージェントの障害状態に対して 1つのアラートを生成します。 |
| |
| Let the system operating 12 hours under those criteria and evaluate the impact, following the previous criteria. | Leave the system operating for 12 hours under these criteria and evaluate the impact, following the above criteria. |
| |
| これらの基準の下でシステムを 12時間稼働させ、前の基準に従って影響を評価します。 | これらの基準の下でシステムを 12時間稼働させ、前の基準に従って影響を評価します。 |
| | |
| | <wrap #ks3_1_2 /> |
| |
| === データ削除と移動の評価 === | === データ削除と移動の評価 === |
| * 7日以上経過したデータをヒストリデータベースへ移動 | * 7日以上経過したデータをヒストリデータベースへ移動 |
| |
| Should let the system working "only" during at least 10 days to evaluate the long term performance. We could see a "peak" 7 days later due to the moving of data to the history DDBB. This degradation is <wrap hi>important</wrap> to consider. If you can't have so many time available, it is possible to replicate (with less "realism") changing the purging interval to 2 days in events and 2 days to move data to history, to evaluate this impact. | You should leave the system running "alone" for at least 10 days to evaluate long-term performance. You may see a substantial "spike" after 7 days due to the movement of data to the historical DB. This degradation is <wrap hi>important</wrap> to take into account. If you do not have that much time, you can reproduce it (with less "realism") by changing the purge interval to 2 days for events and 2 days to move data to history, to evaluate this impact. |
| |
| 長期的なパフォーマンスを評価するために、システムを少なくとも 10日間動作させる必要があります。 データがヒストリデータベースに移動される 7日後に "ピーク" が見られます。 このパフォーマンス低下は、<wrap hi>重要</wrap>な考慮点です。確認のための時間がそれほど多くとれない場合は、イベント削除を 2日に、データのヒストリデータベースへの移動を 2日に変更して、この影響を評価できます("実環境" とは少しことなりますが)。 | 長期的なパフォーマンスを評価するために、システムを少なくとも 10日間動作させる必要があります。 データがヒストリデータベースに移動される 7日後に "ピーク" が見られます。 このパフォーマンス低下は、<wrap hi>重要</wrap>な考慮点です。確認のための時間がそれほど多くとれない場合は、イベント削除を 2日に、データのヒストリデータベースへの移動を 2日に変更して、この影響を評価できます("実環境" とは少しことなりますが)。 |
| |
| ==== ICMP サーバ(Enterprise) ==== | <wrap #ks3_2 /> |
| |
| This is specifically for the [[:en:documentation:01_understanding:02_architecture#the_enterprise_network_server_for_snmp_and_icmp|ICMP network server]]. In case of doing the tests for the Open network server, please see the corresponding section of the network server (generic). | ==== ICMP サーバ ==== |
| |
| これは、[[:ja:documentation:01_understanding:02_architecture#エンタープライズネットワーク_enterprise_network_サーバ_snmp_icmp_用|ICMPネットワークサーバ]]用です。オープンソースのネットワークサーバのテストを行う場合は、ネットワークサーバ(汎用)の対応する章を参照してください。 | It is specifically the [[en:documentation:pandorafms:introduction:02_architecture|ICMP network server]]. In case of testing for the network server Open version, see the point corresponding to the network server (generic). |
| |
| Supposing that server is already working and configured, some key parameters for its performance: | これは、[[:ja:documentation:pandorafms:introduction:02_architecture#icmp_サーバ|ICMPネットワークサーバ]]用です。オープンソースのネットワークサーバのテストを行う場合は、ネットワークサーバ(汎用)の対応する章を参照してください。 |
| | |
| | Assume you already have the server up and running and configured. Some key parameters for its operation: |
| |
| サーバがすでに設定され動作していると仮定すると、そのパフォーマンスに関するいくつかの重要なパラメーターは次のとおりです。 | サーバがすでに設定され動作していると仮定すると、そのパフォーマンスに関するいくつかの重要なパラメーターは次のとおりです。 |
| |
| <file> | <file> |
| |
| block_size X | block_size X |
| |
| </file> | </file> |
| |
| It defines the number of "pings" that the system will do for any execution. If the majority of pings are going to take the same time, you can increase the number to considerably high numberm i.e: 50 to 70 | Defines the number of pings that the system will do per run. If most pings will take the same amount of time, you can raise the number to a considerably high number, such as 50 to 70. |
| |
| これは、システムが 1回に実行する "ping" の数を定義します。 多くの ping を同時に実行する場合は、数をかなり多く、つまり 50 から 70 に増やすことができます。 | これは、システムが 1回に実行する "ping" の数を定義します。 多くの ping を同時に実行する場合は、数をかなり多く、つまり 50 から 70 に増やすことができます。 |
| |
| On the contrary, the module ping park is heterogeneous and they are in very different networks, with different latency times,it is not convenient for you to put a high number, because the test will take the time that takes the slower one, so you can use a number quite low, such as 15 to 20. | If, on the other hand, the number of ping modules is heterogeneous and they are in very different networks, with very different latency times, it is not interesting to set a high number, because the test will take as long as the slowest one takes, so you can use a relatively low number, such as 15 to 20. |
| |
| 逆に、ping モジュールが少なく、対象のネットワークが大きく異なり遅延時間もそれぞれ異なるような場合は、テストに遅い方の時間を要するため、大きな数値は設定しない方が良いです。15 から 20 などの非常に低い数を使用します。 | 逆に、ping モジュールが少なく、対象のネットワークが大きく異なり遅延時間もそれぞれ異なるような場合は、テストに遅い方の時間を要するため、大きな数値は設定しない方が良いです。15 から 20 などの非常に低い数を使用します。 |
| </file> | </file> |
| |
| Obviously, the more threads it has, the more checks it could execute. If you make an addition of all the threads that Pandora FMS execute, they will not be more than 30 to 40. You should not use more than 10 threads here, thought it depends a lot of the kind of hardware an GNU/Linux version that you are using. | Obviously, the more threads you have, the more checks you will be able to execute. If you add all the threads that Pandora FMS executes, they should not reach the range of 30 to 40. You should not use more than 10 threads here, although it depends a lot on the type of hardware and the GNU/Linux version you are using. |
| |
| 明らかに、スレッドが多いほど、実行できるチェックも多くなります。 Pandora FMS が実行するすべてのスレッドを追加しても、30〜40 を超えることはありません。利用している GNU/Linux バージョンとハードウェアの種類に大きく依存しますが、ここでは 10 を超えるスレッドは使用するべきではありませｎ。 | 明らかに、スレッドが多いほど、実行できるチェックも多くなります。 Pandora FMS が実行するすべてのスレッドを追加しても、30〜40 を超えることはありません。利用している GNU/Linux バージョンとハードウェアの種類に大きく依存しますが、ここでは 10 を超えるスレッドは使用するべきではありませｎ。 |
| |
| Now "create" a fictitious number of modules ping type to test. Assume that you are going to test a total of 3000 modules of ping type. To do this, the best option is to choose a system in the network that would be able to support all pings (any GNU/Linux server would do it) | Now, you must "create" a fictitious number of ping type modules to test. It is assumed that you will test a total of 3000 ping modules. To do this, it is best to take a system on the network that is capable of supporting all pings (any GNU/Linux server can handle the task). |
| |
| 次に、テストする架空の数の ping モジュールを "作成" します。 ping タイプのモジュール合計 3000個をテストするとします。 これを行うための最良のオプションは、すべての ping をサポートするネットワーク内のシステムを選択することです(GNU/Linux サーバならどれでも大丈夫です)。 | 次に、テストする架空の数の ping モジュールを "作成" します。 ping タイプのモジュール合計 3000個をテストするとします。 これを行うための最良のオプションは、すべての ping をサポートするネットワーク内のシステムを選択することです(GNU/Linux サーバならどれでも大丈夫です)。 |
| |
| Using the Pandora CSV importer (available in the Enterprise version) and create a file with the following format: | Using the Pandora FMS CSV importer, create a file with the following format: |
| |
| Pandora CSV インポーター(Enterprise 版で利用可能)を使用して、次の形式でファイルを作成します。 | Pandora CSV インポーターを使用して、次の形式でファイルを作成します。 |
| |
| <code> | <WRAP center round box 90%> |
| (Agent name, IP,os_id,Interval,Group_id) | |
| |
| </code> | (agent name,IP address,OS identifier,interval,group identifier) |
| | |
| | </WRAP> |
| |
| You can use this shellscript to generate this file (changing the destination IP and the group ID) | This shellscript can be used to generate such a file (by changing the destination IP address and group ID): |
| |
| 以下のシェルスクリプトを使用して、ファイルを生成できます(宛先 IP とグループ ID を変更します)。 | 以下のシェルスクリプトを使用して、ファイルを生成できます(宛先 IP とグループ ID を変更します)。 |
| |
| <file> | <code bash> |
| A=3000 | A=3000 |
| while [ $A -gt 0 ] | while [ $A -gt 0 ] |
| done | done |
| |
| </file> | </code> |
| |
| Before start all this process, the Pandora FMS server must be running and monitoring, measuring the metrics from the previous point: CPU consumption (**pandora** and **mysql**), number of modules in unknown state and other interesting monitors. | The main thing is to have Pandora FMS monitored, measuring the metrics from the previous point: CPU consumption (**pandora** and **mysql**), number of modules in unknown state and other interesting monitors. |
| |
| このすべての処理を開始する前に、Pandora FMS サーバが実行および監視され、前述のメトリック(CPU使用率(**pandora** および **mysql**)、不明状態のモジュール数、およびその他の興味深い監視項目)を測定する必要があります。 | このすべての処理を開始する前に、Pandora FMS サーバが実行および監視され、前述のメトリック(CPU使用率(**pandora** および **mysql**)、不明状態のモジュール数、およびその他の興味深い監視項目)を測定する必要があります。 |
| |
| Import the CSV to create 3000 agents, it will take some minutes. After that go to the first agent (''AGENT_3000'') and we create a module Type PING. | Import the CSV to create 3000 agents, which will take a few minutes. Then go to the first agent (''AGENT_3000'') and create a **PING** type module in it. |
| |
| CSV をインポートして 3000エージェントを作成します。数分かかります。 その後、最初のエージェント(''AGENT_3000'')に移動し、PING タイプのモジュールを作成します。 | CSV をインポートして 3000エージェントを作成します。数分かかります。 その後、最初のエージェント(''AGENT_3000'')に移動し、PING タイプのモジュールを作成します。 |
| |
| Go to the massive operations tool and copy that module to the other 2999 agents. | Then go to the bulk operations tool and copy that module to the other remaining 2999 agents. |
| |
| 一括操作ツールに移動し、そのモジュールを他の 2999 エージェントにコピーします。 | 一括操作ツールに移動し、そのモジュールを他の 2999 エージェントにコピーします。 |
| |
| Pandora FMS should then start to process those modules. Measure with the same metrics from the previous case and evaluate how it goes. The objective is to let an operable system for the number of modules of type ICMP required without any of them reaches the unknown status. | Pandora should start processing those modules. Measure with the same metrics as the previous case and see how it evolves. The goal is to leave a system operable for the required number of ICMP type modules without any of them reaching unknown status. |
| |
| その後、Pandora FMS はそれらのモジュールの処理を開始します。 前のケースと同じメトリックを測定し、それがどのように推移するかを評価します。 目的は、必要な ICMP タイプのモジュールの数に対して、不明状態にならずに処理できかです。 | その後、Pandora FMS はそれらのモジュールの処理を開始します。 前のケースと同じメトリックを測定し、それがどのように推移するかを評価します。 目的は、必要な ICMP タイプのモジュールの数に対して、不明状態にならずに処理できかです。 |
| |
| ==== SNMP サーバ(Enterprise) ==== | <wrap #ks3_3 /> |
| | |
| | ==== SNMP サーバ ==== |
| |
| This is specifically about the SNMP Enterprise network server. In case of testing for the Open network server, see the section on the (generic) network server. | This is specifically about the SNMP Enterprise network server. In case of testing for the Open network server, see the section on the (generic) network server. |
| |
| これは SNMP Enterprise ネットワークサーバーに関するものです。 オープンソースのネットワークサーバのテストの場合は、(汎用の)ネットワークサーバの章を参照してください。 | これは SNMP ネットワークサーバーに関するものです。 オープンソースのネットワークサーバのテストの場合は、(汎用の)ネットワークサーバの章を参照してください。 |
| |
| Assuming that you have the server already working and configured, we are going to explain some key parameters for its working: | Assuming that you have the server already working and configured, we are going to explain some key parameters for its working: |
| * 時々発生する問題: 日次サーバの再起動(ログローテーション用)、データベースの定期保守処理の実行、またはサーバまたはデータベースサーバで実行されるその他のスクリプト。 | * 時々発生する問題: 日次サーバの再起動(ログローテーション用)、データベースの定期保守処理の実行、またはサーバまたはデータベースサーバで実行されるその他のスクリプト。 |
| * 監視処理とは関係ない(ネットワーク内のサーバのバックアップなどの)ネットワークの問題で、ネットワークの速度に影響を与えている場合。 | * 監視処理とは関係ない(ネットワーク内のサーバのバックアップなどの)ネットワークの問題で、ネットワークの速度に影響を与えている場合。 |
| | |
| | <wrap #ks3_4 /> |
| |
| ==== プラグイン、ネットワーク(オープンソース)、HTTP サーバ ==== | ==== プラグイン、ネットワーク(オープンソース)、HTTP サーバ ==== |
| |
| Here is applied the same concept that above, but in a more simplified way. You should check: | The same concept applies here as above, but in a more simplified form. It will be necessary to control: |
| |
| 前述と同じ概念を適用しますが、より単純化された方法です。 以下を確認する必要があります。 | 前述と同じ概念を適用しますが、より単純化された方法です。 以下を確認する必要があります。 |
| |
| * Number of threads. | * Number of threads. |
| | * Timeouts to calculate the worst-case incidence. |
| | * Average check time. |
| |
| * スレッド数 | * スレッド数 |
| |
| * Timeouts (to calculate the incidence in the worst case). | |
| |
| * タイムアウト(最悪の場合の発生率を計算するため) | * タイムアウト(最悪の場合の発生率を計算するため) |
| |
| * Check average time. | |
| |
| * 平均時間の確認 | * 平均時間の確認 |
| |
| Scaling with these data a test group and check that the server capacity is constant over time. | Size a test set with this data, and verify that the server capacity is constant over time. |
| |
| これらのデータを使用してテストグループをスケーリングし、サーバ容量が時間の経過とともに一定であることを確認します。 | これらのデータを使用してテストグループをスケーリングし、サーバ容量が時間の経過とともに一定であることを確認します。 |
| | |
| | <wrap #ks3_5 /> |
| |
| ==== トラップ受信 ==== | ==== トラップ受信 ==== |
| |
| Here, the case is more simple: ssume that the system is not going to receive traps in a constant way, but that it is about evaluating the response to a traps flood, from which some of them will generate alerts. | Here the assumption is simpler: it is assumed that the system is not going to receive traps constantly, but rather to evaluate the response to an avalanche of traps, some of which will generate alerts. |
| |
| このケースはより単純です。システムが一定量のトラップを受信するのではなく、一時的に大量のトラップが来た場合の応答を評価し、そこからアラートを生成することを想定します。 | このケースはより単純です。システムが一定量のトラップを受信するのではなく、一時的に大量のトラップが来た場合の応答を評価し、そこからアラートを生成することを想定します。 |
| |
| To do this, you will only have to do a simple script that generates traps in a controlled way and at hight speed: | To do this you simply need to make a script that generates traps in a controlled manner at high speed: |
| |
| それには、制御された方法で高速でトラップを生成する単純なスクリプトを実行するだけで済みます。 | それには、制御された方法で高速でトラップを生成する単純なスクリプトを実行するだけで済みます。 |
| |
| <file> | <code bash> |
| #!/bin/bash | #!/bin/bash |
| TARGET=192.168.1.1 | TARGET=192.168.1.1 |
| done | done |
| |
| </file> | </code> |
| |
| Note: stop it with the CTRL+C key after a few seconds, as it will generate hundreds of traps quickly. | **Note**: stop it with the CTRL+C key after a few seconds, as it will generate hundreds of traps quickly. |
| |
| 注: 数百のトラップがすばやく生成されるため、数秒後に CTRL+C キーで停止してください。 | **注**: 数百のトラップがすばやく生成されるため、数秒後に CTRL+C キーで停止してください。 |
| |
| Once the environment is set up we need to validate the following things: | Once the environment has been set up, the following assumptions must be validated: |
| |
| 環境をセットアップしたら、次のことを検証する必要があります。 | 環境をセットアップしたら、次のことを検証する必要があります。 |
| |
| - Traps injection to a constant rate(just put one ''sleep 1'' to the previous script inside the loop **while**, to generate 1 trap/sec. Let the system operating 48 hours and evaluate the impact in the server. | - Injection of traps at a constant rate (just enter a ''sleep 1'' command to the above script inside the **while** loop, to generate 1 trap per second. The system is left running for 48 hours and the impact on the server is evaluated. |
| - Traps Storm. Evaluate moments before, during and the recovery if a traps storm occurs. | - Trap storm. Evaluate the before, during, and recovery from a trap storm. |
| - Effects of the system on a huge traps table ( more than 50 thounsand). This includes the effect of passing the DDBB maintenance. | - Effects of the system on a very large table of traps (greater than 50 thousand). This includes the effect of passing the DB maintenance. |
| |
| - 一定速度のトラップを受信します(前述のスクリプトの **while** ループ内に ''sleep 1'' を設定するだけで、1トラップ/秒を生成します)。システムを 48時間稼働させ、サーバへの影響を評価します。 | - 一定速度のトラップを受信します(前述のスクリプトの **while** ループ内に ''sleep 1'' を設定するだけで、1トラップ/秒を生成します)。システムを 48時間稼働させ、サーバへの影響を評価します。 |
| - 大量トラップ。大量のトラップ受信が発生した場合の、その前後、発生中の評価をします。 | - 大量トラップ。大量のトラップ受信が発生した場合の、その前後、発生中の評価をします。 |
| - 巨大なトラップテーブル(5万以上)に対するシステム影響の確認。 これには、データベースメンテナンスへの影響も含みます。 | - 巨大なトラップテーブル(5万以上)に対するシステム影響の確認。 これには、データベースメンテナンスへの影響も含みます。 |
| | |
| | <wrap #ks3_6 /> |
| |
| ==== イベント ==== | ==== イベント ==== |
| |
| In a similar way as with the SNMP, evaluate the PFMS system's [[:en:documentation:04_using:02_events|events]] in two cases: | Similar to SNMP, the [[en:documentation:pandorafms:management_and_operation:02_events|events]] of the PFMS system will be evaluated in two scenarios: |
| |
| SNMP の場合と同様に、次の 2つの場合の Pandora FMS システムの[[:ja:documentation:04_using:02_events|イベント]]を評価します。 | SNMP の場合と同様に、次の 2つの場合の Pandora FMS システムの[[:ja:documentation:pandorafms:management_and_operation:02_events|イベント]]を評価します。 |
| |
| 1. Normal range of event reception. This has been already tested in the data server, so in each status change, an event will be generated. | - Normal event reception rate. This has already been tested in the data server, since an event is generated at each state change. |
| | - Event generation storm. To do this, we will force the generation of events via CLI. Using the following command (with an existing group called "Tests"): |
| |
| 1. イベント受信の通常の範囲。 これはデータサーバですでにテストされているため、ステータスが変更されるたびにイベントが生成されます。 | - イベント受信の通常の範囲。 これはデータサーバですでにテストされているため、ステータスが変更されるたびにイベントが生成されます。 |
| | - 大量のイベント生成。これを行うには、CLI を介してイベントの生成を強制します。 次のコマンドを使用します(作成された "TestingGroup" を使用)。 |
| |
| 2. Event generation Storm. To do this, we force the generation of evets via CLI. Using the following command (with a created "TestingGroup"): | <code bash> |
| | pandora_manage /etc/pandora/pandora_server.conf --create_event "Event test" system Tests |
| |
| 2. 大量のイベント生成。これを行うには、CLI を介してイベントの生成を強制します。 次のコマンドを使用します(作成された "TestingGroup" を使用)。 | </code> |
| |
| <file> | That command, used in a loop like the one used to generate traps, can be used to generate dozens of events per second. It can be parallelized in a script with several instances to cause a higher number of insertions. This would serve to simulate the behavior of the system in an event storm. In this way the system could be tested before, during and after an event storm. |
| |
| /usr/share/pandora_server/util/pandora_manage.pl \ | このコマンドは、トラップの生成に使用したものと同様にループを使用し、1秒ごとに数十のイベントを生成するために使用します。発生数を増やすために、複数のインスタンスを使用して 1つのスクリプトを並列化することができます。 これは、大量のイベントが発生した場合にシステムのパフォーマンスをシミュレートするのに役立ちます。 このようにして、大量イベントの前後、最中にシステムをチェックできます。 |
| /etc/pandora/pandora_server.conf --create_event "Event test" system TestingGroup | |
| |
| </file> | <wrap #ks3_7 /> |
| | |
| This command, used un a loop as the one used to generate traps, it can be used to generate tens of events by second. It could be parallelize in one script with several instances to get a higher number of insertions. This will be useful to simulate the performance of the system if an event storm happens. This way we could check the system, before, during and after the event storm. | |
| | |
| このコマンドは、トラップの生成に使用したものと同様にループを使用し、1秒ごとに数十のイベントを生成するために使用します。発生数を増やすために、複数のインスタンスを使用して 1つのスクリプトを並列化することができます。 これは、大量のイベントが発生した場合にシステムのパフォーマンスをシミュレートするのに役立ちます。 このようにして、大量イベントの前後、最中にシステムをチェックできます。 | |
| |
| ==== ユーザの同時アクセス ==== | ==== ユーザの同時アクセス ==== |
| |
| For this use another server, independent from Pandora FMS, using the WEB monitoring functionality. Do a user session where we have to do the following tasks in this order, and see how long they take. | For this, another server independent from Pandora FMS will be used, using the WEB monitoring functionality. In a user session where it will perform the following tasks in a specific order and measure how long they take to be processed: |
| |
| こにには、WEB 監視機能を使用して、Pandora FMS から独立した別のサーバを使用します。 次のタスクをこの順序で実行するユーザセッションを実行し、それらにかかる時間を確認します。 | こにには、WEB 監視機能を使用して、Pandora FMS から独立した別のサーバを使用します。 次のタスクをこの順序で実行するユーザセッションを実行し、それらにかかる時間を確認します。 |
| |
| - Login in the console | - Login to the web console. |
| - See events. | - See events. |
| - Go to the group view. | - Go to the group view. |
| - Go to the agent detail view. | - Go to agent detail view |
| - Visualize a report (in HTML). This report should contain a pair of graphs and a pair of modules with report type SUM or AVERAGE. The interval of each item should be of one week or five days. | - Display a report (in HTML). This report should contain a couple of graphs and a couple of modules with SUM or AVERAGE type reports. The interval for each item should be one week or five days. |
| - Visualization of a combined graph (24 hours). | - Display of a combined graph (24 hours). |
| - Generation of report in PDF (another different report). | - Generation of PDF report (another different report). |
| |
| - コンソールへのログイン。 | - コンソールへのログイン。 |
| - PDF でのレポート生成(他のレポートにて)。 | - PDF でのレポート生成(他のレポートにて)。 |
| |
| This test is done with at least three different users. This task could be parallelize to execute it every minute, so as if there are 5 tasks (each one with their user) we would be simulating the navigation of 5 simultaneous users.Once the environment is set up, we should consider this: | This test is performed with at least three different users. You can parallelize that task to run it every minute, so that if there are 5 tasks (each with its user), you would be simulating the navigation of five simultaneous users. Once the environment is established, it will take into account: |
| |
| このテストは、少なくとも 3人の異なるユーザを使用して行います。このタスクは並列化して毎分実行することができるため、5つのタスク(それぞれがユーザを含む)があるのであれば、5人のユーザの同時ナビゲーションをシミュレートします。環境をセットアップしたら、次のことを考慮する必要があります。 | このテストは、少なくとも 3人の異なるユーザを使用して行います。このタスクは並列化して毎分実行することができるため、5つのタスク(それぞれがユーザを含む)があるのであれば、5人のユーザの同時ナビゲーションをシミュレートします。環境をセットアップしたら、次のことを考慮する必要があります。 |
| |
| - The average velocity of each module is relevant facing to identify " bottle necks" relating with other parallel activities, such as the execution of the maintenance script, etc. | - The average speed of each module is relevant in order to identify "bottlenecks" related to other parallel activities, such as the execution of maintenance //script//, et cetera. |
| - The impact of CPU and memory will be measured in the server for each concurrent session. | - CPU and memory impact on the server will be measured for each concurrent session. |
| - The impact of each user session simulated referred to the average time of the rest of sessions will be measured. This is, you should estimate how many seconds of delay adds each simultaneous extra session. | - The impact of each simulated user session will be measured with respect to the average time of the rest of the sessions. That is, it should be estimated how many seconds of delay each simultaneous extra session adds. |
| |
| - 各モジュールの平均速度で、メンテナンススクリプトの実行など、他の平行して行われる処理に関連した "ボトルネック" を特定します。 | - 各モジュールの平均速度で、メンテナンススクリプトの実行など、他の平行して行われる処理に関連した "ボトルネック" を特定します。 |