腾讯云ES：日志轻接入和免运维最佳实践

原创

yinanwu

发布于 2022-12-05 17:29:46

1.2K0

发布于 2022-12-05 17:29:46

日志的采集、检索和分析是每个业务在架构设计上都需要考虑的重要一环，同时也是痛点较多、人力成本较高的一环。本文将从日志的生命周期开始，分析业界最成熟的ELKB解决方案在接入时和接入后的痛点，并通过在腾讯云ES上接入日志和运维索引的体验，分享腾讯云ES是如何解决这些痛点，来降低日志接入和运维成本，让业务能专注于日志数据价值的挖掘。

日志的生命周期

通常情况下，日志的整个生命周期可以分为：日志生成、日志采集、日志处理、日志存储、日志分析和查询。

日志生成。业界成熟开源的组件一般有自己规范的日志格式和日志存储路径，而业务开发的程序输入的日志则可能五花八门。在K8S中，日志一般由POD中的业务程序输出到标准输出或标准错误输出中，并最终落盘在K8S规定的日志路径中（例如/var/log/containers），为日志采集提供了便利。
日志采集。确定日志文件的路径后，可以通过常用的日志采集的工具进行采集（例如Filebeat、Fluentd、Flume等），采集过程一般较为轻量，不对日志文件的原始内容进行处理。采集的日志根据业务需求或业务量大小，可以直接进入存储，也可以先进入消息队列，再由其他组件消费。
日志处理。日志的原始内容一般是一个大的文本，里面包含日志时间、错误等级、详细内容等可按正则表达式或JSON等格式分割的字段。一般情况下，可以以原始的大文本存储，但是对于有过滤、聚合、排序需求的场景，则需要事先将大文本中各字段分割开。这个操作比较消耗资源，一般是独立于采集进行，例如通过Logstash、Flink等工具对原始日志文件进行处理，当然也可以在采集端如Filebeat的processors或存储端如Elasticsearch的pipeline中进行。
日志存储。处理后的日志最后需要存储到检索引擎中，供后续分析和查询使用。业界常用的日志检索引擎有Elasticsearch、Clickhouse和Loki等。日志的存储一般具有明显的冷热属性，在最近几天的日志查询量最大，近几星期的日志查询量较小，而一个月以前的历史日志基本没有查询，因此在日志存储时需要根据这个特性考虑日志的存储生命周期，提高热数据的查询性能、节约冷数据的存储成本。
日志分析和查询。一般日志的存储端都具备日志的分析和查询能力，根据不同引擎的实现方式，有些擅长全文检索，有些擅长排序聚合，但是都必须具备实时处理大量数据、支持任意关键词检索、低成本等特性，同时对于分析和查询结果，需要有一个可视化界面用于展示或绘制图表（例如Kibana、Prometheus等）。

这几个生命周期中，业务侧关注的是日志的生成和最终日志的分析查询；运维侧则需要关注日志采集、处理和存储的组件管理。

ELKB解决方案痛点

对应日志的生命周期中各阶段的需求，业界已经形成了一套成熟的并且广泛使用的开源日志采集和分析架构——ELKB（Elasticsearch+Logstash+Kibana+Beats），提供了日志从采集到最后可视化展示分析结果的全链路解决方案。因为都同属于Elastic生态的产品，因此各个产品间在协议、规范、使用上都具有很好的兼容和一致性，并且Elastic社区活跃度高，产品迭代快，在使用上遇到的问题都能得到快速的解决。因此，对于大部分企业的日志管理需求，ELKB架构都能很好的满足。

但在实际使用ELKB的过程中，其实会发现整条链路的构建和使用维护的过程并不轻松，主要有两方面的问题：

日志接入时，终端设备多，部署链路长，无法统一的部署和管理，需要单独部署各个组件，最后再通过配置文件串联起来。这需要运维人员熟悉各个组件的部署过程和配置参数，否则链路很可能构建不通。
日志接入后，需要运维数量不断增加的索引，管理生命周期模版等，并且当索引和分片数量不断增长，可能导致集群不稳定，例如当日志量突增时出现写入拒绝，节点故障导致写入阻塞等。

ELKB因其广泛的使用，其链路中的各组件在各大云平台都有云化产品，因此部署单个产品并不困难，困难的还是将日志数据通路打通和后续的运维，这也是自建ELK和云产品部署ELK的共性问题，也是大部分业务迁移上云意愿不强的原因之一——既然自建和上云都需要业务打通复杂的链路，也需要优化和运维ES索引，上云有什么优势呢？

腾讯云ES上接入日志的体验

