【问题标题】:For audit logging, which technique is the best?对于审计日志,哪种技术最好?
【发布时间】:2018-06-23 09:07:50
【问题描述】:

我需要选择一种技术来存储和检索审核日志(添加、删除、修改等内容时)。场景是:日志可能每天增加1000万条,会被一些关键词检索。 所以我的问题是:

  • 我应该使用哪种技术,例如 ELK(Elasticsearch、Logstash、Kibana)或 MySQLRedis 或更好的方法以及原因。

【问题讨论】:

    标签: mysql logging redis elastic-stack audit


    【解决方案1】:

    ELK 是一种标准选项。它可靠,在数百万条记录中具有出色且快速的关键字搜索功能,并且可以相当线性地扩展。

    MySQL 将是一个不错的次要选择,但根据您需要保留的时间范围,您最终会在空间或搜索能力方面遇到扩展问题(在合理的时间框架)没有分片。分片可以解决很多这些问题,但它可能会比 ELK 之类的东西更手动和更痛苦,ELK 很容易设置为按日期索引/分片。

    Redis 不会是一个很好的选择。所有 redis 数据必须适合内存,这极大地限制了您可以保留的日志数据量。键/值也不适合日志结构的数据,尤其是它的可搜索性,这在 redis 中基本上是没有的。

    如果您要超越 ELK,下一个最佳选择可能是 HDFS + Hadoop/Spark 搜索(或者如果您在 AWS 领域,则为 S3+EMR),但每天 1000 万个 ELK 应该能持续好一会儿(取决于时间范围)。举个例子,我目前正在使用一个 10 节点的 ELK 集群,该集群每天处理大约 10 亿个日志项,并且我们保留了两周的历史记录。


    编辑:

    对于您正在寻找的审计日志记录,为了增加可靠性,将类似 kafka 流的东西作为应用程序和 ELK 之间的层写入可能会很有用。这将绕过一些可能会遇到依赖日志文件传送的奇怪/糟糕的行为,并为您提供所有更改的无限期、可重播流。

    【讨论】:

    • 添加审计日志的一个简单方法是使用另一个线程来做(例如spring @Async)但是随着日志的增加,管理线程的成本很大。所以消息队列(比如kafka)是一个不错的建议。我还想知道是否有任何方法可以在没有代码入侵的情况下将审核日志保存在应用程序中?由于在应用程序中保存日志会存在大量重复代码
    • 这在很大程度上取决于您的应用程序架构。如果您的数据库访问在您的代码中完全分离,并且实体有自己的管理类/服务,则可以设想一个通用实体记录器,其中数据管理类可以为其操作固有并自动发生这种情况。我对 Spring 不是很熟悉,我想这就是你正在使用的东西,所以我不一定有一个非常具体的建议。
    猜你喜欢
    • 2012-02-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-18
    • 2019-12-02
    • 1970-01-01
    相关资源
    最近更新 更多