36.13.3. Kibana
以下故障排除问题适用于 EFK 堆栈的 Kibana 组件。
在 Kibana 上循环登录
如果您启动 Kibana 控制台并成功登录,您会被错误地重定向到 Kibana,这会立即重定向到登录屏幕。
造成此问题的原因是,Kibana 前面的 OAuth2 代理必须与 master 的 OAuth2 服务器共享一个 secret,以便将其识别为有效的客户端。此问题可能表示 secret 不匹配。没有以公开方式报告此问题。
当您部署日志多次时,可能会发生这种情况。例如,如果您修复了初始部署,且由 Kibana 使用的 secret
会被替换,而匹配的 master 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。通过转发端口(例如 1443)而非标准的 443 HTTPS 端口访问 URL 可能会造成此问题。
您可以通过编辑其 oauthclient
来调整服务器白名单:
$ oc edit oauthclient/kibana-proxy
编辑接受的重定向 URI 列表,使其包含您实际使用的地址。保存并退出后,应该解决这个错误。
Kibana 访问显示 503 错误
如果您在查看 Kibana 控制台时收到代理错误,则可能是由两个问题之一造成的。
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
在本例中,没有重叠的路由。