« 第 5 步：下一步 排查通用分析后端问题 »
Elastic 文档 ›Elastic 可观测性 [8.14] ›通用分析 ›在自托管 Elastic Stack 上运行通用分析

操作通用分析后端

编辑

操作通用分析后端编辑

本页面概述了在自托管版本的 Elastic Stack 上运行通用分析时操作后端的方法。您将在此处找到有关以下内容的信息：

资源指南编辑

摄取和查询通用分析数据所需的资源会根据您正在分析的 CPU 核心总数而有所不同。CPU 核心数来自在 /proc/cpuinfo 中记录的所有虚拟核心的总和，将您将部署通用分析代理的所有机器的内核加起来。

摄取和查询资源需求几乎与通用分析代理生成的数据量成正比。使用收集的 CPU 样本数、处理的可执行文件数以及可执行文件的调试元数据大小来计算通用分析代理生成的数据量。虽然收集的 CPU 样本数是可以预测的，但处理的可执行文件数以及可执行文件的调试元数据大小则不可预测。

下表根据您的 CPU 核心数提供了摄取和查询通用分析数据的推荐资源。

CPU 核心数 Elasticsearch 总内存 Elasticsearch 总存储空间（保留 60 天） 分析后端 Kibana 内存

1–100

4GB–8GB

250GB

1 个收集器 2GB，1 个符号化器 2GB

2GB

100–1000

8GB–32GB

250GB–2TB

1 个收集器 4GB，1 个符号化器 4GB

2GB

1000–10,000

32GB–128GB

2TB–8TB

2 个收集器 4GB，1 个符号化器 8GB

4GB

10,000–50,000

128GB–512GB

8TB–16TB

3 个或更多收集器 4GB，1 个符号化器 8GB

8GB

此表来自对通用分析进行的基准测试，其中摄取了高达 15,000 个 CPU 核心。被分析的机器的 CPU 利用率几乎恒定为 75%。部署使用了 3 个 Elasticsearch 节点，每个节点具有 64 GB 内存、8 个 vCPU 和 1.5 TB NVMe 磁盘驱动器。

由于资源需求几乎与通用分析代理生成的数据量成正比，因此您可以通过将您实际分析的 CPU 核心数与表中的 CPU 核心数进行比较，来计算超出表中用例所需的资源。在计算时，请考虑以下因素：

  • 被分析机器的平均负载：平均负载直接影响收集的 CPU 样本数。例如，在大部分处于空闲状态的系统上，并非所有 CPU 都将在采样间隔期间调度任务。
  • 被分析可执行文件的更改率，例如您部署新软件版本的频率：更改率会影响由于符号化而在 Elasticsearch 中存储的调试元数据量；通用分析代理收集的可执行文件种类越多，存储在 Elasticsearch 中的调试数据就越多。请注意，同一应用程序的两个不同构建仍然会导致两个不同的可执行文件，因为通用分析代理会独立处理每个 ELF 文件。

存储注意事项：Elasticsearch 磁盘的带宽和延迟会影响摄取和查询分析数据的延迟。将数据分配到热节点以获得最佳性能和用户体验。如果存储成为问题，请通过自定义通用分析 索引生命周期管理策略 来调整数据保留时间。

配置收集器和符号化器编辑

您可以使用 YAML 文件和 CLI 标志来配置收集器和符号化器，其中 CLI 标志优先于 YAML 文件。配置文件是在安装过程中创建的，如 创建配置文件部分 所示。配置文件中的注释解释了每个配置选项的用途。

修改配置文件后，重新启动后端二进制文件以使更改生效。

使用 CLI 标志覆盖配置文件值编辑

在为每个后端二进制文件构建配置选项时，您可以使用 CLI 标志覆盖 YAML 配置文件中的值。覆盖 必须 包含配置选项的完整路径，并且必须采用键=值格式。例如，-E application.field.key=value，其中 application 是二进制文件的名称。

例如，要启用收集器 HTTP 服务器中的 TLS，您可以传递 -E pf-elastic-collector.ssl.enabled=true 标志。这将覆盖 YAML 配置文件中找到的 ssl.enabled 选项。

监控编辑

通过 日志 和 指标 监控收集器和符号化器，以确保服务正在运行且处于正常状态。如果没有这两个服务运行，分析数据将不会被摄取和符号化，并且查询 Kibana 不会返回数据。

日志编辑

收集器和符号化器始终记录到标准输出。您可以通过在 YAML 配置文件中将 verbose 配置选项设置为 true 来打开调试日志。

避免在生产环境中使用调试日志，因为它们可能非常详细并影响后端性能。仅在排查部署失败或支持人员指示时才启用调试日志。

日志格式为“键=值”对，Elasticsearch 和 Kibana 可以自动将它们解析为字段。

日志收集器（如 Filebeat）可以收集日志并将其发送到 Elasticsearch 以进行索引和分析。根据安装方式，可以使用 journald（对于 OS 包）、log（对于二进制文件）或 container 类型的 Filebeat 输入来处理日志。有关更多信息，请参阅 filebeat 文档。

指标编辑

默认情况下不公开指标。在 YAML 配置文件中的 metrics 部分启用指标。收集器和符号化器可以以 JSON 和 Prometheus 格式公开指标。

JSON 格式的指标可以通过 HTTP 服务器或 Unix 域套接字公开。Prometheus 指标只能通过 HTTP 服务器公开。使用 metrics.prometheus_host 和 metrics.expvar_host 配置选项自定义指标的公开位置。

