日志与可视化方案:从ELK到EFK,再到ClickHouse

这篇具有很好参考价值的文章主要介绍了日志与可视化方案:从ELK到EFK,再到ClickHouse。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

EFK方案

从ELK谈起

ELK是三个开源软件的缩写,分别表示:Elasticsearch,Logstash,Kibana。新增了一个FlieBeat,它是一个轻量级的日志收集处理工具,FlieBeat占用资源少,适用于在各个服务器上搜集日之后,传输给Logstash。
Elasticsearch:开源分布式搜索引擎,提供搜集,分析,缓存数据三大功能,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负 载等。
Logstash 主要是用来日志的搜集、分析、过滤日志的工具,支持大量的数据获取方式。一般工作方式为c/s架构, client 端安装在需要收集日志的主机上, server 端负责将收到的各节点日志进行过
滤、修改等操作在一并发往 elasticsearch 上去。
Kibana 也是一个开源和免费的工具, Kibana 可以为 Logstash 和 ElasticSearch 提供的日志分析友
好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。

从ELK挑战到EFK日志方案

ELK挑战

日志流量的增长导致了平台部署规模巨大,用户需求也发生了显著变化。两者都给基于 ELK 的平台带来了许多挑战,而这些挑战在较小的规模下是看不到的:

  1. 日志模式:我们的日志是半结构化的。ES(Elasticsearch)会自动推导模式,在整个集群中保持一致,并在后续日志中强制执行。如果字段类型不兼容,将导致 ES 出现类型冲突错误,从而丢弃违规日志。尽管对具有明确定义结构的业务事件实施一致的模式是合理的,但是对日志记录而言,这将导致开发人员的生产力大大下降,因为日志模式会随着时间的推移有机地演化。举例来说,一个大型的 API 平台可能会有数百名工程师进行更新,在 ES 索引映射中累积了数千个字段,而且不同的工程师很可能使用相同的字段名,但是不同的字段值是不同的类型,从而导致 ES 的类型冲突。这会迫使工程师学习已有的模式,并保持它们的一致性,仅仅打印一些服务日志,效率很低。理想情况下,平台应该将模式更改作为一个规范,并且能够为用户处理多种类型的字段。
  2. 运营成本:如果一个集群受到大量查询或映射爆炸的不利影响,我们必须在每个区域运行 20 多个 ES 集群,以限制爆炸半径。Logstash 管道的数量更多,每个区域有 50 多个,以适应特殊用例和自定义配置。昂贵的查询和映射爆炸都会严重影响 ES 集群的性能,有时甚至会“冻结”集群,这时我们不得不重新启动集群使其恢复。随着集群数量的增加,这种中断越来越频繁。虽然我们竭尽全力实现流程自动化,例如检测并禁用会引起映射爆炸和类型冲突的字段,重新平衡 ES 集群之间的流量等等,但是人工干预解决类型冲突等仍是不可避免的。我们想要一个能够支持我们组织中大量新用例的平台,而不必承担大量的运营开销。
  3. 硬件成本:在 ES 中,索引字段的成本相当高,因为它需要建立和维护复杂的倒排索引和正排索引结构,并将其写入事务日志,周期性地将内存缓冲区刷新到磁盘上,并定期进行后台合并,以保持刷新索引段的数量不至于无限制地增长,这些都需要大量的处理能力,并且会增加日志成为可查询的延迟。因此,我们的 ES 集群没有对日志中的所有字段进行索引,而是配置为索引多达三个级别的字段。但是摄取所有生成的日志仍然会消耗大量的硬件资源,并且扩展成本太高。
  4. 聚合查询:在我们的生产环境中发现,80% 以上的查询都是聚合查询,比如术语、直方图和百分数聚合。虽然 ES 在优化前向索引结构方面有所改进,但其设计仍然不能支持跨大型数据集的快速聚合。低效的性能会导致不愉快的用户体验。举例来说,在查询最后 1 小时的日志(大约 1.3 TB)时,一个日志数量巨大的服务的关键仪表盘加载速度非常缓慢,而且在查询最后 6 小时的日志时常常出现超时,从而导致无法诊断产品问题。
    我们只能在一个基于 ELK 的平台上摄取 Uber 内部生成的部分日志。在 ELK 平台基础上的大规模部署和许多固有的低效,使扩展以摄取所有日志并提供完整的、高分辨率的产品环境概述的成本高得令人望而却步。

EFK方案

