MS_ServerMonitoring
-
TOP > トラブルシュート > 障害発生時の分析
- サーバーの監視
- ログ収集いろいろ
- パフォーマンス カウンタ
「処理能力」の問題や「障害」の発生を未然に防止したり、迅速に対応したりすることで
高い可用性を維持するには、「処理能力」・「信頼性（障害）」に関する情報の監視が必要になる。
一般的に、サーバの監視タスクには、以下の項目がある。
- サーバ マシン
ハードウェアの状態、リソース消費量などの警告を確認して、問題発生の可能性を確認する。 - サーバ プロセス
サーバ プロセス独自のリソース（キュー数、スレッド数、仮想アドレス空間など）の
利用状況、アクセス状況を確認する。
※ 具体的な指標はパフォーマンス カウンタを参照。
- 信頼性（障害）
ハードウェア・ソフトウェアの障害、設定ミスによるエラーの発生情報と発生原因などを確認する。 - イベント
各種イベント（システム イベント、アプリケーション イベント、セキュリティ イベント）を確認する
（イベント・ログ）。 - アクセス
サーバへのリクエスト・レスポンス、レスポンス時間などを確認する（IISのログ）。
- サービス
サーバ上のネットワーク サービスと定期的に通信を行い、正常に動作しているか否かを確認する。 - ネットワーク
サーバに向かって定期的に ping などを実行することで、
経路が途中で遮断されていないかなどを確認する。
※ ping が通ることとアプリが正常に応答することは別。
Web / AP 層は、実際に業務処理を1つ通すヘルスチェック用エンドポイントを
用意して監視するのが望ましい（DB 接続なども含めて確認できる）。
ネットワークのトラフィック量、特定のサーバ・サービスへのトラフィック量を
定常的に監視することで、トラフィック量が最大になる時間帯の把握や、
回線容量の再見積もりができる
（監視・パケット解析編を参照）。
- オンライン アップデートの状況
- その他のソフトウェアの修正
- プログラム・SP の適用
- ハードウェアのドライバの更新状況
について確認する。
- セキュリティ アップデートについて確認する。
- また、不正アクセス・攻撃、盗聴ノードがないか確認する。
「処理能力」の監視と、問題の分析・対策、結果の確認の手順。
- ハードウェア増設の必要性は、「システム モニタ」で「カウンタ」を監視することで判断する。
- パラメータ チューニングについては、種々の監視を重ね必要性を判断する。
またパラメータを変更する場合は、システムのバックアップを用意した上で、慎重に実施する。 - DBMS のインデックス チューニングの必要性は、
各 DBMS のトレース ツール等を使用して DB サーバを監視することで判断する。 - アプリケーションがボトルネックとなっている際に、コードレベルで問題を特定する。
支援ツールなどを活用してボトルネックの特定後、必要に応じてプログラムを改修する。
「信頼性（障害）」の監視と、問題の分析・対策、結果の確認の手順（フロー図）。
- 障害の特定には、多くの場合、障害発生時のログの内容からサポート技術文書を検索する。
このため障害発生時のログが残るように、システムやアプリケーションを実装する必要がある
（検索サイトで効率的に情報を得る方法）。 - また、正確且つ、迅速な対応が必要となる場合は、
製品サポートに加えて、高度なデバッグ ツール・ダンプツールを必要とする場合もある
（ダンプの概要（種類と取得））。
問題発生後のセルフ・サポートの開始部分になります。
- ツールを使用してシステムがどういう状況にあるか？
問題の把握・原因の特定をしていく作業になります。例えば、システム上で実行される種々の処理が引き起こす、
また、これら収集したシステム状態の情報は解決できなかった場合にも、
サポート・エンジニアに提供する重要な情報源になります。
セルフ・サポートの部分になります。
「原因の把握」ができれば、その情報を元に Web などから情報を収集して解決策を導く事が出来ます。
↓↓↓ 上記で解決できなかった場合
原因の把握 → 本対策とのトレードオフを検討しつつ
運用回避などで対処できないかも合わせて検討しておきます。
・・・例えば、以下の様な場合。
- PG 修正量が大きく現実的でない
- 本番（稼働）環境で発生しており早急な対処が必要
- etc.
サポート・エンジニアとの連携部分になります。
ここまでで収集したシステム状態の情報はサポート・エンジニアに提供します（現象報告レベルでも可）。
この場合も（原因の特定がまだされていないようなら）継続して「原因の把握」が必要になります。
この作業は、現地作業者とサポート・エンジニアとの連携により行われ、最終的に解決策を導く形をとります。
※ 依頼時に何を揃えるべきかはサポートへの問い合わせ時のチェックリストを参照。
補足（最新化）: 現在は、上記の監視項目を個別ツールで揃えるのではなく、 オブザーバビリティ基盤（メトリクス／ログ／トレースの3本柱）に集約する構成が一般的。 Azure なら Azure Monitor（＋ Application Insights の分散トレース）、 OSS なら Prometheus + Grafana + OpenTelemetry。 「監視項目を決める」という本ページの整理自体は、 どの基盤を使う場合でも変わらず必要になる。
- 因果関係の分析例（
MS_CausalAnalysisExamples.md） - 障害対応に使用するツールの一覧
Tags: 障害対応, 性能, デバッグ