Kubernetes 中的 Go 应用程序监控

Site24x7 APM Insight for Kubernetes 使用扩展伯克利数据包过滤器（eBPF）技术，实现对 Kubernetes 集群中运行的 Go 应用程序的自动监控。这种方法无需修改应用程序代码或注入特定语言的代理即可监控性能。
本指南介绍 Kubernetes 中 Go 应用程序监控的架构、组件和监控工作流程。

常用术语

• DaemonSet：确保集群中每个节点上自动运行一个代理 Pod，对所有应用 Pod 提供持续可见性。
• /host/proc 挂载：将宿主机的 /proc 文件系统挂载到代理容器内，使其能够读取宿主机级别的进程信息。
• Cgroup 映射：用于识别某个进程属于哪个容器或 Pod。
• Inode：文件系统中表示文件元数据和位置的唯一标识符。
• eBPF uprobe：用户态探针，用于在不修改代码的情况下追踪应用二进制文件中的函数调用。
• Instrumentor（插桩器）：一种轻量级进程，用于加载 eBPF 程序并收集运行时遥测数据。
• 位置无关可执行文件（PIE）：可在任意内存地址运行的可执行文件，支持地址空间布局随机化（ASLR）等安全特性。
• OverlayFS：一种分层文件系统，将只读镜像层与可写层合并为统一视图。
• Helm charts：预打包的模板，简化 Kubernetes 应用程序的安装和管理。

Kubernetes 中 Go 应用监控的架构图

以下架构图概述了 Kubernetes 环境中监控的工作方式。

您的 Go 应用程序运行在应用 Pod 内。每个节点上有一个专用的 APM Insight 代理 Pod 以 DaemonSet 方式部署，负责处理所有监控任务。下面详细介绍图中各个组件。

APM Insight Go 代理

APM Insight Go 代理是整个系统的控制器和编排器。它通过宿主机进程标识符（PID）和 /host/proc 挂载，发现节点上所有 Pod 中正在运行的 Go 进程，并提取元数据，包括命令行参数、环境变量、容器 ID、Pod 关联关系和 cgroup 映射。

代理应用用户定义的规则来确定哪些应用程序需要插桩。它通过共享 hostPath 解析二进制路径，以确保 eBPF uprobe 附加时 inode 或设备号的稳定性。最后，当 Pod 出现、重启或终止时，代理负责管理插桩器进程的生命周期。

APM Insight Instrumentor

Instrumentor 将 eBPF 程序加载到内核中，并将 uprobe 附加到选定的 Go 函数。它可以捕获函数调用、返回值、延迟、错误和执行路径，而无需修改应用程序或注入库。Instrumentor 还会执行符号解析、运行时偏移映射以及位置无关可执行文件（PIE）的函数地址计算。最后，它通过环形缓冲区将轻量级遥测事件流式传输到用户态收集器。

S247DataExporter

S247DataExporter 将 eBPF 事件转换为标准的 OpenTelemetry Span 和指标，并使用 Kubernetes 元数据（包括 Pod 名称、命名空间、节点、容器 ID、IP 地址和标签）对数据进行丰富。然后，Exporter 使用 OpenTelemetry Protocol（OTLP）将遥测数据发送到 Site24x7 后端，并通过批处理、重试逻辑和背压管理确保数据可靠传输。

共享卷与宿主机访问

共享 hostPath 卷（例如 /var/lib/apm-binaries）将应用程序二进制文件存储在节点的真实文件系统上。这样可以确保 inode 和设备号的稳定性，避免大多数容器运行时中 OverlayFS 带来的不一致性。代理 Pod 还会访问宿主机资源（如 /proc、/sys/kernel/debug 和 /sys/fs/bpf），以发现进程并管理 eBPF 程序。应用 Pod 直接从共享 hostPath 运行二进制文件，确保内核看到的是代理插桩所对应的确切二进制文件。

总结整个监控工作流程：DaemonSet 确保每个节点上运行一个代理 Pod，并随着节点的加入或移除自动调整。Go 代理发现运行中的进程，并为每个符合条件的 Go 应用启动一个 Instrumentor。Instrumentor 附加 eBPF 探针以捕获性能数据，对性能影响极小。最后，S247DataExporter 将遥测数据（包括追踪、指标和错误）转发到 Site24x7 后端进行可视化和分析。

