前段时间写了一篇日志收集方案,Kubernetes日志收集解决方案有部分读者反馈说,都是中小企业,哪有那么多资源上ELK或者EFK,大数据这一套平台比我自身服务本身耗费资源还要多,再说了,现阶段我的业务不需要格式转换,不需要数据分析,我的日志顶多就是当线上出现问题时,把我的多个节点日志收集起来排查错误。但是在Kubernetes平台上,pod可能被调度到不可预知的机器上,如果把日志存储在当前计算节点上,难免会出现排查问题效率低下,当然我们也可以选用一些共享文件服务器,比如GFS、NFS直接把日志输出到特定日志服务器,这种情况对于单副本服务没有任何问题,但是对于多副本服务,可能会出现日志数据散乱分布问题(因为多个pod中日志输出路径和名称都是一样的),下面我介绍通过CNCF社区推荐的fluentd进行日志收集。
"本文主要讲解了fluentd的为什么选用fluentd作为核心组件,它的优势是什么"
两台服务器(注:Fluent-bit只支持centos 7以上版本,Fluentd可以支持centos 6版本),host1写日志到本地,然后通过Fluent-bit支持的forward到Fluentd,Fluentd将日志集中写入host2本地存储归档。
"本文主要对fluent-bit 1.3版本配置做详细介绍,关注后回复【pdf】获得文档"
疑问:既然应用能直接向ElasticSearch写日志,为什么我们还需要Logstash,Fluentd等日志摄取器?而且这些日志摄取器组件还成为日志收集的事实标准?
fluent-bit是一种在Linux,OSX和BSD系列操作系统运行,兼具快速、轻量级日志处理器和转发器。它非常注重性能,通过简单的途径从不同来源收集日志事件。
fluentd 作为开源的数据收集框架。C/Ruby开发,支持使用JSON文件来统一日志数据。可插拔架构,支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性,fluentd 的性能已在许多大型服务中得到检验。实际上,一个普通的 PC 机一次可以处理18,000 条消息/秒。
欢迎阅读 Logging operator 文档!Logging operator 是 Banzai Cloud One Eye for Kubernetes 可观测性工具的核心部分.
「随着 K8s 不断更新迭代,使用 K8s 日志系统建设的开发者,逐渐遇到了各种复杂的问题和挑战。本篇文章中结合作者使用经验,分析和设计 K8s 日志收集实践过程。」
"本文主要对fluent-bit 1.3版本指令做详细介绍,关注后回复【pdf】获得文档"
本文来聊聊 Docker 双栈日志,看看这个方案解决了我们实际应用中的哪些痛点,以及如何落地使用。
Ford, 云原生布道师,云原生实验室(CloudnativeLab.COM)创始人 专注于云计算领域数年,目前主要从事容器云平台的建设,推进各类基础设施服务的云原生化,乐于研发效能建设、产品驱动模式探索和敏捷高效的产品研发团队打造,ServiceMesh拥护者,持续交付、敏捷实践者。
踩入 Kubernetes 的坑以后,不可避免的就会遇到一个需求就是日志的集中采集和检索,这方面最负盛名的就是 ElasticSearch 了,这东西的强大是毋庸置疑的——又强又大。但是我多数时间跟日志打交道只会问一个问题:特定时间范围内,某应用都输出了什么日志?强大的全文检索能力,其实是很少用到的。但无论你用或者不用,索引就在那里,吃你传输和硬盘。
有时候调试fluent-bit的配置,达到想要的输出效果,并不是件简单的事情,以下通过debug镜像调试fluent-bit采集kubernetes Pod的IP。
Loki 是一个可水平伸缩的、高可用的以及多租户的日志集中系统,有这么多功能,唯独没有全文检索。在其简介中,自称是受到 Prometheus 的启发:仅保存和处理元数据,而对日志正文不闻不问。 和 EFK 类似,Loki Stack 也由采集端、服务端和交互端三个部分构成,其中采集端是可变的,目前支持 Promtail、FluentBit 和 Fluentd 三种,服务端和交互端分别使用的是 Loki 和 Grafana。
不到六个月前,CNCF 和Fluent Bit[1]社区宣布,Fluent Bit 已被下载和部署超过 10 亿次[2]。Fluent Bit 现在已经将这一成绩提高了两倍,在 10 月初突破了 30 亿大关。
关注我公众号的朋友,应该知道我写了一些云原生应用日志收集和分析相关的文章,其中内容大多聚焦某个具体的组件:
最近一直在研究Logging Operator,淌了不少坑,但也是真的香。现在总结分享给大家,关注公众号持续更新。
Logging Operator是BanzaiCloud下开源的一个云原生场景下的日志采集方案。之前小白转载过崔大佬介绍的一篇文章,不过由于之前一直认为在单个k8s集群下同时管理Fluent bit和Fluentd两个服务在架构上比较臃肿,便留下了一个不适用的初步印象。后来小白在一个在多租户场景下对k8s集群的日志管理做方案时,发现将日志配置统一管理的传统方式灵活性非常的弱。通常操作者会站在一个全局的角度,尽量的让日志的配置做成模版来适配业务,久而久之模版就变得非常庞大且臃肿,对后续维护和接任者都带来了不小挑战。
Grafna 技术栈推荐客户端,支持收集度量、日志、跟踪和持续性能分析的遥测数据,跟Prometheus、OpenTelemetry、Grafana开源生态系统完全兼容
使用flink kubernetes operator创建flink任务,将flink日志通过sidecar方式发送到es相关配置
本文主要介绍在k8s中收集应用的日志方案,应用运行中日志,一般情况下都需要收集存储到一个集中的日志管理系统中,可以方便对日志进行分析统计,监控,甚至用于机器学习,智能分析应用系统问题,及时修复应用所存在的问题。
最近看到了一份收集Kubernetes故障案例的资料,资料由ZalandoTech的高级首席工程师Henning Jacobs加以维护。这个由社区驱动的项目全面介绍了Kubernetes反模式以及为何导致Kubernetes运行错误的原因。
K8S内部署微服务后,对应的日志方案是不落地方案,即微服务的日志不挂在到本地数据卷,所有的微服务日志都采用标准输入和输出的方式(stdin/stdout/stderr)存放到管道内,容器日志采用的是json格式。
日志对于调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录,对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单,只需要将日志信息写入到 stdout 和 stderr 即可,容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中,同样也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。
hello,之前我写过《一套标准的ASP.NET Core容器化应用日志收集分析方案》,在公司团队、微信公众号、Github上反映良好。
设置正确的日志记录基础结构可帮助我们查找发生的问题、调试和监视应用程序。从最基本的角度来看,我们应该从基础架构中得到以下内容:
前面我们介绍了 Grafana Labs 推出了 Loki V2 版本,新版本提供了不少新的特性,这里我们就来介绍下如何在 Kubernetes 上使用新版本的 Loki 吧。
企业无论是已经使用了开源日志收集工具,还是准备选择一款或多款工具,都有必要了解日志收集工具的关键要求。这些要求包括:高数据吞吐量、可靠性、可扩展性、灵活性、安全性以及资源(CPU和内存)消耗等。本文讨论了市面上流行的几款日志收集工具(包括 Logstash、Fluentd、Fluent Bit 和 Vector)及其主要特点。
在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。因此,在客户端和服务端之间增加一个API网关成为多数微服务架构的必然选择。
把日志放到node节点的主机目录上,在到主机目录上配置rsyslog收集到专门的日志服务器。 从这个日志服务器启一个logstash或者filebeat写入es。 不建议直接从每个节点直接写入es。因为日志量大的时候可能es就会被弄死,另外这么多的filebeat也是要占用不少资源的。 如果觉得麻烦,就每个node写个文件监控。自动添加rsyslog的配置然后重启rsyslog。 这样可以保证日志不丢,还能有序插入es不会因为业务高峰把es弄死,还可以利用logstash再进行一些日志格式化的需求。 目前用这个方案,把istio的所有envoy访问日志、traefik、应用程序日志收集到es上稳定的很。现在每15分钟大概150万条记录。
Kubernetes已经成为编排领域事实上的标准,同时Prometheus也成为基于Kubernetes平台之上、监控领域的标配。Prometheus能够收集业务metrics数据,Grafana界面展示,AlertManager告警,一站式的监控框架就此诞生。通过这一套框架可以在线监控服务运行状态,如果不正常,能够通过各种途径通知给相关人员;相关人员通过查看告警信息,通过日志分析出现问题具体原因。
我们之前说k8s中使用deployment、statefulset工作负载资源来分别维护无状态和有状态应用。这篇小作文我们会学习如何使用DaemonSet来维护一个守护进程(应用)。
我们已经发布了v1.8.0。更新日志在这里。这个版本包含了新的服务发现插件和许多增强功能。
本文介绍了k8s官方提供的日志收集方法,并介绍了Fluentd日志收集器并与其他产品做了比较。最后介绍了好雨云帮如何对k8s进行改造并使用ZeroMQ以消息的形式将日志传输到统一的日志处理中心。 容器日志存在形式 目前容器日志有两种输出形式: stdout,stderr标准输出 这种形式的日志输出我们可以直接使用docker logs查看日志,k8s集群中同样集群可以使用kubectl logs类似的形式查看日志。 日志文件记录 这种日志输出我们无法从以上方法查看日志内容,只能tail日志文件查看。 在k
CNCF 和 Fluent Bit 社区激动地宣布,Fluent Bit[1]已经获下载和部署了超过 10 亿次[2],迅速达到了很少有软件项目能够达到的里程碑。Fluent Bit 正在帮助用户解决云原生、物联网和裸机环境中的复杂可观测性挑战,并嵌入到主要的 Kubernetes 发行版中,它已迅速成为行业标准技术——任何企业可观测性平台的核心要素。
Fluent bit是一个用C写成的插件式、轻量级、多平台开源日志收集工具。它允许从不同的源收集数据并发送到多个目的地。完全兼容docker和kubernetes生态环境。
Fluentd 典型的部署架构需要包含两种不同角色:转发器(forwarder),聚合器(aggregator)。
EFK 版本:es 7.12, fluent-bit 1.7.5, kibana 7.12
in_forward插件通常用于从其他节点接收日志事件,这些节点包括其他Fluentd实例、fluent-cat命令行或者Fluentd客户端程序。这是目前效率最高的日志事件接收方法。
td-agent 是基于 fluentd 核心功能开发,td-agent 优先考虑稳定性而不是新功能。1️⃣
前面我们介绍了 VictoriaMetrics 发布了其日志解决方案 VictoriaLogs,只是简单介绍了其特性,但是并没有介绍其使用方法,本文我们就来体验下 VictoriaLogs。
DaemonSet好比Kubernetes集群Node的守护进程,可以保证在每个Node上(或者一部分Node上)都运行同一个Pod。 目前我们的线上环境主要用到以下两个DaemonSet:
最近群里有小伙伴有说到自己的日志存储路径先是从客户端到Kafka,再通过消费kafka到ElasticSearch。现在要将ES换成Loki面临需要同时支持Kafka和Loki插件的工具。小白查了下当前市面上满足需求且足够可靠的工具分别为Fluentd、Logstash以及Vector。
它支持从不同的数据源采集日志和系统指标, 并使用过滤器修改这些数据,然后将其发送到多个目的地.
众所周知,对于一个云原生 PaaS 平台而言,在页面上查看日志与指标是最为基础的功能。无论是日志、指标还是链路追踪,基本都分为采集、存储和展示 3 个模块。
Loki是grafana团队开发一个日志采集工具。推荐使用helm方式安装loki,官方推荐的tanka需要使用aws的s3服务。安装helm后直接运行如下命令即可在loki命名空间中部署最简单的loki套件。
Fluentd是一个开源数据收集器,旨在统一日志记录基础架构。它旨在通过简化和扩展日志来收集和存储日志,从而将运营工程师,应用工程师和数据工程师聚集在一起。
领取专属 10元无门槛券
手把手带您无忧上云