远程日志是能切实提升程序员定位问题效率的工具，目前已经有成熟的方案es elastic search，也就是elk。在实际使用的过程中，存储时间短，可能会丢少量条目消息的问题会出现，跟同事调研探讨以下解决方案。
问题：远程日志定位问题，有无更多方案 1.辅助以离线数仓日志统一上报，落库kafka分流处理，一道进入elk，一道通过小时级别的大数据数仓，通过hive presto 对小时落库的hdsf数据大表做二次搜索，可以极大拉长可检索时间，简易检索的速度也很快，非常方便。缺点是定位时长需要等小时级别，所以elastic search 还是没法丢弃。
2.使用clickhouse 这个看起来是一个不错的选项，按照速度测试对比，clickhouse读取和写速度是更快的，具体可见 https://zhuanlan.zhihu.com/p/353296392
https://segmentfault.com/a/1190000039919389
看起来基本都是clickhouse更优，但实际上clickhouse暂时无法替代es，主要原因在于数据实时性需要持续写入，这会造成clickhouse小文件merge问题，导致too many parts 异常和大量merge计算影响使用，而如果降频则必然影响数据实时性。目前看到最成功且公布的实践为携程的实践https://zhuanlan.zhihu.com/p/103781296。里面介绍了实际应用clickhouse做远程日志的方案、坑和结果，最终解决方案还是需要降频批量写入。这样下来优点是成本大幅降低，但是相对es远程日志分析的效果是有下降的。
而且，es 相比CK成熟很多，虽然数据摄入速率、数据压缩这些硬指标不如ck，但在软指标，比如平台的稳定性，成熟度，易用性等软指标，es 还是有相对优势。如完整的大数据链路，有数据摄入层（beats, logstash）和可视化层(kibana)，有各种分析app （canvas和lens），直接提供大屏，也可以脱离SQL为业务人员提供探索式、交互式的分析能力，可以更快方便搭建远程日志服务，快速支持业务发展。最后，监控和安全上es也有着更丰富的实现，不需要二次造轮子。
结果最后讨论下来，还是使用elk+离线实时数仓实现更为可行。