スキップしてメイン コンテンツに移動

【Day 13】コンテナのログ確認とデバッグ（logs, inspect, top） 〜標準出力のリアルタイム追跡とリソース監視術〜

Day 13 アイキャッチ
▲ Day 13: コンテナのログ確認とデバッグ（logs, inspect, top）
🐳
皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。
前回【Day 12】では、コンテナの状態確認（ps）、安全な停止（stop）、破棄（rm）の基本ライフサイクルを学びました。
本日は第13回として、開発やトラブルシューティングの現場で最も頻繁に叩くことになる「コンテナのログ確認とデバッグ（logs, inspect, top）」を徹底解説します！
Windowsイベントビューアーやサーバー上のログファイルを手動で探していたベテランの方ほど、Dockerの標準出力ストリームと診断コマンドの圧倒的な快適さに驚かれるはずです！

① 導入・本日の達成目標

「バックグラウンド（-d）で起動したコンテナが正しく動いているか、どうやって確かめるのか？」
「HTTP 500エラーが発生したとき、C#アプリのエラーログはどこに出力されているのか？」
「コンテナのIPアドレスや割り当てられたポート番号、CPU消費量はどう調べるのか？」

これらはすべて、Dockerが標準で提供する診断コマンド群（logs, inspect, stats, top）によって手元のターミナルから1発で把握できます。 本講義のゴールは以下の3点です。

  • docker logs -f を使い、コンテナ内部の標準出力を手元のターミナルへリアルタイムストリーミング監視できるようになる。
  • docker inspect を活用し、コンテナのIPアドレス・環境変数・ボリューム設定をピンポイントで調査・抽出できるようになる。
  • docker stats ＆ docker top により、タスクマネージャー感覚でCPU・メモリ使用率や実プロセスを監視・診断できるようになる。

② VM / Windowsサーバー技術者のためのパラダイムシフト

従来のWindows Serverや物理サーバー環境での障害調査を思い出してみてください。
問題が発生した際、エンジニアは次のような手順を踏んでいました。

  1. リモートデスクトップ（RDP）で対象サーバーにログインする。
  2. 「イベントビューアー」を開き、アプリケーションログやシステムログの警告・エラーをスクロールして探す。
  3. または C:\inetpub\logs\LogFiles や C:\Logspp.log などのファイルをテキストエディタで開き、巨大なログの中からタイムスタンプを目視で追う。

複数のサーバーが並ぶクラスタ環境では、この作業をサーバー1台ずつ繰り返す必要があり、多大な時間と精神的負担がかかっていました。

ログ確認のパラダイムシフト
▲ 【図解①】旧来のファイル探索・イベントビューアー vs 現代の docker logs -f リアルタイム監視

The Twelve-Factor App 原則：ログは「ファイル」ではなく「イベントストリーム」

クラウドネイティブ・コンテナ設計の世界的標準原則である「The Twelve-Factor App（12の設計規範）」では、ログの扱いについて明確な指針が示されています。

「アプリ自体がログファイルのルーティングや保存先を管理してはならない。すべての実行ログは、バッファリングなしで標準出力（stdout）および標準エラー出力（stderr）に書き出されるべきである。」

Dockerはこの原則を全面的に採用しています。コンテナ内で動くアプリケーションが標準出力にテキストを出力すると、Dockerエンジンがそれを自動的に捕捉（キャプチャ）し、JSON形式等のログストレージに蓄積します。 開発者は docker logs コマンドを叩くだけで、手元のPCから即座にログを監視できる のです。

③ docker logs 完全マスター：オプションと実践監視術

基本コマンドは docker logs <コンテナ名またはID> ですが、実務ではオプションの使い分けが極めて重要です。

オプション コマンド例 現場での活用シーン
-f, --follow docker logs -f my-web リアルタイム監視。Linuxの tail -f と同等。ブラウザでリクエストを送った瞬間にログが流れるため、即座に動作検証できる。終了は Ctrl + C。
--tail <行数> docker logs --tail 50 my-web 末尾行の限定取得。長期間動いているコンテナで全ログを出力するとコンソールが数万行で埋まるため、直近50行や100行に絞り込む。
-t, --timestamps docker logs -t my-web タイムスタンプ付与。アプリ側が出力に日時を含めていなくても、DockerがUTCタイムスタンプを先頭に付与して表示する。
--since / --until docker logs --since "10m" my-web 時間帯フィルタリング。「直近10分間（10m）」や「2026-10-09T09:00:00」以降のログだけを精密に切り出して抽出する。

