排查通用性能分析后端
编辑排查通用性能分析后端编辑
请参考以下部分来排查在设置或操作通用性能分析后端服务时遇到的任何问题。
应用程序行为编辑
UI 中缺少堆栈跟踪编辑
如果 UI 中的堆栈跟踪数量突然下降，或者 UI 完全没有显示堆栈跟踪，则收集器服务可能遇到问题，因此数据摄取会受到影响。
可以从健康检查和公开的指标推断出收集器的状态。
收集器性能下降的最常见原因是
- 收集器无法连接到 Elasticsearch 集群：连接或身份验证详细信息可能错误
- 收集器无法正常启动：收集器可能在启动时崩溃，或者可能卡在循环中（通过编排系统部署时）：检查日志以查找任何错误
缺少符号编辑
通用性能分析最实用的功能之一是能够显示堆栈跟踪帧的源代码文件和行号。只有在后端服务中正确处理符号时才有可能。
当缺少符号时，UI 将以十六进制地址的形式显示本机应用程序的堆栈跟踪帧，例如 0x1234abcd。如果大多数本机帧（包括公共操作系统软件包文件）都出现这种情况，则表明调试符号未被正确处理。
可以使用健康检查端点和公开的指标来验证符号化器是否正常工作。
符号化器性能下降的最常见原因是
- 符号化器无法连接到调试符号端点：这是一个面向互联网的端点，因此可能被防火墙阻止
- 符号化器无法正常启动：符号化器可能在启动时崩溃，可能是由于配置错误，或者可能卡在循环中（通过编排系统部署时）：检查日志以查找任何错误
一般故障排除编辑
容量规划编辑
在将通用性能分析代理部署到一组新机器时，后端服务可能无法处理负载。如果通用性能分析代理的数量很大，或者如果通用性能分析代理部署在具有大量内核的机器上，则尤其如此。
通用性能分析代理的流量模式容易在启动时出现突发，后端服务可能无法处理来自大量通用性能分析代理的突发流量。
即使后端服务的容量是根据通用性能分析代理的数量（如 资源指南 中建议的那样）进行规划的，我们建议分批部署通用性能分析代理。例如，一次部署 20% 的集群。部署一批通用性能分析代理后，暂停至少 30 到 60 秒，然后再部署下一批，以使后端服务稳定。当通用性能分析代理在新机器上重新启动时，它会扫描所有现有进程并将可执行文件的元数据发送到后端服务。这会导致突发流量，可能会压垮后端服务。
检查指标编辑
一旦后端服务公开指标，就可以检查它们以了解服务的行为。有关如何公开指标的说明，请参阅 指标。
我们尚未提供用于监控服务的预构建 Kibana 仪表板，但我们已经整理了一份最有用指标的列表。goroutines 或内存使用量的突出峰值表明服务处于压力之下，可能遇到问题。如果有可能访问运行后端服务的宿主机上的 Linux 内核遥测数据，则要监控的最重要的指标是 CPU 节流和网络使用情况。
阅读调试日志编辑
可以将后端服务配置为以调试级别记录日志，这对于排查问题很有用。为此，每个 YAML 配置文件都有一个 verbose 配置项，可以将其设置为 true 以启用调试日志记录。可以通过 CLI 标志设置相同的配置选项，如 使用 CLI 标志覆盖配置文件值 中所述。
在以详细模式运行后端服务时，日志将有助于排查问题。
调试日志会创建不适合长时间运行的生产部署的输出。详细模式应仅在一次在一个副本上启用，并且仅在短时间内启用，因为它会降低性能并增加服务的 CPU 使用率。
启用详细模式后，将记录有关服务操作的细粒度信息。对于收集器，负责将数据摄取到 Elasticsearch 的组件将是最频繁的。对于符号化器，大多数日志将与本机帧的处理相关，最初由收集器检测到。
如果您正在排查两种服务的启动问题，日志是最有用的信息来源。在启动时，每个服务都会生成日志，指示它是否能够解析配置并开始处理传入请求。任何启动错误都将使用 log.level=error 字段记录。使用这些错误日志查找可能阻止服务启动的配置错误或其他问题。错误将使用 log.level=error 字段记录：它们可以用于发现阻止服务启动的配置错误或其他问题。