専門的な活動のたびに、統合されたIT監視システムを構築する問題を解決するたびに、このアプローチを厳守し、顧客が適切に機能する監視システムを入手できるようにします。 このアプローチは普遍的であり、IT分野にないアプリケーションを見つけることができると確信しています。
起こるように
彼らの活動の性質上、彼らはしばしば、実装後に一様に厚い塵の層で覆われた監視システムに対処する必要があり、システムが作成された人はその存在を安全に忘れ、勤勉なサーバーだけがデータセンターの電力を消費し続けます。
そしてもっと！ 注目に値するのは、このような「悲嘆」システムで使用されるソフトウェアが最も近代的で最も高価であり、技術的な欠点について不満がないことです。 しかし、システム管理者は、長年にわたって実績のあるスクリプトを使用して、失敗の通知を受け取り、今日まで受け取りました。 次のよく知られたシンドロームで管理者に写真を補足できます：
- 監視システムが誰のためにどのパラメータを監視するのか、誰にもわかりません。
- システムは文字通り、オペレーターのコンソールまたは管理者のメールにひどい障害に関するメッセージをあふれさせます。 次に、本当に重要なメッセージをキャッチしてみてください。
- 提供される監視サービスの品質には信頼がありません。その結果、誰もが自分で問題を解決するか、監視についてまったく考えていません。
- 監視オブジェクト間の相互影響のモデルは、時間の経過とともに信頼性を失います。それらを更新することは、不可能な作業です。
監視が必要な理由
さらに読むために読者を準備するために、いくつかの定義を追加したいと思います。
監視システム-所定の基準からの観測されたパラメータの偏差を検出し、その結果、特定のアクションを実行するシステム。
監視の目的：
- 例外検出（時間）;
- その結果、自動化されたアクションの実行（2）。
また、ITの最新の監視システムは、たとえば監視対象パラメーターの値の収集と保存、起こりうる障害の予測、インフラストラクチャコンポーネントの自動検出など、多くの機能を必ず提供する必要があると確信しています。 しかし、2つの主要機能（検出とアクション）のパフォーマンスにより、システムは監視システムになります。
さらにいくつかの定義：
顧客 -監視サービスを受けることに興味がある人。
プロバイダー -監視サービスを提供する人。
ゲームルールの定義（規制）
だから、誰が顧客である-これは通常、サービス、ソフトウェア、または組織内のサーバーの操作を担当する人であり、これらのオブジェクトの動作の質を求められるのは彼からです。
プロバイダーは、顧客の監視、障害のタイムリーな検出または防止のためのパラメーターの必要なオブジェクトを編成する機能を備えています。
それで！ 顧客とプロバイダーの間の相互作用の特定のルールを決定する必要があります。 顧客は責任者であり、顧客と監視プロバイダーとの間で責任がどのように分配されるかを理解する必要があるため、この問題の精緻化は快適な対話環境を作成するために必要な手段です。
もう一度、何らかの形で注意したいのですが、規制があるはずです！
規制 -相互作用の規則と、顧客とプロバイダー間の責任の分配に関する規則を定義する文書。
規制が回答すべき質問のリストは次のとおりです。
- 顧客に関する監視プロバイダーの責任。
- お客様の責任;
- 顧客として行動する人の輪の決定。
- 利益相反が発生した場合の紛争を解決するための条件。
- 監視回路にオブジェクトを含めるためのルール。
- 監視オブジェクトをサービスモードに転送するためのルール。
- 監視ループから監視オブジェクトを出力するためのルール。
申込み
顧客とプロバイダーとの間の蜂蜜の相互作用の主な文書は、監視用アプリケーションです。
アプリケーションとは、顧客が監視システムの助けを借りて解決しようとしているタスクに関するすべての要件を正式化した文書です。
私は、規則のすべてを記入、承認、テスト、運用するための規則、および顧客として行動することを許可されている人々のリストを記述することを提案します。
アプリケーションは、顧客とプロバイダーの間の特定のフォームに対応する一種の小さな合意であり、たとえば、「アプリケーションで説明されているように監視がそのタスクを遂行できるか！」など、両者間の紛争を解決する主な手段にもなります。
アプリケーションの処理方法は、組織で採用されているドキュメント管理の方法によって異なります。
- 紙バージョン;
- 電子;
- 専用システム。
アプリケーション構造
それで、私はすでに監視システムを編成する上で最も重要な2つのことについて話しました。規制-今回、アプリケーション-は2つです。 ここでは、読者は「これと同じように、これだけでは不十分です！」と叫ぶことができます。 「もちろん、十分ではありませんが、残りはこの記事の範囲に含まれていません。」
技術的な詳細を追加したいので、使用しなければならなかったアプリケーションの構造の例を示します。 そして、議論は技術的な詳細に焦点を当てるので、この場所でこの記事を読み終える準備ができているすべての人は、あなたにそれを議論することを勧めます、私は生じた問題について議論することを嬉しく思います。
アプリケーションの構造に戻ります。拡大されたアプリケーションを次のグループの形式で説明できます。
- 全般
- 責任者
- 構成単位（KE）
- 状態
- アクション
- 構成
全般：
ここでは、アプリケーションの一意の識別子の決定、バージョン管理の維持、ステータスの維持などを提案します。
責任者 -アプリケーションの作成を監督する顧客側で行動する人。 アプリケーションの責任ある必須属性は、変更できますが、変更することはできません。 アプリケーションの作成プロセスを開始する機会がある人の輪は、規則で決定されることが提案されています。
構成単位（KE）は、このアプリケーションの条件を実装する必要があるオブジェクトのリストです。 KEの情報は、明確な識別のために十分に十分でなければなりません。 監視システムの設計段階で、CEの計画、それらの可能なタイプ、および必要な属性を開発することが提案されています。
監視システムのアーキテクチャに応じて、アプリケーション内のKEのリストは手動で作成するか、インフラストラクチャオブジェクトの検出データに基づいて作成できます（ITインフラストラクチャ全体のインベントリを作成できる特殊なシステムがあります）。 また、アプリケーション内のKEのリストは、条件に基づいて自動的に生成できます（たとえば、特定のサブネットに属するすべてのサーバー。これは、インフラストラクチャオブジェクトに関する情報が保存されているデータベースへのリクエストへのリンクです）。
条件 -監視を実装するために実行する必要のあるチェックの正確な定式化。 条件はアプリケーションに慎重に記録する必要があります。これは開発のソースデータになります。 各条件は、KEのリストまたはKEの個々のコピーと比較されます。
条件タイプの例：
- OSパラメーターの確認。
- ログファイルでエラーを検索します。
- SLMの計算。
アクション
各条件は、実行する必要があるアクションに対応する場合があります。 各アクションには一意の名前（識別子）が必要です。 この識別子は、監視システムに到着するメッセージの属性に含まれている必要があります。これにより、監視システム側で必要なアクションを識別できます。 次に、監視システムには、アクションの名前に応じて特定のアクションを実行できる設定が必要です。
アクションタイプの例：
- メールによる通知。
- SMS通知;
- インシデントの機関。
- KEのHIステータスの計算。
- KEのKPIの計算。
構成 -アプリケーションの条件を実装するソフトウェアの構成へのリンク。 次の情報が含まれる場合があります。
- ソフトウェアの名前。
- アプリケーションの条件を満たすために、対応するKEのセットまたは個別のKEで試行する必要がある構成の名前。 （例：監視ポリシーまたは監視ポリシーのグループ）。
監視システムの構成への参照を入力して、展開プロセスを自動化できます。 また、構成へのリンクにより、特定の監視システム設定が関連付けられているアプリケーションを特定できます。
アプリケーションの概略構造は次のとおりです。
アプリケーションのライフサイクル
最後に注意したいのは、アプリケーションのライフサイクルです。次の手順を強調します。
- デザイン;
- 開発;
- テスト操作。
- 産業開発。
それぞれについての詳細：
クリアランス
ここで、アプリケーションは確立されたフォームに記入され、監視条件が合意され、次の段階である開発に移されます。
開発
ここではすべてがシンプルです！ アプリケーションの条件に応じて監視システムの構成を作成し、次の段階であるテスト操作に移行します。
監視条件を明確化または再定義するために、アプリケーションを登録段階に戻す可能性を排除するものではありません。
試運転
ここでは、「テスト環境の準備に関与している」という微妙な政治的問題を解決し、アプリケーションのテストに関連する必要なすべてのアクティビティを実行します。
テスト結果に基づいて、特定された問題に応じて、実行または開発の段階でアプリケーションを返すことができます。
テスト操作が正常に完了したら、次の段階である工業操作。
産業開発
ここではすべてが深刻です。システムが動作し、インシデントが検出され、通知が送信されます。 産業運用の段階で、変更など、アプリケーションに変更を加える可能性を想定しています。
- マイナー
- メジャー（メジャー）。
これらのタイプの詳細：
マイナー -監視オブジェクトのリストの変更やメーリングリストの変更など、開発段階に戻る必要のない変更。 小さな変更を加えても、アプリケーションのバージョン管理は変更しません。
メジャー -監視条件の変更など、開発段階への復帰が必要な変更。 大きな変更があった場合、注文のバージョンを変更します;以前のバージョンは廃止する必要があります。
そして最後に、産業運用から、アプリケーションのサービスを停止するか、サービスモードにすることができます。 サービスモードは、技術活動の監視を一時的にオフにする必要がある場合です。
次の図に、アプリケーションのライフステージを示します。
合計
要約すると、私は3つの柱である監視システムの成功した仕事に依存していると言いたい：システム自体の規制、アプリケーション、技術的能力。
標準の監視条件を含む特定の数のアプリケーションを作成することをお勧めします。 そのようなアプリケーションの場合、監視対象を単純に決定し、通知の宛先を決定し、産業運用の段階に進むだけで十分です。
この記事で伝えたいことはこれだけです。ディスカッションにご招待します。質問に答える準備ができました。