OpenShiftのトラブルシューティングの第一歩

現象によって調べるポイントは色々ありますが、トラブルシューティングの第一歩としてまずチェックしているログをご紹介します。

OS レベルでのログをチェック

journal の確認

OpenShift のマスタサーバでは、atomic-openshift-master-controllers、atomic-openshift-master-api と atomic-openshift-node というデーモンが動いてます。 ノードサーバでは、atomic-openshift-node が動いています。

v3.6 まではマスターサーバがシングル構成の場合は atomic-openshift-master というデーモンが動いていましたが、v3.7 からはシングルマスター構成の場合でも、HA構成と同様に2つのデーモンに別れました。

これらのデーモンの journal をチェックします。

journalctl -xe -f -u atomic-openshift-master-controllers
journalctl -xe -f -u atomic-openshift-master-api
journalctl -xe -f -u atomic-openshift-node

ログレベルの変更

ログの出力内容を増やして細かく調査したい場合には、ログレベルを変更します。ログレベルを変更する場合は、/etc/sysconfig ディレクトリにある atomic-openshift-master-controllers, atomic-openshift-master-api, atomic-openshift-node というファイルのログレベルを変更してデーモンを再起動します。例えば、atomic-openshift-master-controllers の再起動は

systemctl restart atomic-openshift-master-controllers

というコマンドを実行します。

設定可能なログレベルは、以下の通りです。

ログレベル 表示されるログ
0 Error と Warningのみ表示
2 デフォルトのログレベル。Information レベルのログを表示
4 Debug レベルのログを表示
6 Request/Response のAPIレベルのデバッグログを表示
8 Request/Response のボディレベルのデバッグログを表示

詳細は OpenShift のドキュメントのログレベルの設定を参照してください。

その他のデーモンのログレベルの変更

etcd などのログレベルの変更方法は、Red Hat のカスタマーポータルのナレッジを参照してください。

OC コマンドでのログ出力

OpenShift の CLI(Command Line Interface)の実行時に --loglevel=8 のようにログレベルを設定することで、REST のリクエストの内容を出力させることができます。

# oc whoami --loglevel=8
I0129 17:07:04.917363    9103 loader.go:357] Config loaded from file /root/.kube/config
I0129 17:07:04.918401    9103 round_trippers.go:383] GET https://master.example.com:8443/apis/user.openshift.io/v1/users/~
I0129 17:07:04.918434    9103 round_trippers.go:390] Request Headers:
I0129 17:07:04.918456    9103 round_trippers.go:393]     Accept: application/json, */*
I0129 17:07:04.918468    9103 round_trippers.go:393]     User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff
I0129 17:07:04.970330    9103 round_trippers.go:408] Response Status: 200 OK in 51 milliseconds
I0129 17:07:04.970359    9103 round_trippers.go:411] Response Headers:
I0129 17:07:04.970370    9103 round_trippers.go:414]     Cache-Control: no-store
I0129 17:07:04.970381    9103 round_trippers.go:414]     Content-Type: application/json
I0129 17:07:04.970404    9103 round_trippers.go:414]     Content-Length: 224
I0129 17:07:04.970415    9103 round_trippers.go:414]     Date: Mon, 29 Jan 2018 17:07:04 GMT
I0129 17:07:04.970522    9103 request.go:994] Response Body: {"kind":"User","apiVersion":"user.openshift.io/v1","metadata":{"name":"system:admin","selfLink":"/apis/user.openshift.io/v1/users/system%3Aadmin","creationTimestamp":null},"identities":[],"groups":["system:cluster-admins"]}
system:admin

アプリケーションのログをチェック

実行中のアプリケーションのログの確認

アプリケーションの動作がおかしい場合は、アプリケーションのPodのログをチェックします。 まずは、Pod名を確認します。

oc get pods

ログをチェックしたい Pod 名を指定して、Podのログを確認します。

oc logs app-2-n5jjz 

Crash Loopback になってしまうアプリケーションのログの確認

デプロイに失敗して、Crash Loopback になってしまった場合には、oc logs コマンドに --previous オプションを指定して起動しようとした時のログを確認します。

# oc get pods
NAME            READY     STATUS             RESTARTS   AGE
mysql-1-fd6p7   0/1       CrashLoopBackOff   3          2m
# oc logs mysql-1-fd6p7 --previous
error: database is uninitialized and password option is not specified 
  You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

イベントをチェック

Pod のデプロイを開始したけど、ステータスが Pending のままだったり、Container Creating で止まってしまった場合は、コンテナが起動していないのでコンテナのログではなく、コンテナのイベントをチェックします。

oc get events