現場で最も使われる黄金の組み合わせ

# 直近100行を表示した上で、リアルタイムストリーミング監視に移行する
docker logs --tail 100 -f my-web

このコマンドをターミナルで流しておき、別ウィンドウのブラウザや Postman、curl でAPIを叩くと、C#のリクエスト受付ログやSQLクエリログが手元で鮮やかに流れます。

④ docker inspect：コンテナの「カルテ」を読み解く

「このコンテナに割り当てられた内部IPアドレスは何番か？」
「環境変数（ConnectionStringsやASPNETCORE_ENVIRONMENT）は正しく注入されているか？」
「ホストマシンのどのフォルダがコンテナ内のどこにマウントされているか？」

これらの疑問に一撃で答えてくれるのが docker inspect <コンテナ名> です。

コンテナの内部詳細調査
▲ 【図解②】docker inspect によるコンテナ内部設定（IP・ポート・環境変数）の精密調査

普通に docker inspect my-web を実行すると、数百行に及ぶ巨大なJSONデータが出力されます。 設定のすべて（State, GraphDriver, NetworkSettings, Mounts, Config）が網羅されていますが、必要な情報だけを抽出したい場合は --format（Goテンプレート構文） を使います。 

# 1. コンテナの内部IPアドレスのみをピンポイント抽出
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my-web
# 出力例: 172.17.0.2

# 2. コンテナの稼働ステータスとPIDを抽出
docker inspect -f '{{.State.Status}} (PID: {{.State.Pid}})' my-web
# 出力例: running (PID: 14205)

# 3. 設定されている環境変数の一覧を抽出
docker inspect -f '{{json .Config.Env}}' my-web

# 4. ポートバインディング（ホストポートとコンテナポートの対応）を確認
docker inspect -f '{{json .NetworkSettings.Ports}}' my-web

⑤ docker stats ＆ docker top：コンテナの健康診断

コンテナが急激に重くなったり、CPUファンが激しく回転し始めたとき、タスクマネージャーを開いても「vmmem（WSL2の全体プロセス）」しか見えず、どのコンテナが犯人なのか分からない ことがあります。 そんなときに活躍するのが docker stats と docker top です。

リソース消費とプロセスの監視
▲ 【図解③】docker stats（リソース消費）と docker top（プロセス一覧）による健康診断

1. docker stats：リアルタイム負荷モニター

docker stats

実行すると、稼働中の全コンテナのパフォーマンスが1秒おきにリアルタイム更新表示されます。

  • CONTAINER ID / NAME: コンテナの識別名
  • CPU %: CPU使用率（マルチコア環境では100%超えも表示）
  • MEM USAGE / LIMIT: 現在のメモリ使用量 / 割り当て上限（例: 85.4MiB / 7.66GiB）
  • MEM %: メモリ使用率
  • NET I/O: ネットワーク送受信バイト数
  • BLOCK I/O: ディスク読み書き量

※ 1回だけの静的スナップショットが欲しい場合は docker stats --no-stream を指定します。CI/CDや自動監視スクリプトに重宝します。

2. docker top：コンテナ内の実プロセス一覧

docker top my-web

コンテナ内部で動いているプロセスツリーをホスト側から確認できます。
ASP.NET Core アプリであれば dotnet MyApi.dll が実行されている様子や、そのプロセスID（PID）、親プロセスID（PPID）が確認できます。 【Day 02】で学んだ「コンテナは独立したVMではなく、ホストOSカーネル上の隔離されたプロセスである」という事実を実感できる瞬間です。

⑥ C# / ASP.NET Core 現場実践：ILogger と標準出力のベストプラクティス

C#エンジニアがコンテナ化を進める際、最もよくぶつかる設計の疑問が「log4net や NLog でログファイルを出力していたのを、コンテナではどう変えればよいのか？」という点です。

C#のログ設計と標準出力
▲ 【図解④】C# / ASP.NET Core の ILogger を標準出力（stdout）へ流す3ステップ

