第15章: トラブルシューティングとパフォーマンス最適化

コンテンツ

1. この章で解説する主要な技術・概念（箇条書き）
2. システムの健全性を維持するための監視方法
3. PowerShellを用いたログ解析と問題特定
- 3-1. イベントログの高度なフィルタリング
- 3-2. プロセス・サービス状態からの問題特定
4. パフォーマンスボトルネックの検出と対処
5. 自動化されたトラブルシューティングスクリプトの作成
- 5-1. “Watchdog” スクリプト例
- 5-2. イベントIDトリガー監視
6. ログ分析やアラートの仕組み
- 6-1. 連続失敗や閾値超過時の通知フロー
- 6-2. 定期レポートとダッシュボード化
7. パフォーマンス最適化の具体策
8. 章末まとめと次章へのつながり
- 8-1. 学習のまとめ
- 8-2. 次章へのつながり

1. この章で解説する主要な技術・概念（箇条書き）

システムの健全性を維持するための監視方法
- ログ監視、パフォーマンスカウンター収集、リアルタイム／定期的モニタリング
PowerShellを用いたログ解析と問題特定
- イベントログ（Get-WinEvent / Get-EventLog）フィルタリング・分析
- プロセス状態やサービス状況をスクリプトでチェック
パフォーマンスボトルネックの検出と対処
- CPU, メモリ, ディスクI/O, ネットワークの各指標を監視し、最適化策を検討
自動化されたトラブルシューティングスクリプトの作成
- スクリプトが異常検知→対象サービス/プロセスを再起動 or 通知するフロー
ログ分析やアラートの仕組み
- SIEMや監視ツール連携、PowerShellでのレポート生成
パフォーマンス最適化の具体策
- リソース拡張（RAM/CPU）, ストレージ高速化, ネットワーク設定調整, スケジューリング改善など

2. システムの健全性を維持するための監視方法

2-1. ログ監視の基本サイクル

イベントログ: Application, System, Securityを中心に、各ロール／アプリケーションの個別ログ（DNS Server, Hyper-V, etc.）も含め、定期的にチェック。
PowerShellの活用:
- Get-WinEvent -FilterHashtable {...} 等でフィルタ条件を設定し、エラー系のみ絞り込み→CSVやHTMLでレポート化→メール送信の流れが典型。

$events = Get-WinEvent -LogName "System" | Where-Object { $_.LevelDisplayName -eq "Error" }
if ($events) {
    # レポート生成 or 通知処理
}

2-2. パフォーマンスカウンター収集とリアルタイム監視

Performance Monitor (perfmon) や Resource Monitor がGUIツールとして存在。
PowerShellでは Get-Counter コマンドで特定のカウンターをサンプリングし、結果をファイルに出力・分析可能。
例: Get-Counter -Counter "\Processor(_Total)\% Processor Time" -SampleInterval 5 -MaxSamples 12
- 5秒おきに12回測定（合計60秒）、CPU使用率の変動を記録。

2-3. 定期レポート vs. リアルタイムアラート

定期レポート: 毎日または毎週の集計をメールやダッシュボードに出し、傾向把握や将来予測に使う。
リアルタイムアラート: しきい値超過（CPU 80%超など）やイベントID特定（障害検知）時に即メール・Slack通知。
大規模環境ならZabbix, Nagios, SCOM, Splunkなどを併用し、PowerShellスクリプトで細かい制御を追加するのが一般的。

3. PowerShellを用いたログ解析と問題特定

3-1. イベントログの高度なフィルタリング

