日志平台的一点思考
我对日志平台的理解
日志平台的对开发、运维人员的帮助是非常大的，它可以方便开发、运维人员快速定位问题，从这个角度，日志平台是个搜索平台；同时还可以做有效的数据分析，比如分析 pv, uv，httpstatus，用户行为，资源消耗，网络攻击、trace等等，应用场景非常丰富，这时候它又是个数据分析平台，在马上到来的5G时代，物联网的真正兴起，日志平台会发挥更大的价值。
日志其实是比较宽泛的概念，应用打印的server log,Linux文件系统的syslog，/var/messages 等等都是日志，日志本质上其实是一种时序数据，类似于监控领域的metrics，只不过metrics一般是比较结构化的，每个字段数据长度都比较小，通常是时间+tag+value ，而日志也带有时间，但是单条日志可能会比较长（有时候不止一行） ，同时大多数都是非结构化的文本数据，它们共同的特点是数据产生后不会被更新。
简单说日志平台既要存储又要计算
日志平台应该有哪些功能点
功能上，日志平台应该具备以下几个基本的功能点
1、日志的采集
2、日志数据的存储
3、日志数据的快速检索和分析
1、采集
日志要搜索，就要集中存储，就要采集日志，以前日志采集分2种，一种是agent的方式，一种是agentless的方式，前者是在要采集的服务器上部署一个agent，agent将日志不断的发送给日志server端，agentless的方式是通过类似ssh远程登录服务器去抓日志。
agentless的方式不需要部署agent，一般是定时的方式去拉日志过来，这种方式时效性很差，不能实时监听文件系统获取最新的日志数据，基本上业内很少有人采用了，以前阿里巴巴的TLog似乎是采用这种方式。
现在大部分是采用部署agent的方式获取日志，比较有名的是flume,logstash,filebeat等等，flume和logstash在使用的时候，不方便控制占用的cpu和内存资源，在微服务化架构的环境中，采集日志对agent的性能要求越来越高，同时资源消耗要尽可能的低，filebeat相对比较轻量，功能也非常强大，使用人越来越多。
agent的方式本质上是调用server的api接口将数据发送给日志的server，因此另一种使用方式就是app直接调用日志server的api，比如将这个功能做成log4j的插件，或者写入其它的常用的日志组件中，这样日志采集的成本最低，但是当日志服务不可用的时候，日志数据恢复成了稍微麻烦的事情。
通常在一个成规模的企业内部，使用agent的方式采集日志，管理agent也是一个问题，比如阿里巴巴目前声称SLS的agent部署超过200万个节点，不要说200万个节点，就是200个节点，我们总不能挨个登陆去修改agent的配置文件吧，因此采集任务的自动下发，生效，更改非常重要，同时还要能够自动管理agent的状态，升级agent等等。
以前阿里巴巴的TT也有agent采集，部署规模也较大，在实现方面，有些场景下agent会请求服务端的clientAPI，这种设计在双11降级恢复的时候，会给clientAPI带来非常大的压力，因此，在设计应用于大规模的agent部署场景的时候，应该考虑这种问题。
2、存储
写的目的是为了读，要更好的读，就要设计更合理的存储方案。既要满足检索，又要做数据统计和分析，似乎解决方案只有倒排索引了？开源社区一提到日志的存储，一般都会选择elasticsearch，一些创业公司也会基于或者借鉴es来做存储的方案，这个东西的确开箱即用，一个命令拉起来，日志灌进去，搜索效果似乎也不错，kibana也能分析，但是当我们实际部署应用起来，就会发现用es存日志是一个成本非常昂贵的方案。
在一家稍有规模的公司，日志数据10w/s每秒的写入是非常容易出现的，实时索引，然后刷到文件系统缓存才可见，es这种实现方式，本身就不适合迎接这种高tps的写入，同时它读写不分离，一般情况下，Lucene的设计在日志场景下需要经过特殊的优化，比如将那些常驻内存的数据进行lru处理，将不常用的索引关闭，在merge的时候对避免重复IO，segment关系映射内存优化等等，越深入了解，越发现这种方案真的太奢华了，业内用es做日志存储的基本上都是土豪，动辄几百上千的服务器堆砌 + 精细化运维，性价比极低，真是暴殄天物，日志规模较大的，财力一般的公司就不要考虑这种败家的方案了。
日志的存储实际上需要实时求是，根据日志的特点，灵活的设计存储方案。
3、检索和分析
日志搜索也是一种典型的交互式查询的场景, 当然是越快越好，比较理想的情况是1-3秒返回结果，但是时间跨度非常大的场景，十几秒用户也能接受，超大规模查询最慢不超过30秒等等，检索方面，除了输入关键字，还希望能够支持功能强大的分析、过滤、统计。这种特点，其实给存储留下了非常大的设计空间，也是不小的挑战。
存储首先应该是分布式的，可以方便水平扩展的，同时根据日志的特点，做少量的必要的索引。比如日志一般是按照时间范围搜索和分析的，那么时间显然是最重要的索引，同时日志来自哪些机器，属于哪个应用，什么机房，应该会有一些标签，那做一些基于标签的索引就足够了，那么现有的一些存储系统能不能直接利用呢？
前面说了日志是一种时序数据，那么opentsdb能不能做日志的存储呢？opentsdb本身依赖hdfs，hbase，从部署角度讲，太复杂，同时它一行就存储一小时的数据，每一行是一个metric，这种方式，你日志怎么存，显然不合理。
kafka这种东西呢，它也给每条消息加了时间戳信息，支持按照时间戳seek，kafka的架构设计其实给了我很多日志存储设计的启发，但是它的索引仅有时间是不够的，也许你会想能不能在topic名字上做点文章，我想也是不可以，因为我们要索引的东西还是蛮多的，kafka在topic数量非常大的情况下，性能会下降的比较明显。
日志统计和分析方面阿里巴巴的SLS是通过标准SQL来做的，但是我更喜欢类似shell命令行的风格和方式，sql思维需要一些时间转变，用户并不一定都会喜欢sql，但是不管怎么样，要分析、统计日志，需要在日志存储系统上面搭建一套DSL分析引擎，能够加入常用的算子，同时还能分布式执行这些运算，同时快速的返回结果，曾经想过用MLSQL加载日志的数据然后用sql分析完将结果取回，这其实也是一条很好的思路，虽然MLSQL不需要每次都提交spark作业的过程，但是搬运数据还是会牺牲掉一部分时效性，好处是计算和存储是分离的，同时我还希望日志平台能够实时的监听一些我感兴趣的日志事件，然后在自定义的dashboard中展示，支持报警等等。
最后
最近1-2年一直在研究探索更具性价比的日志管理平台，后续会将一些心得体会、解决方案记录下来跟大家分享。
