想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.
关闭 11 个月前。
社区审核了是否重新打开此问题11 个月前 并关闭:
原始关闭原因未解决
对于可扩展的应用程序，您是否有记录到 NoSQL 数据库的经验？我对用于日志记录的 NoSQL 数据库进行了一些研究，发现 MongoDB 似乎是一个不错的选择。另外，我发现 log4mongo-net这似乎是一个非常简单的选择。
您会推荐这种方法吗？还有其他建议吗？
最佳答案
我决定修改这个公认的答案，因为过去 18 个月中最先进的技术发生了显着变化，并且存在更好的替代方案。
新答案
对于可扩展的日志记录解决方案，MongoDB 是一个低于标准的选择。这有通常的原因(例如负载下的写入性能)。我想再提出一个，那就是它只解决了日志解决方案中的一个用例。
强大的日志记录解决方案至少需要涵盖以下阶段:
MongoDB 作为一种选择只解决了存储用例(尽管有些糟糕)。一旦分析了完整的链条，就会有更合适的解决方案。
@KazukiOhta 提到了一些选项。这些天我首选的端到端解决方案包括:
ElasticSearch 用于日志数据存储的底层使用使用当前最优秀的 NoSQL 解决方案进行日志记录和搜索用例。 Logstash-Forwarder/Logstash/ElasticSearch/Kibana3 属于 ElasticSearch 的保护伞。提出了一个更有说服力的论点。
由于 Logstash 也可以充当 Graphite 代理，因此可以为收集和分析指标(不仅仅是日志)的相关问题构建一个非常相似的链。
旧答案
MongoDB Capped Collections非常受欢迎和suitable for logging ，还有一个额外的好处是“少模式”，这通常是一种适合日志记录的语义。通常我们只知道我们想要登录到项目中的内容，或者在生产中发现某些问题之后。在这些情况下，关系数据库或严格模式往往难以更改，试图使其“灵活”往往只会使它们“缓慢”且难以使用或理解。
但是如果你想 manage your logs in the dark and have lasers going and make it look like you're from space总有 Graylog2它使用 MongoDB 作为其整体基础架构的一部分，但在顶部提供了更多内容，例如通用的可扩展格式、专用的日志收集服务器、分布式架构和时髦的 UI。
https://stackoverflow.com/questions/10525725/