Observability：运用 Fleet 来轻松地导入 Nginx 日志及指标

在我之前的文章：

• Observability：使用 Elastic Agent 和 Ingest Manager 简化数据导入 （一）

• Observability：使用 Elastic Agent 和 Ingest Manager 简化数据导入 （二）

我有讲到如何使用 Ingest Manager 简化数据输入。今天我重新看了一下界面确实变了很多，这就是为什么实验版本的功能一直在演化中。Ingest Manager 的名字也被修改为 Fleet。另外从 7.13 开始，开始引入 Fleet Server。Fleet Server 是 Elastic Stack 的一个组件，用于集中管理 Elastic Agent。 它作为 Elastic Agent 的一部分在用作服务器的主机上启动。 一个 Fleet Server 进程可以支持多个 Elastic Agent 连接，并作为一个控制面来更新代理策略、收集状态信息和协调跨 Elastic Agent 的操作。

如何使用 Elastic fleet 来收集 nginx 日志及指标

使用 Fleet 大规模管理 Elastic Agent

Fleet 是一个组件，用于在你的环境中管理 Elastic Agent 配置。 Fleet 由两部分组成：

• Fleet UI 是一个带有用户界面的 Kibana 应用程序，供用户载入和配置代理、管理载入数据以及管理整个环境中的代理。
• Fleet Server 是一个后端组件，你环境中的弹性代理可以连接到该组件，以检索代理策略、更新和管理命令。

Fleet Server 是 Elastic Agent 的一种特殊模式，可以与你的 Elastic Stack 部署一起集中部署。 你可以在负载平衡设置中配置 Fleet Server 的多个实例，以扩展性能并增加可用性。 Fleet Server 需要连接到支持 Elasticsearch 集群才能运行。

涉及 Elastic Agent 和 Fleet 的架构如下所示：

整个环境中的代理会定期与 Fleet Server 通信，以检索代理策略配置和管理命令。 Fleet Server 与支持的 Elasticsearch 集群交互，为代理创建安全凭证、检索代理策略并保持状态。

Kibana 上的 Fleet UI 将代理策略存储在 Elasticsearch 上，管理用于数据载入的数据流的创建，并为正在使用的数据源加载索引模板和仪表板等工件。

根据代理策略的配置，Elastic Agent 将数据直接发送到目标 Elasticsearch 集群（或其他受支持的输出，例如 Logstash 或 Kafka）以供摄取。

策略可用于在逻辑上将主机分组在一起，具体取决于以下因素：

• 他们运行的工作负载
• 主机所在的环境类型（生产/非生产等）
• 所需的数据收集/插桩水平

使用 Fleet 时，可以更改或重新分配给定主机运行的策略。 这使你可以随着数据收集需求的发展动态控制主机配置。 Fleet 还可用于在一小部分主机上测试策略更改，然后再将其应用于整个环境。

Kibana Management 部分中的 integration 应用程序显示了所有可用的数据收集模块。 集成还包括专为所选数据源设计的预打包仪表板和机器学习作业等工件。 如果集成不可用，则可以使用 Custom logs 集成来收集此信息。

代理策略和集成

代理策略，也就是 agent policy。集成有就是 integration。代理策略是一个 YAML 文件，它定义代理将收集并发送到 Elasticsearch（或其他受支持的目的地）的各种输入和设置。 当你在独立模式下使用 Elastic Agent 时，可以使用 /etc/elasticagent/elastic-agent.yml 文件配置策略。 当代理由 Fleet 管理时，策略会从 Elasticsearch 中检索并在代理启动时自动应用到代理。 Kibana 上的 Fleet 界面可用于创建和管理代理策略。 创建策略后，用户可以添加定义代理收集的数据源的集成。

 在 7.13 之前是这样的一种架构：

在 7.13 及之后是这样的一种架构： 

以 agent 为基础的数据摄入架构

通过添加 Fleet server，我们可以得到如下的好处：

