« 第 5 步：后续步骤 通用性能分析后端故障排除 »
Elastic 文档 ›Elastic 可观测性 [8.16] ›基础设施和主机监控 ›通用性能分析 ›在自托管 Elastic Stack 上运行通用性能分析

操作通用性能分析后端

编辑

操作通用性能分析后端

编辑

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

资源指南
编辑

摄取和查询通用性能分析数据所需的资源会根据您正在分析的 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

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

资源需求几乎与通用性能分析代理生成的数据量成正比。因此，您可以通过比较实际分析的核心数和表中的核心数来计算表中用例之外的用例所需的资源。计算时，请考虑以下因素：

  • 被分析机器的平均负载：平均负载直接影响收集的 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（对于操作系统包）、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：运行时创建的操作系统线程数。
  • 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 来检查应用程序的健康状况。

分析代理遥测数据
编辑

通用分析收集器接收来自分析代理的遥测数据，以帮助调试代理操作并收集产品使用情况统计信息。这些数据使我们能够了解已分析机器的统计数据，并在客户报告问题时帮助进行调查。

默认情况下，所有分析代理收集的遥测数据都会发送到收集器，然后收集器会将其转发到互联网上的 Elastic 端点。您可以通过配置收集器配置 YAML 文件中的 agent_metrics 部分来选择退出。如果您选择退出，则客户服务将需要手动提取并提供遥测数据才能进行故障排除。

“收集器配置文件”允许您配置是否将遥测数据转发到 Elastic、存储在内部还是丢弃。如果收集器部署在没有互联网访问权限的网络中，则不会将遥测数据转发到 Elastic。

以下是每个选项的配置示例

将遥测数据转发到 Elastic

这是默认配置。当 agent_metrics 部分不存在于收集器配置文件中时，收集器会将遥测数据转发到 Elastic。

显式启用它不会改变默认行为。

agent_metrics:
  disabled: false

在内部收集遥测数据并将其发送到 Elastic

在此配置中，来自分析代理的遥测数据将发送到 Elastic 和 存储在内部。数据存储在与通用分析数据位于同一 Elasticsearch 集群中的 profiling-metrics* 索引中，并遵循相同的数据保留策略。

agent_metrics:
  disabled: false
  write_all: true

仅在内部收集遥测数据

要收集遥测数据而不将其转发到 Elastic，请配置收集器以在内部存储数据。您可以通过提供 Elasticsearch 主机列表和用于身份验证的 API 密钥来指定用于存储遥测数据的 Elasticsearch 部署。

agent_metrics:
  disabled: false
  addresses: ["https://internal-telemetry-endpoint.es.company.org:9200"]
  api_key: "internal-telemetry-api-key"

完全禁用遥测数据收集

agent_metrics:
  disabled: true
扩展资源
编辑

在资源指南表中，没有选项对符号化器使用多个副本。这是因为多个符号化器副本必须同步要处理的相同帧记录。虽然仍然可以水平扩展，但我们建议首先垂直扩展符号化器，通过增加其使用的内存和 CPU 内核来处理数据。

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

升级自托管堆栈
编辑

升级自托管堆栈包括升级后端应用程序和代理。我们建议先升级后端，然后再升级代理。这样，如果您遇到后端问题，则可以回滚到以前的版本，而无需降级代理。

我们建议部署相同版本的代理和后端。

我们努力保持次要版本之间的向后兼容性。有时，数据格式的更改可能需要部署相同版本的代理和后端。当引入协议中的重大更改时，未更新的分析代理将停止发送数据。代理日志将报告一条错误消息，指示后端与代理不兼容（反之亦然）。

升级过程步骤因使用的安装方法而异。您可能使用了多种安装方法的组合。例如，您可能在 ECE 上部署后端，在 Kubernetes 上部署代理。在这种情况下，请参阅每种方法中的特定部分（后端/代理）。

根据您的基础架构设置，升级后端也可能会更新收集器公开的端点。在这种情况下，请在升级后修改代理配置以连接到新的端点。

ECE编辑

使用 ECE 时，后端的升级过程是新 ECE 版本安装的一部分。您无需执行任何操作即可升级后端应用程序，因为它们将自动升级。

对于代理部署，如果您是通过 Elastic Agent 部署代理，则可以升级安装在 Elastic Agent 上的 Fleet 集成。

ECK 或通用 Kubernetes编辑

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

对于代理部署，通过 Helm 图表进行升级也是最简单的选项。

