背景

在日常工作中，我们通常需要存储一些日志，譬如用户请求的出入参、系统运行时打印的一些info、error之类的日志，从而对系统在运行时出现的问题有排查的依据。

日志存储和检索是个很常见且简单的工作，市面也有很多关于日志搜集、存储、检索的框架可供使用。

譬如我们只有个位数机器时，可以通过登录服务器，查看log4j之类的框架打印到本地文件的日志。当日志多起来后，可以用elk三剑客处理日志。

当日志量进一步增多，我们可以上消息队列，譬如kafka之类来承接，然后消费入库。或者写本地文件，再采用filebeat之类上报再入库。

以上都是较为常见的日志传输和存储的方案，成本可控的情况下，可适用于绝大多数场景。

我们可以简单总结一下日志框架的功能，大概是暂存、传输、入库保存、快速检索。

量级上升，成本高昂

技术方案的设计和取舍，往往强受限于成本。当成本高企到难以承受时，将必须导致技术方案的升级换代。那么问题来了，我就是存个日志而已，怎么就成本难以承受了呢？

我们以一个常见的日志传输及存储方案来举例，入下图，暂存就是采用客户端写本地文件存日志，传输即是采用MQ，消费入库常见的如ES。下图方案，为了减少部分存储成本，将日志详情存储于压缩更好的Hbase，仅将查询时需要的一些索引字段放在了ES。