リモートサーバーを監視するWebアプリケーションのアーキテクチャ
したがって、私は比較的新しいプログラマーであり、システム情報を表示するためのWebアプリケーション（ASP.net）を作成しようとしています（EG Windowsサービスのステータス、ディスクとリソースの使用状況、およびイベントログのエラー）多数の監視目的のリモートサーバー（当初-これらのサーバーに対するいくつかの基本的なリモートコントロールの追加にも将来対応できるように設計を維持したいと思います）。
小さなプロトタイプを作成することから始めましたが、ソリューションの設計に関して少し混乱しました。
私の現在の解決策は、クライアントサーバーのそれぞれで実行されるwindowsサービス（これらが監視されている）の作成を含みます。ローカルマシンから定期的に必要なデータを収集し、POSTリクエストを介してJSONとして送信します（IIS Monitoringserver、データを受信してSQLデータベースに保存します。今、作成するつもりです個別のASP.net IIS（Monitoringserver）で別のアプリケーションとしてホストするMVCプロジェクトをホストし、これをフロントとして使用するend-DBから読み取り、マシンの統計を表示します。
上記のデザインに盲目的に何か問題がありますか？
このデザインがこのアプリをどこまで実行できるかを制限しているかどうかもわかりません。たとえば、ユーザーがクライアントでアクションを実行できるようにする機能を追加する方法などですWebインターフェースを介したサーバー（例：リアルタイムのシステム情報の手動要求、Windowsサービスのリモート制御、イベントログのクリアなど） clientWindowsサービス内でWeb APIもホストして、サーバーがすべてのクライアントと通信したり、すべてのクライアントにリクエストを送信したりできるようにするのは悪い設計でしょうか？ ？
この投稿が長すぎる/あいまいである場合は、事前に申し訳ありません-アドバイスやデザインの提案は非常にあります！
ログをスクレイピングして中央のソースにフィードするPCにエージェントを設計/展開するアプローチに「誤り」はありません。しかし、最近、特定のヘルス/構成ビットについてPCをポーリングするソリューションを開発するように求められたとき、WMI経由でポーリングして目的の統計情報を取得するサーバーを選択しました。収集する必要のあるビットがWMI経由で利用できる場合（そしておそらくそうである場合）、ログをこするのではなく、それをお勧めします。
私は現在、世界中で約60,000のWindowsデスクトップとサーバーを調査しています。必要な権限がプロビジョニングされたサービスアカウントと、Windows 2008ボックスで実行される4つのプロセス（リージョンごとに1つ）を使用して、結果をMSSQLにダンプし、SSRSをプレゼンテーションレイヤーとして使用しています。
データを収集し、脆弱性のある地域/部門、およびサーバーとデスクトップの数全体にわたる問題のビューを提供できるようになると、問題はすぐに、多数のホストの構成を変更して脆弱性を解消する方法に変わりました。そのためには、WMI呼び出しを "get"から "set"に変更する必要がありました。
WMIを利用して「エージェント」をサーバーに配置することで、クライアントパッケージの開発とテストに必要な時間を回避し、それをプッシュアウトすることなどを行いました。また、要件が変更された場合、多くの場合、その開発/デプロイメントのイテレーションをもう一度実行します。また、WMIは今後も利用できるため、デスクトップがWindows 10に、サーバーが2012に変換されるときにコードが機能します。ログの場所が変更されても、影響はありません。また、ホストに何もデプロイしなかったので、パフォーマンスの問題などについて非難することはできません。情報を取得するためにWMIを呼び出すことによる影響は最小限です。
ログのスクレイピングは最後の手段です。データを収集しているプラットフォームがAPIを提供している場合、そのAPIを活用することで、常に作業が容易になり、ソリューションが拡張され、バージョンのアップグレードに対応できます。