该架构的主要优势

该架构完全基于事件驱动，具备自适应能力，能够自动发现新 Pod，在滚动更新或重启期间重新附加探针，无需对 CI/CD 流水线、应用镜像、Helm charts 或启动脚本进行任何修改。

支持的 Kubernetes 平台

Site24x7 APM Insight for Kubernetes 支持以下托管 Kubernetes 平台：

Kubernetes 中 Go 应用监控的最佳实践

为确保 Kubernetes 中 Go 应用程序的监控顺畅可靠，请遵循以下最佳实践：

• 使用专用命名空间：将监控代理部署在独立的监控命名空间中，使其与应用工作负载相隔离。
• 设置合理的资源限制：根据集群规模分配 CPU 和内存限制，防止资源争用并确保代理性能稳定。
• 为节点添加标签：使用节点标签和选择器，使代理仅在您需要监控的节点上运行。
• 固定镜像版本：在生产环境中使用固定镜像标签，而非 latest，以避免意外升级或行为变更。
• 监控代理健康状态：设置告警，及时通知您 DaemonSet Pod 的故障、重启或代理健康状态的异常波动。
• 定期更新代理：保持代理版本最新，以获取最新的修复、增强功能和安全改进。
• 在预发布环境中验证变更：在将新代理版本或配置变更部署到生产环境之前，先在预发布环境中进行测试。
• 使用一致的二进制文件名称：确保 Go 应用程序二进制文件在各环境中遵循可预测且一致的命名规范，以避免发现问题。
• 验证 hostPath 权限：确认 /var/lib/apm-binaries 目录具有正确的权限（755），使代理能够无误地访问二进制文件。
• 确保网络访问：如果您使用了 Kubernetes 网络策略，请确保代理具有到 Site24x7 端点的出站访问权限，以便成功发送指标和追踪数据。

常见问题

1. 为什么需要 hostPath？代理不能直接从容器访问二进制文件吗？

容器化应用程序通常运行在 OverlayFS 上，其中二进制文件分散存储在多个文件系统层中，导致 inode 和设备号不一致，从而无法可靠地将 eBPF uprobe 附加到函数。

使用 hostPath 卷可以提供：

• 二进制文件的一致、稳定视图。
• 应用程序和代理之间匹配的 inode 或设备号。
• 完全规避 OverlayFS 局限性的解决方案。

2. 代理会监控机器上所有运行的 Go 进程吗？

不会。代理会发现机器上的所有进程，但只对 GO_APPS（Go 应用程序）环境变量中明确列出的进程进行插桩。插桩完全由您的配置控制。

3. 代理会修改或更改 Go 应用程序的二进制文件吗？

不会。代理在运行时通过 eBPF uprobe 在内存中进行插桩，探针附加在内核级别的运行时进程上，磁盘上的应用程序二进制文件保持不变。

4. 应用程序重启时会发生什么？

代理包含一个每 30 秒运行一次的编排器。当检测到重启（PID 变更）时，它会自动：

1. 停止现有的 Instrumentor。
2. 识别新的进程 PID。
3. 启动新的 Instrumentor。
4. 将 eBPF 探针重新附加到新进程。

5. 我可以监控在不同 Kubernetes 命名空间中运行的应用程序吗？

可以。DaemonSet 以 hostPID 运行。当该选项设置为 true 时，无论进程属于哪个命名空间，都可以看到节点上的所有进程。请确保您的 GO_APPS 配置中包含所有必要的进程名称。

6. 使用基于 eBPF 的插桩的性能开销是多少？

eBPF 插桩设计为轻量级且高效，对系统性能的影响极小。

典型开销：

• CPU：< 5%
• 内存：极小（内核空间中的少量 eBPF map）
• 延迟：每个被追踪函数仅微秒级

实际开销会因应用负载和被插桩函数的数量而有所不同。

7. 该方案是否支持 EKS、GKE 和 AKS？

是的，Site24x7 APM Insight for Kubernetes 支持所有三个托管 Kubernetes 平台，但各平台有一些特定要求。

相关文章

• Kubernetes 中 Go 应用程序的监控设置
• Kubernetes 中 Go 应用程序监控故障排除提示