ELK真的好用吗

在涉及到日志分析处理时，仿佛出现了一致性的ELK，因为花费的时间少，只需要简单的搭建，然后filebeat或mq入口即可，但是今天讨论的是他的不足

1.ELK资源占用高，性能 性价比较低

        真正在生产环境中用过的应该清楚，采用ES存储的，日志多点需要进行分片，logstash分析也非常消耗性能

2.UI太low

        采用kibana进行DQL，返回数据，在网页上显示不友好，特别是熟悉了linux命令行的伙伴们，非常影响效率

3.不方便做离线日志分析

        除了排查bug，就是做日志分析了，es本身是用于检索的数据库。采用全量读取，比直接文件存储差多了，再加上还存储了巨大索引，通常情况只需要查询最近1个月的数据

4.排查bug非常鸡肋

        通常需要进行日志处理，是在系统开始扩大的时候，一个是调用链变深，一个是横向实例变多。这些结构导致排查日志难度加大，问题就是日志分布在不同的应用实例下。es利用索引能够做到这点，但是其本质是日志分散，所以直接将文件合并即可，完全无需ELK，采用文件系统存储即可，DFS系列是最佳选择，然后就可以愉快的grep 了。