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