# 例: Applicationログからエラーのみ、EventID 1000~1005で絞り込み
Get-WinEvent -FilterHashtable @{
    LogName='Application';
    Level=2;                # 2=Error, 3=Warning, 4=Information
    Id=1000..1005;
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

このように-FilterHashtableを使うと高パフォーマンスで目的のイベントだけ取得可能。
Securityログなど膨大なイベントを扱う際にも効果が大きい。

3-2. プロセス・サービス状態からの問題特定

CPU過負荷プロセス: $highCPU = Get-Process | Where-Object { $_.CPU -gt 100 } | Sort-Object CPU -Descending
メモリ使用量が多いプロセス: WorkingSetやPM(PrivateMemory)を監視し、一定閾値を超えたらメール通知や再起動検討。
サービス停止: Get-Service -Name wuauserv などでStatusがStoppedなら Start-Serviceするなど、前章例の自動再起動アプローチを応用。

4. パフォーマンスボトルネックの検出と対処

4-1. CPUボトルネックの判断基準

\Processor(_Total)% Processor Time が常に80～90%超え続ける場合、CPUコア増設かプロセス再分散を検討。
スレッド数の急増やプロセスがマルチスレッドに対応していないケースを検証。
Dynamic Memory (Hyper-V) との組み合わせで仮想マシンがCPU過負荷になっていないか確認。

4-2. メモリ不足の兆候

\Memory\Available MBytes が常時極端に少ない（< 100MB）
Page File Usage が高い、ディスクI/Oが増大する
Approach: 追加RAM検討、不要プロセス停止、64ビットアプリへの移行など

4-3. ディスクI/Oボトルネック

\PhysicalDisk(_Total)\Avg. Disk sec/Read / Avg. Disk sec/Write が高い値（通常は0.010以下を目標）
ストレージの種類（HDD / SSD / SAN / Storage Spaces）を見直し、IOPS向上策を実施する。
システムドライブとデータドライブを分け、ログや一時ファイルを高速ディスクに置くことで負荷分散。

4-4. ネットワーク遅延

\Network Interface(*)\Bytes Total/sec や Current Bandwidth、Output Queue Length を監視。
帯域不足ならNICチーミング、ネットワークインフラ強化（10GbEなど）、VLAN再設計などを検討。
TCPオフロード機能やRSS(Rx/Tx重複)の設定もパフォーマンス改善に寄与する場合あり。

5. 自動化されたトラブルシューティングスクリプトの作成

5-1. “Watchdog” スクリプト例

<#
.SYNOPSIS
  サーバー稼働状況を定期チェックし、問題を検知したら対処／通知

.PARAMETER CPUThreshold
  CPU使用率が閾値を超えたらレポート

.PARAMETER ServiceList
  監視対象サービスをカンマ区切りで指定
#>
param(
    [int]$CPUThreshold = 80,
    [string[]]$ServiceList = @("Spooler","wuauserv")
)

# 1. CPU監視
$cpuUsage = (Get-Counter "\Processor(_Total)\% Processor Time" -SampleInterval 1 -MaxSamples 1).CounterSamples[0].CookedValue
if ($cpuUsage -gt $CPUThreshold) {
    Write-Warning "High CPU usage: $cpuUsage %"
    # TODO: 通知 / ログ
}

# 2. サービス監視
foreach ($svc in $ServiceList) {
    $status = (Get-Service -Name $svc -ErrorAction SilentlyContinue).Status
    if ($status -eq "Stopped") {
        Write-Warning "Service $svc is Stopped. Starting..."
        Start-Service -Name $svc
        # TODO: 再起動失敗時の処理
    }
}

タスクスケジューラで10分おきに回し、問題発生時にログやメールを送るよう拡張すれば監視の自動化が可能。

5-2. イベントIDトリガー監視

タスクスケジューラのイベントトリガー機能や**Get-WinEvent** でリアルタイム性を高める。
例えば、セキュリティログにEventID 4625（ログオン失敗） が連続発生したらアラートを出すスクリプトなど、セキュリティ面でも活用可能。

6. ログ分析やアラートの仕組み

6-1. 連続失敗や閾値超過時の通知フロー

スクリプト内でカウンター値やイベント件数をしきい値と比較し、超過したら Send-MailMessage で管理者にメール、またはWebhookやSlack通知を行う設計。
大規模組織ではSIEMとの連携が標準的：
- WindowsイベントログをエージェントまたはWinRMで収集→分析。
- PowerShellスクリプトで必要な追加メトリクス（アプリ独自ログなど）を抽出→転送。

6-2. 定期レポートとダッシュボード化

毎朝や毎週、HTMLレポートを生成し、サーバーごとの稼働率や主要なエラーイベントをまとめると管理者が一目で傾向把握。
例: GrafanaやKibanaなどのOSSツールとWindows環境を統合し、可視化ダッシュボードを構築する事例が増えている。
PowerShellでJSON出力→Elastic Stack（Elasticsearch, Logstash, Kibana）に送るなど柔軟な連携が可能。

7. パフォーマンス最適化の具体策

7-1. リソース追加と負荷分散

ハードウェア的にRAM増設、CPUコア増設、SSD/ NVMe導入などが最も直接的な改善策。
仮想化環境なら他ホストへライブマイグレーションで分散。
物理サーバーならNLB（Network Load Balancing）やDNSラウンドロビンなどで負荷分散する方法も考慮。

7-2. スケジューラ設定やチューニング

Windows Serverの内部スケジューラは自動最適化されるが、バックアップや重いバッチを深夜に集中させるとディスクI/OやCPU負荷が飽和する場合がある。
タスクスケジューラの実行時刻を分散させ、リソース使用を平準化する設計がパフォーマンス向上につながる。

7-3. アプリケーション固有のチューニング

IIS: アプリプールの同時接続数制限、リサイクル間隔、キャッシュ設定。
SQL Server: メモリ上限、TempDBの構成、インデックス最適化。
ファイルサーバー: Offline filesの設定やSMB設定など最適化。
アプリごとに最適なガイドラインが提供されている場合はPowerShellでレジストリ・設定ファイルを一括変更する。

8. 章末まとめと次章へのつながり

8-1. 学習のまとめ

トラブルシューティングにおいては、イベントログとパフォーマンスカウンターが強力な手掛かりであり、PowerShellでフィルタリング・自動化できる点が大きい。
パフォーマンスボトルネック（CPU, メモリ, ディスクI/O, ネットワーク）を特定し、原因別にリソース追加やアプリケーション最適化、スケジューリング調整など多面的に対策を講じる必要がある。
自動化されたトラブルシューティングスクリプトは、小規模サーバーでも非常に有効で、サービス再起動やアラート通知を組み合わせることでダウンタイムを最小化できる。
継続的なログ分析や監視ツール（SIEM, Nagios等）連携によって、大規模環境の問題検知を早め、セキュリティ面でも重要な可視性を確保できる。
パフォーマンス最適化策はリソース追加だけでなく、運用設計（タスクスケジュール分散、アプリチューニング）にも大きく左右されるので総合的な検討が求められる。

8-2. 次章へのつながり

次章（第16章）では、高可用性と災害復旧（DR）のためのPowerShellソリューションを解説。
本章で学んだトラブルシュートとパフォーマンスの考え方を踏まえて、システム障害時にどのように自動化で復旧を早めるか、ストレージレプリケーションやフェイルオーバークラスタなどを使ったDR設計を深めていきます。
障害が起きないように最適化しつつ、もし起きても迅速に復旧・代替できる高可用性が、実際の運用において必須要素となるため、次章はそれを最終的にまとめあげるステップとなるでしょう。