36.13.3. Kibana
以下のトラブルシューティングの問題は EFK スタックの Kibana コンポーネントに適用されます。
Kibana でのログインのループ
Kibana コンソールを起動し、ログインが成功した場合に、誤って Kibana にリダイレクトされ、すぐにログイン画面にリダイレクトされます。
この問題の原因として考えられる点として、Kibana の前にある OAuth2 プロキシーが、これを有効なクライアントとして特定するためにシークレットをマスターの OAuth2 サーバーと共有する点があります。この問題は、シークレットが一致しないことを示唆している可能性があります。シークレットが一致するかどうかをプログラムを使用して確認できる方法はありません。
これは、ロギングを複数回デプロイする場合に生じる可能性があります。たとえば、初期のデプロイメントを修正しても、Kibana によって使用される secret が置き換えられる一方で、一致するマスター oauthclient エントリーは置き換えられません。
以下を実行できます。
$ oc delete oauthclient/kibana-proxy
openshift-ansible の説明に従って openshift_logging ロールを再実行します。これにより oauthclient は置き換えられ、次のログインではループは生じません。
*"error":"invalid\_request" on login*
Kibana でのログインエラー
Kibana コンソールにアクセスしようとする際に、以下のブラウザーエラーが表示される場合があります。
{"error":"invalid_request","error_description":"The request is missing a required parameter,
includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."}この問題は、OAuth2 クライアントとサーバー間の不一致が原因で発生します。ログイン後にサーバーが安全にリダイレクトできるように、クライアントのリターンアドレスがホワイトリストで指定されている必要があります。不一致がある場合、エラーメッセージが表示されます。
これは、直前のデプロイメントからの残りである oauthclient エントリーによって引き起こされる可能性があります。 この場合、エントリーを置き換えることができます。
$ oc delete oauthclient/kibana-proxy
openshift-ansible の説明に従って openshift_logging ロールを再実行します。これにより、oauthclient エントリーが置き換えられます。Kibana コンソールに戻り、再びログインします。
問題が解決しない場合は、OAuth クライアントに一覧表示されている URL の Kibana にアクセスしていることを確認してください。この問題は、転送先ポート (標準の 443 HTTPS ポートではなく 1443 など) の URL にアクセスすることで発生する可能性があります。
oauthclient を編集してサーバーのホワイトリストを調整できます。
$ oc edit oauthclient/kibana-proxy
実際に使用しているアドレスを組み込むことが許可されているリダイレクト URI の一覧を編集します。保存し、終了した後に、エラーは解決するはずです。
Kibana のアクセスにより 503 エラーが表示される
Kibana コンソールを表示する時にプロキシーエラーが発生する場合は、2 つの問題のうちのいずれかが原因である可能性があります。
Kibana が Pod を認識していない可能性があります。ElasticSearch の起動が遅い場合、Kibana は ElasticSearch に到達しようとする際にエラーを出す可能性があり、この場合 Kibana はこれを有効であるとは見なしません。関連するサービスにエンドポイントがあるかどうかをチェックすることができます。
$ oc describe service logging-kibana Name: logging-kibana [...] Endpoints: <none>
Kibana Pod が有効である場合に、エンドポイントは一覧表示されます。有効でない場合は、Kibana Pod およびデプロイメントの状態を確認してください。
Kibana サービスにアクセスするための名前付きルートはマスクされている可能性があります。
これは、あるプロジェクトでテストデプロイメントを実行し、次に最初のデプロイメントを完全に削除することなく別のプロジェクトでデプロイした場合に発生する可能性があります。複数のルートが同じ宛先に送信される場合、デフォルトルーターのみが最初に作成された宛先にルーティングされます。問題が発生するルートをチェックして、そのルートが複数の場所で定義されているかどうかを確認してください。
$ oc get route --all-namespaces --selector logging-infra=support NAMESPACE NAME HOST/PORT PATH SERVICE logging kibana kibana.example.com logging-kibana logging kibana-ops kibana-ops.example.com logging-kibana-ops
この例では、重複するルートがありません。
