操作 Universal Profiling 后端

Elastic Stack

本页概述了在自管理版本的 Elastic Stack 上运行 Universal Profiling 时操作后端的情况。在这里，您将找到以下相关信息：

资源大小调整
配置收集器和符号器
监控收集器和符号器
缩放资源
升级后端二进制文件
Kubernetes 提示

资源指南

摄取和查询 Universal Profiling 数据所需的资源因您要分析的 CPU 核心总数而异。核心数量来自 /proc/cpuinfo 中记录的所有虚拟核心的总和，并将部署 Universal Profiling 代理的所有机器加起来。

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

下表根据您的 CPU 核心数提供了推荐的用于摄取和查询 Universal Profiling 数据的资源

CPU 核心数	Elasticsearch 总内存	Elasticsearch 总存储 (保留 60 天)	Profiling 后端	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

注意

此表源自对 Universal Profiling 执行的基准测试，其中最多摄取了 15,000 个 CPU 核心。被分析的机器的 CPU 利用率接近恒定的 75%。该部署使用了 3 个 Elasticsearch 节点，每个节点具有 64 GB 内存、8 个 vCPU 和 1.5 TB NVMe 磁盘驱动器。

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

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

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

配置收集器和符号器

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

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

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

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

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

监控

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

日志

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

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

日志格式为“key=value”对，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：运行时创建的 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 中更新的现有文档数；当速率增加时，可能会影响 Elasticsearch 性能。

运行状况检查

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

运行状况检查端点托管在接受传入分析数据的同一 HTTP 服务器中。此端点通过应用程序的 host 配置选项进行配置。

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

Profiling 代理遥测数据

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

默认情况下，所有分析代理收集的遥测数据都会发送到收集器，然后收集器通过互联网将其转发到 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 时，请按照以下附加说明进行操作

获取当前应用的 Helm 值

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

	

更新存储库以查找新图表
```
helm repo update
```
卸载旧图表
```
helm -n uninstall pf-host-agent
```

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

		helm install -n universal-profiling universal-profiling-agent elastic/profiling-agent -f profiling-agent-values.yaml

	

OS 包

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

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

二进制文件

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

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

Kubernetes 提示

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

Ingress 配置

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

我们提供一个 Ingress 资源作为 Helm 图表的一部分。由于入口可以是任何实现，因此您必须使用 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 配置

目前，即使 pf-elastic-collector 和 pf-elastic-symbolizer 配置包含 ssl 部分，也不支持在应用程序级别终止 TLS 连接。相反，您应该使用入口控制器来终止 TLS 连接并将未加密的流量转发到后端服务。

要启用 TLS 终止，请在 ingress 资源中配置 tls 部分，如上一节所示。收集器和符号器 Helm 图表都支持 ingress.tls 部分，您可以在其中指定 TLS 密钥名称和证书应使用的主机。

我们建议使用证书管理器，例如cert-manager来自动执行入口资源的证书配置和续订。

有关如何使用 NGINX 入口控制器配置 TLS 终止的示例，请参阅Kubernetes 入口文档。

一般来说，步骤如下

将您的 TLS 证书存储在与收集器和/或符号器相同的命名空间中的 Kubernetes 密钥中。

		kubectl -n universal-profiling create secret tls my-tls-secret --cert=path/to/cert.pem --key=path/to/key.pem

	

在用于运行后端应用程序的 Helm values 文件中配置 ingress.tls 部分，例如

		ingress:
  <other configs...>
  tls:
    - secretName: my-tls-secret
      hosts:
        - my-host.com

	

使用 helm upgrade 部署图表，并传入更新的 values 文件。

输出 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 连接

使用 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

更新收集器和符号器 Helm values 文件以启用 TLS 配置的使用，取消注释 output.elasticsearch.ssl 部分
```
output:
  elasticsearch:
    ssl:
      enabled: true
```
使用 helm upgrade 命令升级图表，并提供更新的 values 文件。

水平缩放

在 Kubernetes 上扩展通用分析后端时，您可以增加收集器的副本数量，或者启用 Horizontal Pod Autoscaling V2。

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

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