通用性能分析后端故障排除
编辑通用性能分析后端故障排除
编辑请参考以下部分来排除在设置或操作通用性能分析后端服务时遇到的任何问题。
应用程序行为
编辑如果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 字段记录：它们可用于发现阻止服务启动的错误配置或其他问题。