IIS website状態確認では、画面に値が出たことと目的を満たしたことを分けて考えます。結論は「Get-Websiteでsite State、bindings、physical pathを読み、application pool状態とHTTP health checkを別に確認します。Startedはsite設定が開始状態という意味で、application正常応答の保証ではありません。」。Windows ServerでIIS management toolsとWebAdministration moduleが導入済みの管理端末条件のもと、出力の意味、境界値、影響のある操作を順に確認します。
WebAdministration moduleと対象siteを確認する
IISサイトの稼働確認は、Webサイト、アプリケーションプール、バインド、HTTP応答の四層に分けます。exactなサイト名でStateを取得し、対応するプールのStateとホスト名・ポート・証明書バインドを確認します。最後に安全なヘルスURLへ要求し、サービスStartedと利用可能な2xx応答を同一視しません。
- Get-WindowsFeature Web-Serverとmanagement toolsの導入を確認する
- Get-Module -ListAvailable WebAdministrationを確認する
- site name、binding、app pool、ownerを確認する
- health URLとexpected status/contentを定義する
site stateとapplication poolを別に読む
全site状態を読む
Import-Module WebAdministration
Get-Website | Select-Object Name,Id,State,PhysicalPath,ApplicationPool,BindingsImportはmodule読込でsite設定を変更しません。
一siteをexact指定
Get-Website -Name 'Default Web Site' | Select-Object Name,State,ApplicationPool,PhysicalPath実site名へ置き換えます。wildcardで複数siteを巻き込みません。
app pool状態
Get-WebAppPoolState -Name 'DefaultAppPool'site Startedでもpool Stoppedの場合があります。
bindingを展開
Get-WebBinding -Name 'Default Web Site' | Select-Object protocol,bindingInformation,sslFlagshost、port、protocolを確認し、credentialやcertificate private keyは表示しません。
local health check
Invoke-WebRequest -Uri 'https://localhost/health' -UseBasicParsing -TimeoutSec 10 | Select-Object StatusCode,Headers実際のbinding、Host header、TLS trustに合わせます。外部URLへ無断requestしません。
bindingのIP・port・host nameを展開する
Website State、app pool state、worker process、HTTP status、application business healthは段階が違います。Startedでもbinding衝突、certificate、backend、databaseで失敗します。IIS ExpressやAzure-hosted appは同じWebAdministration対象ではありません。module未導入をsite不存在と誤認しません。
実bindingに合うhealth URLを選ぶ
IIS Manager、Get-Website、Get-WebAppPoolState、HTTP healthを同時刻で照合します。期待status codeとcontent、TLS certificate、backend dependencyを確認し、監視結果にsite/pool/HTTPを別列で残します。
HTTP statusとTLS失敗をIIS stateから分ける
- Startedをapplication正常とする
- siteとapp poolを混同する
- module未導入をsiteなしとする
- host headerなしでhealth判定する
- 監視が自動restartする
Start・Stop操作をhealth checkへ混ぜない
確認は読み取りです。Start-Website、Stop-Website、Restart-WebAppPoolは利用者切断やsession lossを招くため一般例で自動実行しません。変更前にconfig backup、site/pool状態、active request、maintenance、rollbackを準備します。問題時は追加restartを繰り返さず、event、IIS log、Failed Request Tracing等のevidenceを集めます。
site・pool・HTTPの三層で検収する
Get-WebsiteのState、Get-WebAppPoolState、Get-WebBindingと、実際のInvoke-WebRequest health endpointを別層として確認します。site Startedだけでapplication正常とはせず、bindingごとのscheme/host/portとHTTP status/latencyを対応付けます。
Default Web Siteを三層のobjectへまとめる
Import-Module WebAdministration -ErrorAction Stop
$site=Get-Website -Name 'Default Web Site' -ErrorAction Stop
$pool=Get-WebAppPoolState -Name $site.ApplicationPool
$http=Invoke-WebRequest -Uri 'https://localhost/health' -UseBasicParsing -TimeoutSec 10 -ErrorAction Stop
[pscustomobject]@{Site=$site.Name;SiteState=$site.State;Pool=$site.ApplicationPool;PoolState=$pool.Value;HttpStatus=$http.StatusCode}site・pool・HTTPのどこで止まったか特定する
- siteとHTTPが正常：exact siteが一件でStarted、app pool Started、期待binding、health 2xxを同時に満たす
- site・pool停止：site不存在はNotConfigured、health 404/503はHTTPFailureとして区別する
- module・binding・request error：module不在、IIS管理権限、TLS/DNS/timeout errorはLayer別Errorにする
Default Web Siteの名前を全環境へ仮定せず、bindingInformationの*:port:hostを展開します。localhost成功だけで外部経路正常とせず、確認記事でsite/app poolをrestartしません。
bindingなし・pool停止・TLS失敗を試す
Get-WebBinding -Name 'Default Web Site' | ForEach-Object { $parts=$_.bindingInformation.Split(':',3); [pscustomobject]@{Protocol=$_.protocol;IP=$parts[0];Port=$parts[1];Host=$parts[2];SslFlags=$_.sslFlags} }site不存在、Stopped、pool stopped、binding違い、HTTP 404/503、TLS error、timeoutをtestします。各layerのstate、binding、status、latency、exception typeを保存します。
Started表示だけではapplicationの応答を保証しません。site、application pool、実bindingへのHTTP requestを個別に判定し、localhostの証明書やhost headerが本番bindingと違う場合は正規URLへ置き換えます。
コメント