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