Azure 辅助角色向跟踪日志存储写入意外错误
我们有一个在云中运行的辅助角色，它定期轮询 Azure CloudQueue，检索 Web 角色为我们放在那里的消息。目前，辅助角色和 Web 角色位于同一云服务应用程序中，并且目前我们仅运行一个实例。
在测试时，我们已打开日志记录，因此消息内容和其他有用信息会出现在我们的云存储中，我们可以使用 Cerebrata Azure 诊断管理器查看这些信息。 （顺便说一句，很棒的产品）
DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();
diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
实际上，这一切似乎都工作得非常好，但是偶尔我们会在跟踪日志中看到一条详细消息，其中仅包含“失败”作为消息。它似乎生成的代码被包装在 try catch 中，因此奇怪的是我们没有通过这些方式看到该消息。
似乎正在发生一些超出我们代码控制范围的事情，可能正在重新启动辅助角色，或者云操作系统正在检测到一个重大错误，只有它可以通过重新启动辅助角色来处理。它会恢复并继续下去，所以对我们来说可能发生的事情有点神秘。
我们尚未确定的是我们是否丢失了消息。
任何帮助将不胜感激。 干杯 金都马来语
We have a worker role running in the cloud which polls an Azure CloudQueue periodically retrieving messages that a web role has put on there for us. Currently the worker role and web role are housed in the same Cloud Service application and currently we are only running one instance.
As we are testing we have our logging switched on and so the contents of the messages and other useful information appear in our cloud storage which we view using Cerebrata Azure Diagnostics Manager. (Great product btw)
DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();
diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
It all appears to work remarkably well actually, however occasionally we see a Verbose message in the trace log which simply has "Fail"as the message. The code it appears to be generated from is wrapped in a try catch so it is odd that we aren't seeing the message through those means.
It would appear that something is happening that is out of our code's control, perhaps the worker role is being restarted, or the cloud op system is detecting a major error that only it can deal with by restarting our worker role. It recovers and carries on so it is somewhat of a mystery to us what might be happening.
What we haven't ascertained yet is whether we are losing a message.
Any help would be gratefully appreciated.
Cheers
Kindo Malay
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果没有堆栈跟踪，很难说太多，但是当日志记录设置为详细时，您很可能会看到来自您正在使用的 dll 之一的一些内部日志记录。
例如，如果您运行的 Azure 表查询导致某些类型的错误，则该错误将被注销 3 次，因为存储客户端库正在捕获错误、追踪错误，然后重试。
如果您的 try catch 块没有捕获错误，那么您可能无需担心。
如果队列消息的可传递性对您很重要，则应确保利用 CloudQueue.GetMessage 的可见性超时重载，并且仅在处理完消息后才将其删除。您最终可能会处理某些消息两次，但至少您会处理所有消息。
Without the stack trace it's hard to say too much, but with the logging set to verbose it's quite likely that you're seeing some internal logging from one of the dlls you're using.
For example if you run a Azure Table query that causes certain kinds of errors, the error will be logged out 3 times because the storage client library is catching the error, tracing it out and then retrying.
If the error is not being caught by your try catch block, then it's likely nothing you need to worry about.
If deliverability of queue messages is important to you, you should ensure that you make use of the visibility timeout overload of CloudQueue.GetMessage and only delete the message when you've finished processing it. You may end up processing some messages twice, but at least you will process all of them.
如果您的角色实例在运行一段时间后重新启动，通常是因为您的进程由于未处理的异常而退出。
If your role instance is getting restarted after running for a while, it's often because your process exited due to an unhandled exception.