由于 logstash 内存占用较大,灵活性相对没那么好, ELK 正在被 EFK 逐步替代 . 其中本文所讲的 EFK 是 Elasticsearch+Fluentd+Kfka。
Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch 、 Fluentd 和 Kibana ( EFK) 技术栈,也是官方现在比较推荐的一种方案。
Fluentd 是一个收集日志文件的开源软件,目前提供数百个插件可用于存储大数据用于日志搜索,数据分析和存储。
Fluentd适用于以下场景。
收集多台服务器的访问日志进行可视化
在AWS 等云端使用 AutoScaling 时把日志文件收集至 S3( 需要安装插件 )
收集客户端的信息并输出至Message Queue ,供其他应用处理
elk clickhouse,云原生,elk,clickhouse,elasticsearch
第一层,数据采集层:数据采集层位于最左边的业务服务器集群上,在每个业务服务器上面安装了 Filebeat 做日志收集,然后把采集到的原始日志发送到 Kafka+ZooKeeper 集群上。
第二层,消息队列层:原始日志发送到 Kafka+ZooKeeper 集群上后,会进行集中存储,此时,Filbeat 是消息的生产者,存储的消息可以随时被消费。
第三层,数据分析层:Logstash 作为消费者,会去 Kafka+ZooKeeper 集群节点实时拉取原始日志,然后将获取到的原始日志根据规则进行分析、清洗、过滤,最后将清洗好的日志转发至 Elasticsearch 集群中。
第四层,数据持久化存储:Elasticsearch 集群在接收到 Logstash 发送过来的数据后,执行写磁盘、建索引库等操作,最后将结构化的数据存储到 Elasticsearch 集群上。
第五层,数据查询、展示层:Kibana 是一个可视化的数据展示平台,当有数据检索请求时,它从 Elasticsearch 集群上读取数据,然后进行可视化出图和多维度分析。

elk clickhouse,云原生,elk,clickhouse,elasticsearch

ClickHouse方案

ClickHouse 是一款常用于大数据分析的 DBMS,因为其压缩存储,高性能,丰富的函数等特性,近期有很多尝试 ClickHouse 做日志系统的案例。本文将分享如何用 ClickHouse 做出通用日志系统。
可以解决的问题:
大数据量。对开发者来说日志最方便的观测手段,而且很多情况下会直接打印 HTTP、RPC 的请求响应日志,这基本上就是把网络流量复制了一份。
非固定检索模式。用户有可能使用日志中的任意关键字任意字段来查询。
成本要低。日志系统不宜在 IT 成本中占比过高。
即席查询。日志对时效性要求普遍较高。
数据量大,检索模式不固定,既要快,还得便宜。所以日志是一道难解的题,它的需求几乎违反了计算机的基本原则,不过幸好它还留了一扇窗,就是对并发要求不高。大部分查询是人为即兴的,即使做一些定时查询,所检索的范围也一定有限。

elk clickhouse,云原生,elk,clickhouse,elasticsearch
elk clickhouse,云原生,elk,clickhouse,elasticsearch
Fluent bit:目前社区日志采集和处理的组件不少,之前elk方案中的logstash,cncf社区中的fluentd,efk方案中的filebeat,以及大数据用到比较多的flume。而Fluent Bit是一款用c语言编写的高性能的日志收集组件,整个架构源于fluentd。官方比较数据如下:
日志系统主要分为四个部分:日志采集、日志传输、日志存储、日志管理。
● 日志采集:LogCollector 采用 Daemonset 方式部署,将宿主机日志目录挂载到 LogCollector 的容器内,LogCollector 通过挂载的目录能够采集到应用日志、系统日志、K8S 审计日志等
● 日志传输:通过不同 Logstore 映射到 Kafka 中不同的 Topic,将不同数据结构的日志做了分离
● 日志存储:使用 Clickhouse 中的两种引擎数据表和物化视图
● 日志管理:开源的 ClickVisual 系统,能够查询日志,设置日志索引,设置 LogCollector 配置,设置 Clickhouse 表,设置报警等

B站架构

elk clickhouse,云原生,elk,clickhouse,elasticsearch
如图所示为日志实时上报和使用的全链路。使用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 Operator,KubeSphere 实现了通过控制台灵活的添加/删除/暂停/配置日志接收者。
elk clickhouse,云原生,elk,clickhouse,elasticsearch文章来源地址https://www.toymoban.com/news/detail-781145.html

