Elastic 中国社区官方博客

ETW是一种轻量级、高性能的 Windows 原生机制，用于记录有关系统性能和活动（）的详细事件数据。与传统的 Windows 事件日志不同，ETW 使用户能够收集低级遥测数据，这些遥测数据可针对不同的提供商和场景进行定制，包括系统性能洞察和特定于应用程序的诊断。提供商订阅：Filebeat 根据用户配置发起对一个或多个 ETW 提供商的订阅，无论是通过创建新会话还是连接到现有会话。数据收集：从活动 ETW 会话捕获事件或从 .etl 文件中解析事件。

本指南演示了如何从 Python 应用程序中提取日志并将其安全地传送到 Elasticsearch Service 部署中。你将设置 Filebeat 来监控具有标准 Elastic Common Schema (ECS) 格式字段的 JSON 结构日志文件，然后你将在 Kibana 中查看日志事件发生的实时可视化。虽然此示例使用的是 Python，但这种监控日志输出的方法适用于多种客户端类型。查看列表。在今天的展示中，我将使用 Elastic Stack 8.14.1 来进行展示。

​在 8.12 版本中，我们引入了性能预设 —— 一种更简单的方法，用于调整 Elastic Agent 和 Beats 以适应各种场景。这提高了常见环境的性能，而过去通常需要进行详细调整。从 8.13 版本开始，我们专注于改进我们的内部库，以更好地支持这些预设。其结果是我们的内部事件队列进行了重写，为所有 Beats 带来了降低的内存使用。在我们的内部基准测试套件中，Filebeat 8.13 在所有预设上显示出大约 20% 的内存减少。在这篇文章中，我们将探讨如何实现这一点。

本文档作为如何在同一服务器上配置和运行 Filebeat/Metricbeat/Auditbeat 的多个实例的指南。当你需要为同一台计算机上的不同应用程序或环境分离数据收集和处理时，此设置特别有用。在今天的展示中，我们将以 Filebeat 为例来进行展示。此方法也适用于其他的 Beats。

Elastic 已经拥有针对特定数据库的 metricbeat 和集成包。一个例子是 MySQL 的metricbeat— 以及相应的集成包。这些 beats 模块和集成是针对特定数据库定制的，并且使用预定义的查询从特定数据库中提取指标。这些集成中使用的查询和相应的指标不可修改。而通用 SQL 输入（metricbeat或输入包）可用于使用用户的 SQL 查询从任何支持的数据库中抓取指标。用户根据要提取的特定指标来提供查询。

Filestream是 Filebeat 中的一种输入类型，用于从给定路径摄取文件。文件扫描器组件中实现了新的指纹模式，以避免上述问题。对于给定的文件字节范围，新的指纹模式将默认文件扫描程序行为从使用文件系统元数据切换为使用 SHA256 哈希。默认情况下，该范围为 0 到 1024，但可以通过 offset 和 lengthconfig参数进行配置。既然我们在文件扫描器中拥有了此指纹信息，它也会随每个文件系统事件一起传播，并且可以使用此指纹哈希作为文件身份提供程序中的唯一文件标识符。

重点讲述如何根据最佳实践来配置 Metricbeat。

我详细描述了如何在 Elastic Stack 7.x 安装及配置 Beats。在那里的安装，它通常不带有安全及 Elasticsearch 在默认的情况下，不含有 HTTPS 访问。在最新的 Elastic Stack 8.x 中，Elasticsearch 集群在默认的情况下是带有安全访问的。这样针对 Metricbeat 访问 Elasticsearch 它和之前的情形是不同的。

毫无疑问，日志记录是任何应用程序最重要的方面之一。当事情出错时（而且确实会出错），我们需要知道发生了什么。为了实现这一目标，我们可以设置 Filebeat 从我们的 golang 应用程序收集日志，然后将它们发送到 Elasticsearch。最后，使用 Kibana 我们可以可视化这些日志并对它们执行复杂的查询。

我们将探讨使用 3 种不同的架构发送应用的日子到 Elasticsearch。应用程序 -> Filebeat -> Logstash -> Elasticsearch应用程序 -> Filebeat -> Elasticsearch应用程序 (Java) + Logstash-logback-encoder -> Logstash -> Elasticsearch虽然可能还有其他发送日志的方法，但根据我的经验，将这些方法结合起来可以满足任何业务需求。

今天在这篇博客中，我们将学习如何在容器环境中运行 Filebeat。我们在 Host 机器上部署 Elasticsearch 及 Kibana。然后在 Docker 里部署 NGINX。我们使用 Filebeat 来收集 NGINX 里的日志。这个想法是 Filebeat 容器应该从客户端机器上运行的所有容器收集所有日志，并将它们发送到主机上运行的 Elasticsearch。我的主机的 IP 地址是 192.168.0.3。

