我已打开应用程序日志记录来传输日志。问题是流式传输器仅在 12 小时内处于活动状态（默认超时为 2）。在我们的案例中，某些问题很少发生，因此当用户回复我时，时间已经过去了（在某些情况下，由于其他情况，无法重现错误）。
我们记录的内容相当广泛，只要我坐在本地环境中，我几乎可以在终端窗口中跟踪任何内容。每个事件、警告、错误等都会被记录下来，包括 GUID。这很好用。
如何在服务器上托管时生成的日志中通过 GUID 进行搜索？我读过一些博客，但感到很困惑 - 部分原因是 Azure 中的 GUI 最近发生了变化，部分原因是我看不出如何像在本地一样访问记录信息的连续负载。也许还有更好的方法，我不知道，但我尝试关注有关该主题的 MSDN。
在我驻扎的新公司，我注意到当我们重新启动服务器时，启动 MSMQ 服务需要一点时间。它会自动启动，并在很长一段时间内处于启动状态-我们接触的是小时，而不是分钟（此时我已经过去了 67 分钟，但还没有完成）！
我对 MSMQ 的体验就像企鹅的飞行体验——见过它，我自己从未做过，所以我无法真正判断如此大量时间消耗的合理性。但是，感觉不对劲，我觉得这背后有些可疑之处。
我得到的解释是“一直都是这样”。因此，我们仍然应该使用火而不是电来获得光...我并不是说这里的人错了。我只是想进一步调查它是“新鲜血液”。我可以补充一下，非常不耐烦的血液。
我的 google-fu 产生的东西并没有让我更明智（主要是如果它根本不工作或在手术阶段工作不令人满意怎么办）。事件日志什么也没说，之后手动启动其他服务（默认服务除外）。启动时的缓慢似乎是一致的，但并非如此。队列被清空，否则服务器的行为或多或少像一个正常人。我们有大量的硬盘空间。
所以，问题是双重的。
系统如下。