【ITニュース解説】#DAY 4 - Expanding My Monitoring Scope: External & Advanced Checks

監視は、システムが常に正常に機能し、問題が発生する前にそれを発見するための、IT運用における非常に重要な活動である。従来の監視では、自社が管理するサーバーやアプリケーションといった内部のサービスに焦点を当てることが一般的だった。しかし、現代のシステムはますます複雑化し、ウェブサイトやAPI、クラウドサービスなど、外部に公開されている多くの要素と連携している。そのため、ユーザーがシステムを利用する際に直接影響を受ける外部の要素、例えば外部のWebサービス、ネットワークゲートウェイ、DNSサーバーなども含めて監視する、より包括的なアプローチが必要とされている。このような外部監視を導入することで、内部だけでなく外部に起因する問題も早期に発見し、ユーザー体験の低下を防ぎ、システムの全体的な信頼性を高めることができる。

今回は、このような外部リソースの監視と、より高度なチェック方法を実際に導入することを目標とした。その最初の一歩として、監視ツールであるUptime Kumaのダッシュボードにアクセスしようとしたが、ここで思わぬトラブルに遭遇した。ブラウザで指定されたIPアドレスとポート番号にアクセスしても、画面がロード中のまま進まず、最終的にタイムアウトエラーが発生したのだ。

この問題の解決は、システムエンジニアにとって非常に重要な、系統的なトラブルシューティングの良い実例となった。まず、ネットワーク接続に問題がないかを確認するため、nc -zvというコマンドを使って、問題のIPアドレスとポート番号（例：192.168.92.134:3002）に接続を試みた。結果は「Connection denied」、つまり接続が拒否されたことを示しており、これはポートが閉じているか、あるいはそのポートでサービスが応答していないことを意味した。この状況は、ネットワークのファイアウォールによるブロックではなく、アプリケーション自体に問題がある可能性が高いことを示唆していた。

次に、Uptime KumaがDockerコンテナとして稼働していることを考慮し、Docker内部の状況を調べた。sudo lsof -i:3002というコマンドを実行してポート3002を監視しているプロセスを確認すると、「docker-pr」というDockerのプロキシプロセスがそのポートをリッスン（待ち受け）していることがわかった。これは、Dockerが外部からの通信をこのポートで受け取り、コンテナに転送する準備はできているが、コンテナ自体がその通信に応答していないという、少し矛盾した状態を示していた。

そこで、コンテナの起動時に何か問題がなかったかを確認するため、sudo docker logs uptime-kumaコマンドでコンテナのログを確認した。しかし、ログにはエラーメッセージは一切なく、データベースへの接続も成功し、アプリケーションが正常に起動しているかのように表示されていた。Dockerがポートを扱っているにもかかわらず、アプリケーションにアクセスできないというこの矛盾から、コンテナの内部状態に何らかの問題があるのではないかと推測した。

この状況を打開するため、Dockerサービス全体を再起動することを試みた。sudo systemctl restart dockerを実行し、その後sudo docker psコマンドで現在稼働中のDockerコンテナを確認したところ、以前起動していたはずのUptime Kumaコンテナが一覧から消えていることに気づいた。ここで過去の操作履歴を思い返すと、以前にUptime Kumaコンテナを再デプロイしようとしたことがあったのを思い出した。

問題の根本原因はここにあった。以前、新しいコンテナを起動しようとした際に、sudo docker runコマンドを実行したものの、Dockerから「Conflict. "/uptime-kuma" is already being used as a container name.」というエラーメッセージが返されていたのだ。これは、同じ名前のコンテナが既に存在していることを意味する。この時、古いコンテナを停止させるためにdocker stopコマンドは使ったが、docker rmコマンドで完全に削除していなかったため、システム内に見えない形で古いコンテナの残骸が残り、新しいコンテナの起動を妨げていたのだ。また、一度停止した古いコンテナを、必要な設定オプションを省略したdocker runコマンドで再起動しようとしたため、ポートマッピングが正しく行われず、結果的に外部からアクセスできない状態になっていたと考えられる。

