【ITニュース解説】#DAY 8 & 9: Cross-Platform Monitoring - Adding a Windows Host

現代のIT環境は、単一のオペレーティングシステム（OS）だけで構成されることはほとんどなく、Windows、Linuxといった様々なOSが混在しているのが一般的だ。このような多様な環境では、それぞれのシステムを個別に監視するのではなく、全てを一元的に把握し管理できる「クロスプラットフォーム監視」が不可欠となる。これにより、システム全体の状況を可視化し、一貫した制御を可能にすることで、運用管理の効率を大幅に向上させ、可用性やパフォーマンスに関する深い洞察を得ることができる。今回の取り組みは、既存の監視環境にWindowsサーバーとWindows 10コンピューターを追加することで、監視の範囲を広げ、異種OS環境における統一された監視フレームワークを構築することを目的としている。

この取り組みでは、Linuxマシンに加えて、WindowsサーバーとWindows 10コンピューターを監視システムに統合することが目標であった。具体的には、Windowsホストと監視ダッシュボード間の通信を確立し、必要な監視エージェントを設定し、パフォーマンス統計や重要なシステムメトリクスが適切に収集されていることを確認した。このステップにより、監視環境はクロスプラットフォームインフラストラクチャをサポートできるようになり、可視性が向上し、運用上の一貫性が確保された。

Windowsホストを監視対象に追加する具体的な手順を見てみよう。まずWindowsサーバーを統合する。監視を行うためには、Windowsファイアウォールで必要な通信を許可する必要がある。Windows Defender Firewall with Advanced Securityを開き、受信の規則から新規ルールを作成した。カスタムルールとしてICMPv4-In（Internet Control Message Protocol version 4 Inbound）を設定し、特に「Ping」として知られるICMPエコー要求を許可した。これにより、監視システムがWindowsサーバーに対してPingを実行し、基本的なネットワーク接続性やホストの生存状態を確認できるようになる。ルールを保存し、有効になっていることを確認した。

次に、監視対象となるサービスをWindowsサーバー上に用意した。ここでは、WebサーバーソフトウェアであるIIS（Internet Information Services）を例として利用した。PowerShellを管理者として実行し、「Install-WindowsFeature -name Web-Server -IncludeManagementTools」コマンドでIISをインストールした。インストール後、Windowsホスト上でブラウザを開き、「http://192.168.92.10」（例示IPアドレス）にアクセスすることで、IISが正常に動作し、Webページが提供されていることを確認した。

これらの準備が整った後、監視ダッシュボードであるUptime KumaにWindowsホストを追加する。Uptime Kumaのダッシュボードで「新しいモニターを追加」をクリックし、Pingタイプのモニターを作成した。名前を「Windows Host - Ping」、ホスト名をWindowsサーバーのIPアドレス「192.168.92.10」、間隔を60秒と設定して保存した。同様に、HTTP(s)タイプのモニターも追加した。名前を「Windows Host - IIS」、URLを「http://192.168.92.10」と設定した。これにより、Windowsサーバーがネットワーク上で生存しているか（Ping）、またIISが正常にWebサービスを提供しているか（HTTP）を監視できるようになった。

Uptime Kumaのダッシュボードに戻り、追加したPingとHTTPモニターの両方が「UP」ステータスを表示していることを確認した。さらに、別のマシンからWindowsサーバーのIISデフォルトWebページにアクセスし、外部からの到達性も確認した。これらの一連の作業で、Windowsサーバーが監視対象として適切に設定され、基本的な監視が開始されたことが確認できた。

さらに、監視の信頼性を検証するために、障害シミュレーションを行った。Windowsサーバーを意図的にシャットダウンすると、Uptime Kumaのダッシュボードにサーバーがダウンした旨の通知が表示され、同時に設定されたTelegramなどの通知システムを通じてアラートメッセージがポップアップ表示された。このテストにより、システム障害発生時に、監視システムが適切に異常を検知し、即座に担当者に通知する機能が正常に動作することが確認された。

次に、Windows 10コンピューターを監視システムに統合する手順について説明する。Windows 10マシンでも、まずファイアウォールの設定が必要となる。Windows Securityの「ファイアウォールとネットワーク保護」から「詳細設定」を開き、「ファイルとプリンターの共有 (エコー要求 - ICMPv4-In)」ルールを有効にした。これは、Uptime KumaからのPing要求に対してWindows 10マシンが応答できるようにするためである。この設定により、Windows 10の基本的な生存監視が可能となる。Uptime Kumaには、Windows 10のIPアドレスを指すPingモニターを追加し、「ホストが稼働しているか」という基本的な状態監視を確認した。

