如何使用错误日志解决用户问题？

支持
1

我位于加州的比利时用户抱怨我们的网站点击响应太慢。我目前尚未收到其他用户的投诉，他们目前分布在明尼苏达州、德国和荷兰。该用户告诉我她使用的是 Windows 系统上的 Chrome 浏览器。她的下载和上传速度与我在 speedof.me 上测试的结果相似。

如果我访问 https://discourse.MY_DOMAIN.com/logs/，会看到最新一条记录的时间戳就在她发送邮件前的几分钟。其“info”标签页显示：

Uncaught [object Object]
Url: https://discourse.MY_DOMAIN.com/assets/ember_jquery-1ed3f3559e6f967733b4088aa729ff7039dff2c09c5a5f787a214b016f58aabc.js
Line: 1
Column: 268124
Window Location: https://discourse.MY_DOMAIN.com/

其“backtrace”标签页为空。其“env”标签页显示：

hostname    MY_APP-app
process_id    780
application_version    ab0b0344048e7e7354615286486bf0508c7c2df6
HTTP_HOST    discourse.MY_DOMAIN.com
REQUEST_URI    /logs/report_js_error
REQUEST_METHOD    POST
HTTP_USER_AGENT    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
HTTP_ACCEPT    */*
HTTP_REFERER    https://discourse.MY_DOMAIN.com/
HTTP_X_FORWARDED_FOR    IP_ADDRESS_IN_BELGIUM
HTTP_X_REAL_IP    IP_ADDRESS_IN_BELGIUM
time    4:25 am
params    
message    Uncaught [object Object]
url    https://discourse.MY_DOMAIN.com/assets/ember_jquery-1ed3f3559e6f967733b4088aa729ff7039dff2c09c5a5f78
line    1
column    268124
window_location    https://discourse.MY_DOMAIN.com/

我该如何利用这些信息，或者还需要采取哪些其他措施来排查她的问题？

谢谢。

2

如果是单个用户的问题，那很可能是本地客户端问题或网络相关的问题。

  • 您的网站托管在哪里？
  • 您是否使用了 CloudFlare？
  • 您是否已确认她是否使用了 VPN 或任何影响其到服务器路由的工具？traceroute 可以帮助排查此类问题。
3

感谢您的回复。

  • 网站托管在 AWS 上，而不是 CloudFlare。
  • 用户不太懂技术，所以我怀疑她是否使用了 VPN，但我可以问一下。我请她以安全模式登录，看看是否有改善，但她尚未回复（现在欧洲时间已经很晚了）。
  • 您能否推荐或提供 Discourse 的 traceroute 工具链接？
4

Traceroute 是一个命令行工具，在 macOS（traceroute）和 Windows（tracert）上都有。它可以逐跳显示从用户计算机到你的服务器的网络路径。据我所知，没有好的基于浏览器的替代方案，大多数工具显示的是从服务器出发的路径，而不是从客户端出发的路径。

你也可以要求对方提供浏览器截图，以查看是否安装了某些奇怪的扩展程序。

你是否已排除本地安全软件的影响？我偶尔会看到一些杀毒软件的浏览器扩展程序通过代理流量，这可能会导致问题。

5

啊。所以，我可以 SSH 登录到我们的 Discourse 服务器，发现没有安装 traceroute，然后运行 apt install traceroute（安装版本 2.1.0），接着执行 traceroute HER_APPARENT_IP_ADDRESS_FROM_DISCOURSE LOGS？

如果我这样做，输出如下：

traceroute to 84.196.9.6 (84.196.9.6), 30 hops max, 60 byte packets
 1  * * *
 2  10.70.134.15 (10.70.134.15)  1.101 ms 10.70.134.35 (10.70.134.35)  1.079 ms 10.70.134.27 (10.70.134.27)  0.988 ms
 3  138.197.251.92 (138.197.251.92)  1.323 ms 138.197.251.94 (138.197.251.94)  1.628 ms 138.197.251.124 (138.197.251.124)  1.206 ms
 4  138.197.251.110 (138.197.251.110)  1.079 ms  1.071 ms 138.197.251.114 (138.197.251.114)  1.056 ms
 5  138.197.244.17 (138.197.244.17)  1.247 ms  1.251 ms 138.197.244.19 (138.197.244.19)  1.112 ms
 6  nyk-b3-link.telia.net (62.115.45.5)  1.866 ms  1.383 ms nyk-b3-link.telia.net (62.115.45.9)  1.331 ms
 7  * * *
 8  ldn-bb3-link.telia.net (62.115.113.21)  82.665 ms  82.486 ms  82.459 ms
 9  adm-bb4-link.telia.net (62.115.134.26)  78.418 ms adm-bb3-link.telia.net (62.115.113.210)  82.951 ms  83.025 ms
10  brx-b3-link.telia.net (62.115.116.191)  82.894 ms brx-b4-link.telia.net (62.115.116.231)  78.732 ms  78.321 ms
11  be-dgb01a-rb1-ae-20-0.aorta.net (213.46.162.13)  82.955 ms  82.970 ms be-zav01a-rb1-ae-21-0.aorta.net (213.46.162.6)  87.143 ms
12  * * *
13  * * *
14  * * *
15  * d54C40906.access.telenet.be (84.196.9.6)  94.362 ms  93.255 ms

最长的跳是最后一步，延迟为 94 毫秒，看起来是合理的。这是否表明从我们位于北加州的 Discourse 服务器到她在比利时的电脑的路由应该是完全正常的？除了获取她 apparent IP 地址之外，我之前帖子中的 Discourse 日志是否完全没有其他有价值的信息？

6

你需要让她对你执行 traceroute 测试，因为她从 ISP 发出的路径不一定与你的服务器到达她网络的路径相同。

这个问题是最近才出现的吗？今天 Level3/CenturyLink 发生了大规模中断，确实影响了某些跨大西洋路由。

7

感谢您持续的回复。

我的用户昨晚反馈，通过 Discourse 安全模式登录解决了她的问题。我现在已请她帮忙确认三个安全模式复选框中具体哪一个起到了作用。

我面临的挑战依然是时区差异、语言差异以及对技术熟悉程度的不同。一旦我了解到更多信息，我会更新此线程。

另外，感谢您提供的相关新闻文章。这是她首次使用我们的 Discourse，因此我现在也在想那次中断是否与此有关。