解決策は明確だった。まず、残っていた古いコンテナをdocker rmコマンドで完全に削除した。次に、Dockerサービスを再起動してシステムの状態をクリーンにした。そして、必要な全てのオプション（バックグラウンド実行を指示する-d、ポート番号を関連付ける-p、データを永続化する-v、コンテナ名を指定する--name）を正確に指定したdocker runコマンドで、Uptime Kumaコンテナを再デプロイした。この一連の作業を行った結果、Uptime Kumaに正常にアクセスできるようになった。nc -zvコマンドで再度確認したところ、「Connection ... succeeded!」という成功メッセージが表示され、問題が完全に解決したことを確認できた。

このトラブルシューティングの経験から、いくつかの重要な教訓が得られた。Dockerコンテナの名前はシステム内で一意である必要があり、単にコンテナを停止させるdocker stopだけでは問題が解決しない場合がある。特に名前の衝突が起きるような状況では、docker rmコマンドでコンテナを完全に削除することが不可欠である。また、ログファイルにエラーが表示されていなくても、実際にネットワーク経由でサービスに到達可能であることをncのようなツールで確認する習慣が重要だ。このように、問題発生時には焦らず、系統的かつ段階的に確認を進めることで、見過ごされがちな問題の根源をほぼ確実に見つけ出すことができる。

Uptime Kumaへのアクセスが可能になったことで、いよいよ計画していた外部リソースの監視設定へと進んだ。 まず、自分のネットワークのデフォルトゲートウェイ（例：192.168.92.2）の可用性を確認するため、Ping監視を追加した。Ping監視は、特定のIPアドレスに対して信号を送信し、応答があるかどうかを確認することで、ネットワーク接続の基本的な健全性をチェックする。これは、ネットワークの入り口が機能しているかを確認する上で非常に重要である。

次に、インターネット上の信頼できるテストサイト（例：https://httpstat.us/200）に対して、基本的なHTTP(S)監視を設定した。この監視は、指定されたURLにアクセスし、Webサーバーが正常に動作していることを示すHTTPステータスコード（例：200 OK）が返されることを確認することで、外部のWebサービスが稼働しているかを監視する。

さらに、Webサイトの内容まで確認するため、キーワード監視を導入した。これは、特定のニュースサイト（例：https://www.bbc.com/news）のようなURLにアクセスし、そのページのHTMLコンテンツ内に特定のキーワード（例：「UK」）が含まれているかをチェックするものだ。この監視により、Webサイトが単にアクセス可能であるだけでなく、期待するコンテンツが正しく表示されているかを確認でき、より高度なWebサイトの健全性を判断できる。

最後に、DNS監視を追加した。これは、GoogleのDNSサーバー（8.8.8.8）のような特定のDNSサーバーが、「google.com」のようなドメイン名を正しいIPアドレスに解決できるかを確認するものだ。DNSはインターネットの「電話帳」のような役割を果たしており、これが機能しないと、たとえWebサーバーが稼働していてもWebサイトにアクセスできなくなるため、その健全性を監視することは非常に重要である。

これらの監視設定を完了すると、Uptime Kumaのダッシュボードには、内部ネットワークの監視項目だけでなく、世界地図のアイコンやサーバーのアイコンで示される外部リソースの監視項目も表示されるようになった。これにより、システムの内部状況に加え、外部の依存関係まで含めた、ユーザーが実際にシステムを利用する際の体験に近い、より包括的な視点での監視体制が確立された。

今回の取り組みにより、内部サービスのみのチェックから、高度なHTTP検証、DNS健全性チェック、そして外部のエンドポイントを含む、より広範な監視戦略への重要な転換が実現された。Docker環境における最初のポート衝突とコンテナ管理の課題は、体系的なトラブルシューティング、コンテナのライフサイクルへの理解、そして正確なコマンド実行の重要性を明確に示した。この問題解決がUptime Kumaの完全な利用を可能にし、その後の洗練された監視設定へとつながった。

最終的に、ネットワークゲートウェイの到達性を検証するPing監視、信頼性の高い外部エンドポイントの稼働状況を確認する基本HTTP監視、外部コンテンツの読み込み状況を確認するキーワード監視、そして名前解決の正常性を保証するDNS監視が全て効果的に設定された。ダッシュボードは今や、自身のネットワーク内部だけでなく、外部の依存関係をも網羅する包括的なビューを提供し、実際のユーザー体験を反映した強固な監視体制が構築されたと言える。これにより、より堅牢でプロアクティブな監視姿勢が確保され、内部サービスだけでなく外部の信頼性要因まで含めたシステム全体の健全性に対する洞察が深まった。