你好 Quincy @ossia
让我们先退一步，从专业网络安全的角度，抛开猜测和“病急乱投医”的方式来审视这个问题。
所有网络安全任务的核心概念是“态势感知”（situational awareness），在本例中称为“网络态势感知”（CSA）。
为了以确定的方式了解“正在发生什么”，你需要在不做任何猜测或臆测的情况下，尽可能建立最完善的态势认知——只关注事实。
具体该怎么做呢？
嗯，简要说明如下：
嗯，简要说明如下：
我们通过融合来自所有传感器的信息来实现这一点；对于基于 Web 的应用程序，这些信息通常来自日志文件和会话数据。我一时想不起来（off the top of my head）Discourse 是否在 PostgreSQL 数据库中维护会话信息（上次我检查时，不像某些 LAMP Web 应用那样有专门的会话表），但这完全不是问题。
你所需的大部分信息都包含在 nginx 日志文件 中，无论是容器外部的反向代理（我记得在这个话题中你提到过使用 nginx 作为代理），还是容器内部，都有相同的日志信息。在两种设置中，日志文件都位于标准开箱即用（OOTB）配置下的相同位置：
以下是我们某个设置中（容器外部）反向代理的示例：
# cd /var/log/nginx
# ls -l
total 779964
-rw-r----- 1 www-data adm 0 Jun 17 06:25 access.log
-rw-r----- 1 www-data adm 660766201 Jun 25 18:26 access.log.1
-rw-r----- 1 www-data adm 107367317 Jun 17 03:18 access.log.2.gz
-rw-r----- 1 www-data adm 21890638 May 21 03:08 access.log.3.gz
-rw-r----- 1 www-data adm 7414232 May 5 07:26 access.log.4.gz
-rw-r----- 1 www-data adm 63289 Apr 18 09:12 access.log.5.gz
-rw-r----- 1 www-data adm 0 Jun 17 06:25 error.log
-rw-r----- 1 www-data adm 904864 Jun 25 18:19 error.log.1
-rw-r----- 1 www-data adm 96255 Jun 17 03:17 error.log.2.gz
-rw-r----- 1 www-data adm 79065 May 21 02:58 error.log.3.gz
-rw-r----- 1 www-data adm 70799 May 5 06:54 error.log.4.gz
-rw-r----- 1 www-data adm 1977 Apr 18 05:49 error.log.5.gz
以下是 Discourse 容器内部的基本日志信息：
# cd /var/discourse/
# ./launcher enter socket
# cd /var/log/nginx
# ls -l
total 215440
-rw-r--r-- 1 www-data www-data 87002396 Jun 25 18:28 access.log
-rw-r--r-- 1 www-data www-data 101014650 Jun 25 08:02 access.log.1
-rw-r--r-- 1 www-data www-data 8217731 Jun 24 08:02 access.log.2.gz
-rw-r--r-- 1 www-data www-data 6972317 Jun 23 07:53 access.log.3.gz
-rw-r--r-- 1 www-data www-data 3136381 Jun 22 07:50 access.log.4.gz
-rw-r--r-- 1 www-data www-data 2661418 Jun 21 07:45 access.log.5.gz
-rw-r--r-- 1 www-data www-data 5098097 Jun 20 07:38 access.log.6.gz
-rw-r--r-- 1 www-data www-data 6461672 Jun 19 07:40 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Jun 25 08:02 error.log
-rw-r--r-- 1 www-data www-data 0 Jun 24 08:02 error.log.1
-rw-r--r-- 1 www-data www-data 20 Jun 23 07:53 error.log.2.gz
-rw-r--r-- 1 www-data www-data 254 Jun 23 02:36 error.log.3.gz
-rw-r--r-- 1 www-data www-data 20 Jun 21 07:45 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jun 20 07:38 error.log.5.gz
-rw-r--r-- 1 www-data www-data 20 Jun 19 07:40 error.log.6.gz
-rw-r--r-- 1 www-data www-data 274 Jun 18 15:40 error.log.7.gz
注意：上述“容器内”的信息也可以通过共享卷从容器外部访问。
因此（为保持回复简洁），@ossia，你几乎可以从这些健壮的日志文件中获取了解“正在发生什么”所需的所有态势认知。无需任何猜测，数据就在那里。
此外，在 Rails 日志中还有更多有价值的数据。例如，在我们某个设置中，Rails 生产日志如下：
tail -f /var/discourse/shared/socket/log/rails/production.log
Rails 日志也包含大量优秀的用户日志信息，例如：
Started GET "/embed/comments?topic_id=378686" for 73.63.114.60 at 2020-06-25 18:36:15 +0000
Started GET "/embed/comments?topic_id=378686" for 195.184.106.202 at 2020-06-25 18:36:16 +0000
Started GET "/embed/comments?topic_id=378686" for 17.150.212.174 at 2020-06-25 18:36:16 +0000
Started GET "/embed/comments?topic_id=378686" for 76.235.99.73 at 2020-06-25 18:36:18 +0000
Started GET "/embed/comments?topic_id=378686" for 124.253.211.42 at 2020-06-25 18:36:19 +0000
Started GET "/embed/comments?topic_id=378686" for 103.96.30.11 at 2020-06-25 18:36:21 +0000
Started GET "/embed/comments?topic_id=378686" for 72.191.206.59 at 2020-06-25 18:36:22 +0000
Started GET "/embed/comments?topic_id=378686" for 68.252.68.76 at 2020-06-25 18:36:23 +0000
Started GET "/embed/comments?topic_id=378686" for 69.17.252.83 at 2020-06-25 18:36:23 +0000
Started GET "/embed/comments?topic_id=378686" for 98.109.33.230 at 2020-06-25 18:36:24 +0000
注意：以上示例中，我们看到了从另一台服务器拉取 Discourse 嵌入代码的客户端 IP 地址。
当前任务....
回到当前任务，关键在于超越猜测和臆断，进行有趣的（1）过滤/数据清洗、（2）数据融合，以及（3）对传感器数据（日志文件）的分析，从而构建（4）关于你网站当前状况的态势感知（SA）。
对于较旧的 LAMP 应用，我多年前编写了自定义代码，将所有这些信息写入数据库表，并实时进行分析，按 IP 地址统计“访问次数”（仅为示例之一），这样我就能快速了解谁、从何处、正在访问网站的哪些内容。因为要进行此类数据清洗、过滤和融合，确实需要一些代码。（例如在 DDoS 攻击和恶意机器人活动时非常有用）。
这对您来说 @ossia 完全不是问题，因为您是 freeCodeCamp.org，具备寻找优秀日志分析工具的知识（网络空间中有许多此类工具），或者可以根据您希望理解的具体场景（您的话题和问题）快速轻松地创建自己的自定义代码进行分析。
多年前，我为一个旧的遗留 LAMP 应用编写自定义代码仅用了几个小时，而我绝非任何意义上的 编程天才，尽管在网络安全领域，我有时被许多人称为“传奇”，哈哈 
总结一下....
好吧，总结一下……
你拥有所有必要的数据，可以深入掌握“网站上正在发生什么”的态势认知。你可以通过清洗、过滤、融合日志数据并进行一些基本分析来构建这种态势感知（SA）。虽然有一些工具可以提供帮助，但我发现根据分析目标（依赖分析）快速编写一些自定义代码往往更简单，当然这因人而异（YMMV）。但你完全可以做到，因为你是 freeCodeCamp.org，拥有强大的技术技能。
我建议你彻底放弃试图通过 Google Analytics 和其他基于 JavaScript 的第三方应用来获取态势感知。没有什么比你自己的 Web 日志文件（以及如果有会话数据的话，数据库会话数据）更好的了，你也不必担心“某些内容可能被或未被阻止”等问题。你的 Web 服务器日志文件包含了获取所需 CSA 的数据（并且必要时还可以进行自定义）。
在我的一些 CSA 代码中，我实际上会拦截那些未被 nginx、apache2 和其他 Web 服务器记录的 HTTP 请求中的会话信息和日志信息（以获取额外信息）；但我尚未为 Discourse 编写此类代码，因为作为 Discourse 插件开发者，我远不如这里的 meta Discourse 团队专家那样“轻车熟路”。我接触 Discourse 才几个月，尚未为 Discourse 编写任何自定义 CSA 代码（老实说，今年我尽量少写代码）。
CSA 基于传感器数据的融合，而从 CSA 中获得的认知将指导你采取哪些行动来解决任何网络安全问题。
祝你在探索中一切顺利，希望这能帮助你获得更充足的休息 :slight_smile
祝好！
原始（历史）CSA 参考文献：
原始（历史）CSA 参考文献：
https://www.researchgate.net/publication/220420389_Intrusion_Detection_Systems_and_Multisensor_Data_Fusion
（仅供对 CSA 起源和核心技术感兴趣的人士参考）
