相比较人们目前对于日志的关心，我想人们应该给予更多的关注。在设计一个应用的时候，有许多的精力都耗费在了创建客户逻辑模型，确保所有用例被覆盖并被正 确处理。商务模型被映射到一个持久化存储（是存在RDBMS或者是NoSQL解决方案中），人们挑选各种框架：web，中间件，批任务，还有可能是用 log4j或logback实现的SLF4J(简单日志门面Simple Logging Facade for Java)。
几乎所有我参与的应用都是这样的，日志往往都是二等公民，它依赖于良好的老的字符串日志框架。 但最近我意识到，需要日志记录的东西远不止目前基于字符串的日志系统所做的。特别是在系统被部署在云端，具有良好的伸缩性时，这时采集文本文件并将它们聚集到一个公共的地方，感觉就像是黑客行为。 在最近一个应用中，我们实现了一种消息机制，它具有更复杂的信息，弥补了基于字符串日志的不足。我必须要感谢与我共事的一位同事，他说“消息位于我们应用的核心”。我还未曾想过日志作为任何系统的核心。商务逻辑是应用的核心，而不会是日志。但他的话富含真理，因为如果不具备一个能够知道系统是否确如期望而动作的好的机制，你将无法部署任何东西。 所以我的通知是比较复杂的对象(调试级通知比错误级通知的数据要少)，NoSQL文档数据库是存放我们的日志的绝好存储库。一个通知内包含了以下所有类型的数据: - 当前正在制定的任务,
然后，既然我可以用一种“无模式”的风格来存储复杂对象，我也就可以对日志进行查询，而且日志到达的顺序也没有什么影响，因为我可以按照来源和创建时间对他们进行排序。这样我就可以拥有一个安排好的任务，用来在监测到大量错误的时候产生警告和报告。 这是一个定制的日志实现，因为我们还没有对提醒使用专用的框架，但我从中得到了比经典的基于字符串的日志文件更多的价值。
我仍然认为log4j和logback是很棒的实现，我们还没有替换它们，仅仅加入了一个额外的日志特征来克服它们的局限，但即使有了新的logback 输出源，我依然认为当前基于字符串的日志对于生产系统需求来说太简单了。如果你使用它们更多是为了调试的目的，而且在生产环境有额外的监控方法，那么也许 是时候使用一个聪明的、可以在开发和生产环境应用的日志解决方案。 假如说10年前，当关系型数据库统治着存储世界，这是一件很难实现的事情，而基于文件日志是一个很好的折中方案。那么我认为现在我们已经有方法实现一个更 好的日志框架。当前“基于String的文件日志”模型已经很有效率了，尤其是当我们的服务器垂直缩放在单个机器中。但是在一个有许多水平分布服务器的世 界，这种模型需要额外的处理。
大玩家们已经使用这种新一代日志系统了，譬如Facebook Scribe和 LinkedIn Kafka log processing. 我真的喜欢 LinkedIn 的方案，而且他也是鼓舞着我去探寻出一个工作在CQRS时尚的新的日志系统。在这个日志系统中，日志实体像事件一样存入日志数据库，而且每一个事件通过一 系列操作来更新当前的系统状态。这个就结合了日志和监视器，而且每个监视命令直接缓存最新的系统状态呈现，这些状态包括：
|