您可以使用 Metricbeat 抓取指标。通过 http 模块直接使用 JSON。使用 prometheus 模块使用 Prometheus 端点。当对任一格式使用 HTTP 服务器时，要抓取指标的 URI 为 /metrics。

例如，以下收集器配置将以 Prometheus 格式在端口 9090 上公开指标，并以 JSON 格式在端口 9191 上公开指标。然后，您可以通过连接到 http://127.0.0.1:9090/metrics 和 http://127.0.0.1:9191/metrics 分别抓取它们。

pf-elastic-collector:
  metrics:
    prometheus_host: ":9090"
    expvar_host: ":9191"

或者，您还可以通过将 expvar_socket 配置选项设置为有效路径，在 Unix 域套接字上公开 expvar 格式。例如，以下收集器配置将以 Prometheus 格式在端口 9090 上公开指标，并以 JSON 格式在 /tmp/collector.sock 上的 Unix 域套接字上公开指标。

pf-elastic-collector:
  metrics:
    prometheus_host: ":9090"
    expvar_host: "/tmp/collector.sock"

以下部分显示了后端二进制文件公开的最相关指标。将这些指标包含在您的监控仪表板中，以检测后端问题。

常见的运行时指标

  • process_cpu_seconds_total：跟踪进程使用的 CPU 时间。
  • process_resident_memory_bytes：跟踪进程使用的 RAM 量。
  • go_memstats_heap_sys_bytes：跟踪堆内存量。
  • go_memstats_stack_sys_bytes：跟踪堆栈内存量。
  • go_threads：运行时创建的 OS 线程数。
  • go_goroutines：活动 goroutine 的数量。

收集器指标

  • collection_agent.indexing.bulk_indexer_failure_count：批量索引器未能将数据摄取到 Elasticsearch 的次数。
  • collection_agent.indexing.document_count.*：表示摄取到 Elasticsearch 中的每个索引的文档数量的计数器；可用于计算每个索引的摄取率。
  • grpc_server_handling_seconds：gRPC 服务器处理请求所用时间的直方图。
  • `grpc_server_msg_received_total: gRPC 服务器接收到的消息计数；可用于计算每个 RPC 的摄取率。
  • grpc_server_handled_total：gRPC 服务器处理的消息计数；可用于计算每个 RPC 的 gRPC 服务器可用性。

符号化器指标

  • symbols_app.indexing.bulk_indexer_failure_count：批量索引器未能将数据摄取到 Elasticsearch 的次数。
  • symbols_app.indexing.document_count.*：表示摄取到 Elasticsearch 中的每个索引的文档数量的计数器；可用于计算每个索引的摄取率。
  • symbols_app.user_client.document_count.update.*：表示每个索引中更新的现有文档数量的计数器；当速率增加时，可能会影响 Elasticsearch 性能。

健康检查

后端二进制文件公开了两个健康检查端点，/live 和 /ready，您可以使用它们来监控应用程序的运行状况。当检查成功时，端点返回 200 OK HTTP 状态代码。

健康检查端点位于接收传入分析数据的同一 HTTP 服务器中。此端点通过应用程序的 host 配置选项进行配置。

例如，如果收集器配置为默认值 host: 0.0.0.0:8260，则可以通过运行 curl -i localhost:8260/live 和 curl -i localhost:8260/ready 来检查应用程序的运行状况。

扩展资源编辑

在 资源指南表 中，没有选项对符号化器使用超过一个副本。我们不建议扩展符号化器副本的数量，因为当前实现存在技术限制。我们建议通过增加符号化器用于处理数据的内存和 CPU 内核来垂直扩展符号化器。

如果这对您的部署用例更方便，您可以随意增加收集器副本的数量，同时保持它们的垂直大小更小。收集器的内存使用量和 CPU 线程会随着它所服务的通用分析代理数量线性增加。请记住，由于通用分析代理/收集器通信通过 gRPC 进行，因此可能存在绑定到单个收集器副本的长期 TCP 会话。在扩展副本数量时，根据您在收集器端点前面使用的负载均衡器，您可能希望在添加新副本后关闭旧副本。这确保负载均匀分布在所有副本上。

升级后端二进制文件编辑

在升级 Elastic Stack 的其余部分时，升级后端二进制文件。虽然我们努力保持两个连续次要版本之间的向后兼容性，但我们可能会对数据格式进行更改，这些更改需要应用程序使用相同版本的 Elasticsearch 和 Kibana。

升级过程步骤因所使用的安装方法而异。

ECE编辑

使用 ECE 时，升级过程由平台本身管理。您无需执行任何操作即可升级后端二进制文件。

Kubernetes编辑

使用 helm upgrade 命令执行 helm 升级。您可以在每次升级时重复使用现有值或提供完整的 values YAML 文件。

OS 包编辑

使用 OS 包管理器升级包版本。并非所有包管理器都会调用 systemd 来重新启动服务，因此您可能需要手动重新启动服务或通过任何其他自动执行的流程来重新启动服务。

二进制文件编辑

下载相应的二进制文件版本，并使用设置指南的 二进制文件 部分中看到的命令替换现有二进制文件。替换旧的二进制文件并重新启动服务。

容器编辑

拉取新的容器镜像，并用新的镜像替换现有镜像。

« 第 5 步：下一步 排查通用分析后端问题 »