.NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。(障害)」に関する情報の監視が必要になる。一般的に、サーバの監視タスクには、以下の項目がある。[#o5394949]ハードウェアの状態、リソース消費量などの警告を確認して、問題発生の可能性を確認する。プロセス独自のリソース(キュー数、スレッド数、仮想アドレス空間など)の利用状況、アクセス状況を確認する。[#if8850b4]ハードウェア・ソフトウェアの障害、設定ミスによるエラーの発生情報と発生原因などを確認する。イベント)を確認する。[#yf6ff0cf]サーバへのリクエスト・レスポンス、レスポンス時間などを確認する。サービスと定期的に通信を行い、正常に動作しているか否かを確認する。[#b984ca1e]サーバに向かって定期的にpingなどを実行することで、~経路が途中で遮断されていないかなどを確認する。特定のサーバ、サービスへのトラフィック量を定常的に監視することで、~トラフィック量が最大になる時間帯の把握や、回線容量の再見積もりができる。アップデートの状況-その他のソフトウェアの修正-プログラム・SPの適用-ハードウェアのドライバの更新状況について確認する。アップデートについて確認する。-また、不正アクセス・攻撃、盗聴ノードがないか確認する。[#k69df5be]「処理能力」の監視と、問題の分析・対策、結果の確認の手順。モニタ」で「カウンタ」を監視することで判断する。チューニングについては、種々の監視を重ね必要性を判断する。~またパラメータを変更する場合は、システムのバックアップを用意した上で、慎重に実施する。ツール等を使用してDBサーバを監視することで判断する。+++アプリケーションがボトルネックとなっている際に、コードレベルで問題を特定する。~支援ツールなどを活用してボトルネックの特定後、必要に応じてプログラムを改修する。[#j9ff7095]「信頼性(障害)」の監視と、問題の分析・対策、結果の確認の手順(フロー図)。#ref(ProcedureOfReliabilityMonitoringAndMeasures.png,left,nowrap,「信頼性(障害)」の監視と対策の手順)-障害の特定には、多くの場合、障害発生時のログの内容からサポート技術文書を検索する。~このため障害発生時のログが残るように、システムやアプリケーションを実装する必要がある。ツール・ダンプツールを必要とする場合もある。[#j4393ca6]問題発生後のセルフ・サポートの開始部分になります。-ツールを使用してシステムがどういう状況にあるか?問題の把握・原因の特定をしていく作業になります。etc.また、これら収集したシステム状態の情報は解決できなかった場合にも、サポート・エンジニアに提供する重要な情報源になります。[#u1926a9c]セルフ・サポートの部分になります。~「原因の把握」ができれば、その情報を元に~Webなどから情報を収集して解決策を導く事が出来ます。[#u3a5a9ac]原因の把握→本対策とのトレードオフを検討しつつ~運用回避などで対処できないかも合わせて検討しておきます。・・・例えば、以下の様な場合。[#n093ec63]サポート・エンジニアとの連携部分になります。ここまでで収集したシステム状態の情報は~サポート・エンジニアに提供します(現象報告レベルでも可)。この場合も(原因の特定がまだされていないようなら)~継続して「原因の把握」が必要になります。この作業は、現地作業者とサポート・エンジニアとの~連携により行われ、最終的に解決策を導く形をとります。