排查通用分析代理部署问题
编辑排查通用分析代理部署问题
编辑您可以使用通用分析代理日志来查找错误。
以下是一个正常的通用分析代理输出示例
time="..." level=info msg="Starting Prodfiler Host Agent v2.4.0 (revision develop-5cce978a, build timestamp 12345678910)" time="..." level=info msg="Interpreter tracers: perl,php,python,hotspot,ruby,v8" time="..." level=info msg="Automatically determining environment and machine ID ..." time="..." level=warning msg="Environment tester (gcp) failed: failed to get GCP metadata: Get \"http://169.254.169.254/computeMetadata/v1/instance/id\": dial tcp 169.254.169.254:80: i/o timeout" time="..." level=warning msg="Environment tester (azure) failed: failed to get azure metadata: Get \"http://169.254.169.254/metadata/instance/compute?api-version=2020-09-01&format=json\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" time="..." level=warning msg="Environment tester (aws) failed: failed to get aws metadata: EC2MetadataRequestError: failed to get EC2 instance identity document\ncaused by: RequestError: send request failed\ncaused by: Get \"http://169.254.169.254/latest/dynamic/instance-identity/document\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" time="..." level=info msg="Environment: hardware, machine ID: 0xdeadbeefdeadbeef" time="..." level=info msg="Assigned ProjectID: 5" time="..." level=info msg="Start CPU metrics" time="..." level=info msg="Start I/O metrics" time="..." level=info msg="Found tpbase offset: 9320 (via x86_fsbase_write_task)" time="..." level=info msg="Environment variable KUBERNETES_SERVICE_HOST not set" time="..." level=info msg="Supports eBPF map batch operations" time="..." level=info msg="eBPF tracer loaded" time="..." level=info msg="Attached tracer program" time="..." level=info msg="Attached sched monitor"
如果以下命令的输出为空,则表示通用分析代理部署正在工作
head host-agent.log -n 15 | grep "level=error"
如果运行此命令输出错误级别的日志,则可能有以下原因
-
通用分析代理正在不支持的 Linux 内核版本上运行,或者缺少内核功能。
如果通用分析代理在不支持的内核版本上运行,则会记录以下内容
Universal Profiling Agent requires kernel version 4.19 or newer but got 3.10.0
如果内核中没有 eBPF 功能,则通用分析代理将无法启动,并且会记录以下内容之一
Failed to probe eBPF syscall
或
Failed to probe tracepoint
-
通用分析代理无法连接到 Elastic Cloud。在这种情况下,会记录类似于以下内容的消息
Failed to setup gRPC connection (retrying...): context deadline exceeded
验证
collection-agent
配置值已设置,并且等于单击 添加数据 时在 Kibana 中打印的值。 -
密钥令牌无效或已更改。在这种情况下,通用分析代理将关闭,并记录类似于以下内容的消息
rpc error: code = Unauthenticated desc = authentication failed
-
通用分析代理无法将数据发送到您的部署。在这种情况下,会记录类似于以下内容的消息
Failed to report hostinfo (retrying...): rpc error: code = Unimplemented desc = unknown service collectionagent.CollectionAgent"
这通常意味着您的 Elastic Cloud 集群尚未配置为进行通用分析。要配置您的 Elastic Cloud 集群,请按照配置数据摄取中的步骤进行操作。
-
收集器(Elastic Cloud 中接收来自通用分析代理的数据的后端部分)内存不足。在这种情况下,会记录类似于以下内容的消息
Error: failed to invoke XXX(): Unavailable rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 502 (Bad Gateway); transport: received unexpected content-type "application/json; charset=UTF-8"
通过导航到 Elastic Cloud → 部署 →
<部署名称>
→ 集成服务器 (在Elastic Cloud中),验证收集器是否正在运行。如果 Profiling 旁边的 复制端点 链接显示为灰色,则您需要通过单击 集成服务器管理 下的 强制重启 来重启收集器。对于非演示工作负载,请验证集成服务器至少具有建议的 4GB RAM。您可以在 实例 下的集成服务器页面上检查此信息。
-
通用分析代理与 Elastic Stack 版本不兼容。在这种情况下,会记录以下消息
rpc error: code = FailedPrecondition desc= HostAgent version is unsupported, please upgrade to the latest version
请按照 Kibana 中显示的通用分析代理部署说明进行操作,该说明始终适用于您正在使用的 Elastic Stack 版本。
-
您正在使用较新 Elastic Stack 版本的通用分析代理,该代理配置为连接到较旧的 Elastic Stack 版本集群。在这种情况下,会记录以下消息
rpc error: code = FailedPrecondition desc= Backend is incompatible with HostAgent, please check your configuration
请按照 Kibana 中显示的通用分析代理部署说明进行操作,该说明始终适用于您正在使用的 Elastic Stack 版本。
如果您无法找到解决通用分析代理故障的方案,可以提出支持请求,将 通用分析
和 通用分析代理
指示为问题来源。
在通用分析代理中启用详细日志记录
编辑在支持过程中,您可能会被要求提供来自部署中某个通用分析代理安装的调试日志。
要启用调试日志,请在命令行中添加 -verbose
标志,或在配置文件中添加 verbose true
设置。
我们建议仅在通用分析代理的单个实例上启用调试日志,而不是在整个部署中启用,以限制产生的日志量。
缩短加载时间
编辑使用慢速连接(例如,DSL 或移动网络)时,火焰图、TopN 函数和跟踪视图的加载数据量可能会导致延迟。
设置 Kibana 集群选项 server.compression.brotli.enabled: true
可减少传输的数据量,并应缩短加载时间。
排查通用分析代理 Kubernetes 部署问题
编辑Helm 图表安装完成后,输出将包含有关如何检查通用分析代理 Pod 状态和读取日志的说明。以下部分提供了通用分析代理安装 不正常 时的潜在情况。
污点
编辑Kubernetes 集群通常在其设置中包含污点和容忍度。在这种情况下,即使对于大型集群,通用分析代理安装也可能显示没有 Pod 或只有极少数 Pod 正在运行。
这是因为污点会阻止 Pod 在节点上执行,除非该工作负载已被容忍。Helm 图表 values.yaml
中的 tolerations
键使用官方 Kubernetes 调度 API 格式设置对污点的容忍度。
以下示例提供了您可以添加到 Helm 图表 values.yaml
的 tolerations
配置
-
要在所有具有污点
workload=python:NoExecute
的节点上部署通用分析代理,请将以下内容添加到values.yaml
tolerations: - key: "workload" value: "python" effect: "NoExecute"
-
要在所有具有键
production
和效果NoSchedule
(未提供值)的污点节点上部署通用分析代理,请将以下内容添加到values.yaml
tolerations: - key: "production" effect: "NoSchedule" operator: Exists
-
要在所有节点上部署通用分析代理,容忍所有污点,请将以下内容添加到
values.yaml
tolerations: - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists
安全策略实施
编辑某些 Kubernetes 集群配置了强化的安全插件,以限制受攻击应用程序漏洞的影响范围。不同的强化方法可能会损害通用分析代理的操作,例如,可能会导致 Pod 在显示 CrashLoopBackoff
状态后不断重启。
此 Kubernetes API 已弃用,但有些人仍然使用它。PodSecurityPolicy (PSP) 可能会明确禁止在整个集群中执行 privileged
容器。
由于通用分析代理在大多数内核/CRI 中需要特权,因此您需要构建 PSP 以允许通用分析代理 DaemonSet 运行。
在SIG-Security 文档中阅读有关 Kubernetes 策略引擎的更多信息。
以下工具可能会阻止通用分析代理 Pod 的执行,因为 Helm 图表会构建一个集群角色并将其绑定到通用分析代理服务帐户(我们将其用于容器元数据)
- Open Policy Agent Gatekeeper
- Kyverno
- Fairwinds Polaris
如果您的策略引擎已就位,请将其配置为允许通用分析代理执行和 RBAC 配置。
在某些情况下,您的通用分析代理 Pod 可能运行良好,但它们不会连接到远程数据收集器 gRPC 接口,并且会停留在启动阶段,同时尝试定期连接。
以下是潜在原因
- Kubernetes
NetworkPolicies
定义了连接规则,这些规则会阻止所有传出流量,除非明确允许列入白名单。 - 云或数据中心提供商网络规则仅限制到允许目标的传出流量 (ACL)。
这些设置不是 Kubernetes 的一部分,可能已包含在节点设置中。它们可能会阻止通用分析代理正常工作,因为它们会拦截从通用分析代理到内核的系统调用并修改或阻止它们。
如果您已实施安全强化(下面列出了一些提供商),您应该知道通用分析代理需要的特权。
- GKE 上的 gVisor
- seccomp 过滤器
- AppArmor LSM
提交支持请求
编辑您可以从 Elastic Cloud 控制台中的支持请求页面提交支持请求。
在支持请求中,请指定您的问题是与通用分析代理还是 Kibana 应用程序有关。
发送反馈
编辑如果故障排除和支持无法解决您的问题,或者您有任何其他想要分享的有关产品的反馈,请发送电子邮件至 [email protected]
给通用分析团队。