-
ELK是什么?
ELK 是一套开源的日志分析解决方案,是三个工具的首字母缩写:ElasticSearch、Logstash 和 Kibana。ElasticSearch简称ES,是一个实时的分布式搜索和分析引擎,它可以用于全文搜索,结构化搜索以及分析。Logstash是一个具有实时传输能力的数据收集引擎,用来进行数据收集、解析,并将数据发送给ES。Kibana为 Elasticsearch 提供了分析和可视化的 Web 平台。传统意义上,ELK是作为替代Splunk的一个开源解决方案(Splunk 是日志分析领域的领导者)。
媲美Splunk,还开源?相信大多数有日志分析需求的开发者和运维工程师都兴奋起来了。没错,我们也不例外。于是,一众小伙伴研究官网,奔走各大论坛,阅读大量相关文档,搭建环境,测试指标,调研对比。的确,ELK非常强大,不愧为目前最好的开源日志解决方案。
But,想要把ELK用起来,用好,还要长期稳定可靠,却非易事。它是一套很好的解决方案,但不是企业级的产品,如果你是想搭个环境玩玩--那没问题,如果你想直接把他用作生产环境(除非你有一个强大的支撑团队)劝你还是趁早另谋出路吧。
好吧,下面根据团队的亲身经历来个现身说法,聊聊我们曾踩过的关于ELK的坑。 -
ELK踩过的坑
Logstash性能问题
如果将Logstash作为纯粹的日志收集,而不做泛化处理(啥是泛化?简单说就是将日志字段提取出来,规则化,通用化,标准化)。单节点性能可以达到80-100KEPS。但是当加入泛化功能后,性能直线下降。泛化规则越复杂,性能越受影响。通过实测,使用泛化和不使用泛化,性能差距在10倍左右。Logstash的泛化功能简直就是超级拖油瓶。
(当然泛化慢是有其客观原因的,毕竟它要提取、修改日志内容,又要马儿跑又不给吃草不现实。如果要优化泛化性能,则需要对ruby和logstash比较熟悉(至少熟练使用)。您可能会问为啥是ruby?因为泛化功能插件是jruby实现的。动态语言在满足了灵活性和易用性时,是以牺牲性能为代价的。)
当然如果对性能要求不高,几百几千EPS,Logstash还是可以勉强搞定的,实在不行只能加设备。
Logstash的硬伤:泛化太太太复杂
话接上回,Logstash的泛化功能由Filter模块实现,不得不承认Filter即强大又灵活,但是真正用起来时你就会发现:调试部署是个费时费力的过程,实在太太太太复杂。以下是我们攻城狮槽点:
- 编写Filter类似于编程,不直观不方便(有点类似Shell脚本解析日志)
- 配置管理不方便,需要自己管理Logstash,配置版本信息。
- 如果是在线编辑Logstash配置,需要重启Logstash或者配置自动重载,也相当于重启,且不稳定。
- 当日志种类繁多时,每种日志都需要编写Filter处理。日志泛化配置维护非常耗时耗力。
- 当部署多节点时,不能自动部署新配置,需要人工干预。
如果对上面观点没有感觉,下面是一个配置脚本的一部分截图,直观感受下吧。像这样的脚本配置可能你需要几百个,复杂程度可想而知。
Logstash的资源消耗
Logstash是使用Java和Jruby实现的。Java应用面对的资源问题,其同样也存在。Java对内存需求较高,一般Logstash的配置都是GB起步。与同样日志收集为目的Filebeat(go语言实现)应用对比,资源需求10倍起步,且在启用Filter时,其性能很低,需要部署多个实例或者结点。资源需求按照同等倍数增加。
Elasticsearch索引分片规划是门技术活
如果你用ES存几十G或者几百G的数据,那没问题,你可以无视下面我提到的ES的坑,直接跳过。如果你需要存储的数据是TB甚至PB级别,那么下面的技术点非常有用(当然也非常枯燥):
ES是一个分布式、面向文档的数据库,每一条数据记录称为一个文档。索引(Index)是一系列具有相同映射文档的集合,是ES数据管理对象。一个索引是由若干个分片(Shard)组成,每个分片是一个完整的Lucene运行实例,是底层索引的最小单元。分片有主分片、复制分片,一个索引下的不同主分片数据没有交集,而每一个主分片可以有0或多个副本(复制分片)。多个主分片存在的意义在于集群环境下利用多节点优势,让每个主分片运行在不同主机上,提高数据的写入、检索性能。而复制分片一方面可以提供数据的冗余备份,在对应主分片失效时实现“热备”效果,另一方面在数据访问时,复制分片也可以提供服务,从而增加数据的访问吞吐量。
图1 三个节点的ES集群,一个索引有3个主分片,每个主分片有2个复制分片
ES的分片设计在使用上需要遵循其特性和限制。例如索引建立后,主分片数不能任意调整。多个主分片可以同时工作在同一个集群节点上,但复制分片和其对应主分片不会同时工作在同一节点上。此外分片的大小在软件实现上虽然没有限制(文档数硬上限2,147,483,519),但它的大小应该能够被硬件处理,具体尺寸取决于硬件和应用场景。分片太大势必影响数据的访问性能(一般社区不建议分片超过50G);分片的数量太多,会降低整体访问性能,而且由于每个分片是一个完整的Lucene实例,它有自己的JVM堆等管理开销,集群中充斥着大量小数据的分片也会降低集群整体的性能。
所以索引在建立之初就需要合理规划主分片数量,一般需要考虑索引将来能长到多大,长得有多快;需要在索引长大之后再对索引做大的变更(例如reindex)还是现在就多分片;按什么来拆分索引,按时间、按日志的用户还是其他特征?这些数据将来的使用可能依赖JVM堆、OS页缓存、磁盘随机IO还是CPU密集型任务等。在没有经验数据指导的情况下一般可以用短期的数据来做预测,这样在未来集群扩充节点时,索引的分片可以顺利迁移。否则就可能涉及重新索引(Reindex)等操作,费时费力。此外分片的映射等也需要在索引创建时做好规划,避免映射爆炸(Mapping Explosion)等映射不合理问题,加剧JVM堆的消耗,降低集群性能。
说了这么对技术细节,总之就一句话:没规划好索引和分片,随着数据越来越多,ES随时可能崩溃,而索引和分片规划这门技术活需要用户自己做。
数据生命周期管理ES不会帮你做
日志类应用是典型的写多、读少应用场景,随着日志的不断收集、存储,我们可以将日志看成流式数据,写满一个又一个的ES索引。在固定的硬件规模下,索引数量不能无限增加,这时我们必须考虑删除或关闭最老的索引(较新版本的ES还增加了冻结索引的方式)。在这种场景下面临的问题一般是如何达到高的写入性能、保持更多的数据可检索并且检索性能足够好、同时又能持久化尽量多的日志数据。
图2 典型的数据生命周期
这种需求会用到数据的生命周期管理机制,我们可以将数据索引分为热、温、冷三种状态。热索引为当前正在写入的索引(同时可以被检索),当该索引“写满”或“过期”时将它转为温索引,同时创建新的热索引接收新数据,此时的温索引不再可写但仍可被检索,当温数据变得很“老”不大具有检索价值时,可以将其变为冷数据,冷数据仍是持久化数据但不能被直接检索(需要“打开”、“解冻”或其他特殊方式才能被访问)。
ES提供了热、温、冷机制,但非常遗憾,哪些数据是热数据?什么时候转温?什么时候转冷?需要你自己控制,说得直白一点,需要自己写一套程序,实现数据生命周期管理。
ES的搜索又双叒叕超时了
数据的搜索一般是查询包含有特定术语的文档数据,这些数据都在OS页缓存中,所以不用从硬盘读取,根据统计,检索方式往往服从Zipfian分布,即80%的搜索只用到20%的数据,所以也不用那么多的内存。
图3 ES搜索
单分片的典型检索过程如下:用对应的Term字典和Posting List来检索到候选文档,此时如果这些数据已经在OS页缓存,那么过程将较快完成,否则将访问低速磁盘。在检索结果打分前,先用过滤器,如果过滤器没缓存,就立刻生成一个(考虑未来、全局的使用)。如果只是找TOP N,搜索引擎计算匹配的相关性(尽量不计算非TOP N的文档),如果请求的字段在页缓存中,就能较快得到结果。而如果需要其他方面的信息,就可能需要知道所有文档中该字段的值,这些就需要用到字段缓存(没有就立刻创建)。对简单的检索过程,只要没有聚类、排序、脚本加载大量字段,只需要较少的堆,但需要多的页缓存。分析类应用如聚类,不显示所有的结果,只需要少量页缓存,但需要大量堆。
在实际使用中,当面临的目标索引数量较大、而且ES集群写入负载也很重时,检索过程需要小心设计,否则很容易耗时过长、消耗大量内存等硬件资源还得不到检索结果。如果想尽可能高效得到检索结果,减少等待感,需要用到异步检索,同样,ES不支持异步检索,异步检索需要编程实现。
ELK的问题还有......
篇幅所限,ELK的问题不再一一阐述,仅罗列几个常见的问题,如有兴趣欢迎切磋交流。
- ELK是三个独立的开源套件,不能统一部署,搭建环境较复杂,需要专业人士。
- 在Kibanna上搜索不方便,需先指定索引,当然前提是你事先知道你想要的数据可能在哪些索引中。
- 缺少权限管理,没有访问隔离,数据对所有人可见,易造成数据泄露。
- ELK对数据一致性没有专门的保证机制,无法做到数据不重、不错、不漏。
- 不易扩展,需在新设备上手工安装ES,配置ES集群。
哎!ELK,想说爱你不容易!
-
秒云日志分析系统如何解决问题
首先,我们承认ELK的强大,但要正视它的问题。站在ELK这个巨人的肩膀上,我们有更高的起点,同时也必须回过头来补齐它的短板,把通用的ELK解决方案做成专业的产品。秒云日志分析系统就是这样一款针对日志分析的专业产品,下面重点聊聊秒云日志分析系统是如何完善ELK方案的。
化繁为简
这要从几个方面说起:
简化日志解析:Logstash解析泛化日志的复杂程度相信大家有所感触,我们的攻城狮怎么能把难题交给客户呢?所以,我们直接抛弃了Logstash Filter,自研日志解析引擎。现在你看到的日志泛化是这样的:
按照引导式界面操作,通过勾选,自动完成解析配置,就是这么简单。
简化ES使用:ES很强大,但要把它用好却不容易。秒云提供存储管理、数据生命周期管理,为你屏蔽掉复杂的中间处理,你只管存数据,诸如索引分片规划、冷热数据转变等问题统统交给秒云就好。
简化搜索:直接搜索大量ES数据往往会超时,因此秒云日志分析系统提供了搜索加速引擎。加速引擎采用异步搜索,将搜索任务尽量拆分成若干个小部分,并逐步完成,不定时将各部分结果逐渐拼凑并及时呈现,确保每次搜索有结果。用户只管搜索数据,超时问题我们来解决。同时,搜索加速引擎提供简化版搜索语句,支持全文检索,支持联想提示。你会用Google搜索吗?那你一定也会用秒云搜索。
易分析:不需要输入繁琐的语句,不需要记住复杂的统计函数,界面操作,鼠标点选实现任意维度的统计,立刻生成图形直观展示统计结果--这是秒云日志分析系统的分析工具:数据透视工具。
易扩展:秒云日志分析系统部署在秒云容器管理平台,采用微服务架构,扩展容量非常方便,只需两步:1、新设备加入K8s集群;2、为设备打上标签。后续容器管理平台将自动部署ES,自动加入ES集群。
在简化使用,提升用户体验方面秒云日志分析系统还做了很多,例如自动发现数据源,自动匹配解析规则;
APP一键导入,特定场景分析图表自动生成等等。无论你是运维大神还是刚入职的新手,相信使用秒云日志分析系统都会得心应手。
极致性能
秒云日志分析系统在性能上的改进主要表现在三个方面:
处理性能:Logstash启用Filter功能性能非常低,也正是因为这个原因,让我们下定决心舍弃Filter,自研解析引擎。解析引擎采用Go语言,设计之初就充分考虑性能问题,经过测试,解析引擎处理能力超过100KEPS,而相同环境下Logstash的性能不到7KEPS,性能相差近20倍。
压缩性能:得益于秒云日志分析系统数据生命周期管理,新数据为Hot状态时采用较低性能的压缩算法,既可以提升存储速率,又可以减少搜索时间。当数据随着时间而老化,对旧数据采用高性能压缩算法,减少磁盘占用,压缩后空间占用仅为原始数据的20%左右。
搜索性能:秒云日志分析系统搜索能力建立在ES之上,封装一层搜索加速引擎。加速引擎的加速主要体现在两个方面:1、结合存储管理,将搜索范围尽量缩小,看似大范围全文检索,其实后端也会将搜索范围定位到局部的索引中。2、异步搜索,逐步返回。我们将一次搜索拆分成多次小的搜索任务,依次返回结果。优化过后,即使在10亿级的数据中搜索,结果返回也不会超过10秒。
云原生优势
秒云日志分析系统是支持容器化部署的云原生应用,天生具有低耦合、高内聚、弹性扩展、分布式等优势。同时,也得益于秒云容器平台的技术积累,秒云日志分析系统支持识别到应用日志,以及识别应用所在K8s集群,运行在哪台服务器,跑在什么容器内以及使用的镜像名称等等细节。有了关于容器的详尽日志数据,再通过秒云专业的容器日志分析APP,可全方位多角度展示云原生应用,更好的服务于微服务运维场景。
企业级产品
秒云日志分析系统是一款企业级产品,除了丰富的日志功能,我们还实现了权限管理、配额管理、告警通告,在数据一致性上下功夫,保证数据不重、不漏、不错。当然系统的稳定性也是我们考虑的重点,为此团队投入了大量的开发资源加固产品,投入大量测试资源长期对产品做高压测试,异常情况测试,保证产品的可靠性和稳定性。
全面国产化,信创支持
秒云日志分析系统致力于打造全面国产化的自主品牌。面对激烈的国际竞争态势,公司积极响应国产化号召,带头推进和落实国产化战略。从2019年开始,秒云系列产品陆续与兆芯、海光、鲲鹏、飞腾等国产芯片,以及中标麒麟、银河麒麟、统信UOS等国产操作系统完成兼容性互认证。未来,秒云将着力于技术创新和产品研发,携手更多合作伙伴,积极推进国产化适配工作,加速全面国产化生态体系建设,为国家信息安全保驾护航。
总结
取其精华,去其糟粕,秒云日志分析系统保留了ELK中的E(Elasticsearch),用自研的解析引擎替换了Logstash,用自研的Web前端替换了Kibana,新增了存储管理、数据生命周期管理、数据配额管理、数据缓存确认机制、搜索加速引擎、数据透视、权限管理、告警通告等等等等。无论从功能、性能、易用性还是可靠性、稳定性方面,秒云日志分析系统相比开源解决方案都有非常多的增强和改进。秒云日志分析系统致力于成为日志分析领域的专业产品,提供开箱即用、简单易用的数据分析平台,并提供信创版本,全方位帮助客户解决审计、运维、安全和业务分析场景的问题。