IIS 監視

はい、XitogentはフルインストールとCoreインストールの両方で動作します。

はい、メトリクスはサイトごとおよびアプリケーションプールごとに収集されます。

IIS 8.5 以降（Windows Server 2012 R2 以降）。

統合パイプライン(IIS 7 以降のデフォルト)は、すべてのリクエストを統一された IIS + ASP.NET パイプラインを通してルーティングします — 1 セットの HTTP モジュールが静的コンテンツとマネージドコンテンツの両方の認証、ロギング、リクエスト処理を担当します。クラシックパイプラインはレガシー IIS パイプラインの背後で ASP.NET を ISAPI 拡張として実行します(2 つの別々のリクエストパス)。クラシックモードは非推奨で低速です。新しいアプリは統合を使用すべきです。Xitogent は両方を監視しますが、統合の方がマネージドパイプラインのカウンターを多く公開します。

`HTTP Service Request Queues` PerfMon カテゴリは、`ArrivalRate`(カーネルへの受信リクエストレート)、`CurrentQueueSize`(ワーカーを待っているリクエスト)、`RejectedRequests`(キュー制限に達したためドロップされた数)を公開します。ゼロ以外の RejectedRequests レートは、HTTP 503 エラーの最も優れた単一の先行指標です。そこと `CurrentQueueSize > MaxQueueLength × 0.8` でアラートを発行しましょう。

ASP.NET Core は ASP.NET Core Module(ANCM)を使用します。インプロセスホスティング(2.2 以降のデフォルト)は Kestrel を `w3wp.exe` 内で実行します — 他のアプリプールと同じように監視し、ANCM 固有のメトリクスについては `IISHttpServer` プロバイダを追加します。アウトオブプロセスホスティングは Kestrel を別途実行して IIS 経由でプロキシします — `w3wp.exe` プロキシとバックエンドの Kestrel プロセスの両方を追跡しましょう。

主な原因は 3 つあります: (1) アプリケーションプールが停止またはクラッシュ(多くは Rapid-Fail Protection がトリガーされた)、(2) HTTP.SYS がキューが `MaxQueueLength` を超えたためリクエストを拒否、(3) ワーカープロセスがリサイクル中でまだ準備できていない。それぞれが異なるシグナルを示します: プール状態、RejectedRequests カウンター、リサイクルイベント。Xitogent は 3 つすべてを可視化するため、トリアージは数時間ではなく数分で完了します。

はい。Xitogent は Windows Server Core でもフル Server インストールでも同じように動作します — 同じ API 経由でパフォーマンスカウンターを読み取ります。Server Core は攻撃面とリサイクルをトリガーする OS アップデートを減らすため、実際には本番 IIS ワークロードの推奨デプロイメントです。

デフォルトでは 60 秒ごと、インシデント対応用にサブミニッツのポーリングも可能です。プールごとのリサイクルイベントは Windows イベントサブスクリプション経由で発生した瞬間にキャプチャされます(ポーリング遅延なし)。そのため、503 の根本原因は次のサンプル間隔ではなく即座に表示されます。