-
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，新增了存储管理、数据生命周期管理、数据配额管理、数据缓存确认机制、搜索加速引擎、数据透视、权限管理、告警通告等等等等。无论从功能、性能、易用性还是可靠性、稳定性方面，秒云日志分析系统相比开源解决方案都有非常多的增强和改进。秒云日志分析系统致力于成为日志分析领域的专业产品，提供开箱即用、简单易用的数据分析平台，并提供信创版本，全方位帮助客户解决审计、运维、安全和业务分析场景的问题。
.png)