• Scale：在之前的架构中，我们如果有1000个 agents，那么在 Kibana 中将会有1000个显示的 agent。通过改造之后，我们的 Kibana 将只会和 Fleet Server 进行交互。它可以支持更多的 agents。
• Secuirty：它可以使得我们使用较少的访问权限。因为 Kibana 只需要和 Fleet Server 进行交互，Fleet Server 相比较而言，设计较为简单，而且它具有更少的访问权限。
• More flexibility：给我们的部署带来更多的灵活性。你可以把你的 Fleet Server 安装在你的 agents 附近，而不需要 Kibana 安装于你的数据采集附近。

Fleet Server 是 Elastic Agent 用来与 Elasticsearch 通信的机制：

• 创建新的代理策略后，它会保存到 Elasticsearch。
• 为了注册该策略，Elastic Agents 使用为身份验证生成的注册密钥向 Fleet Server 发送请求。
• Fleet Server 接收请求并从 Elasticsearch 获取代理策略，然后将该策略发送到在该策略中注册的所有 Elastic Agent。
• Elastic Agent 使用策略中的配置信息来收集数据并将其发送到 Elasticsearch。
• Fleet Server 会定期检查 Elastic Agent 的状态信息。
• 当策略更新时，Fleet Server 从 Elasticsearch 检索更新的策略并将其发送到连接的 Elastic Agent。

Fleet Server 作为 Elastic Agent 内的子进程运行。Agent 使用描述 Fleet Server 配置的特殊策略。 在大规模 self-managed 部署或在 Elastic Cloud 上托管的 Elasticsearch 服务中，Fleet Server 通常作为专用的 Elastic Agent 通信主机运行，但你可以选择将其用于自我管理集群上的数据收集。

在目前的设计中，在 data plane 里，Elastic Agent 所管理的每个 Beats 都会和 Elasticsearch 建立一个连接。这在很多的情况下，并不是最理想的。在未来的设计中，Elastic Agent 会包含一些 Collectors 收集数据，并传输到一个 shipper。从某种意义上讲，这和最初的 Beats 的设计思想还是蛮像的，不过 Elastic Agent 可以同时管理多个 Beats 的数据收集。

Elastic Agent -  supervisor

Elastic Agent 就本质来说就是一个主管。它和其它的软件栈进行交互：

在上面，grpc 是一个高性能、开源的通用 RPC （Remote Procedure Call ）框架。Elastic Agent 通过 grpc 管理及调用 Endpoint， Metricbeat，Filebeat 等。

另外一个需要注意的是在 Fleet 出现之前，我们通过 Beats，Logstash 或 Fluentd 收集上来的数据是这样的：

 在这之前，针对一些数据类型，比如 NGINX，它可能被不同的技术来进行收集，比如：

这样导致有关 NGINX 的信息分布于不同的索引之中，依赖于采集的技术不同。这对于我们分析有不利的一面。Elastic 在最新版本里的设计思想是无论 NGINX 是采用什么样的技术采集的，NGINX 的数据应该永远看起来是一样的。那么我们该如何实现这个呢？

我们通过 Elastic Common Schema 及 Data stream naming scheme 来实现上述目的。有关 Data stream naming scheme 在我之前的文章 “Elastic data stream 命名方案介绍” 里有介绍。

  

Elastic Agent 注册

• Fleet Server host + enrollment key
• Fleet Server 验证 enrollment key
• Fleet Server 创建两个 API keys
  • 和 Fleet Server 的 Authentication key
  • 和 Elasticsearch 的 数据摄入 key 
• Elastic Agent 报到（check in）
• 从 Fleet Server 收到 policy
• Elastic Agent 开始启动 subprocesses
  • Subprocesses 开始发送数据至 Elasticsearch

使用基于 agent 数据摄入和 Beats 相比较：

需要为每个用例安装 beat	适用于所有用例的单一代理
在命令行安装模块	从 Kibana UI 安装集成
需要手写/编辑 YAML 配置	从集成 UI 配置
无法向已安装的 beat 发送动作	中央、远程代理管理
或是所有开箱即用的 assets 或没有	选择要添加的集成
手动输入凭据（用户名及密码）	自动生成的 ES API 密钥
边缘设备需要更高的 ES 权限	边缘设备所需的最低 ES 权限
具有大量字段的单个索引	生成具有更少字段的多个索引，并提高了查询性能

