« 第 5 步：后续步骤 排查通用性能分析后端问题 »
Elastic 文档 ›Elastic Observability [8.17] ›基础设施和主机监控 ›通用性能分析 ›在自托管的 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

此表来源于在最多摄取 15,000 个 CPU 核心的通用性能分析上执行的基准测试。进行性能分析的机器具有接近恒定的 75% CPU 利用率负载。该部署使用了 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（对于 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。

例如，以下收集器配置将在端口 9090 上以 Prometheus 格式公开指标，并在端口 9191 上以 JSON 格式公开指标。然后，您可以通过连接到 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 格式。例如，以下收集器配置将在端口 9090 上以 Prometheus 格式公开指标，并在 /tmp/collector.sock 的 Unix 域套接字上以 JSON 格式公开指标。

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 中更新的现有文档数量；当速率增加时，可能会影响 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 上的 Fleet 集成。

ECK 或通用 Kubernetes编辑

使用 helm upgrade 命令执行后端图表的 Helm 升级。您可以重用现有值，也可以在每次升级时提供完整的 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 上部署通用性能分析后端时，应遵循一些最佳实践。

Ingress 配置编辑

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

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

例如，当使用 NGINX Ingress 控制器时，请设置注释 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 步：后续步骤 排查通用性能分析后端问题 »