web-dev-qa-db-ja.com

定期的なシステムヘルスチェック中に何をチェックするか

私は、チームが行うことになっている毎週のシステムヘルスチェックルーチンの一部として実行するチェックのリストを準備することを任されています。問題は、私も同僚もプロのシステム管理者ではなかったことであり、私たちが思いつくことができる最高のものはかなり笑えるものです。

システムはSiemensSIMATIC ITとLIMSを実行しますが、オペレーティングシステムとデータベースサーバーの一般的なチェック/テストに興味があります。他の誰かが、実行されているアプリケーションに固有のテストを処理します。

セットアップは次のとおりです。

すべてのサーバーは仮想であり、vSphere5環境で実行されます。

  • Webサーバー– MS Windows Server 2003 R2
  • SIMATIC ITコンポーネントを実行する2台のサーバー1台はHistorian用、もう1台はProduction Modelerおよびその他のコンポーネント用– MS Windows Server 2003 R2
  • データベースサーバー– MS Windows Server 2003 R2 + MS SQL Server 2005
  • データベース+ LIMSサーバー– MS Windows Server 2008 R2 + Oracle Database 11g

ほとんどの場合、vCenterコンソールにアクセスできないため、リモートデスクトップをそれらのサーバーに接続し、建設的なチェック/テストを行ってレポートを作成することをお勧めします。

すでに書いたように、ディスクの空き容量を確認する以外に、思いつくことはほとんどありません。また、ChkDskを使用してファイルシステムの断片化とファイルシステムエラーのレベルを確認し、Windowsイベントビューアで重要なエラーと警告を調べ、データベースのインデックス断片化のレベルを確認し、応答時間の統計を収集することも考えられます。いくつかの重要なクエリの実行時間。

どんな助けでも大歓迎です。何をチェックすべきかについての情報に加えて、24時間年中無休で負荷がかかっているシステムで何をすべきでないかについてのヒントも非常に役立ちます。たとえば、負荷がかかっているデータベースサーバーで分析するためだけでもデフラグツールを実行するのは非常に悪い考えかもしれませんが、私はまだそれを知りません。

ありがとうございました。

windows-server-2003sql-serverwindows-server-2008-r2oracle-11ghealthcheck
3
Maciej Hehl

あなたはそれを間違ってするように求められています。

本番システムにログインして定期的に手動チェックを行うべきではありません。
これにより、（a）チェックの間に発生した何かを見逃してビジネスを停止し、（b）チェックの実行中に失敗してビジネスを停止することが保証されます。

代わりに、継続的な定期チェック（5〜10分ごと）を実行し、異常を報告する 監視システム を実装する必要があります。何をチェックするかについての詳細とアイデアについては、 monitoring タグを参照してください。

ディスク容量、スワップ使用率、およびCPU負荷（RunQの深さ）は、監視する一般的なものです。また、データベースサーバーで標準のテストクエリを実行（および時間/出力を確認）することもできます（これらのクエリは、環境に基づいて作成する必要があります）。

9
voretaq7

Windows OSで実行されているサーバーの場合、重要なチェックは次のとおりです。

  • CPU使用率。
  • RAM使用率。
  • ハードディスクの空き容量。
  • Webサーバー（IIS）サービスが実行されているかどうか。

ネットワークの観点から：

  • 適切に構成されたDNS
  • DHCPからのIP

これは役に立つかもしれません...

1
Avi Mehenwal

これはWebサーバーであるため、リストに別のものを追加します。

  • IISログ内の「200」、「500」、「401」、および「503」応答の数をカウントするようにスケジュールされたタスクを設定します。これを行うには、LOGPARSERを使用できます。つまり、スクリプトはそれぞれの発生数をカウントし、500応答と503応答の数を200応答の数で除算します。これにより、Webサーバーの応答パフォーマンスの全体的な状態が障害の比率として示されます（ 500）/成功（200）。

    • 500-エラー-Web呼び出しが失敗しました
    • 503-タイムアウト-WebプロキシがアップストリームWebサーバーから応答を受信しませんでした
    • 401-無許可-Web通話が認証されませんでした
    • 200-成功-Web呼び出しはエラーをスローせずに処理されました

次に、スクリプトは結果（生データを含む）を中央のレポートシステムにアップロードする必要があります。これにより、ローカルにログインしなくても結果を調べることができます。

ログのより詳細な調査が必要な場合（たとえば、該当する場合、どのアプリプールがうまく機能していないか）、LOGPARSERでこれを掘り下げることができる他の多くのことがあります。

0
George Erhard