在本教程中，我们将部署一个 metricbeat 来监控正在运行的容器的健康状况和系统指标。

针对带有 HTTPS 访问的 Elasticsearch 集群来说，在我之前的很多文章，我都习惯于使用集群的证书来访问 Elasticsearch。你可以参考我之前的文章 “这是一种非常简便的方法。好处是，我们可以随时使用在安装过程中的证书来访问 Elasticsearch。一个很大的缺点就是，我们必须拷贝证书，并把它放到 Beats 或者 Logstash 可以访问的位置进行配置。这个在使用的过程中非常不方便。相反，我们可以使用 fingerprint 来进行配置 Beats 及 Logstash。

除了 Logstash 之外，Elastic 提供了两种主要的方式来向 Elasticsearch 发送数据：我们可以选择直接把数据从 Beats 发送至 Elasticsearch。当然我们也可以通过 Logstash 更进一步处理再发送至 Elasticsearch。另外一种方式是使用 Elastic Agents 来发送数据至 Elasticsearch：如上图所示，我们可以直接从 Elastic Agent 来把数据发送至 Elasticsearch 中。你们这两种方法各有什么优缺点呢？

在我之前的文章 “Observability：使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0”，我详细地描述了如何安装 Elasticsearch，Stack 及 Elastic Agents 来采集系统日志及指标。很多开发者可能会有疑问，在我们的实际使用中，我们更多的可能是需要采集定制的应用日志，而不是系统日志。那么在这个时候，我们该如何使用 Elastic Agents 来把这些日志摄入呢？在以前的系统中，我们可以使用如下的几种方式来采集日志：在今天的文章里，

到目前为止，我们看到有很多中不同的方法来收集日志。甚至，我们针对同样的一个日志，有好多种方法来进行采集。在今天的这篇文章中，我来简单里回顾一下。

这是之前的文章 “” 的续篇。在上一篇文章中，我详细地介绍了如何使用传统的收集器来监控 Elastic Stack。这个是不被推荐的方法。在 Elastic Stack 7.16 推出以后，更为推荐的方法是使用 Metricbeat 来监控 Elastic Stack。在今天的文章中，我将详细地介绍如何使用一个监控 Elasticsearch 集群来监控一个生产环境的集群。如上所示，我们使用一个专有的 Elasticsearch 集群来作为监控集群来监控其它的 Elastic Stack 组件。

在我之前的很多文章中，我基本上使用的 CA 证书来进行配置的。在很多其它的场合，我们可以使用 fingerprint 来进行连接。那么我们该如何得到并使用这个证书呢？在上面，我们配置 output.elasticsearch 部分。你们需要根据自己的配置进行相应的修改。如上所示，我们可以发现 CA 证书的 fingerprint。上面也显示了这个 fingerprint。但是在实际的使用中，这个带有 : 符号的字符串，并不能直接使用。从上面的输出中我们可以看出来我们的配置是成功的。我们先安装之前的教程 “

Elastic Stack 在收集日志方面有很多的方面的应用。在今天的文章中，我将使用 docker 来安装 Elastic Stack。我将演示如何使用 docker 安装 Filebeat 并收集容器的日志。

​在我之前的文章 “Observability：使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0”，我详细地描述了如何安装 Elasticsearch，Stack 及 Elastic Agents 来采集系统日志及指标。很多开发者可能会有疑问，在我们的实际使用中，我们更多的可能是需要采集定制的应用日志，而不是系统日志。那么在这个时候，我们该如何使用 Elastic Agents 来把这些日志摄入呢？在以前的系统中，我们可以使用如下的几种方式来采集日志：......

如何配置 Metricbeat 及 Logstash 为 Elasticsearch 8.0 收集数据如何配置 Metricbeat 及 Logstash 为 Elasticsearch 8.0 收集数据_哔哩哔哩_bilibili

注意：在独立模式（standalone）下运行 Elastic Agent 是一个高级用例。 文档不完整，还不成熟。 如果可能，我们建议使用 fleet 管理的代理而不是独立模式。要在独立模式下运行 Elastic Agent，请在你要监控的每台主机上安装该代理，并在安装它的系统上本地手动配置该代理。 你负责管理和升级代理。 仅建议高级用户使用此方法。我们建议尽可能使用 Fleet-managed Elastic Agents，因为它使你的代理程序的管理和升级变得相当容易。你可以阅读我之前的文章.

