如果你的应用运行在分布式架构上，你很可能会使用集中式日志系统来收集它们的日志，其中我们使用比较广泛的一个工具就是 fluentd，包括在容器化时代用来收集 Kubernetes 集群应用日志 fluentd 也是使用非常多的。我们将解释它是如何工作的，以及如何根据需求来调整配置 fluentd。
大部分 Kubernetes 应用，我们都会将不同类型的日志记录到 stdout 中，比如在《Fluentd 简明教程》中提到的应用日志和访问日志，这两者都是非常重要的信息，因为他们的日志格式不一样，所以我们需要对他们分别进行解析，这就需要我们使用到 Fluentd 的一些插件来配合。本文我们将介绍如何将这些日志拆分为并行的日志流，以便可以进一步处理它们。
前段时间写了一篇日志收集方案，Kubernetes日志收集解决方案有部分读者反馈说，都是中小企业，哪有那么多资源上ELK或者EFK，大数据这一套平台比我自身服务本身耗费资源还要多，再说了，现阶段我的业务不需要格式转换，不需要数据分析，我的日志顶多就是当线上出现问题时，把我的多个节点日志收集起来排查错误。但是在Kubernetes平台上，pod可能被调度到不可预知的机器上，如果把日志存储在当前计算节点上，难免会出现排查问题效率低下，当然我们也可以选用一些共享文件服务器，比如GFS、NFS直接把日志输出到特定日志服务器，这种情况对于单副本服务没有任何问题，但是对于多副本服务，可能会出现日志数据散乱分布问题（因为多个pod中日志输出路径和名称都是一样的），下面我介绍通过CNCF社区推荐的fluentd进行日志收集。
EFK（ElasticSearch、Fluentd、Kibana）是常见的分布式系统日志收集方案，es 用于存储数据，kibana 用于展示数据，支持各种搜索及维度聚合。fluentd 为日志收集工具，支持从各个数据源收集数据，对数据进行过滤、解析、转换、结构化后，写入 es。
日志对于调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录，对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单，只需要将日志信息写入到 stdout 和 stderr 即可，容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中，同样也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。
Kubernetes 集群中会编排非常多的服务，各个服务不可能保证服务一定能稳定的运行，于是每个服务都会打印出各自的日志信息方便调试。由于服务的众多，每个服务挨个查看日志显然是一件非常复杂的事情，故而日志的统一收集、整理显得尤为重要。
上节课和大家介绍了 Kubernetes 集群中的几种日志收集方案，Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案。
以往有篇文章介绍 EFK（Kibana + ElasticSearch + Filebeat）的插件日志收集。Filebeat 插件用于转发和集中日志数据，并将它们转发到 Elasticsearch 或 Logstash 以进行索引，但 Filebeat 作为 Elastic 的一员，只能在 Elastic 整个体系中使用。
Elasticsearch 是一个实时的、分布式的可扩展的搜索引擎，允许进行全文、结构化搜索，它通常用于索引和搜索大量日志数据，也可用于搜索许多不同类型的文档。
Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案。
关于日志收集、处理、分析的方案，其实是很多，常见的就是ELK组合，即：Elasticsearch + Logstash + Kibana，官方网站：https://www.elastic.co/products
前面大家介绍了 Kubernetes 集群中的几种日志收集方案，Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案。
它允许fluentd从文本文件尾部读取日志事件，其行为类似linux的tail -F命令（按文件名来tail）。
ELK（Elasticsearch、Logstash、Kibana）是一个流行的日志管理解决方案，可以在Kubernetes中进行日志管理。下面是在Kubernetes中使用ELK组件进行日志管理的步骤：
fluentd 是一个实时的数据收集系统，不仅可以收集日志，还可以收集定期执行的命令输出和 HTTP 请求内容。数据被收集后按照用户配置的解析规则，形成一系列 event。每一个 event 包含如下内容：
本文承接上文，主要讲解Logging Operator中除logging外的CRD应用。在开始之前，我们还是先看下Logging Operator对K8S中处理容器日志流向的逻辑图。
它支持从不同的数据源采集日志和系统指标, 并使用过滤器修改这些数据，然后将其发送到多个目的地.
in_forward插件通常用于从其他节点接收日志事件，这些节点包括其他Fluentd实例、fluent-cat命令行或者Fluentd客户端程序。这是目前效率最高的日志事件接收方法。
企业无论是已经使用了开源日志收集工具，还是准备选择一款或多款工具，都有必要了解日志收集工具的关键要求。这些要求包括：高数据吞吐量、可靠性、可扩展性、灵活性、安全性以及资源（CPU和内存）消耗等。本文讨论了市面上流行的几款日志收集工具（包括 Logstash、Fluentd、Fluent Bit 和 Vector）及其主要特点。
在微服务架构中，日志是一个不得不面临与需要解决的点。因为微服务架构中，服务是分散在不同的节点或虚拟机上运行，这意味着服务产生的日志也是分散的，所以收集分散的日志就成为了微服务中的一个痛点。否则有需要时查询起日志来就非常麻烦与不方便。
Fluentd是一个开源数据收集器，旨在统一日志记录基础架构。它旨在通过简化和扩展日志来收集和存储日志，从而将运营工程师，应用工程师和数据工程师聚集在一起。
告警是预防系统故障的一个重要工具，目前已经有许多成熟的方案通过监控系统运行指标来进行阈值预警。
1. 前 言 本文在书写过程中，咨询了红帽技术专家郭跃军、李春霖、张亚光，并借鉴了他们提供的技术文档，在此表示感谢！ 此外，在书写过程中，笔者也借鉴了红帽官方技术文档以及互联网上的一些信
我们已经发布了v1.8.0。更新日志在这里。这个版本包含了新的服务发现插件和许多增强功能。
本文来聊聊 Docker 双栈日志，看看这个方案解决了我们实际应用中的哪些痛点，以及如何落地使用。
https://epsagon.com/blog/cncf-tools-overview-fluentd-unified-logging-layer/
Logging Operator是BanzaiCloud下开源的一个云原生场景下的日志采集方案。之前小白转载过崔大佬介绍的一篇文章，不过由于之前一直认为在单个k8s集群下同时管理Fluent bit和Fluentd两个服务在架构上比较臃肿，便留下了一个不适用的初步印象。后来小白在一个在多租户场景下对k8s集群的日志管理做方案时，发现将日志配置统一管理的传统方式灵活性非常的弱。通常操作者会站在一个全局的角度，尽量的让日志的配置做成模版来适配业务，久而久之模版就变得非常庞大且臃肿，对后续维护和接任者都带来了不小挑战。
最近一直在研究Logging Operator，淌了不少坑，但也是真的香。现在总结分享给大家，关注公众号持续更新。
通过应用和系统日志可以了解Kubernetes集群内所发生的事情，对于调试问题和监视集群活动来说日志非常有用。对于大部分的应用来说，都会具有某种日志机制。因此，大多数容器引擎同样被设计成支持某种日志机制。对于容器化应用程序来说，最简单和最易接受的日志记录方法是将日志内容写入到标准输出和标准错误流。 但是，容器引擎或运行时提供的本地功能通常不足以支撑完整的日志记录解决方案。例如，如果一个容器崩溃、一个Pod被驱逐、或者一个Node死亡，应用相关者可能仍然需要访问应用程序的日志。因此，日志应该具有独立于Node、Pod或者容器的单独存储和生命周期，这个概念被称为群集级日志记录。群集级日志记录需要一个独立的后端来存储、分析和查询日志。Kubernetes本身并没有为日志数据提供原生的存储解决方案，但可以将许多现有的日志记录解决方案集成到Kubernetes集群中。在Kubernetes中，有三个层次的日志：
当您将Docker容器转移到生产环境中时，您会发现经常需要将日志保留在容器外的地方。Docker提供了一个本机日志驱动程序，可以很容易地收集这些日志并将它们发送到其他地方，例如Elasticsearch和Fluentd。Elasticsearch是是目前全文搜索引擎的首选。它可以快速地储存、搜索和分析海量数据。维基百科、Stack Overflow、Github 都采用它。这样您就可以分析数据了。Fluentd是一个开源数据收集器，旨在统一您的日志记录基础架构。它将操作工程师，应用工程师和数据工程师结合在一起，使其简单且可扩展，以收集和存储日志。
多行日志（例如异常信息）为调试应用问题提供了许多非常有价值的信息，在分布式微服务流行的今天基本上都会统一将日志进行收集，比如常见的 ELK、EFK 等方案，但是这些方案如果没有适当的配置，它们是不会将多行日志看成一个整体的，而是每一行都看成独立的一行日志进行处理，这对我们来说是难以接受的。
我们知道，Fluentd是一个通用的日志采集框架，一个很重要的原因就在于它可以处理各种各样的源数据。
最近群里有小伙伴有说到自己的日志存储路径先是从客户端到Kafka，再通过消费kafka到ElasticSearch。现在要将ES换成Loki面临需要同时支持Kafka和Loki插件的工具。小白查了下当前市面上满足需求且足够可靠的工具分别为Fluentd、Logstash以及Vector。
http://tonybai.com/2017/03/03/implement-kubernetes-cluster-level-logging-with-fluentd-and-elasticsearch-stack/
Logstash logstash基于JRuby实现，可以跨平台运行在JVM上 优点 主要的优点就是它的灵活性，这还主要因为它有很多插件。然后它清楚的文档已经直白的配置格式让它可以再多种场景下应用。
运行上述镜像，在对于的容器进程目录下可以看到该进程打开个4个文件，其中fd为10的即是运行的shell 脚本，
引言 自从2018年从Cloud Native Computing Foundation（CNCF）出现以来，您可能已经在使用K8操作系统，随着容器云技术的发展以及落地，提高了企业运维的效率和质量，并且降低了企业运营成本，但同时带来的问题是运维的复杂度和难度，举个例子🌰：由于容器的生命周期短，随时可能飘移到其他物理资源上运行，因此日志的采集和运行的监控很难像传统方式登录到服务器上查看，而运营团队需要了解有价值的数据来进行问题定位以及运营数据分析。 为了更广泛地提供这种可观察性，我们需要提
in_http插件允许使用HTTP协议来采集日志事件。这个插件会建立一个支持REST风格的HTTP端点，来接收日志事件请求。
前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。 面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机的应用日志、系统服务日志如何采用同一套方案快速、完整的收集和检索？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？本文主要从以下几个方面来分享下笔者在日志监控方面的一些经验。 目录 一、DevOps浪潮下带来的监控挑
理解OpenShift（5）：从 Docker Volume 到 OpenShift Persistent Volume
Kubernetes在容器编排市场中占主导地位，通常用于托管微服务。但是，微服务的每个实例都会生成大量日志事件，这些日志事件很快就会变得难以管理。更糟糕的是，当出现问题时，由于服务间的复杂交互以及不可预知的故障模式，很难找到根本原因。
Kubernetes 主导着容器编排市场，推动企业向微服务演进。微服务的每个实例都会生成大量日志事件，这些事件很快就会变得难以管理。但更复杂的是，当问题发生时，服务和故障模式之间的复杂交互使得很难找到根本原因。潜在的问题使 Kubernetes 日志管理工具变得非常重要。
https://devopscube.com/kubernetes-logging-tutorial/
日志收集方案是采用 Elasticsearch、Fluentd、Filebeat 和 Kibana（EFK）技术栈。 Fluented主要用来收集k8s组件和docker容器日志，Filebeat主要用来收集应用日志，主要因为目前项目中应用日志并未全部通过stdout方式输出到docker日志驱动中，导致flunted收集日志并不全面，需要通过Filebeat来将应用日志收集到es中，再由kibana来展示。
中心化的日志处理方案有效地解决了在完整生命周期内对日志的消费需求，而日志从设备采集上云是始于足下的第一步。
Kubernetes在容器编排市场中占主导地位，推动企业向微服务演进。微服务的每个实例都会生成大量日志事件，这些事件很快就变得难以管理。但更复杂的是当出现问题时，由于服务之间复杂的交互作用，以及可能的故障模式，导致很难找到根本原因。潜在的问题使得Kubernetes日志管理工具变得十分重要。
关注我公众号的朋友，应该知道我写了一些云原生应用日志收集和分析相关的文章，其中内容大多聚焦某个具体的组件：
随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