到了这里,关于日志与可视化方案:从ELK到EFK,再到ClickHouse的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • logstack 日志技术栈-01-ELK/EFK 入门介绍 ELK+filebeta

    ​在Kubernetes集群上运行多个服务和应用程序时,日志收集系统可以帮助你快速分类和分析由Pod生成的大量日志数据。 Kubernetes中比较流行的日志收集解决方案是Elasticsearch、Fluentd和Kibana(EFK)技术栈,也是官方推荐的一种方案。 1)Elasticsearch:是一个实时的,分布式的,可扩

    2024年01月21日
    浏览(58)
  • 电教智能云数据可视化平台开发电能优化日志实录

    在 PHP 中, @ 符号被称为错误抑制操作符。当在表达式之前使用 @ 符号时,它会告诉 PHP 忽略该表达式可能产生的任何错误或警告消息。 使用 @ 符号的主要目的是在运行时隐藏错误消息,以防止它们显示在最终的用户界面上。然而,过度使用错误抑制符可能会导致问题的隐藏

    2024年02月14日
    浏览(52)
  • ElasticSearch+Kibana+Logstash实现日志可视化运维监控

    1.目标 1.安装ElasticSearch 2.安装Kibana 3.安装Logstash采集/var/log/messages日志内容 4.图表化展示日志监控结果 2.版本 这三者的版本号要完全一样 ElasticSearch 6.1.1 Kibana 6.1.1 Logstash 6.1.1 Jdk1.8.0_181 3.安装ElasticSearch 安装包:https://cloud.189.cn/t/zuQz6v2YZRVb (访问码:6sbf) 下载网站:https://www.elast

    2024年02月10日
    浏览(54)
  • 基于Elasticsearch+Logstash+Kibana+Filebeat的日志收集分析及可视化

    sudo rm /var/lib/dpkg/lock* sudo dpkg --configure -a apt update tail -f /var/log/car.log 海量的业务应用,也带来了海量的日志数据,给业务应用的运维带来了新的挑战。例如,我们常用的网约车应用,单个平台的日订单数量可以达到上亿条,产生各种类型的日志数据,像用户业务方面会产生交

    2024年01月21日
    浏览(53)
  • ELK(Elasticsearch、Kibana、Logstash)以及向ES导入mysql数据库数据或CSV文件数据,创建索引和可视化数据

    地址:Past Releases of Elastic Stack Software | Elastic 在Products和version处分别选择需要下载的产品和版本,E(elasticsearch)L(logstash)K(kibana)三者版本必须相同 将下载好的elk分别解压到相同路径下 本文中elasticsearch=E=ES=es;L=logstash;K=kibana 一般情况下使用默认配置即可,下面对我的

    2024年02月15日
    浏览(53)
  • 【前端可视化】前端大屏适配方案

    动态设置 html 根字体的大小和 body 字体大小(使用 lib_flexible.js) 将设计稿的宽(1920)平均分成 24 等份,每一份 80px; html 根字体大小就设置为 80px,即 1rem = 80px,24rem = 1920px(移动端推荐分为 10 份); 将 body 字体大小设置为 16px; 最后需要使用插件或者其他方式将 px 转为 rem 单位:

    2024年02月11日
    浏览(43)
  • 【tensorboard】深度学习的日志信息events.out.tfevents文件可视化工具

    在用深度学习模型训练完模型后,会有一些events.out.tfevents格式的日志信息文件,如下图: 在这类文件需要用tensorboard进行打开,并且查看训练过程的信息内容。 命令格式为: 注意:日志所在的目录是指日志的目录文件夹,不是日志本身路径。 以上面图片中为例,命令为:

    2024年02月12日
    浏览(46)
  • vue大屏可视化自适应完美方案

    在做大屏可视化项目的时候,一般设计稿会设计成1920*1080,但是页面写死1920*1080在2k、4k等分辨率的屏幕下是不适配的。如果页面能够根据屏幕比例进行等比缩放那就好了。 什么?不知道屏幕比例?其实我们常见的1920*1080(1080P)、2k、4k...都是16:9的比例,在做项目之前我们

    2024年02月12日
    浏览(50)
  • 可视化大屏的几种适配方案

    对于可视化大屏项目而言,我们主要需要考虑下面两个问题:         首先是div元素的适配,需要保持每个div元素在不同分辨率的屏幕下依然会显示正常的比例,不会因为不同分辨率的屏幕而变得拉伸变形;         第二个要考虑的因素是字体,通常情况下我们会吧字体设

    2023年04月08日
    浏览(56)
  • pytorch对中间特征层可视化方案

    本文主要介绍如何使用pytorch获得已经训练好的网络的中间特征层,并将其转化为热力图的简单方法 效果图 1、在原本的test代码上进行修改 2、随便写一个钩子函数(具体了解可以搜索“pytorch中的钩子(Hook)有何作用?”) 3、然后注册一下钩子函数(在你需要保存的卷积层进行

    2024年02月13日
    浏览(63)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包