你会推荐这种方法吗？还有其他建议吗？
新答案
MongoDB是可扩展日志解决方案的次级选择。这里有通常的原因(例如写负载下的性能)。我想提出一个，这是它只解决了日志解决方案中的单个用例。
强大的日志解决方案需要至少涵盖以下阶段：
>集合
>运输
>处理
>存储
>搜索
>可视化
MongoDB作为选择只解决存储使用情况(虽然有点不好)。一旦分析完整的链，就有更合适的解决方案。
@KazukiOhta提到几个选项。我最喜欢的端到端解决方案这些天涉及：
> Logstash-Forwarder收集&运输
> Logstash& Riemann加工
> ElasticSearch for Storage&查询
> Kibana3可视化
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。