腾讯云上提供了独立部署的Elasticsearch集群、Logstash实例、Beats管理等云服务，对于有单个产品使用需求的客户，提供了非常友好便捷的可视化管理界面。

同时，针对上面提到的日志接入的痛点，腾讯云ES也提供了一站式的数据接入解决方案。进入腾讯云ES数据接入页面，只需按照提示选择数据源、数据采集器、可选中间件（如数据缓存、数据加工）以及数据目的，就能快速的构建起一条日志采集的ELKB数据链路。

丰富的场景和数据源支持。 数据源支持多种场景和多种云产品，满足日志采集、指标采集、数据同步、数据库加速等各种ES使用需求。

* 日志采集场景，支持云服务器CVM、容器服务TKE中业务产生的日志，以及云防火墙、Web应用防火墙等云产品产生的日志，并且在不断丰富其他云产品日志的接入。

* 数据同步和数据库加速场景，支持从云数据库MySQL、消息队列CKafka、自建Kafka和弹性Topic中同步数据到ES，自动解析并动态生成字段映射，无需业务部署额外组件或开发。

多样的配置和高效的管理。 数据采集根据不同场景，支持日志采集器Filebeat和指标采集器Metricbeat，支持原生的Beats语法和配置，并自动化的安装Beats到数据源中，无需业务额外的脚本下发，并且支持界面的化的采集器管理，部署再多的CVM也可以一目了然。
灵活而便捷的链路搭建。 数据缓存和加工作为可选项，可不配置或Logstash、CKafka+Logstash、弹性Topic等多种模式，满足不同业务场景的不同需求。

相比固定单一的SaaS产品，腾讯云ES的数据链路提供的是灵活而易用的数据接入方式，业务可以根据自身特点，选择合适的组件，定义简单或多样的组件配置，并且所有组件都兼容原生产品的使用方式，让上云业务不需要改变原有的使用习惯，不需要改造原有的业务代码。

腾讯云ES上运维索引的体验

日志已经采集到ES了，可以顺利的分析和查询日志了，这篇文章按道理也应该结束了。但事实上，从我们大量的线上运营与实践经验看，运维的工作远没有结束，随着日志的不断写入，问题也随之而来，而这些问题让头发本就稀疏的程序员雪上加霜。

如何定义和创建索引？ 随着新业务的不断加入，定义和创建日志索引的工作量只增不减。万事开头难，对于新业务，怎么创建新索引，是创建普通索引还是data stream，怎么使用别名，怎么确定主分片数，索引模版和生命周期规则是复用还是新建，都是索引创建的痛点。
如何设置主分片数量，既能应对写入拒绝，又能收敛分片数？ 通常日志索引通过一个索引模版按天滚动，命名例如app-log-2022.12.01，模版中定义了一个固定的主分片数量，因此无法合理的控制每个索引大小。当遇到日志量大的日子，索引可能过大导致分片无法承载写入出现写入拒绝；遇到日志量小的日子，设置的过多分片随着时间的推移增加了ES集群管理元数据的负担。
如何防止创建索引和更新mappings任务阻塞写入？ 多个以时间命名的业务索引可能在每天的同一时间同时创建新索引，例如每天0:00或8:00，会导致这个时间点大量的分片创建任务阻塞写入任务的执行，导致写入失败甚至数据丢失。同样的，在日志字段数量较多的场景中，日志字段的频繁变更导致mappings的频繁更新，也会阻塞写入的任务。
如何提高日志写入吞吐？ 日志的写入量通常较大，因此节点规模也常常较高，但有时会发现，集群的整体资源使用率较低时却出现了写入延迟较高的情况，无法充分利用集群资源提高写入吞吐。
如何提高日志查询性能？ 以时间命名的索引在查询时往往采用通配符方式，例如GET app-log-*/_search，这种查询会遍历匹配到的所有索引的分片，极大的增加了查询延迟，在PB级以上的日志查询尤其明显。
如何应对0副本ES集群的硬件故障导致的写入失败？ 硬件的故障在所难免，ES原生通过分片副本的机制保证高可用。但日志场景往往数据量较大，从成本考虑会将索引设置为0副本，这样虽然降低了成本，但是遇到分片所在节点硬件故障时，写入会失败。

针对上面的使用和运维痛点，腾讯云ES提供了独家的索引管理解决方案——自治索引。顾名思义，自治索引是一种能够自运维的索引，在ES原生索引增删改查能力的基础上，提升了易用性和免运维能力。通过自治索引，能很好的解决上面提到的问题。

1. 如何定义和创建索引

自治索引基于ES原生的data stream方案，因此不需要考虑怎么使用别名。但是ES原生data stream的创建过程较为复杂，如下图所示，各步骤分别调用ES API并互相关联。

