Kibana Web 界面未加载答案

【问题标题】：Kibana web interface not loadingKibana Web 界面未加载
【发布时间】：2023-03-12 10:49:01
【问题描述】：

尽管 ElasticSearch 和 Kibana 都在我的生产服务器上运行，但我无法通过公共 IP 访问 GUI：http://52.4.153.19:5601/

Localhost curls 返回 200 但浏览器上的控制台错误在检索到几张图像后报告超时。

我已在本地 (Windows 10) 和暂存的 AWS EC2 Ubuntu 14.04 环境中成功安装、运行和访问 Kibana。我可以通过 localhost 上的端口 5601 访问，并且可以通过公共 IP 地址访问暂存环境，并且所有域都可以相应地寻址。反向代理也可以工作，仪表板上的所有状态指示器都是绿色的。

我正在运行 Kibana 4.5、ElasticSearch 2.3.1、Apache 2.4.12

我使用了工作环境中完全相同的卷来附加到生产实例，所以这两个卷上的所有内容都是相同的，除了临时环境的 apache vhost 使用子域，而生产环境的服务器名是基本域.两者均针对 SSL 通配符进行了配置。两者都位于亚马逊的不同可用区。我尝试更改服务器块以在生产服务器上使用子域，只是为了查看该域是否有影响，但错误仍然存在。

我还尝试单独运行一个实例，以防 EC2 出现某种 0.0.0.0 的网络错误，但我无法解决问题。 ElasticSearch 和 Kibana 的两台服务器之间的所有日志和配置都是相同的。

我已经尝试删除并重新创建 kibana 索引，尝试了其他设置，包括主机、elasticsearch url、扩展最大 ping 和超时、最大重试次数、扩展 apache 限制、http.cors 以允许不同的来源。我尝试了其他端口，但两台服务器都表明 5601 正在以相同的方式监听。

我在之前附加到此实例的完全不同的卷上也遇到了同样的问题。

我能看到的唯一区别是工作版本 ping 正常，而非工作版本在 ping IP 时有 100% 的数据包丢失，虽然我无法想象为什么会这样，因为我能够到达80的网站，就好了。我还可以访问在其他端口上运行的各种其他工具。我认为可能存在某种网络冲突。有什么想法吗？

【问题讨论】：

您是否确保登台服务器上的端口 5601 可从公共 IP 访问，您能否再次检查您的防火墙规则以进行验证？超时主要发生在请求未到达所需服务器且没有主体响应时。
暂存服务器没有问题。需要明确的是，当我说我已经“访问了 kibana”时，我是在 5601 的公共 IP 上进行的。在登台时打开和访问的每个端口也是在实时时打开和访问的（22、80、443、10000等）来自公共 IP 和域。只有 5601 实时失败，但两台服务器具有相同的 iptables。即使我尝试将 kibana 或 elasticsearch 绑定到非标准端口，我仍然会遇到同样的问题。
你是否也为kibana绑定了IP？
是的，如果没有绑定，我将无法成功启动它并让它在 5601 上运行。
鉴于开发服务器实例在相同的卷上运行时没有出现错误，我感觉 AWS 与这个特定实例存在一些网络冲突。我启动了一个新的实时实例作为不工作的实时服务器的克隆，它立即工作。我不能完全解释它，但如果我只是丢弃那些不起作用的工作，那至少能让我度过难关。

标签： elasticsearch amazon-ec2 kibana kibana-4

【解决方案1】：

可能是端口5601被防火墙阻止了

通过以下方式允许到端口 5601 的传入连接：

sudo iptables -I INPUT -p tcp --dport 5601 -j ACCESS

为了安全：

修改上述命令，只接受来自特定地址的连接。（见man iptables）

或使用 Shield 插件进行 elasticseach

【讨论】：

端口 5601 未被阻止。该规则已经设置（接受，而不是访问）。两台服务器都有相同的 iptables 并且 netstat 显示了相同的监听结果。同样如前所述，日志显示的结果与运行状况良好的服务器相同。 Kibana verbose 也显示了与 Elasticsearch 的连接。我可以通过端口 80 和 443 从我的 Web 服务远程对两台服务器进行 ElasticSearch 调用。我会试一试 shield，但如果另一台服务器不需要它，如何解决这个问题？
鉴于开发服务器实例在相同的卷上运行时没有出现错误，我感觉 AWS 与这个特定实例存在一些网络冲突。我启动了一个新的实时实例作为不工作的实时服务器的克隆，它立即工作。我不能完全解释它，但如果我只是丢弃那些不起作用的工作，那至少能让我度过难关。

【解决方案2】：

抱歉，忘记更新此问题。答案是我只需要部署一个新实例。只需创建实例的克隆，我就能解决问题。我以前在 AWS 遇到过网络问题，因为他们的内部 dns/ip 冲突，所以我过去不得不这样做，结果证明这是最快和最干净的解决方案，尽管没有提供任何明确的洞察力原因。

【讨论】：