告别ELK,APO提供基于ClickHouse开箱即用的高效日志方案——APO 0.6.0发布
· 17 min read
ELK一直是日志领域的主流产品,但是ElasticSearch的成本很高,查询效果随着数据量的增加越来越慢。业界已经有很多公司,比如滴滴、B站、Uber、Cloudflare都已经使用ClickHose作为ElasticSearch的替代品,都取得了不错的效果,实现了降本增效,费用节约大多在50%以上。但是目前使用ClickHose作为日志方案,存在以下问题。
- 主流的Vector+ClickHose并未实现开箱即用,有许多的管理配置工作
- 绝大多数方案不支持近似全文检索的功能(该功能很重要)
- 使用双数组或者Map的表结构查询效率不高
- ClickVisual是最接近的开箱即用的日志方案,也存在以下问题:
○强依赖Kafka,对于某些中小用户而言方案不够灵活,不友好
○未引入Vector,原生的ClickHose Kafka引擎在大流量情况下可能导致ClickHose内存爆掉(感谢社区大佬 十四反馈)
主流的Vector+ClickHouse方案并未实现开箱即用
目前业界很多公司都是基于Vector+ClickHouse的方案来实现日志的采集和存储,该方案需要管理维护的工作量相对而言比较高,适用于动手能力强的公司。
维护工作:为每种日志手动维护一张表
每个公司的部门团队可能日志规范都不完全一致,如果需要对日志内容进行快速搜索定位故障,就需要提前想好ClickHouse的表结构,然后调整Vector的配置文件,最终实现Vector根据不同日志格式,parse成不同的日志表字段,写入不同的日志表。
比如每种日志都得建立以下类似的表结构,才能完成日志按照ip、url等字段的索引实现快速搜索。但是另外一个部门的日志也许就不需要IP和url字段,那么该部门得重新设计表结构。
CREATE TABLE log
(
`ip` String,
`time` Datetime,
`url` String,
`status` UInt8,
`size` UInt32,
`agent` String
)
ENGINE = MergeTree
ORDER BY date(time)