ja:documentation:01_understanding:01_introduction

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン 前のリビジョン
次のリビジョン		 前のリビジョン
最新のリビジョン両方とも次のリビジョン
ja:documentation:01_understanding:01_introduction [2023/06/02 23:46] – [対応手順の検討] junichija:documentation:01_understanding:01_introduction [2023/06/22 05:43] – [対応手順の検討] junichi
行 113: 行 113:
  
   * **Urgency of the event**: Being able to distinguish something usual from something rare or critical.   * **Urgency of the event**: Being able to distinguish something usual from something rare or critical.
-  * **Form of notification**: Email, SMS, Telegram, sound alert…+  * **Form of notification**: Email, SMS, [[https://pandorafms.com/guides/public/search?term=telegram|Telegram]], sound alert…
   * **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.   * **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.
  
   * **イベントの緊急性**: まれなものや致命的なものと、通常状態の区別   * **イベントの緊急性**: まれなものや致命的なものと、通常状態の区別
-  * **通知形態**: email, sms, 音声アラートなど+  * **通知形態**: Email、SMS、[[https://pandorafms.com/guides/public/search?term=telegram|Telegram]]、音声アラートなど。
   * **スケーリング**: 問題が繰り返された後の違う形での報告。一般的なケースでは、問題の解決前に一定時間が経過したらマネージャーに通知するなどです。   * **スケーリング**: 問題が繰り返された後の違う形での報告。一般的なケースでは、問題の解決前に一定時間が経過したらマネージャーに通知するなどです。
  
行 131: 行 131:
  
 ==== 管理モデル ==== ==== 管理モデル ====
- 
-管理モデルによって、我々は監視システムが、自動的に情報をレポートするように設計され、人が直接または間接的に参照するシステムであることを理解できます。システムを参照する人は良くオペレータと呼ばれ、画面を見たり、スマートフォンや電子メール、何らかのツールでのログの参照などで、イベントを確認しています。どうやっているかというのは重要ではなく、重要なのはシステムがあるということです。 
- 
-{{  :wiki:notice_ways.png  }} 
- 
-一方では、全体もしくはインフラにおけるシステム管理者と呼ばれる人がいます。彼らは何か発生したときにオペレータから「障害が発生しました」という連絡を受けたり、SMS や E-mail でシステムから自動送信される警告通知を受けます。 
- 
-ここに、すでに大きな違いがあります。 
  
   * **直接管理モデル** は、一人または複数の人が定常的にシステムを見ています。何か障害が発生すればすぐに検出されます。それはちょっとした通知でクリティカルなものではありません。また、より柔軟性があります。すべてのケースを通知 (Pandora でのアラート) する必要はありません。常にシステムで何が起っているかのイベント (状態の変化をみつけます) を参照すれば十分です。多くの画面を定義することができ、集約したアラートを定義することができます。このモデルは、ラートポリシーを定義することが重要ではなく、自動的な管理ができない大規模環境で利用されます。   * **直接管理モデル** は、一人または複数の人が定常的にシステムを見ています。何か障害が発生すればすぐに検出されます。それはちょっとした通知でクリティカルなものではありません。また、より柔軟性があります。すべてのケースを通知 (Pandora でのアラート) する必要はありません。常にシステムで何が起っているかのイベント (状態の変化をみつけます) を参照すれば十分です。多くの画面を定義することができ、集約したアラートを定義することができます。このモデルは、ラートポリシーを定義することが重要ではなく、自動的な管理ができない大規模環境で利用されます。
行 144: 行 136:
 オペレータ、管理者、その上の人のチームワークにとって、Pandora FMS は、イベントのチケット化、インシデント作成、通知のエスカレーション、内部メール、掲示板、Pandora FMS ユーザ間のチャットなどとても便利です。 オペレータ、管理者、その上の人のチームワークにとって、Pandora FMS は、イベントのチケット化、インシデント作成、通知のエスカレーション、内部メール、掲示板、Pandora FMS ユーザ間のチャットなどとても便利です。
  
-==== そして何をする? ==== +[[:ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]]
- +
-以降の章からは、完全に Pandora FMS についての内容です。ここまでは Pandora FMS を利用するにあたって、その前に知っておくべき重要なことについて述べてきました。あなたはすでに多くのことを知っているかもしれません。また、他の監視ツールを使っているかもしれません。常にアプリケーションを監視することが良いということは聞いていることでしょう。 +
- +
-しかし、我々の経験から、我々のノウハウを越えて、それぞれのユーザのみなさんには特定の方法が必要です。我々はあなたのインフラがどのように設定されているかを良く知っているわけではありません。モニタリングそのものは簡単で問題ではありません。大変なのは、監視にあなたのビジネスを適用するのではなく、あなたのビジネスに監視を適用することです。あなたの組織で Pandora FMS を使って最善の監視手法を見つけることは、本当のチャレンジです。+
  
 ===== (OBSOLETE) モニタリングの概要 ===== ===== (OBSOLETE) モニタリングの概要 =====
行 169: 行 157:
  
 これら 3つのパラダイムは、モニタリングツールの選択とともに、それぞれの環境の違いを意味します。どんな種類の情報が必要で、それを得るための最善策は何かを認識してください。どんな情報があって、どのようにモニタリングするかを計画してください。 これら 3つのパラダイムは、モニタリングツールの選択とともに、それぞれの環境の違いを意味します。どんな種類の情報が必要で、それを得るための最善策は何かを認識してください。どんな情報があって、どのようにモニタリングするかを計画してください。
 +
 +==== そして何をする? ====
 +
 +以降の章からは、完全に Pandora FMS についての内容です。ここまでは Pandora FMS を利用するにあたって、その前に知っておくべき重要なことについて述べてきました。あなたはすでに多くのことを知っているかもしれません。また、他の監視ツールを使っているかもしれません。常にアプリケーションを監視することが良いということは聞いていることでしょう。
 +
 +しかし、我々の経験から、我々のノウハウを越えて、それぞれのユーザのみなさんには特定の方法が必要です。我々はあなたのインフラがどのように設定されているかを良く知っているわけではありません。モニタリングそのものは簡単で問題ではありません。大変なのは、監視にあなたのビジネスを適用するのではなく、あなたのビジネスに監視を適用することです。あなたの組織で Pandora FMS を使って最善の監視手法を見つけることは、本当のチャレンジです。