从安装的角度来说，Elastic agent 一个 agent 代替之前所有的 Beats：

在今天的文章中，我将基于 7.14.1 的版本如何使用 Fleet 导入 Nginx 日志。

安装

Elastic Stack

我们可以按照我之前的文章 “Security：如何安装 Elastic SIEM 和 EDR” 来安装 Elasticsearch 及  Kibana。我们为 Elasticsearch 及 Kibana 配置上安全及 HTTPS 访问，尽管 HTTPS 不是不必要的。针对我的配置，我使用一台 Ubuntu 系统的集群安装 Elasticsearch 及 Kibana，并且它的 IP 地址为 193.168.0.4。安装完毕后，我们必须使用 https://192.168.0.4:5601 来登录 Kibana：

Nginx 及 Nodejs 

我们可以按照我之前的文章 “Beats：使用 Elastic Stack 对 Nginx Web 服务器监控”。在那篇文章中，我们跳过按照 Elasticsearch 及 Kibana。我们直接进入到安装 Nodejs 及 Ngnix 部分。我们需要同时运行那个 samplenodejs 的应用。

等我们安装好后，我们可以在 Mac OS 的浏览器中输入地址 192.168.0.4。

它说明我们的 Nginx 工作是正常的。我们可以仔细查看一下 Ubuntu 机器下如下的位置的 log 文件：

$ pwd
/var/log/nginx
liuxg@liuxgu:/var/log/nginx$ ls *.log
access.log  error.log

上面是在 Ubuntu OS 机器下的 Nginx  的日志文件的位置。记住这个信息。我们在一下的练习中将会用到。

安装 Elastic Agent

我打开 Kibana：

  在 Kibana 中它已经集成了许多的开箱即用的应用及服务。如上图所示，我们可以找到 Nginx 的服务集成，虽然目前还处于一个实验的阶段。

 点击进去，我们可以查看到 Nginx 的一些介绍。在上面，我们可以看到 Nginx 的 Dashboard 的一些截屏。

我们接下来选择 Fleet：

 如上所示，我们可以看到已有的 policy。在通常的情况下，我们可以直接使用 Default Policy。在今天的练习中，我们来创建一个属于自己的 policy：

    

这样就创建了一个叫做 nginx_demo 的 policy。点击上面的 nginx_demo：

在这个 policy 里面，它已经包含了一个叫做 system-1 的 integration。我们可以点击 Edit integration 来查看这个 integration 里到底包含一些啥东东：

如上所示，它采集系统的日志，Windows 系统的事件以及系统的指标等等。当然对于我们的 nginx_demo 这个 policy 来说，我们甚至可以删除 system-1 这个 integration，如果我们不是对它里面所采集的信息感兴趣的话。针对我的配置，我选择保留。接下来，我们来添加 nginx 这个 integration：

 

我们接着根据我们的系统上的 log 的位置来进行配置上面的选项。针对我的情况，它上面显示了 Linux 系统上的 access.log 及 error.log 的正确位置，所以我不需要做任何的修改。如果是是 Mac OS 系统，你可能需要根据自己的日志的位置来进行相应的修改。

 点击上面的 Save integration 按钮：

如上图所示，我们可以看见一个新增加的 nginx-1 的 integration。

自从 7.13 发布版以来，新增加了一个叫做 fleet server 的元件。我们至少需要在一个机器上部署一次，这样各个 elastic-agent 可以对它进行连接。针对我们的情况，我们按照上面添加 nginx integration 相同的方法来添加 fleet-server。

最终我们的 nginx-demo policy 是这样的：

 接下来，我们对 Fleet 进行配置：

我们必须添加 Fleet 服务器。这是一个从 7.13 开始的要求。我们添加一个 Fleet 服务器的地址：

 我们回到 Fleet 的首页：

我们点击 Go to download page。针对我的情况，我安装 DEB 版本的 Elastic Agent：

curl -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-7.14.1-linux-x86_64.tar.gz

我使用如下的命令来进行安装：