Windows 10でも、監視対象となるサービスとしてIISを導入した。Win + Rキーを押し「optionalfeatures」と入力して「Windowsの機能」ダイアログを開いた。「インターネット インフォメーション サービス（IIS）」と「IIS管理コンソール」にチェックを入れてOKをクリックし、IISをインストールした。Windows 10マシン上でブラウザを開き、「http://192.168.92.142」（例示IPアドレス）にアクセスすることで、IISが正常に動作していることを確認した。さらに、別のラップトップのChromeブラウザからもローカルホストにアクセスし、デフォルトのIISランディングページが表示されることを確認した。Uptime Kumaには、このWindows 10マシンのIPアドレスをURLとする新しいHTTP(s)モニターを追加した。これにより、Windows 10ホストが稼働しているだけでなく、Webページを提供しているかどうかも可視化できるようになった。

PingやIISといった基本的な監視に加え、Windows 10の他の組み込みサービスもUptime Kumaで監視するように設定した。ここでは、ファイル共有プロトコルであるSMB（Server Message Block）の監視（TCP 445番ポート）を例に挙げる。まず、Windows 10マシンでファイル共有が有効になっており、ファイアウォールを通過できることを確認した。「コントロールパネル」の「ネットワークと共有センター」から「詳細な共有設定の変更」を開き、現在アクティブなネットワークプロファイルで「ファイルとプリンターの共有」と「ネットワーク探索」を有効にした。変更を保存した。

次に、SMBがWindowsファイアウォールを通過できるように設定した。Windows Defender Firewallの「詳細設定」から「受信の規則」を開き、「ファイルとプリンターの共有 (SMB-In)」ルールを見つけて有効にした。これを適切なプロファイル（プライベート、ドメイン、パブリック）に適用した。SMBサービスがローカルでリッスンしていることを確認するため、Windows 10マシン上でPowerShellを開き、「netstat -an | findstr 445」コマンドを実行した。出力結果からTCPポート445がLISTEN状態にあることが確認できた。

Uptime Kumaダッシュボードで新しいモニターを追加し、タイプを「TCPポート」、名前を「Windows 10 - SMB」、ホストをWindows 10のIPアドレス「192.168.92.142」、ポートを「445」と設定して保存した。ダッシュボードでは、新しいSMBモニターが「UP」に切り替わり、SMBサービスが到達可能であることを確認できた。

これらの設定により、WindowsサーバーとWindows 10コンピューターが監視システムに完全に統合され、Uptime Kumaのステータスページで全てのサービスの稼働状況が一元的に表示されるようになった。これにより、インフラストラクチャ全体の健全性を一目で把握できるだけでなく、Telegramなどのリアルタイムアラート通知によって、問題発生時には迅速に検知し、対応できる体制が整った。

今回の取り組みにより、WindowsサーバーとWindows 10コンピューターを既存の監視設定に統合することに成功し、異種プラットフォーム間での可視性を大幅に向上させることができた。ファイアウォールルールの有効化、IISをテストサービスとしての設定、Ping、HTTP、SMBモニターによる接続確認を通じて、統一された監視フレームワークが確立された。IISウェブサービスの導入、ICMP監視の有効化、SMB（TCP 445）などの他のプロトコルの検証を行った。障害シミュレーションでは、Windowsホストがダウンした際に、ダッシュボードの更新とアラームが計画通りに機能することを確認できた。

Uptime Kumaダッシュボードにより、LinuxサーバーとWindowsサーバーの一元的な制御が可能となり、Telegramのリアルタイムアラートは、迅速な障害特定と危機対応を保証する。公開ステータスページにWindowsホストを含めることで、透明性が向上し、インフラストラクチャの状態を包括的に把握できるようになった。クロスプラットフォーム監視の目標は完全に達成されたと言える。可視性とプロアクティブな通知を通じて、監視環境は複数のシステム間での運用の一貫性を保証し、信頼性追跡を強化し、関係者の信頼を高める。

この一連の作業からいくつかの重要な教訓が得られた。まず、「クロスプラットフォームの一貫性」の重要性だ。WindowsとLinuxの両方を同じダッシュボードから監視することで、情報収集の死角が減り、運用効率が向上する。次に「Windowsファイアウォールの最適化」が不可欠であること。ICMP、SMB、HTTPといった適切なファイアウォール設定がなければ、正確な監視は不可能である。また、「多層的な検証」も重要だ。Ping、HTTP、TCPテストを組み合わせることで、ホストの可用性とサービスの状態をより深く理解できる。最後に「障害テスト」は信頼性を強化する。シャットダウンをシミュレートすることで、複数のOSにわたるリアルタイム警告が確実に機能することを確認でき、万が一の事態への備えを強化できる。