而在自治索引中，只需要调用一次ES API就可完成创建，API定义中支持原生的settings、mappings参数，并加入了精简的生命周期规则参数policy以及自治索引特性参数options。同时，自治并且也提供了控制台可视化的界面支持白屏化索引创建。

2. 如何设置主分片数量，既能应对写入拒绝，又能收敛分片数

运维索引最头疼的问题就是如何设置索引主分片数量，因为这个参数在创建时设置完，后续是不能修改的。主分片数设置过少，单个分片承载的写入量有限，容易出现写入拒绝；主分片数设置过多，随着时间的推移，集群的分片数越来越多，对元数据管理造成压力。

针对这个问题，自治索引基于data stream的后备索引（Baking indices）结构及自研算法实现了主分片数量的自动调优，使业务不再需要关系如何设置主分片数量的问题。

对于写入突增的场景，自治索引通过监测写入流量和拒绝指标，在发生流量突增或写入拒绝后，计算能够承载突增流量的分片数，并自动滚动出新的后备索引作为新的写入索引，过程平滑无感知，也无需人工干预。
对于写入稳定上涨的场景，自治索引会通过历史监控数据预测写入流量的趋势，提前设置合适的分片数，提前规避写入拒绝。
对于写入存在周期性波动的场景，自治索引考虑了调整的容忍比例，避免频繁的调整分片数滚动出太多的后备索引，产生调整震荡，在不出现写入拒绝的前提下保持分片数稳定。
对于写入减少的场景，自治索引会谨慎缩容索引分片数，通过更长的时间窗口观察，通过多个相邻的历史后备索引的分片数的变化趋势来判断当前是否应该缩容分片数。对于分片数规划不合理的集群，采用自治索引后，分片数由9000+持续降低到4000以内，收敛约60%+。

3. 如何防止创建索引和更新mappings任务阻塞写入

这个问题的根因在于，创建新索引或更新索引mappings的元数据更新任务，与写入任务冲突导致。

针对这个问题，在自治索引中，通过索引预创建将元数据更新任务和数据写入任务分隔开，在索引创建好之前，继续写旧索引，不阻塞写入，直到新的后备索引创建完成后，再写入新的后备索引。同时为了降低mappings更新对写入的影响，自治索引会继承历史后备索引的mappings字段，将之前动态加入的字段映射也体现在新的后备索引中，降低在新的后备索引中更新mappings的频率。

4. 如何提高日志写入吞吐

这个问题的根因在于，对于不指定路由的写入，一个bulk请求中包含的成百上千个文档，会被ES原生哈希算法均匀打到每个分片上，而这些分片又均匀分布在每个节点中，这就导致了一次bulk请求会与索引分片所在的所有节点交互，就像一面扇子一样，从扇子根部的一个点往外扩大成一个扇面，称为写入扇出。这种情况下，只要分片所在的任何一个节点存在例如硬件故障、后台任务堆积、长时间GC等情况无法及时处理写入请求，就会导致整个bulk请求都在等待这个节点处理完成，造成写入延迟和吞吐降低。

针对这个问题，在自治索引中，通过分组路由策略，将分片的写入请求分组，减少单次bulk请求涉及的分片数，降低写入扇出，减少长尾影响，使得写入TPS提升了1倍多，CPU利用率提升50%以上。

5. 如何提高日志查询性能

在查询方面，日志场景一般具有明显的冷热特点，比如保留7天的日志数据，但P90查询都集中在近12小时；并且在查询日志时一般使用索引前缀查询，比如filebeat-*，这种查询比指定索引名查询，耗时会长3倍以上。我们分析发现耗时主要集中在query阶段，由于索引前缀查询匹配的到的索引的分片数量大，遍历这些分片的网络请求总耗时很高。

为了降低这类场景的查询延迟，结合查询行为冷热明显的特点，自治索引基于时间字段进行了查询裁剪优化，在后备索引的元数据中加入索引中文档时间字段的最小值和最大值。在查询时，协调节点根据查询条件中指定的时间范围，通过后备索引元数据中记录的时间范围信息，快速跳过无关索引，降低分片发送请求的数量，并实现了在PB级日志查询性能3倍多的提升。

6. 如何应对0副本ES集群的硬件故障导致的写入失败

自治索引基于data stream后备索引的结构，在没有设置分片副本的情况下，当监测到索引分片所在的某个节点故障导致索引red或者写入异常时，自治索引会自动滚动出新的后备索引，并将写入路由到新的后备索引上，剔除异常节点的分片分布，保证新的后备索引分片都分布在正常节点，保证写入的可用性，整个过程无需人工干预，业务无感知，全部由自治索引自动完成。