tar xzf elastic-agent-7.14.1-linux-x86_64.tar.gz

我们使用如下的方法来安装 Fleet Server：

 

 

我们拷贝上面的命令。由于我们使用了自签名证书，所以我们需要对这个命令做一下修改：

 sudo ./elastic-agent install --certificate-authorities=/home/liuxg/beats/ca.crt -f \
 --fleet-server-es=https://192.168.0.4:9200 \
 --fleet-server-service-token=AAEAAWVsYXN0aWMvZmxlZXQtc2VydmVyL3Rva2VuLTE2MzA3MjIxNTYxNTQ6em5DTkFJZEZSYTJIMXkxbkNWZ0dMdw \
  --fleet-server-policy=e0f064b0-0d23-11ec-8830-cb272d7fa437

在上面，我对命令添加了 --certificate-authorities=/home/liuxg/beats/ca.crt。你需要根据自己的证书路径做相应的调整。

针对我的情况，我有使用自签名的证书。我们需要参考链接  Fleet User Guide。

在运行之前，我们把证书拷贝到 Ubuntu 机器的如下地址：

sudo cp ca.crt /usr/local/share/ca-certificates

然后，我们使用如下的方法来进行更新：

sudo update-ca-certificates

sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:ca.pem
done.
done.

接着，我们使用如下的命令来运行 elastic-agent：

sudo ./elastic-agent install --certificate-authorities=/home/liuxg/beats/ca.crt -f \
 --fleet-server-es=https://192.168.0.4:9200 \
 --fleet-server-service-token=AAEAAWVsYXN0aWMvZmxlZXQtc2VydmVyL3Rva2VuLTE2MzA3MjIxNTYxNTQ6em5DTkFJZEZSYTJIMXkxbkNWZ0dMdw \
  --fleet-server-policy=e0f064b0-0d23-11ec-8830-cb272d7fa437

或者：

sudo ./elastic-agent install -a /home/liuxg/beats/ca.crt -f \
 --fleet-server-es=https://192.168.0.4:9200 \
 --fleet-server-service-token=AAEAAWVsYXN0aWMvZmxlZXQtc2VydmVyL3Rva2VuLTE2MzA3MjIxNTYxNTQ6em5DTkFJZEZSYTJIMXkxbkNWZ0dMdw \
  --fleet-server-policy=e0f064b0-0d23-11ec-8830-cb272d7fa437

更多关于 Elastic Agent 的 install 参数，请参阅官方文档。有关 elastic-agent 运行的 logs 可以在如下的地址找到（在 Ubuntu 机器上）

/opt/Elastic/Agent/data/elastic-agent-{xxxxxx}/logs

 当我们运行完上面的命令后，我们可以再次查看 Agents：

 再过一会儿：

当我们看到上面的状态从 updating 变为 Healthy，它表明我们的安装时成功的。

我们也可以通过如下的方式来查看 fleet server 是否已经正在运行：

netstat -nat | grep :8220

我们可以通过如下的方式来查看 elastic-agent 的状态：

更多 troubleshooting 方面知识可以参阅官方链接。

我们接下来查看它的 data streams：

 

查看数据

我们在 Discover 上查看数据。我查找 logs-* 索引模式。 

我们也可以找到相关的 Nginx 的 Dashboard：

 也许你已经看出来了。在以前，如果我们使用 Filebeat 来收集日志的话，我们可以看到 Filebeat 的日志。现在它变成了 [Logs Nginx] Overview：

 我们可以通过如下的方式来查看已经收到的日志信息：

GET logs-nginx.access-*/_search

通过使用 Fleet，一个好处是通过上面的 nginx 相关的 data stream 的搜索，它可以帮我们限定更加小的范围进行搜索，从而提高搜索的效率。如果是像之前的那种搜索 filebeat-*，我们可能会工作于一个比较大的索引，从而增加搜索的开支。同样，如果我们搜索 error，我们可以使用如下的方式来进行搜索：

GET logs-nginx.error-*/_search

更多关于 data stream 的命名方式，请参阅文章 “Elastic data stream 命名方案介绍”。