コンテナ内にログファイルを保存してはいけない3大理由

  1. ディスク枯渇の危機: コンテナ内の書き込み可能レイヤーに数ギガのログが溜まると、Dockerの仮想ディスク（vhdx）を圧迫しDocker全体がクラッシュする。
  2. コンテナ再起動でログが消滅する: コンテナがクラッシュして再起動（または docker rm）されると、内部ファイルはすべて消え去るため、肝心のクラッシュ原因のログが読めない。
  3. ログ収集の分断: 複数台にスケールアウトした際、各コンテナにログインしてログファイルを回収するのは不可能。

ASP.NET Core の標準ロガー（Console）をそのまま使う

.NET 6 / 8 の ASP.NET Core では、標準で Console ロガープロバイダーが組み込まれています。 Program.cs や DI（依存性の注入）で ILogger<T> を使って出力されたログは、自動的にコンテナの標準出力（stdout）へ送られます。 

// ASP.NET Core Minimal API でのロギング例
app.MapGet("/api/order/{id}", (int id, ILogger logger) =>
{
    logger.LogInformation("注文ID {OrderId} の処理を開始しました", id);
    try
    {
        // 業務ロジック...
        return Results.Ok(new { Status = "Success", OrderId = id });
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "注文ID {OrderId} の処理中に予期せぬエラーが発生しました", id);
        return Results.Problem("処理エラーが発生しました");
    }
});

このようにC#コード側は「単に ILogger を呼ぶだけ」で完結します。 出力されたログは Docker 経由で docker logs -f で追跡でき、本番環境（AWS ECS / Azure Container Apps / Kubernetes）ではログ収集エージェントが標準出力を集約して CloudWatch や Azure Monitor、Datadog へ自動転送してくれます。

⑦ ハンズオン実習：Nginx ＆ .NET アプリでの実践デバッグ手順

それでは、実際にターミナル（PowerShell または WSL2 Ubuntu）を開いて、本日の診断コマンドを一通り実践してみましょう！ 

# 1. テスト用Webコンテナをバックグラウンド（-d）で起動
docker run -d -p 8080:80 --name debug-nginx nginx:alpine

# 2. 直近の起動ログを確認
docker logs debug-nginx

# 3. リアルタイムストリーミング監視を開始（別ターミナルまたはバックグラウンド）
docker logs -f debug-nginx

# 4. （別のターミナルから）リクエストを送り、ログがリアルタイムに流れるのを目撃！
curl http://localhost:8080/

# 5. コンテナの詳細カルテ（IPアドレス等）を inspect で確認
docker inspect debug-nginx
docker inspect -f '{range .NetworkSettings.Networks}{.IPAddress}{end}' debug-nginx

# 6. コンテナのリソース使用率（CPU・メモリ）を stats で確認（確認したら Ctrl+C）
docker stats debug-nginx

# 7. コンテナ内の実行プロセス一覧を top で確認
docker top debug-nginx

# 8. 実習完了！コンテナを停止して綺麗にお掃除
docker stop debug-nginx
docker rm debug-nginx

⑧ ベテランが陥りやすい落とし穴・現場の知恵袋

⚠️ ログ＆デバッグの3大現場トラブルと回避策

罠① docker logs が肥大化してホストPCのCドライブを食い尽くす
Dockerのデフォルト設定（json-file）では、コンテナを破棄しない限りログファイルが無制限にディスクに蓄積されます。
対策として、コンテナ起動時に --log-opt max-size=10m --log-opt max-file=3 を付与するか、Dockerデーモンの設定（daemon.json）でデフォルトのログローテーションを設定しましょう。

罠② 停止（Exited）したコンテナのログが見られないと思い込む
「コンテナが異常終了して停止してしまった！原因のログが見られないのでは？」
安心してください。docker rm で削除されない限り、停止したコンテナに対しても docker logs は完全に動作します。クラッシュ原因（例外スタックトレース）は停止後に落ち着いて docker logs <コンテナ名> で確認しましょう。

罠③ inspect で調べたコンテナのIPアドレスに依存した設計をしてしまう
docker inspect で表示される内部IP（例: 172.17.0.2）は、コンテナを再起動したり再作成するたびにコロコロ変わります。
コンテナ間通信でIPアドレスを固定指定するのは厳禁です。Dockerネットワークのサービス名（DNS）による名前解決や、ホストへのポートマッピングを利用しましょう（第4部で詳解します）。