从 8.15 版本开始，代理 Helm 图表已从 pf-host-agent 重命名为 profiling-agent。

当从 8.14 或更低版本升级到 8.15时，请遵循以下附加说明

  1. 获取当前应用的 Helm 值

    helm -n universal-profiling get values pf-host-agent -oyaml > profiling-agent-values.yaml

  2. 更新仓库以查找新的图表

    helm repo update

  3. 卸载旧图表

    helm -n uninstall pf-host-agent

  4. 按照通用分析“添加数据”页面中显示的说明或使用以下命令安装新图表

    helm install -n universal-profiling universal-profiling-agent elastic/profiling-agent -f profiling-agent-values.yaml
操作系统包编辑

使用操作系统包管理器升级包版本。“添加数据”页面中将提供新包的名称和链接。

并非所有包管理器都会调用 systemd 来重新启动服务，因此您可能需要手动或通过任何其他就位的自动化来重新启动服务。

二进制文件编辑

下载相应的二进制版本并替换现有的二进制版本，使用安装指南“二进制文件”部分中所示的命令。二进制文件 替换旧的二进制文件并重新启动服务。

您可以在“添加数据”页面下的“二进制文件”选项卡中找到新二进制文件的链接。

Kubernetes 提示
编辑

在 Kubernetes 上部署通用分析后端时，需要遵循一些最佳实践。

入口配置编辑

如果您使用的是入口控制器，则应将到收集器服务的连接路由配置为使用 gRPC 协议。

我们在 Helm 图表中提供了一个 Ingress 资源。由于入口可以是任何实现，因此您必须使用 ingress.annotations 字段用类名和任何必要的注释配置控制器。

例如，当使用 NGINX 入口控制器时，请设置注释 nginx.ingress.kubernetes.io/backend-protocol: "GRPC"，如下例所示

ingress:
  create: true
  ingressClassName: "nginx"
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

对于符号化器，连接路由应配置为使用 HTTP 协议。通常不需要为此类型的服务自定义注释，但图表提供了类似的配置选项。

输出 TLS 配置编辑

您可以通过在收集器和符号化器配置文件的 output.elasticsearch 部分启用 TLS 来保护通用分析后端和 Elasticsearch 集群之间的通信。

为此，应在安装后端的命名空间中预配包含 TLS 密钥对的 Kubernetes 密钥。对于自签名证书，用于验证 Elasticsearch 证书的 CA 捆绑包也应该是密钥的一部分。

创建两个密钥，一个用于收集器，一个用于符号化器，名称分别为 pf-symbolizer-tls-certificate 和 pf-collector-tls-certificate。密钥应包含以下密钥

  • tls.key：证书私钥
  • tls.cert：证书公钥
  • ca.cert（可选）：证书 CA 捆绑包

请按照以下步骤启用从收集器/符号化器到 Elasticsearch 的 TLS 连接

  1. 使用 TLS 密钥对创建密钥（如果您不使用自签名 CA，请省略 ca.pem 字段）

    kubectl -n universal-profiling create secret generic pf-collector-tls-certificate --from-file=tls.key=/path/to/key.pem \
--from-file=tls.cert=/path/to/cert.pem --from-file=ca.pem=/path/to/ca.crt
    kubectl -n universal-profiling create secret generic pf-symbolizer-tls-certificate --from-file=tls.key=/path/to/key.pem \
--from-file=tls.cert=/path/to/cert.pem --from-file=ca.pem=/path/to/ca.crt

  2. 更新收集器和符号化器 Helm values 文件以启用 TLS 配置的使用，取消 output.elasticsearch.ssl 部分的注释

    output:
  elasticsearch:
    ssl:
      enabled: true
  3. 使用 helm upgrade 命令升级图表，提供更新的 values 文件。
水平扩展编辑

在 Kubernetes 上扩展通用分析后端时，您可以增加收集器的副本数量，或启用水平 Pod 自动缩放 V2。

要为收集器或符号化器启用 HPAv2，您可以在每个 Helm values 文件中设置 autoscalingV2 字典。

目前，不建议为符号化器启用自动缩放器。由于符号化器副本同步其工作负载的当前限制，最好只对符号化器使用单个副本。首先垂直扩展符号化器。只有在对原生帧进行符号化时出现高延迟 (10 分钟以上) 的情况下，您才能评估添加更多副本。

« 第 5 步：后续步骤 通用性能分析后端故障排除 »