☰

服务器无法访问的原因，如何排查？

tag-icon • tag-icon ssh shutdown reboot mongodb
服务器无法访问的原因，如何排查？

我的一台托管 mongoDB 的服务器是，有时和“随机地”无法到达。

过了一会儿，它又回来了，就像什么都没发生过一样。

在此期间，无法打开 ssh 隧道（超时，甚至不要求密码），每个应用程序与托管 MongoDB 的连接都中断，...

我什至不确定服务器是否仍在运行，这个问题实际上可能每天发生 2 次或每周 1 次。

不幸的是，我无法找到任何可耻的关闭/重启的痕迹或任何其他关于此时发生的事情的线索。

到目前为止我所做的调查：

foo@bar:/var/log$ who -b
         system boot  Jun 22 09:25

这里没有什么可疑的，服务器在 1 个月内没有启动。

这可以通过 boot.log 来确认：

foo@bar:/var/log# tail boot.log
2016/06/22 09:25:34 Processing completed for Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9001
2016/06/22 09:25:34 Finished processing ExtensionsConfig.xml
monit: /opt/foo/common/lib/libcrypto.so.1.0.0: no version information available (required by monit)
monit: /opt/foo/common/lib/libssl.so.1.0.0: no version information available (required by monit)
 * Starting daemon monitor monit
   ...done.
 * Stopping System V runlevel compatibility

我再次检查了上次登录的用户，似乎没有任何问题：

foo@bar:/var/log# last -x
localadm pts/0        16.618.3.75      Tue Jul 19 14:37   still logged in
localadm pts/0        16.618.3.75      Tue Jul 19 13:59 - 14:36  (00:37)
localadm pts/0        16.618.3.75      Tue Jul 19 13:18 - 13:53  (00:35)
localadm pts/0        16.618.3.75      Tue Jul 19 07:45 - 09:15  (01:29)
localadm pts/3        16.618.3.75      Mon Jul 18 15:14 - 15:51  (00:37)
localadm pts/0        16.618.3.75      Mon Jul 18 14:57 - 15:22  (00:24)
localadm pts/0        16.618.3.75      Mon Jul  4 10:01 - 10:06  (00:05)
localadm pts/0        16.618.3.75      Mon Jul  4 09:03 - 09:19  (00:16)
localadm pts/0        16.618.3.75      Mon Jul  4 08:16 - 08:19  (00:03)
localadm pts/0        16.618.3.75      Mon Jul  4 08:07 - 08:14  (00:06)
localadm pts/0        16.618.3.75      Mon Jul  4 08:00 - 08:04  (00:04)

我还检查了 cron 作业，它们似乎都不会影响任何运行级别：

foo@bar:/var/log$ cat syslog
Jul 20 07:02:01 bar CRON[28967]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D)
Jul 20 07:17:01 bar CRON[29489]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 20 08:02:01 bar CRON[30754]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D)

（我还手动检查了全局级别和用户级别的每个 CRON 表less /etc/crontab：）

服务器实际上是Azure Cloud的一部分（我不知道这是否与问题有关）。

您知道还有什么可能导致此问题吗？

知道我如何进一步调查吗？

答案1

服务器实际上是Azure Cloud的一部分

该错误可能发生在 ssh 客户端/mongo 客户端和服务器之间的网络路径上的任何位置。这可能代表大量您无权访问的组件。

您的下一个停靠点（检查是否重新启动后）应该是 Microsoft 的支持（祝您好运）。

同时：

检查系统日志中是否有与网络设备相关的任何消息。

如果这没有发现任何问题，那么您需要设置一些远程监控来跟踪中断情况。除了为支持人员提供有用的信息来调查问题之外，它还为您提供了一种摆脱合同并切换到其他提供商的方法。

答案2

根据您的问题，我猜测不存在性能或可用性问题，这似乎是网络连接问题，可能与您的客户端或目标服务器上的防火墙有关。

可以有多种调查方法。

检查 ping 响应

从客户端到服务器以及从客户端到服务器traceroute and tracepath命令的跟踪路由

尝试通过 FQDN 和 IP 地址进行连接，并检查 中的名称服务器条目/etc/resolv.conf ，确保它们是 ipv4 地址。

检查服务器上的 sshd 配置

检查tcp连接超时设置

禁用防火墙和se-linux一段时间，然后重试，如果与此相关。

检查/var/log/messages和/var/log/secure或/var/log/auth等中/var/log/audit/audit.log 的一些线索

使用tcpdump检查数据包，可能是由于tcp keepalive问题造成的。

也请阅读这篇文章

相关内容