在我之前的文章 “Observability：使用 Elastic Agent 来摄入日志及指标 - Elastic Stack 8.0” 我详述了如何使用 Elastic Agent 来摄入数据。事实上，在之前的最新的几版 7.14里，Elastic Agent 已经是正式版发布了。我们知道在之前我们使用 Filebeat 进行数据采集时，在 Elasticsearch 中，我们看到的索引名称是 filebeat-* 这样的索引，而且 filebeat-* 也被当做 index pattern 来方.

我们知道在许多的 Web Service 中，有许多的数据是以 JSON 形式提供的。有些时候，我们希望使用一种方式能够把这些数据摄入到 Elasticsearch 中，并对这些数据进行分析。针对一些用户来说，它们可能想到的工具就是使用常用的编程语言，比如 Java, Python, Go, Nodejs, Ruby 等来对数据进行抓取，并把数据导入到 Elasticsarch 中。这种方法虽然很好，但是需要有专业的技术人员进行编程，但是它还不能充分运用 Filebeat 里所提供的强大的一些 proces

在本入门指南中，你将了解 elastic-package 如何帮助你快速启动完整的 Elastic Stack。Elastic-package 是一种开源工具，可通过提供预构建的命令来帮助你缩短开发时间。 例如，它将帮助您整理、格式化、测试、构建和推广你的包。每个想要通过创建自己的集成（integrations）做出贡献的开发人员都应该使用 elastic-package。 它将提供一个即用型代码环境。开始使用 elastic-package作为开发人员，你可以通过两种方式使用...

Kafka 是分布式事件流处理平台，具有高可用性，既可以在裸机、虚拟化环境或容器化环境中运行，也可以作为托管服务运行。本质上，Kafka 是一种发布/订阅（简称“pub/sub”）系统，通过提供“代理”来分发事件。发布者将事件发布到主题，而使用者订阅主题。当新事件被发送到某个主题时，订阅该主题的使用者会收到新事件通知。如此一来，发布者不必了解所发布事件的使用者，多个客户端也可以收到活动通知。例如，当有新订单下达时，网店可能会发布一个附带订单详情的事件，然后可能会通知订单分拣部门的使用者从货架提取相应货物..

今天，我们很高兴地宣布三项重大改进，它们将使您的系统和应用程序与 Elastic Stack 的集成变得更加容易。首先，我们推出了Elastic 代理的正式发布 (GA) 版，这是一个兼具可观测性和安全的单个一体化代理。一体化代理将简化数据上线过程，并减少配置和安装方面的工作。其次，我们发布了Fleet的正式发布版，这是一个全新的 Kibana 应用，可让您大规模地集中管理整个 Elastic 代理队列。Fleet 作为一个控制平面，可让您实时查看代理状态，远程升级代理，在每个主机上执行查询，以及...

这篇博文将解释什么是 UNIX 域套接字，以及如何将发送到 UNIX 域套接字的索引编入 Elastic Stack - 以及为此存在哪些不同的用例。UNIX 域套接字 - 简短的历史如果你想让进程相互通信，你有几种可能通过文件，一个组件写入，完成后另一个读取。需要同步（即文件锁定） 信号（kill -HUP），不提供有效载荷，只是一个触发器 共享内存、内存映射文件 网络套接字，需要联网 Unix 域套接字，类似于套接字，但无法从外部访问从实现的角度来看，UNIX 域套接字是一

在生产中运行的应用程序是一头难以驯服的野兽。大多数有经验的开发人员——那些花了足够多的深夜或周六早上试图打破一个令人讨厌的生产错误的人 — 会在编写代码时尝试为他们以后的自己创造尽可能清晰的画面，以便他们能够理解实际发生的事情 事件期间的系统。为了让生活更轻松，开发人员可以结合使用强大的可观察性堆栈来收集、转换和查看应用程序范围内的日志，搭配实时可观测性平台，无需推送新代码、重新部署或甚至重新启动服务。 这就是 Elastic Stack 为我们运维带来的好处。日志记录是一个难题虽然写日志相

在 Elastic 7.9 中，发布了 Elastic Agent 和 Fleet，以及一种在 Elasticsearch 中为时间序列数据构建索引和数据流的新方法。 在这篇博文中，我们将概述 Elastic data stream 命名方案及其工作原理。 这是围绕 Elastic data stream 命名方案的一系列博客文章中的第一篇。Elastic data stream 的命名方案Elastic data stream 的命名方案是由时间序列数据，由数据集分割成不同的数据。它使用以下命

在许多时候，我们需要监控一个网站的 TLS 证书。如果快要过期了，我们希望能发出警报。这个需求我们可以使用 Heartbeat 并在 Kibana 中的 Uptime 应用中来实现。首先，我们来安装好自己的 Heartbeat，并修改它的配资文件 heartbeat.yml 文件。在它的 heartbeat.monitors 下添加如下的配置：heartbeat.ymlheartbeat.monitors:# 一下是添加的部分- type: http id: elastic-offi

