公司网站建设ihanshi,南通企业网站排名,凡科网站代理登录入口,开发微信小程序流程EFK方案
从ELK谈起
ELK是三个开源软件的缩写#xff0c;分别表示#xff1a;Elasticsearch#xff0c;Logstash#xff0c;Kibana。新增了一个FlieBeat#xff0c;它是一个轻量级的日志收集处理工具#xff0c;FlieBeat占用资源少#xff0c;适用于在各个服务器上搜集…EFK方案
从ELK谈起
ELK是三个开源软件的缩写分别表示ElasticsearchLogstashKibana。新增了一个FlieBeat它是一个轻量级的日志收集处理工具FlieBeat占用资源少适用于在各个服务器上搜集日之后传输给Logstash。 Elasticsearch开源分布式搜索引擎提供搜集分析缓存数据三大功能它的特点有分布式零配置自动发现索引自动分片索引副本机制restful风格接口多数据源自动搜索负 载等。 Logstash 主要是用来日志的搜集、分析、过滤日志的工具支持大量的数据获取方式。一般工作方式为c/s架构 client 端安装在需要收集日志的主机上 server 端负责将收到的各节点日志进行过 滤、修改等操作在一并发往 elasticsearch 上去。 Kibana 也是一个开源和免费的工具 Kibana 可以为 Logstash 和 ElasticSearch 提供的日志分析友 好的 Web 界面可以帮助汇总、分析和搜索重要数据日志。
从ELK挑战到EFK日志方案
ELK挑战
日志流量的增长导致了平台部署规模巨大用户需求也发生了显著变化。两者都给基于 ELK 的平台带来了许多挑战而这些挑战在较小的规模下是看不到的
日志模式我们的日志是半结构化的。ESElasticsearch会自动推导模式在整个集群中保持一致并在后续日志中强制执行。如果字段类型不兼容将导致 ES 出现类型冲突错误从而丢弃违规日志。尽管对具有明确定义结构的业务事件实施一致的模式是合理的但是对日志记录而言这将导致开发人员的生产力大大下降因为日志模式会随着时间的推移有机地演化。举例来说一个大型的 API 平台可能会有数百名工程师进行更新在 ES 索引映射中累积了数千个字段而且不同的工程师很可能使用相同的字段名但是不同的字段值是不同的类型从而导致 ES 的类型冲突。这会迫使工程师学习已有的模式并保持它们的一致性仅仅打印一些服务日志效率很低。理想情况下平台应该将模式更改作为一个规范并且能够为用户处理多种类型的字段。运营成本如果一个集群受到大量查询或映射爆炸的不利影响我们必须在每个区域运行 20 多个 ES 集群以限制爆炸半径。Logstash 管道的数量更多每个区域有 50 多个以适应特殊用例和自定义配置。昂贵的查询和映射爆炸都会严重影响 ES 集群的性能有时甚至会“冻结”集群这时我们不得不重新启动集群使其恢复。随着集群数量的增加这种中断越来越频繁。虽然我们竭尽全力实现流程自动化例如检测并禁用会引起映射爆炸和类型冲突的字段重新平衡 ES 集群之间的流量等等但是人工干预解决类型冲突等仍是不可避免的。我们想要一个能够支持我们组织中大量新用例的平台而不必承担大量的运营开销。硬件成本在 ES 中索引字段的成本相当高因为它需要建立和维护复杂的倒排索引和正排索引结构并将其写入事务日志周期性地将内存缓冲区刷新到磁盘上并定期进行后台合并以保持刷新索引段的数量不至于无限制地增长这些都需要大量的处理能力并且会增加日志成为可查询的延迟。因此我们的 ES 集群没有对日志中的所有字段进行索引而是配置为索引多达三个级别的字段。但是摄取所有生成的日志仍然会消耗大量的硬件资源并且扩展成本太高。聚合查询在我们的生产环境中发现80% 以上的查询都是聚合查询比如术语、直方图和百分数聚合。虽然 ES 在优化前向索引结构方面有所改进但其设计仍然不能支持跨大型数据集的快速聚合。低效的性能会导致不愉快的用户体验。举例来说在查询最后 1 小时的日志大约 1.3 TB时一个日志数量巨大的服务的关键仪表盘加载速度非常缓慢而且在查询最后 6 小时的日志时常常出现超时从而导致无法诊断产品问题。 我们只能在一个基于 ELK 的平台上摄取 Uber 内部生成的部分日志。在 ELK 平台基础上的大规模部署和许多固有的低效使扩展以摄取所有日志并提供完整的、高分辨率的产品环境概述的成本高得令人望而却步。
EFK方案
由于 logstash 内存占用较大灵活性相对没那么好 ELK 正在被 EFK 逐步替代 . 其中本文所讲的 EFK 是 ElasticsearchFluentdKfka。 Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch 、 Fluentd 和 Kibana EFK 技术栈也是官方现在比较推荐的一种方案。 Fluentd 是一个收集日志文件的开源软件目前提供数百个插件可用于存储大数据用于日志搜索数据分析和存储。 Fluentd适用于以下场景。 收集多台服务器的访问日志进行可视化 在AWS 等云端使用 AutoScaling 时把日志文件收集至 S3( 需要安装插件 ) 收集客户端的信息并输出至Message Queue 供其他应用处理 第一层数据采集层数据采集层位于最左边的业务服务器集群上在每个业务服务器上面安装了 Filebeat 做日志收集然后把采集到的原始日志发送到 KafkaZooKeeper 集群上。 第二层消息队列层原始日志发送到 KafkaZooKeeper 集群上后会进行集中存储此时Filbeat 是消息的生产者存储的消息可以随时被消费。 第三层数据分析层Logstash 作为消费者会去 KafkaZooKeeper 集群节点实时拉取原始日志然后将获取到的原始日志根据规则进行分析、清洗、过滤最后将清洗好的日志转发至 Elasticsearch 集群中。 第四层数据持久化存储Elasticsearch 集群在接收到 Logstash 发送过来的数据后执行写磁盘、建索引库等操作最后将结构化的数据存储到 Elasticsearch 集群上。 第五层数据查询、展示层Kibana 是一个可视化的数据展示平台当有数据检索请求时它从 Elasticsearch 集群上读取数据然后进行可视化出图和多维度分析。 ClickHouse方案
ClickHouse 是一款常用于大数据分析的 DBMS因为其压缩存储高性能丰富的函数等特性近期有很多尝试 ClickHouse 做日志系统的案例。本文将分享如何用 ClickHouse 做出通用日志系统。 可以解决的问题 大数据量。对开发者来说日志最方便的观测手段而且很多情况下会直接打印 HTTP、RPC 的请求响应日志这基本上就是把网络流量复制了一份。 非固定检索模式。用户有可能使用日志中的任意关键字任意字段来查询。 成本要低。日志系统不宜在 IT 成本中占比过高。 即席查询。日志对时效性要求普遍较高。 数据量大检索模式不固定既要快还得便宜。所以日志是一道难解的题它的需求几乎违反了计算机的基本原则不过幸好它还留了一扇窗就是对并发要求不高。大部分查询是人为即兴的即使做一些定时查询所检索的范围也一定有限。 Fluent bit目前社区日志采集和处理的组件不少之前elk方案中的logstashcncf社区中的fluentdefk方案中的filebeat,以及大数据用到比较多的flume。而Fluent Bit是一款用c语言编写的高性能的日志收集组件整个架构源于fluentd。官方比较数据如下 日志系统主要分为四个部分日志采集、日志传输、日志存储、日志管理。 ● 日志采集LogCollector 采用 Daemonset 方式部署将宿主机日志目录挂载到 LogCollector 的容器内LogCollector 通过挂载的目录能够采集到应用日志、系统日志、K8S 审计日志等 ● 日志传输通过不同 Logstore 映射到 Kafka 中不同的 Topic将不同数据结构的日志做了分离 ● 日志存储使用 Clickhouse 中的两种引擎数据表和物化视图 ● 日志管理开源的 ClickVisual 系统能够查询日志设置日志索引设置 LogCollector 配置设置 Clickhouse 表设置报警等
B站架构 如图所示为日志实时上报和使用的全链路。使用ClickHouse作为存储实现了自研的日志可视化分析平台并使用OpenTelemetry作为统一日志上报协议。日志从产生到消费会经过采集→摄入 →存储 →分析四个步骤分别对应我们在链路上的各个组件先做个简单的介绍 ● OTEL Logging SDK完整实现OTEL Logging日志模型规范和协议的结构化日志高性能SDK提供了Golang和Java两个主要语言实现。 ● Log-Agent 日志采集器以Agent部署方式部署在物理机上通过Domain Socket接收OTEL协议日志同时进行低延迟文件日志采集包括容器环境下的采集。支持多种Format和一定的加工能力如解析和切分等。 ● Log-Ingester 负责从日志 kafka 订阅日志数据 然后将日志数据按时间维度和元数据维度(如AppID) 拆分并进行多队列聚合, 分别攒批写入ClickHouse中. ● ClickHouse 我们使用的日志存储方案在ClickHouse高压缩率列式存储的基础上配合隐式列实现了动态Schema以获得更强大的查询性能在结构化日志场景如猛虎添翼。 ● Log-Query 日志查询模块负责对日志查询进行路由、负载均衡、缓存和限流以及提供查询语法简化。 ● BLS-Discovery 新一代日志的可视化分析平台提供一站式的日志检索、查询和分析追求日志场景的高易用性让每个研发0学习成本无障碍使用。
结合湖仓一体
在湖仓一体日益成熟的背景下日志入湖会带来以下收益 ● 部分日志有着三年以上的存储时间要求比如合规要求的审计日志关键业务日志等数据湖的低成本存储特性是这个场景的不二之选。 ● 现在日志除了用来进行研发排障外也有大量的业务价值蕴含其中。日志入湖后可以结合湖上的生态体系快速结合如机器学习、BI分析、报表等功能将日志的价值发挥到最大。 此外我们长远期探索减少日志上报的中间环节如从agent直接到ClickHouse去掉中间的Kafka以及更深度的结合ClickHouse和湖仓一体打通ClickHouse和iceberg。
Kubesphere方案
在 KubeSphere 中选择 Elasticsearch 作为日志后端服务使用 Fluent Bit 作为日志采集器KubeSphere 日志控制台通过 FluentBit Operator 控制 FluentBit CRD 中的 Fluent Bit 配置。用户也可以通过 kubectl edit fluentbit fluent-bit 以 kubernetes 原生的方式来更改 FluentBit 的配置 通过 FluentBit OperatorKubeSphere 实现了通过控制台灵活的添加/删除/暂停/配置日志接收者。
