ロギングとデバッグ

ロギングとデバッグ

最後に、設定ポイントではありませんが、デプロイ時のデバッグ方法やログの確認方法について簡単に紹介していきます。

ログの種類と見方

まず、アプリケーション開発者側から確認する基本的なログは、コンテナの出力ログ(oc logs <pod名>)とeventログ(oc get events)になります。oc logsはすでに今回の記事で使っていますが、いくつかのオプションを紹介しておきます。まず、コンテナのプロセスが終了してしまった場合、Podは自動で再起動されていることが多いでしょう。そうなると、oc logsは再起動後の稼働状態となったコンテナのログを取得するため、あまり有効ではありません。その場合、-p(--previous)オプションを指定します。

oc logsの-pオプション

$ oc logs -p <POD名>

-pオプションを指定することで、現在稼働しているPodの1つ前のコンテナのログが確認できます。コンテナのRESTARTカウントが増えていた場合や、CrashLoopのステータスになっていた場合には、まずはoc logs -pを確認するのが有効です。

次に、--all-containersオプションです。

oc logsの--all-containersオプション

$ oc logs --all-containers <POD名>

サイドカーコンテナを使って、Pod内に複数のコンテナが存在する場合には、このオプションが便利でしょう。例えば、以下のprometheus-k8s-0 Podは、コンテナが4つも起動しています。コンテナを1つずつ確認しても良いですが、--all-containersを使ってざっと確認するのが便利です。

複数コンテナが起動しているPod

$ oc get pod prometheus-k8s-0
NAME               READY     STATUS    RESTARTS   AGE
prometheus-k8s-0   4/4       Running   1          21h

さて、Podのコンテナプロセスが何らか原因で停止している場合には、コンテナのログを確認すれば良いのですが、外的要因で障害が発生した場合には、コンテナのログには何も出力されていません。この場合、eventログが有効になります。

eventログを取得

$ oc get event

eventログはクラスタで発生したイベントのログで、例えば最初に見たLiveness ProbeやReadiness Probeによる再起動のイベントや、ストレージのmountイベントのログも出力されています。

アプリケーション開発者側でログを確認する場合には、まずは上記のoc logsとoc get eventを確認するのが良いでしょう。

またOpenShiftでは、EFKスタック(ElasticSearch、Fluentd、Kibanaによる分析基盤)を使ってログの可視化も可能です。クラスタ管理者がOpenShift用に提供されているEFKスタックをデプロイしていれば、ユーザーはKibanaからログを見ることも可能です。

デバッグ方法

さて、次はデバッグ方法です。デバッグの方法は問題の状況や環境によって千差万別です。ここでは、よく使うコマンドを簡単に紹介していきます。

まず、oc rshでのコンテナ環境へのログインです。コンテナが稼働していれば、このコマンドでコンテナにログインし、ディレクトリ・ファイルのパーミッションや設定ファイルを直接確認できます。また、ネットワークのトラブル時にも、コンテナにrshでログインして、ネットワーク疎通や名前解決を確認するのは有効な手段になります。

oc rshでログイン

oc rsh <POD名>

ちょっとした隠し技として、ネットワークのトラブルシューティング時に、netstatやdig、tcpdumpといったコマンドがインストールされていないコンテナ上でのデバッグ方法を紹介します。コンテナにこれらのコマンドがない場合には、nsenterコマンドを使ってNodeホスト上からコンテナのネットワーク環境に入ります。

nsenterコマンドによるコンテナ環境でのnetstatの実行

# nsenter -t <ホスト上で見えるコンテナのプロセスID> -n -- netstat -anp

こうすることで、ホスト上のコマンドを使って、コンテナ環境でのネットワークのトラブルシューティングが可能です。もちろんNodeホスト上にsshログインできる権限が必要になるので、ここまで行う場合には、クラスタ管理者と連携が必要になります。

次にoc cpコマンドは、コンテナ内のファイルをローカルにコピーするコマンドです。設定ファイルやログファイルをローカルにコピーすることができます。

oc cpコマンドによるファイルの取得

oc cp <POD名>:/ファイルパス/ /出力先/ファイル/パス

最後に、oc debugというコマンドを紹介して終わりにします。oc debugコマンドは、指定したオブジェクトをインタラクティブなshellで立ち上げるコマンドです。コンテナが起動できないときに、このコマンドを使うと便利です。実際にdc/go-httpdを指定して立ち上げてみましょう。

oc debugコマンドの使用例

# oc debug dc/go-httpd
Defaulting container name to go-httpd.
Use 'oc describe pod/go-httpd-debug -n ch05' to see all of the containers in this pod.

Debugging with pod/go-httpd-debug, original command: /bin/sh -c go run main.go
Waiting for pod to start ...
If you don't see a command prompt, try pressing enter.
/app #

コマンドを実行すると、いくつかのメッセージとコマンドプロンプトが起動しました。この新しく起動したPodは、go-httpdのDeploymentConfigから起動コマンドをshellに変更したPodです。/bin/sh -c go run main.goはまだ実行されていない状態です。

oc debug

oc debug

この状態から/bin/sh -c go run main.goを実行して、エラーログを確認しても良いですし、起動オプションがあれば、それを変更するのも良いでしょう。インタラクティブなシェルで実行できるので、非コンテナ環境でのデバッグ作業と同じように、できることの幅が広がります。

本章では、アプリケーションの運用に関わる設定内容を確認し、実際に動かしてみました。かなり駆け足での紹介となりましたが、どういったことができるか大まかな機能を把握していただければ幸いです。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30