📌 本日のまとめ ＆ 明日へのステップ
  • コンテナのログはファイルではなく「標準出力（stdout/stderr）」に流すのが現代の絶対基準。
  • docker logs -f（または --tail 100 -f）で、リアルタイムのログストリームを手元で快適に監視できる。
  • docker inspect により、IPアドレスや環境変数などの内部カルテを --format でピンポイント抽出できる。
  • docker stats でCPU・メモリのリアルタイム負荷測定、docker top で実行プロセスを確認できる。
次回【Day 14】予告:
『稼働中コンテナへの潜入操作（docker exec -it）』〜Bash/shシェルで内部デバッグ〜

コメント

コメントを投稿

このブログの人気の投稿

【Perfume】Perfume 3rd Tour　「JPN」さいたまスーパーアリーナに行って参りました～

Perfume 3rd Tour　「JPN」1月28日、29日の2daysで参戦して参りました。 ファンクラブ会員の選考抽選会に28日、29日の両日で申し込んでいたんですが、両方とも当選していたという嬉しい誤算。 仕事だぁ、なんだかんだと紆余曲折ありまして28日の参戦は危ぶまれていたのですが、なんとかかんとか28日は40分遅刻しながらも参戦、29日はフル参戦する事が出来ました(∩´∀｀)∩
2 件のコメント
続きを読む

Perfume、2025年末で“コールドスリープ（活動休止）”へ──東京ドーム2daysの記録と、公式・各界・ファンの声

  1) 公式発表・基本情報 活動休止（コールドスリープ）を正式発表 2025年9月21日、公式サイト「 Perfumeより 」で、2026年から一度コールドスリープに入ると発表。再始動の意思（“新しいPerfume”として戻る）も明記。 Perfume Official Site 今後の運用告知（配信・上映など） 同21日付の「 今後のPerfumeに関して 」で、9/23（火・祝）東京ドーム公演の LIVESHIP全世界生配信 および 全国ディレイビューイング 決定を案内。特設サイトも併記。 Perfume Official Site +1 公式グッズ **「Perfume Calendar 2026」**発売決定（B2壁掛け／表紙＋2カ月1枚×6枚＋ポスター）。テーマは“フルーツ”。 Perfume Official Site 2) 東京ドーム2days（9/22・23）要点 公演タイトル： ZO/Z5 Anniversary “ネビュラロマンス” Episode TOKYO DOME 。日程・開場/開演・会場・物販等の実務情報は特設で公開。 Perfume Official Site 9/23公演を世界配信（LIVESHIP） ／ディレイビューイング実施。 Perfume Official Site 海外向け報道（英語）も「 indefinite hiatus 」として広く配信。 The Times of India 国内英字メディアも速報。 朝日新聞 3) 現地レポ（ メリ爺 ）から見える空気 あなたの現地記録（9/24公開）を、ファクトと現場情景の両面で反映： 両日参戦 。22日は アリーナ 、23日は 1階席から俯瞰 。前日の発表を受け、開演前のザワつき→MC後に“いつもの一体感”へ。開演は22日 18:45 頃。オープニングは**P³ツアー東京ドーム（2020/2）**と同趣向で“回収”の演出。 メリ爺のゲーム万歳 MC所感 ：解散ではなく前向きな休止で不安を和らげる内容。 かしゆか の涙、 のっち の気丈さ、 あ〜ちゃん の思い出語り──3人の結束と「 また戻る 」約束が強く刻まれた。 メリ爺のゲーム万歳 体感時間 ： “3時間弱”級のボリューム ながら“過去一...
コメントを投稿
続きを読む

ニンテンドースイッチでオンラインゲームを遊ぶには？

モンスターハンターライズが発売になって、家族でモンハン楽しみたい人が増えたみたいですね。 某ブログの検索キーワードを調べると、モンハンを家族でやるにはどうしたらいいのか？を調べている人が沢山いるのがわかります。 ※これでも一部  家族で協力するにはSwitch2台、ソフトも2つ購入する必要があります。 1台のスイッチでは遊べませんし、ソフト１つでも遊べません。 でも、1台のスイッチで別々アカウントがあれば交代で遊ぶこともできますよ。セーブデータもしっかり分かれます。 Switchのオンラインゲームを家族で遊ぶ方法については以下の記事にまとめてますのでよろしければ参考にしてみてくださいね。 家族でモンスターハンターライズDL版のオンラインプレーを楽しむ方法
コメントを投稿
続きを読む