设计Azure的云的日志框架

Question

我有麻烦找上设计和实施生活在Azure云应用的弹性日志框架标准做法的信息。这个想法是，应用程序不需要知道或处理自己的日志记录和信息\错误信息的记录可以照顾“在后台”

我正在考虑的设计基本上是“队列 - 基于负载均衡模式“（https://msdn.microsoft.com/en-us/library/dn589783.aspx）通过链接自动转发的服务总线实体进行增强。

的想法是，每个应用程序都有它自己的队列地方在它的地方丢弃的日志信息资源组。此本地队列然后将日志消息转发到中央日志队列。当日志消息落在中央队列中时，它触发一个工作服务（或类似的）来适当地处理消息（格式并将其发送到适当的数据存储区）

这种方法的思想是如果中央消息队列日志消息将保留在应用程序的本地队列中，从而提供额外的弹性层。如果本地队列失败，该应用程序可以作为备份\冗余登录到其他数据存储。

所以我只是想知道是否有任何缺点或理由上面不会是一个好方法，或者如果任何人都可以推荐一个更好的方法来设计/实施Azure中的共享日志框架？

Answer 1

这将是很容易实现日志客户端，例如把日志消息到服务总线队列。你会有一个很好的保护消息队列与自动毒信件检测等。当然大问题是：你会需要它，或者它会足够像存储队列一样简单，甚至直接登录到存储？

任何类型的日志记录都可以使用任务内部的pub/sub模式（例如Event Aggregator）作为后台任务完成。

现有的日志框架

还有一些日志已经实施很多你描述，较受欢迎的一个，名叫Log4Net框架，采用了附加器的概念作为描述实际记录的引擎的方式。这真的可以是任何事情;存储，队列，数据库，并且只需很少的努力，您也可以编写自己的appender以满足您的需求。

成本

更多的往往不是的问题，这可以归结为成本比弹性更大。而弹性是一个风险计算的问题。你的系统可能会崩溃的可能性很大，在这种情况下，你很可能没有看到日志文件。最后，您需要记录哪些尚未由应用程序运行时发生的现有日志处理的内容？最后，没有这些信息会花费多少钱？ 这些问题的答案会给你一个数字，然后你可以转化为适当的日志框架的投资。

我知道，作为开发商，我们一直在寻找完美的解决方案，但是这并不总是符合逻辑的选择。