| 両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン |
| ja:documentation:pandorafms:introduction:01_introduction [2025/09/27 21:49] – [ドキュメントについて] junichi | ja:documentation:pandorafms:introduction:01_introduction [2025/09/27 22:02] (現在) – [対応手順の検討] junichi |
|---|
| ===== Pandora プロジェクトの進化 ===== | ===== Pandora プロジェクトの進化 ===== |
| |
| Pandora FMS was born from a personal development of its [[https://pandorafms.com/es/historia-de-pandora-fms/|original author, Sancho Lerena, in 2003]]. Initially it was 100% open source and over the years the need arose to offer a version oriented to large companies: **Pandora FMS Enterprise**, capable of processing large volumes of information through the [[:en:documentation:pandorafms:command_center :01_introduction|Command Center (Metaconsole)]]. | Pandora FMS was born from a personal development of its [[https://pandorafms.com/en/pandora-fms-history/|original author, Sancho Lerena, in 2003]]. Initially it was 100% open source and over the years the need arose to offer a version oriented to large companies: **Pandora FMS Enterprise**, capable of processing large volumes of information through the [[:en:documentation:pandorafms:command_center :01_introduction|Command Center]]. |
| |
| Pandora FMS は、[[http://pandorafms.com/en/pandora-fms-history/|2003年に Sancho Lerena]] によって個人的な開発プロジェクトとして始まりました。当初は 100% オープン ソースでしたが、数年後、大企業向けのバージョンが必要になりました。それは、[[:ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター(メタコンソール)]] を通じて大量の情報を処理できる Pandora FMS Enterprise です。 | Pandora FMS は、[[http://pandorafms.com/en/pandora-fms-history/|2003年に Sancho Lerena]] によって個人的な開発プロジェクトとして始まりました。当初は 100% オープン ソースでしたが、数年後、大企業向けのバージョンが必要になりました。それは、[[:ja:documentation:pandorafms:command_center:01_introduction|コマンドセンター(メタコンソール)]] を通じて大量の情報を処理できる Pandora FMS Enterprise です。 |
| |
| {{ :wiki:pfms-roadmap-2021.png }} | [[https://pandorafms.com/en/roadmap/|{{ :wiki:pfms-roadmap-2025.png?nolink& }}]] |
| |
| <wrap #ks4 /> | <wrap #ks4 /> |
| ===== Pandora FMS の機能概要 ===== | ===== Pandora FMS の機能概要 ===== |
| |
| * **Self-monitoring**: By default it allows detecting storage devices or databases (BB.DD.) in a BB.DD. server, among other things. | * **Self-monitoring**: By default it allows detecting storage devices or databases (BB.DD.) in a BB.DD. server, among other things. |
| * **Auto discovery**: Remotely by network you can detect all its elements, catalog them according to operating system (O.S.) and monitor with an assigned profile. | * **Auto discovery**: Remotely by network you can detect all its elements, cataloged them according to operating system (O.S.) and monitor with an assigned profile. |
| * **Agents**: They can obtain information from the execution of a command to the lowest level call of the MS Windows® API: events, logs, memory consumption, CPU usage, etc. PFMS has a library of default checks for speed. | * **Agents**: They can obtain information from the execution of a command to the lowest level call of the MS Windows® API: events, logs, memory consumption, CPU usage, etc. PFMS has a library of default checks for speed. |
| * **Control**: The agents themselves can start services, delete temporary files or run processes. It can be done from the Web Console, remotely executing tasks such as stopping or starting services, including periodic executions. Furthermore, Pandora FMS can be used to remotely access remote systems thanks to [[:en:documentation:09_pandora_rc:start|Pandora RC]] (Telnet, VNC or SSH). | * **Control**: The agents themselves can start services, delete temporary files or run processes. It can be done from the Web Console, remotely executing tasks such as stopping or starting services, including periodic executions. Furthermore, Pandora FMS can be used to remotely access remote systems thanks to [[:en:documentation:09_pandora_rc:start|Pandora RC]] (Telnet, VNC or SSH). |
| * **Alert and notify**: As important as detecting a failure is notifying it. With Pandora FMS there are several ways and notification formats available. | * **Alert and notify**: As important as detecting a failure is notifying it. With Pandora FMS there are [[:en:documentation:pandorafms:management_and_operation:01_alerts|several ways and notification formats available]]. |
| * **View and analyze**: Although monitoring is receiving an SNMP trap or viewing an interrupted service, it is also presenting trend reports, summary graphs of data collected over months, generating user portals, delegating reports to third parties or define your own graphs and tables. | * **View and analyze**: Although monitoring is receiving an SNMP trap or viewing an interrupted service, it is also presenting trend reports, summary graphs of data collected over months, generating user portals, delegating reports to third parties or define your own graphs and tables. |
| * **Inventory**: Contrary to other solutions, where the CMDB concept is the base, for Pandora FMS this is optional. Inventory is flexible and dynamic, can be self-discovered, checked remotely, and so on. You can also notify changes, such as uninstalled software on a computer, or use it to create listings. | * **Inventory**: Contrary to other solutions, where the CMDB concept is the base, for Pandora FMS this is optional. [[:en:documentation:pandorafms:management_and_operation:04_inventory|Inventory]] is flexible and dynamic, can be self-discovered, checked remotely, and so on. You can also notify changes, such as uninstalled software on a computer, or use it to create listings. |
| |
| * **自動検出(ローカル)** Pandora エージェントのデフォルトの監視で、ハードディスク、パーティション、データベースサーバにおけるデータベース、その他を検出できます。 | * **自動検出(ローカル)** Pandora エージェントのデフォルトの監視で、ハードディスク、パーティション、データベースサーバにおけるデータベース、その他を検出できます。 |
| * **モニタリング** Pandora FMS のエージェントは最も強力です。基本的なコマンドの実行結果や Windows API から、イベント、ログ、数値データ、プロセスの状態、メモリやCPUの使用率などの情報を取得することができます。Pandora にはデフォルトでモニタリング用のライブラリがあります。しかし、Pandora の最大の利点は、新たなモニタリングを作成し追加できることにあります。 | * **モニタリング** Pandora FMS のエージェントは最も強力です。基本的なコマンドの実行結果や Windows API から、イベント、ログ、数値データ、プロセスの状態、メモリやCPUの使用率などの情報を取得することができます。Pandora にはデフォルトでモニタリング用のライブラリがあります。しかし、Pandora の最大の利点は、新たなモニタリングを作成し追加できることにあります。 |
| * **コントロール** エージェントはそれ自身でサービスを有効化したり、テンポラリファイルを削除したり、プロセスを実行したりできます。コンソールからリモートでサービスの停止・起動などのコマンド実行も可能です。さらに、指定した時間にタスクを実行することもできます。[[ja:documentation:09_pandora_rc:start|Pandora RC]] を用いて Pandora FMS からリモートのシステムにアクセスすることや、ウェブインタフェースから telnet や ssh のツールを利用することも可能です。 | * **コントロール** エージェントはそれ自身でサービスを有効化したり、テンポラリファイルを削除したり、プロセスを実行したりできます。コンソールからリモートでサービスの停止・起動などのコマンド実行も可能です。さらに、指定した時間にタスクを実行することもできます。[[ja:documentation:09_pandora_rc:start|Pandora RC]] を用いて Pandora FMS からリモートのシステムにアクセスすることや、ウェブインタフェースから telnet や ssh のツールを利用することも可能です。 |
| * **アラートと警告** 通知は障害検出と同様に重要です。Pandora は、ほぼ無限の通知方法とフォーマットを提供します。エスカレーション、アラートの関連、イベントの依存関係による集約なども制限なしで含みます。 | * **アラートと警告** 障害の検出と同様に重要なのは、それを通知することです。Pandora FMS では、[[:ja:documentation:pandorafms:management_and_operation:01_alerts|複数の通知方法と形式が用意されています]]。 |
| * **分析と表示** モニタリングは trap を受信したりダウンしているサービスを表示したりするだけではありません。予測レポートや、長期間収集したデータの関連グラフを出すことができ、ユーザポータルとして第三者に提供したり、独自のグラフや表の定義を作成できます。 | * **分析と表示** モニタリングは trap を受信したりダウンしているサービスを表示したりするだけではありません。予測レポートや、長期間収集したデータの関連グラフを出すことができ、ユーザポータルとして第三者に提供したり、独自のグラフや表の定義を作成できます。 |
| * **インベントリ生成** 一般なソリューションとして構成管理ツールがありますが、Pandora ではこれがオプションとしてついています。インベントリは柔軟で動的です(自動検出可能で、リモート入力等も可能です)。変更(ソフトウエアのアンインストールなど)を通知するために利用したり、単純に一覧を生成するために利用したりできます。 | * **インベントリ生成** 一般なソリューションとして構成管理ツールがありますが、Pandora ではこれがオプションとしてついています。[[:ja:documentation:pandorafms:management_and_operation:04_inventory|インベントリ]]は柔軟で動的です(自動検出可能で、リモート入力等も可能です)。変更(ソフトウエアのアンインストールなど)を通知するために利用したり、単純に一覧を生成するために利用したりできます。 |
| |
| <wrap #ks5 /> | <wrap #ks5 /> |
| リモート監視とは、Pandora FMS サーバが監視対象のデバイスを **同期** でポーリングすることを意味します。 この処理は、ポーリングまたはリモート監視として知られています。 | リモート監視とは、Pandora FMS サーバが監視対象のデバイスを **同期** でポーリングすることを意味します。 この処理は、ポーリングまたはリモート監視として知られています。 |
| |
| {{ :wiki:esquema-remote-module-execution.png }} | {{ :wiki:remote-module-execution-schema.png }} |
| |
| Generally speaking, remote monitoring is used: | Generally speaking, remote monitoring is used: |
| * 値の取得 (例えば、ネットワークトラフィックやアクティブな接続数) | * 値の取得 (例えば、ネットワークトラフィックやアクティブな接続数) |
| |
| <WRAP center round info 60%>Synchronous monitoring is always done in the same direction: from the monitoring server to the monitored element and can be done through the most extended protocols such as SNMP and WMI (MS Microsoft®).</WRAP> | <WRAP center round info 90%> |
| |
| <WRAP center round info 60%>同期監視は常に同じ方向、つまり監視サーバから監視対象に対して行われ、SNMP や WMI (MS Microsoft®) などのプロトコルを通じて実行できます。</WRAP> | This monitoring, when it is synchronous, is always carried out in the same direction: from the monitoring server to the monitored element and can be carried out with the most widespread protocols, SNMP and WMI (MS Microsoft®). |
| | |
| | </WRAP> |
| | |
| | <WRAP center round info 90%> |
| | |
| | 同期監視は常に同じ方向、つまり監視サーバから監視対象に対して行われ、SNMP や WMI (MS Microsoft®) などのプロトコルを通じて実行できます。 |
| | |
| | </WRAP> |
| |
| The opposite process is called **asynchronous** monitoring, and in case of remote monitoring, we usually refer to it as SNMP traps. | The opposite process is called **asynchronous** monitoring, and in case of remote monitoring, we usually refer to it as SNMP traps. |
| * ネットワーク環境を監視するには、SNMP デバイスの外部ブラウザを使用した SNMP プロトコル、ネットワークデバイスメーカーの MIB コレクション (OID ライブラリ) へのアクセス、およびトラップリスニングを選択します。 そして、各デバイスのカスタム OID コレクションに追加します。Unix® および Linux® システムの場合は、SNMP 機能を有効にする必要があります。 | * ネットワーク環境を監視するには、SNMP デバイスの外部ブラウザを使用した SNMP プロトコル、ネットワークデバイスメーカーの MIB コレクション (OID ライブラリ) へのアクセス、およびトラップリスニングを選択します。 そして、各デバイスのカスタム OID コレクションに追加します。Unix® および Linux® システムの場合は、SNMP 機能を有効にする必要があります。 |
| * MS Windows® サーバの WMI 監視では、認証を通じて適切に実行され、かつ強力です。 | * MS Windows® サーバの WMI 監視では、認証を通じて適切に実行され、かつ強力です。 |
| | |
| | Finally, you can always monitor network elements by using TCP (for example: HTTP protocol or SMTP protocol) or ICMP (for example: [[:en:documentation:pandorafms:introduction:03_glossary#ping|ping]] or latency time) tests. |
| | |
| | 最後に、TCP (例: HTTP プロトコルまたは SMTP プロトコル) または ICMP (例: [[:ja:documentation:pandorafms:introduction:03_glossary#ping|ping]] または待ち時間) テストを使用して、いつでもネットワーク要素を監視することができます。 |
| |
| <wrap #ks6 /> | <wrap #ks6 /> |
| 導入や設定を開始する前に、監視対象における技術的なキーポイントを把握しておくことが重要です。それにより、無駄な時間を浪費せずに、システム上の特定のデータに関する情報が何のためにあるのか、最大限に活用するにはどうすべきかが明確になります。 | 導入や設定を開始する前に、監視対象における技術的なキーポイントを把握しておくことが重要です。それにより、無駄な時間を浪費せずに、システム上の特定のデータに関する情報が何のためにあるのか、最大限に活用するにはどうすべきかが明確になります。 |
| |
| * **Availability:** You are mostly interested in event-based monitoring and remote monitoring will probably be enough for your needs. It is faster to deploy and will give you fairly quick results. SLA reports will be the most useful ones in this case. | * **Availability**: Event-based monitoring is of interest above all, and remote monitoring is probably sufficient; it is faster to deploy and results can be obtained in a short time. The SLA reports will be the most useful in this case. |
| * **Performance:** They are graphics and numbers, collecting information through agents or remotely, even though you will probably require agents to get in-depth information on their systems. Group reports and combined graphics are of capital importance. | * **Performance**: Are the graphs and the numbers; you can get that information with both agents and remote checks, but agents are probably needed to get detailed information from the systems. Grouped reports and combo charts take precedence. |
| * **Capacity Planning:** Much more specific. It is necessary to obtain data, as in the second instance, but to parse and manipulate the data, with predictive monitors and very specialized projective reports. Establishing early alerts will be of great help and you are required to have good knowledge of the WARNING and CRITICAL status meanings, besides elaborating serial event management policies to prevent the problem from happening, which is without a doubt the most complex and interesting case. | * **Capacity Planning**: Much more specialized; It is necessary to obtain data, as in the second case, with predictive type monitors and very specific projection reports. Establishing early alerts will be very helpful, and you will need to know the concepts of <wrap :en>WARNING</wrap> and <wrap :en>CRITICAL</wrap> states well, in addition to developing a series of event management policies that allow you to anticipate the problem before it happens, without a doubt the most complex and interesting case. |
| |
| * **可用性:** ほとんどの場合、イベントベースの監視と必要に応じてリモート監視で十分な場面が多いでしょう。素早く展開が可能で比較的迅速に結果を得ることができます。 この場合に、SLA レポートが最も役立ちます。 | * **可用性:** ほとんどの場合、イベントベースの監視と必要に応じてリモート監視で十分な場面が多いでしょう。素早く展開が可能で比較的迅速に結果を得ることができます。 この場合に、SLA レポートが最も役立ちます。 |
| * **パフォーマンス:** グラフや数値データが重要な要素です。エージェントまたはリモートから情報を取得します。エージェントでシステムのより深い情報をとる必要があるかもしれません。グループレポートおよび組み合わせグラフがポイントです。 | * **パフォーマンス:** グラフや数値データが重要な要素です。エージェントまたはリモートから情報を取得します。エージェントでシステムのより深い情報をとる必要があるかもしれません。グループレポートおよび組み合わせグラフがポイントです。 |
| * **キャパシティプランニング:** より独自性が高くなり、2つ目の件とどうようにデータの取得が必要です。ただし、それをもとに、予測監視やより特別な予想レポートを使います。エージェントからの初期のアラートは、警告や障害状態の意味を把握するのに必要です。問題が発生する前に防止するために、発生するイベントの管理(運用)ポリシーを策定します。これは、間違いなく最も複雑で興味深いパターンです。 | * **キャパシティプランニング:** より独自性が高くなり、2つ目の件とどうようにデータの取得が必要です。ただし、それをもとに、予測監視やより特別な予想レポートを使います。エージェントからの初期のアラートは、<wrap :ja>警告</wrap>や<wrap :ja>障害</wrap>状態の意味を把握するのに必要です。問題が発生する前に防止するために、発生するイベントの管理(運用)ポリシーを策定します。これは、間違いなく最も複雑で興味深いパターンです。 |
| |
| <wrap #ks8 /> | <wrap #ks8 /> |
| ===== 対応手順の検討 ===== | ===== 対応手順の検討 ===== |
| |
| In order to be able to draw up action procedures, it will be necessary to take into account several factors: | In order to develop action procedures, the following must be taken into account: |
| |
| 対応の手順を立てるためには、いくつかの要因を考慮する必要があります： | 対応の手順を立てるためには、いくつかの要因を考慮する必要があります： |
| |
| * **Urgency of the event**: Being able to distinguish something usual from something rare or critical. | * **Criticality of the event**: Being able to discriminate something habitual from something infrequent or critical. |
| * **Form of notification**: Email, SMS, [[https://pandorafms.com/guides/public/search?term=telegram|Telegram]], sound alert… | * **Method of notification**: email, SMS, [[https://pandorafms.com/guides/public/search?term=telegram|Telegram]], sound alert, etc. |
| * **Scaling**: Different forms of warning in face of a recurrent problem. A common case is notification to a manager after a certain amount of time without solving a problem. | * **Escalated**: Different forms of warning after the repetition of a problem. A common case is the notification to a person in charge after a certain time without solving a problem. |
| |
| * **イベントの緊急性**: まれなものや致命的なものと、通常状態の区別 | * **イベントの緊急性**: まれなものや致命的なものと、通常状態の区別 |
| * **スケーリング**: 問題が繰り返された後の違う形での報告。一般的なケースでは、問題の解決前に一定時間が経過したらマネージャーに通知するなどです。 | * **スケーリング**: 問題が繰り返された後の違う形での報告。一般的なケースでは、問題の解決前に一定時間が経過したらマネージャーに通知するなどです。 |
| |
| Before getting into any configurations, it is advisable to have these concepts clear, draw up schemes with the critical elements, how to monitor them, what to do with all the information gathered and how to report problems that arise. | Before entering configurations, it is advisable to be clear about these concepts, draw up diagrams with the critical elements, how to monitor them, what to do with all the information collected and how to report any problems that appear. |
| |
| 設定を実施する前に、これらの概念について明確にし、監視方法、収集されたすべての情報をどのように処理するか、発生した問題をどう報告するかといった、重要な要素の計画を作成することをお勧めします。 | 設定を実施する前に、これらの概念について明確にし、監視方法、収集されたすべての情報をどのように処理するか、発生した問題をどう報告するかといった、重要な要素の計画を作成することをお勧めします。 |
| |
| {{ :wiki:scalation_example.png?500 }} | |
| |
| By focusing on the most critical issues first, you reach a logical starting point that defines **what** the most important issues for your organization are. Once you know what the most critical elements are, you can define **how** to monitor the target(s), while considering **who** will be responsible for the resolution of the reported problems in those systems as well as how to notify the appropriate people of the existence of a problem. | |
| |
| まず、最も重要な問題に焦点を当てることで、組織にとって最も重要な問題は何かを定義する論理的な出発点に立つことができます。最も重要な要素が何であるかが分かったら、対象を監視する方法を定義し、そのシステムであがった問題を解決する担当者を考えます。適切な人々に問題の存在を通知する方法について説明します。 | |
| |
| <wrap #ks9 /> | <wrap #ks9 /> |