サーバトラブル解決に
Windows Server 2008の新ツールでサーバ履歴を分析
Windows Server 2008のユーティリティ「Reliability and Performance Monitor」は、サーバの履歴をチェックし、問題を引き起こしたイベントを特定するのに役立つ。
サーバの履歴を調べるには、イベントログを検査するのが一般的な方法だ。しかし残念なことに、イベントログに含まれる情報量が不十分であったり、逆に情報が多過ぎるために本当に必要な情報を探し出せないかのどちらかであることが多い。もちろん、サーバの履歴を確認するだけであれば、何時間もかけてイベントログを丹念に検査するには及ばない。
幸いにも、Microsoftはわれわれの苦労を理解してくれたようだ。Windows Server 2008には「Reliability and Performance Monitor」というユーティリティが付属している。このツール（Windows Vistaにも含まれる）は、サーバの履歴をチェックし、問題を引き起こしたイベントを特定するのに役立つ。実際、わたしも最近、仕事で使っているサーバの1台で起きた問題の原因を特定するのにこのツールを利用した。
このユーティリティにアクセスするには、サーバの「Administrative Tools」メニューから「Reliability and Performance Monitor」コマンドを選択する。Reliability and Performance Monitorが開くと、サーバの現在のパフォーマンスデータを示した幾つかのグラフが表示される（図A）。
図A《クリックで拡大》
このパフォーマンスデータも役立つが、サーバの履歴を知りたいのであれば、コンソールツリーから「Reliability and Performance」→「Monitoring Tools」→「Reliability Monitor」を選択する。すると図Bのような画面が現れる。
図B《クリックで拡大》
恐らくこの画面で最初に目に付くのは、上側にある大きなグラフだろう。このグラフはさまざまなイベントを記録し、サーバの信頼性を時系列で表したものだ。画面の右上の数字は、サーバの現在の信頼性を1から10の指標で評価したものだ。
この図によると、今日のわたしのサーバの信頼性指標は6.15であり、これはあまり良いとはいえない。しかし画面の下側の部分を見ていただきたい。この部分は、今日起きたイベントでサーバの信頼性に影響するものを示している。これを見れば分かるように、今日は何も起きていない。グラフに戻ると、2008年4月21日以降は重要なイベントが起きていないことが分かる。しかしサーバの信頼性指標は最初の時点で10だったのが、4月に幾つかイベントが起きたために信頼性に問題があると判断されたのだ。
重要な問題が検出されるたびに、信頼性指標の値が少し（問題の性質によっては大きく）減少する。何も問題が起きずに1日が過ぎれば、信頼性指標の値が少し増加する。これは、サーバが前日よりも少し信頼性が高いことを実証したことを意味する。グラフでは、4月21日以降、信頼性指標が徐々に増加しているのが分かる。
これらのスクリーンショットは本稿執筆用にわたしのサーバでキャプチャーしたものであり、4月に起きた問題のほとんどは、一部のメモリチップの不具合に関連したものであることが分かっている。しかし、わたしがこのサーバを初めて見るコンサルタントで、それまでに起きた問題についてもっと詳しく知りたいとしよう。その場合、グラフに表示された日付のどれかをクリックすれば、その日のイベントに関する情報を見ることができる。図Cに示すように、Reliability Monitorはその日に起きた問題に関する具体的な情報を提供してくれる。
図C《クリックで拡大》
既に述べたように、このチャートのイベントのほとんどはメモリチップの不具合に関連したものである。この問題は4月15日ごろから起きなくなったようだが、4月21日には新たに問題が発生している。
4月21日に起きた問題は複数の電源障害に関係したものだったが、Windowsにはそれは分からない。グラフを見れば、4月20日から21日にかけて信頼性指標が大きく落ち込んでいるのが分かる。図Dに示すように、4月20日にイベントが起きているが、これはエラーではない。
図D《クリックで拡大》
図Dは、わたしが4月20日に新しいデバイスドライバをインストールしたことを示している。4月21日に電源障害が起きたのは単なる偶然だが、Reliability Monitorは信頼性指標が急激に低下したことを示している。これは、システムの信頼性にかかわるイベントが前日に起きたという事実に対して注意を喚起するためだ。Reliability Monitorは、4月20日にインストールされたデバイスドライバが、その翌日に起きた障害の原因となった可能性があることを示そうとしているのだ。このケースではそうではなかったが、通常は、こういったイベントと障害の因果関係を調査する必要がある。
本稿筆者のブライエン・M・ポージー氏はMCSE（マイクロソフト認定システムエンジニア）の資格を持ち、Windows Server、IISおよびExchange Serverに関する仕事でMicrosoft Most Valuable Professionalの認定を4回受けた。全米規模の病院／医療施設チェーンでCIOを務めた経験を持つほか、フォートノックス（ケンタッキー州にある米軍施設）のネットワーク管理者を務めたこともある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[株式会社ラクス] どうすれば「変革を楽しむ組織」になれるのか？ 事例に学ぶ、未来への一歩 -
製品レビュー
[デル・テクノロジーズ株式会社] 変化するサイバー脅威に備える、これからのストレージの選び方 -
事例
[サイボウズ株式会社] 受注約1.5倍と年間2万3000時間超の業務時間を削減、日機装に学ぶDX実践術 -
製品レビュー
[サイボウズ株式会社] 人材不足にどう挑む？ ものづくり太郎が語る、製造現場でのAI活用成功の鍵 -
市場調査・トレンド
[グーグル・クラウド・ジャパン合同会社] 金融機関はAIエージェント導入でどう変わる？ 7つの変化から19の事例まで解説
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
Microsoft 365侵害企業の9割はMFA導入済み 1002人調査で見えた盲点
-
2
RAGで「データをAIに送る」運用が限界を迎えている理由
-
3
「Copilot」がIT予算を食いつぶす？ 高額請求を招く課金体系と節約術
-
4
PHPはそもそも必要か？ 脆弱性で問われる自社サイト安全性と保守負担のバランス
-
5
セキュリティ担当者“試練の1週間” 「PHP」脆弱性と認証局の失態が同時発生
-
6
いまIBM iエンジニアが直面する「5つの技術的課題」とその解決策
-
7
なぜストレージ不足は長引くのか？ 77％が「12〜18カ月続く」と予測
-
8
SAPの負荷増に苦しむZeissが「リアルタイム分析」「安定運用」を両立させた道
-
9
なぜ「Claude Code」拡張は消しても危ないのか？ Cursorで不正版配信
-
10
PHP2Shellの「事前の情報流出」でパニックに パッチ公開を巡る“混乱劇”
ホワイトペーパーランキング PR
-
1
「IT史に名を残すシステム障害」8選
-
2
侵入から横展開まで27秒の脅威にどう立ち向かう？ 防御のカギがEDRの理由
-
3
有識者が語る、中堅中小企業に求められる最新のサイバーセキュリティ対策とは
-
4
AI駆動攻撃にどう対抗する？ 超速の攻撃からエンドポイントを保護する方法
-
5
10G回線の真価をフルに享受するには？ 導入前にチェックしたいポイント
-
6
なぜAIは組織で定着しないのか？ 全社展開を阻む「3つの壁」と突破のヒント
-
7
パスワードレスへの移行で失敗しないためには？ 導入・運用上の注意点を解説
-
8
自社のセキュリティ対策は大丈夫？ 自己診断リストで対策の優先順位が分かる
-
9
ランサムウェア攻撃“究極の対策”はこれだ
-
10
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー