Golang执行bpftrace命令手动运行正常、gRPC调用时命令异常的问题

需求 #

• 解析运行在K8s Pod内部的bpftrace命令输出。

目标Shell命令 #

bpftrace -p 13111 -e uretprobe:/ebpfKit/Examples/cpp/main:enqueue { @[pid] = count(); interval:s:1{ print(@); clear(@); }

现有Go实现代码 #

func RunUretprobe(tool string, loguretprobe chan Log, pid string, filepath string, funcname string) {

		fmt.Println("checkpoint 1")
		command  := `uretprobe:` + filepath + `:` + funcname + `{ @[pid] = count(); }` +`interval:s:1` + `{ print(@); clear(@); }`
		cmd := exec.Command("bpftrace", "-p", pid , "-e", command)
		fmt.Println(cmd)
		stdout, err := cmd.StdoutPipe()
		if err != nil {
			log.Fatal(err)
		}
		cmd.Start()
		buf := bufio.NewReader(stdout)
		fmt.Println("checkpoint 2")
		for {

			line, _, _ := buf.ReadLine()
			parsedLine := strings.Fields(string(line))
			fmt.Println("checkpoint 3 -", cmd)
			if (len(parsedLine) > 0) && parsedLine[0] != "Attaching"{
				s := strings.Split(parsedLine[0], "[")
				sep := strings.Split(s[1], "]")
				log := sep[0] + " " + parsedLine[1]
				timest := 0.00
				fmt.Println("count--", log)
				n := Log{Fulllog: log, Pid: 1234, Time: timest, Probe: tool}
				loguretprobe <- n

			}
		}
}

func main() {

	loguretprobe := make(chan Log, 1)

	go RunUretprobe("uretprobe", loguretprobe, "13111" , "/ebpfKit/Examples/cpp/main" , "enqueue")
	go func() {

		for val := range loguretprobe{

			fmt.Println("Printing - ", val.Fulllog);
			time.Sleep(time.Duration(1) * time.Second)

		}

	}()

	for{
		time.Sleep(time.Duration(1) * time.Second)
	}

}

问题现象 #

• 手动进入Pod运行上述Go程序时，功能完全符合预期；
• 通过gRPC客户端远程调用RunUretprobe方法时，生成的bpftrace命令格式异常，可通过kubectl logs "pod_name"查看Pod日志确认。

预期目标 #

• 生成与手动执行时格式一致的完整bpftrace命令，可正常执行并完成后续输出解析。

• 入参携带脏字符：gRPC链路传递的pid、filepath、funcname参数未做清洗，可能携带首尾空格、换行符、制表符等不可见字符，拼接进bpftrace命令字符串后直接造成格式断裂。手动运行时参数是硬编码的干净值，因此无异常。
• 命令拼接缺少显式分隔：现有代码拼接两个探针块（uretprobe探针、interval探针）时直接将字符串首尾相连，没有添加语法要求的分隔空格。手动运行时硬编码的字符串凑巧满足bpftrace解析规则，一旦拼接环节因为脏字符偏移，立刻出现语法错误，表现为命令格式异常。
• 运行上下文不一致：手动进入Pod运行程序时，Shell的工作目录、环境变量是交互式配置的；gRPC服务长期运行时的工作目录、环境变量可能和手动场景不一致，导致bpftrace解析可执行文件路径、查找探针目标时出错，日志输出的命令看起来格式错乱。
• 序列化补全影响：gRPC框架在处理字符串参数时，可能因为序列化、反序列化的固定长度补全逻辑，给字符串参数添加不可见的填充字符，这类字符在常规日志输出时不可见，但会直接破坏bpftrace的语法规则。
• 变量重名隐患：现有代码在解析循环内定义了名为log的字符串变量，和引入的标准库log包重名，运行时可能因为作用域解析问题出现流程分支异常，输出非预期的命令日志。

• 入参全量清洗：所有外部传入的参数（来自gRPC请求的pid、filepath、funcname）统一用strings.TrimSpace()去除首尾空白字符，对包含特殊符号的参数做拦截校验，避免非法字符拼入命令。
• 修正命令拼接逻辑：使用固定模板生成bpftrace命令，显式补全所有语法要求的空格，替换原有硬拼接的逻辑。修正后的拼接代码示例：

  command := fmt.Sprintf(
    "uretprobe:%s:%s{ @[pid] = count(); } interval:s:1 { print(@); clear(@); }",
    filepath, funcname,
  )
  

  这里重点补全了两个探针块之间、interval:s:1和代码块之间的分隔空格，避免字符串直接相连导致的语法解析失败。
• 修复变量重名问题：将循环内定义的局部字符串变量log重命名为logContent，避免和标准库log包重名，消除作用域解析的隐患。
• 统一执行上下文：给exec.Command生成的cmd实例显式指定工作目录（和手动运行时的目录保持一致），并补全必要的环境变量（比如PATH），消除运行环境差异带来的解析异常。
• 增强日志校验：在cmd.Start()之前，将最终拼接完成的完整command字符串逐字符打印到Pod日志，和手动运行的命令逐位对比，定位缺失的字符、多余的不可见内容。
• 增加前置语法校验：拼接完成后，先把命令字符串打印出来做预检，确认没有语法错误后再启动bpftrace进程，避免格式错误的命令直接被执行。

内容的提问来源于stack exchange，提问作者user10024422