在我之前的文章：Beats：Beats 入门教程 （一） Beats：Beats 入门教程 （二）我详述了如何使用 Filebeat 中的 system 模块来为 syslog 导入到 Elasticsearch。这是目前为止最为快捷的方法。在实际的使用中，我们也可以使用其它来导入 syslog。这里的方法是：使用 Filebeat 中的 syslog input使用 Logstash 导入在今天的文章中，我将详述如何配置 Rsyslog 把数据导入到 Elasticsearch .

在我之前的文章 “使用 Heartbeat 进行 Uptime 监控” 中，我详细地讲述了如何使用 Heartbeat 来对一个服务或者网站进行监控。在实际的很多监控中，如果我们能对监控的服务或者网站添加一个位置的信息，那么我们可以针对这个服务使用 Maps 来进行显示是非常好的。我们可以在地图上清楚地看到哪些网站或者服务是运行良好的。在今天的文章中，我将展示如何为 Heartbeat 的监控提供一个 geo 的信息。启动 hello-app 服务首先，我们来启动一个简单的服务。我们下载如下的一

Filebeat 模块为常见日志格式提供最快的入门体验。如果你对如何使用 Filebeat 模块还不是挺了解的话，请参阅我之前的文章：Beats：Beats 入门教程 （一） Beats：Beats 入门教程 （二）为了能够手动配置 Filebeat 而不是使用模块，你可以在配置文件 filebeat.yml的 filebeat.inputs 部分定义一个列表的inputs。这些 inputs 定义了 Filebeat 如何定位及处理 input 数据。这个列表是一个 YAML 的数组。每个..

Elastic在6.5的版本中退出Heartbeat。Heartbeat 也就是我们通常所说的心跳。我们知道在医院，医生是用听心跳来判断一个人是否有生命迹象。在Elastic的Heartbeat里，它也是一样的道理。Heartbeat是一个轻量级的数据收集器。它用来帮我们进行uptime的健康监控。它可以帮我们查看一个服务器及服务器中一些服务是否运行正常。心跳可以在网络内部或外部运...

在之前的一篇博文中，我们介绍了一种使用 Metricbeat 监控 Elastic Stack 的新方法。 使用 Metricbeat 从外部收集有关 Elastic Stack 产品的监控信息，提高了监控这些产品的可靠性。 它还为如何将监控数据路由到 Elasticsearch 监控集群提供了灵活性。 在这篇博文中，我们通过展示用户如何将 Metricbeat 收集的监控数据通过 Logstash 或 Kafka 路由到监控集群来更深入地研究第二个方面。 因此，如果您已经在 Metricbeat 配置中将

在之前的文章 “Logstash：使用 ELK 堆栈进行 API 分析”，我展示了如何使用 Logstash 的 http_poller input plugin 来对微服务的 API 数据进行分析。如果我们只是为了对微服务的数据采集使用 Logstash，感觉有些 Logstash 有些大材小用了，比较 Logstash 的部署还是蛮耗资源的。相比较而言，我们可以使用 Filebeat 的 HTTP JSON input 来对微服务的数据进行采集。我们知道 Beats 的架构是属于一种轻量级的部署。可以直

在 Elastic Stack 的使用中，一个典型的 Elastic Stack 架构框图：从上面，我们可以看出来如果采集的数据比较多的话，我们可以使用 Kafka => Logstash => Elasticsearch 这样的 data pipeline 把数据传入到 Elasticsearch 中。在今天的文章中，我将介绍：从 Kafka topic 中读取数据 使用 Logstash 来处理这个数据 把 Logstash 传入的数据导入到 Elasticsearch 中，

在我之前的教程 “Logstash：Logstash 入门教程 （二）”，我详述了如何使用 Logstash 来处理数据。在那个教程的最后的部分，我也讲述了如何使用 Filebeat 把数据送到 Logstash 并对数据进行加工。在今天的教程中，我将使用一个简单的例子来展示如何使用 Logstash 来对 Metricbeat 的数据进行加工。导入 Metricbeat 数据我们可以参考文章 “Beats：Beats 入门教程 （二）” 来安装我们的 Metricbeat。我们只启动 s.

前一段时间有一个开发者私信我说自己的 Beats 连接到 Logstash，然后连接到 Elasticsearch。等数据在 Elasticsearch 中收集完后，发现 Kibana 中的 Dashboard 不能被使用。数据类型不匹配。这个到底是什么原因呢？Beats 为我们的数据导入带来了极大的方便。目前在 Elastic Stack 的架构中：我们可以通过如下的三种路径吧数据导入到 Elasticsearch 中：Beats ==> Elasticsearch Beats