# go-ebpf

**Repository Path**: xingwei-liu/go-ebpf

## Basic Information

- **Project Name**: go-ebpf
- **Description**: 使用go开发的ebpf程序
- **Primary Language**: Go
- **License**: MulanPSL-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2025-12-15
- **Last Updated**: 2026-01-24

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Go eBPF 示例项目

这是一个使用 Go 和 eBPF 的示例项目，展示了如何使用 [cilium/ebpf](https://github.com/cilium/ebpf) 库来创建和加载 eBPF 程序。

## 功能

这个项目包含两个主要的监控功能：

1. **系统调用监控**     - 跟踪 `openat` 系统调用的执行次数
2. **内存回收监控**     - 监控内存回收和压缩活动（移植自 SysAK 的 reclaimhung 工具）
3. **ACL跟踪监控**      - 跟踪文件系统ACL设置活动（移植自 SysAK 的 acltrace 工具）
4. **信号跟踪监控**     - 跟踪进程间信号发送活动（移植自 SysAK 的 tracesig 工具）
5. **内存图谱检查**     - 内存使用分析和可视化（移植自 SysAK 的 memgraph 工具）
6. **系统诊断检查**     - 系统异常检测和诊断（移植自 SysAK 的 ossre_client 工具）
7. **负载任务检查**     - 系统负载分析和任务监控（移植自 SysAK 的 loadtask 等工具）
8. **TCP Ping 监控**      - 测量 TCP 三次握手各阶段延迟（移植自 SysAK 的 tcpping 工具）
9. **Socket/TCP 内存检查** - 检查 TCP 内存使用和 Socket 泄漏（移植自 SysAK 的 skcheck 工具）

## 项目结构

```
go-ebpf/
├── main.go                    # 主程序入口，支持多种监控模式
├── types.go                   # 通用数据结构和工具函数
├── go.mod                     # Go 模块依赖管理
├── Makefile                   # 构建脚本和自动化任务
├── README.md                  # 项目文档和使用说明
├── LICENSE                    # 项目许可证
├── bpf/                       # eBPF 程序源代码目录
│   ├── helloworld.c          # 系统调用跟踪程序（openat）
│   ├── reclaimhung.c         # 内存回收和压缩监控程序
│   ├── acltrace.c            # 文件系统ACL设置跟踪程序
│   ├── tracesig.c            # 进程间信号发送跟踪程序
│   └── tcpping.c             # TCP Ping 监控程序
│
├── ebpfobjs/                 # BPF 程序生成的 Go 绑定代码
│
├── monitor/                   # 核心监控功能实现
│   ├── acltrace_monitor.go    # ACL跟踪监控器实现
│   ├── reclaimhung_monitor.go # 内存回收监控器实现
│   ├── syscall_monitor.go     # 系统调用监控器实现
│   ├── tracesig_monitor.go    # 信号跟踪监控器实现
│   ├── tcpping_monitor.go     # TCP Ping 监控器实现
│   └── helpers.go             # 监控器通用辅助函数
│
└── tools/                    # 扩展工具和功能模块
    ├── loadtask/             # 系统负载分析和任务监控
    │   ├── cpu_flamegraph.go # CPU火焰图生成工具
    │   ├── cpu_flamegraph    # 编译后的火焰图工具
    │   ├── loadtask.go       # 负载任务监控主程序
    │   ├── flamegraph.pl     # 火焰图生成Perl脚本
    │   └── stackcollapse-perf.pl # perf数据折叠脚本
    │
    ├── memgraph/             # 内存泄露检测与碎片化分析
    │   ├── memgraph.go       # 内存图分析主程序
    │   └── memgraph_const.go # 内存图常量定义
    │
    └── ossre/                # 系统诊断工具（OSSRE客户端）
        ├── ossre.go          # OSSRE客户端主程序
        └── internal/         # OSSRE内部实现
            ├── checkers/     # 各种系统检查器
            ├── collectors/   # 数据收集器
            ├── config/       # 配置管理
            ├── diagnosis/    # 诊断引擎
            ├── models/       # 数据模型
            ├── output/       # 输出格式化
            ├── rules/        # 诊断规则
            └── utils/        # 工具函数

```

## 依赖要求

- Go 1.22+
- clang 11+ (用于编译 eBPF 程序)
- Linux 内核 4.14+ (支持 eBPF)
- 内核配置启用了 eBPF 相关选项

## 快速开始

### 1. 安装依赖
```bash
make deps
```

### 2. 构建项目
```bash
make all
```

### 3. 运行程序

#### 系统调用监控（默认）
```bash
# 默认监控10秒
sudo ./go-ebpf

# 指定监控时间
sudo ./go-ebpf syscall -t 60
```

#### 内存回收监控
```bash
# 监控内存回收活动，持续30秒
sudo ./go-ebpf reclaimhung -t 30
```

#### ACL跟踪监控
```bash
# 监控文件系统ACL设置活动，持续30秒
sudo ./go-ebpf acltrace -t 30
```

#### 信号跟踪监控
```bash
# 监控所有信号发送活动，持续30秒
sudo ./go-ebpf tracesig -t 30

# 只监控指定进程名的信号接收者
sudo ./go-ebpf tracesig -c bash -t 30
```

#### 内存图谱检查
```bash
# 收集 5 次内存性能数据到test文件
sudo ./go-ebpf memgraph -j ~/test -g -l -f -k -c 5
```

#### 系统诊断检查
```bash
# 打开调试模式（日志信息、内部执行步骤、错误详情等）并输出json格式数据
sudo ./go-ebpf ossre_client  -d -f json
```

#### 负载任务检查
```bash
# 收集cpu火焰图
sudo ./go-ebpf loadtask -s -g
```

#### TCP Ping 监控
```bash
# 标准用法
sudo ./go-ebpf tcpping baidu.com:80 -c 3

# 指定源IP和端口
sudo ./go-ebpf tcpping -s 127.0.0.1 -p 50000 127.0.0.1:22

# 使用 -d 分离目标
sudo ./go-ebpf tcpping -d baidu.com -q 80 -c 1
```


## 命令行参数

```bash
Usage: ./go-ebpf [command] [options]

Commands:
  syscall      监控系统调用 (默认)
  reclaimhung  监控内存回收和压缩活动
  acltrace     监控文件系统ACL设置活动
  tracesig     跟踪进程间信号发送活动
  memgraph     内存泄露检测与碎片化
  ossre_client 系统诊断
  loadtask     系统负载分析和任务监控
  tcpping      TCP Ping 监控 (详细延迟分析)
  skcheck      TCP 内存和 Socket 泄漏检查

Options:
  -t duration  监控持续时间(秒), 默认10秒
  -c count     包数量 (tcpping专用)
  -s sip       源IP (tcpping专用)
  -d dip       目的IP (tcpping专用)
  -p sport     源端口 (tcpping专用)
  -q dport     目的端口 (tcpping专用)
  -h           显示帮助信息
```

## 内存回收监控功能

内存回收监控功能移植自 SysAK 的 reclaimhung 工具，可以监控以下活动：

### 监控类型

1. **直接内存回收 (Direct Reclaim)**
   - 监控进程直接回收内存页面的情况
   - 显示 PID、进程名、回收次数、延迟时间

2. **内存压缩 (Compaction)**
   - 监控内存压缩操作
   - 显示压缩次数和相关统计信息

3. **Cgroup 内存回收**
   - 监控控制组内存回收活动
   - 适用于容器化环境

### 输出示例

```
开始监控内存回收和压缩活动，持续 30 秒...
按 Ctrl+C 可以中断监控

监控时间结束，输出统计结果:

=== 直接内存回收统计 ===
PID              进程名              回收次数             延迟(ms)           运行时间(s.ms)
1234             nginx               5                    1.023              45.234
5678             mysql               12                   2.046              46.123

=== 内存压缩统计 ===
PID              进程名              压缩次数             延迟(ms)           运行时间(s.ms)
1234             nginx               2                    0.512              45.567

=== Cgroup内存回收统计 ===
PID              进程名              回收次数             延迟(ms)           运行时间(s.ms)
5678             mysql               8                    1.534              46.789
```

## 内存回收监控功能测试

### 测试环境要求
- Linux 内核 4.14+ 支持相关 tracepoint
- 系统内存充足以模拟内存压力场景
- 安装 stress 工具用于创建内存压力

### 功能验证测试

#### 1. 直接内存回收测试
触发系统级内存回收：
```bash
# 启动内存回收监控
sudo ./go-ebpf reclaimhung -t 20 &

# 创建内存压力（分配2GB内存）
sudo stress --vm 8 --vm-bytes 2G --timeout 10s
```

#### 2. 内存压缩测试
通过大量内存分配触发内存压缩：
```bash
# 启动内存回收监控
sudo ./go-ebpf reclaimhung -t 15 &

# 创建内存压力（分配1.5GB内存）
sudo stress --vm 6 --vm-bytes 1.5G --timeout 8s
```

#### 3. Cgroup内存回收测试
使用systemd创建受限内存环境：

**方法1：使用systemd-run（推荐）**
```bash
# 启动内存回收监控
sudo ./go-ebpf reclaimhung -t 10 &

# 在50MB内存限制下运行压力测试
sudo systemd-run --unit=test-memory --scope -p MemoryMax=50M stress --vm 1 --vm-bytes 80M --timeout 5s
```

**方法2：使用cgroup v2手动创建**
```bash
# 创建cgroup并启用内存控制器
sudo mkdir -p /sys/fs/cgroup/test_memory
sudo echo "+memory" | sudo tee /sys/fs/cgroup/test_memory/cgroup.subtree_control

# 设置内存限制
sudo echo 50M | sudo tee /sys/fs/cgroup/test_memory/memory.max

# 启动内存回收监控
sudo ./go-ebpf reclaimhung -t 10 &

# 在cgroup中运行压力测试
sudo systemd-run --unit=test-memory2 --scope -p MemoryMax=50M stress --vm 1 --vm-bytes 80M --timeout 5s
```

#### 4. 测试结果示例
```
=== 直接内存回收统计 ===
PID              进程名              回收次数             延迟(ms)           运行时间(s.ms)
1691125          stress           3469             1518               15.234
1691122          stress           3419             0                  15.123

=== 内存压缩统计 ===
PID              进程名              压缩次数             延迟(ms)           运行时间(s.ms)
113              kcompactd0       8                0                  12.890

=== Cgroup内存回收统计 ===
PID              进程名              回收次数             延迟(ms)           运行时间(s.ms)
1915607          stress           4903             0                  18.540
```

**注意**：时间显示格式说明：
- **运行时间(s.ms)**：显示为内存回收事件发生时相对于系统启动的时间，格式为"秒.毫秒"（如：15.234 表示系统启动后15秒234毫秒）
- **延迟(ms)**：显示内存回收操作的耗时，单位为毫秒
- 这种格式更适合性能分析，专注于相对时间和延迟测量

### 性能指标说明
- **回收次数**：进程触发内存回收的次数
- **延迟(ms)**：内存回收操作的耗时（毫秒）
- **运行时间(s.ms)**：操作发生的时间（相对于系统启动的秒.毫秒）
- **kcompactd0**：内核压缩守护进程
- **回收延迟**：直接回收通常延迟较高（微秒到毫秒级），cgroup回收延迟较低（几十微秒级）

## ACL跟踪监控功能测试

### 测试环境要求
- Linux 内核 4.14+ 支持相关 tracepoint
- 系统支持ACL（访问控制列表）功能
- 安装 setfacl/getfacl 工具（通常在 acl 软件包中）

### 功能验证测试

#### 1. 基本ACL设置跟踪测试
测试acltrace监控文件ACL设置活动的能力：
```bash
# 启动ACL跟踪监控
sudo ./go-ebpf acltrace -t 10 &

# 等待2秒后执行ACL设置操作
sleep 2

# 创建测试文件并设置ACL
rm -rf testfile1.txt
touch testfile1.txt
setfacl -m u:root:-w- testfile1.txt
```

**预期结果**：
```
=== ACL设置统计 ===
PID          进程名              文件名                              ACL属性                            次数           时间
XXXXXX       setfacl          testfile1.txt                    u:root:-w-                       1            XXXXXXX.XXX
```

#### 2. 多种ACL操作测试
测试不同类型的ACL设置操作：
```bash
# 启动ACL跟踪监控
sudo ./go-ebpf acltrace -t 15 &

# 执行多种ACL操作
sleep 2
touch testfile2.txt
touch testfile3.txt

# 设置用户ACL
setfacl -m u:root:rwx testfile2.txt

# 设置组ACL
setfacl -m g:users:r-x testfile3.txt

# 设置默认ACL
setfacl -d -m u:root:rwx testdir 2>/dev/null || mkdir testdir && setfacl -d -m u:root:rwx testdir
```

**预期结果**：
监控器应该捕获所有ACL设置操作，显示不同的进程名、文件名和ACL属性。

#### 3. 权限拒绝测试
测试acltrace对权限拒绝场景的跟踪：
```bash
# 启动ACL跟踪监控
sudo ./go-ebpf acltrace -t 10 &

# 创建一个受保护的文件
sleep 2
touch protected.txt
chmod 600 protected.txt

# 尝试设置ACL（可能会失败，但仍应被跟踪）
setfacl -m u:nobody:r-x protected.txt 2>/dev/null || true
```

**预期结果**：
即使ACL设置失败，系统调用仍然会被跟踪和记录。

### 测试结果说明

#### 输出字段解释
- **PID**：执行ACL设置的进程ID
- **进程名**：执行ACL设置的进程名称（通常是setfacl）
- **文件名**：被设置ACL的目标文件或目录
- **ACL属性**：具体的ACL设置（如u:root:-w-表示用户root有写权限）
- **次数**：该进程执行的ACL设置操作次数
- **时间**：操作发生的时间（相对于系统启动的秒.毫秒）

#### ACL属性格式
- **u:用户名:权限**：用户ACL（如u:root:rwx）
- **g:组名:权限**：组ACL（如g:users:r-x）
- **d:u:用户名:权限**：默认用户ACL
- **d:g:组名:权限**：默认组ACL

#### 常见权限字符
- **r**：读权限
- **w**：写权限
- **x**：执行权限
- **-**：无权限

### 性能注意事项
- ACL跟踪对系统性能影响很小，因为只跟踪系统调用入口
- 大量ACL操作可能会产生较多的监控数据
- 建议在测试环境中进行大规模ACL操作测试

## 信号跟踪监控功能

信号跟踪监控功能移植自 SysAK 的 tracesig 工具，可以监控进程间信号发送活动：

### 监控类型

1. **信号发送跟踪**
   - 监控进程发送信号给其他进程的情况
   - 显示发送者PID、接收者PID、信号编号
   - 记录发送时间、进程名、工作目录

2. **信号接收者过滤**
   - 支持按接收进程名过滤
   - 只显示指定进程接收到的信号

3. **详细信息记录**
   - 信号发送者的命令行参数
   - 父进程信息
   - 当前工作目录

### 输出示例

```
=== 信号发送统计 ===
发送者PID    发送者进程名      目标进程名        信号编号     目标PID          工作目录                          时间

1234         bash             test.sh          SIGTERM    5678             /root/tmp/                        1218119.311
  父进程: sshd[1221]
```

### 信号跟踪监控功能测试

### 测试环境要求
- Linux 内核 4.14+ 支持相关 kprobe 和 tracepoint
- 系统支持进程间信号通信
- 具有基本的信号发送和接收测试环境

### 功能验证测试

#### 1. 基本信号跟踪测试
测试tracesig监控信号发送活动的能力：
```bash
# 启动信号跟踪监控
sudo ./go-ebpf tracesig -t 10 &

# 在另一个终端中执行信号发送操作
sleep 100 &
kill -TERM $!  # 发送SIGTERM信号给sleep进程
```

**预期结果**：
```
=== 信号发送统计 ===
发送者PID    发送者进程名      目标进程名        信号编号     目标PID          工作目录                          时间
XXXXXX       bash             sleep            SIGTERM    XXXXXX           /current/directory               XXXXXXX.XXX
```

#### 2. 指定进程过滤测试
测试按接收进程名过滤功能：
```bash
# 启动信号跟踪监控，只监控bash进程
sudo ./go-ebpf tracesig -c bash -t 15 &

# 在另一个终端中执行信号发送操作
bash -c "sleep 100" &
kill -TERM $!  # 发送SIGTERM信号给bash进程
```

**预期结果**：
只显示接收者为bash进程的信号发送事件。

#### 3. 多种信号测试
测试不同类型信号的跟踪：
```bash
# 启动信号跟踪监控
sudo ./go-ebpf tracesig -t 20 &

sleep 10 & SPID=$!; sudo ./go-ebpf tracesig -t 5 & TPID=$!; sleep 2; python3 -c "import os; os.kill($SPID, 9)"; wait $TPID

sleep 10 & SPID=$!; sudo ./go-ebpf tracesig -t 5 & TPID=$!; sleep 2; echo "Sending SIG0 to $SPID"; kill -0 $SPID; sleep 1; echo "Sending SIGKILL to $SPID"; kill -9 $SPID; wait $TPID
# 执行多种信号操作
sleep 100 &
kill -HUP $!   # SIGHUP
kill -INT $!   # SIGINT
kill -KILL $!  # SIGKILL
```

**预期结果**：
监控器应该捕获所有不同类型的信号发送事件。

### 测试结果说明

#### 输出字段解释
- **发送者PID**：发送信号的进程ID
- **发送者进程名**：发送信号的进程名称
- **目标进程名**：接收信号的进程名称
- **信号编号**：发送的信号编号（显示为信号名称如SIGTERM）
- **目标PID**：接收信号的进程ID
- **工作目录**：信号发送者的当前工作目录
- **时间**：信号发送的时间（相对于系统启动的秒.毫秒）
- **父进程**：信号发送者的父进程信息

#### 常见信号类型
- **SIGTERM (15)**：终止信号，优雅关闭进程
- **SIGKILL (9)**：强制终止信号，无法被捕获或忽略
- **SIGHUP (1)**：挂起信号，通常用于重新加载配置
- **SIGINT (2)**：中断信号，通常由Ctrl+C产生
- **SIGUSR1/SIGUSR2 (10/12)**：用户自定义信号

#### 使用场景
- **进程调试**：跟踪进程异常终止的信号来源
- **系统监控**：监控系统中的信号通信活动
- **故障排查**：分析进程被意外终止的原因
- **安全审计**：检测可疑的进程间信号发送行为

### 性能注意事项
- 信号跟踪对系统性能影响很小，因为只跟踪信号发送事件
- 大量信号发送可能会产生较多的监控数据
- 建议在测试环境中进行大规模信号操作测试

### 测试注意事项与常见问题

1. **关于 SIG0 信号**
   - 如果您看到大量 PID 不同但信号编号为 0 (SIG0) 的事件，这是正常的。
   - SIG0 常被进程用于检查目标进程是否存活（不实际发送信号），Systemd、Node.js 等服务管理器会频繁使用此机制。

2. **关于 unknown 和 target_process**
   - 在某些情况下（特别是 SIGKILL），目标进程可能在 tracesig 尝试读取其信息（如 /proc/[pid]/comm）之前就已经终止了。
   - 这种情况下，目标进程名可能会显示为 `target_process`，或者工作目录显示为 `/unknown`。这是由于用户空间数据解析的竞争条件导致的，属于预期行为。

3. **关于 SIGKILL 捕获**
   - 信号跟踪能够捕获 `SIGKILL` (9)，但请注意，使用 shell 内建的 `kill` 命令可能会有不同的行为。
   - 某些 shell 可能会优化 kill 命令或使用不同的系统调用路径。推荐使用 `python3 -c "import os; os.kill(pid, 9)"` 进行可靠的测试验证。


## TCP Ping 监控功能

TCP Ping 监控功能移植自 SysAK 的 tcpping 工具，可以精确测量 TCP 三次握手过程中各阶段的内核与网络延迟。

### 延迟阶段说明

| 阶段 | 说明 | 测量路经 |
| :--- | :--- | :--- |
| **TRANS** | 传输层延迟 | 从用户态发起连接到第一个 SYN 包发送前 |
| **IP** | IP层延迟 | 网络层处理时间 (IP 队列发送) |
| **DEV** | 物理/网络 RTT | 从驱动发包到驱动收包的时间（真实物理延迟） |
| **R_DEV** | 接收端驱动延迟 | 驱动层到 IP 层接收的处理时间 |
| **R_IP** | 接收端网络延迟 | IP 层到 TCP 层处理的时间 |
| **TOTAL** | 总握手延迟 | 完整的 SYN -> SYN/ACK 处理链路时间 |

### 参数说明

- `-c`: 发送探测包的数量（默认 5）
- `-s`: 源 IP 地址绑定（用于多网卡路由测试）
- `-d`: 目的地址（可直接指定域名或 IP）
- `-p`: 源端口绑定
- `-q`: 目的端口绑定

### 输出示例

```
SEQ   TRANS      IP         DEV        R_DEV      R_IP       TOTAL     
1     0.02 ms    0.01 ms    15.70 ms   0.02 ms    0.01 ms    15.76 ms  
```

## TCP Ping 监控测试

### 测试环境要求
- Linux 内核 6.12+ (为特定偏移量优化，但兼容旧内核)
- 网络工具（如 ping, ssh）

### 功能验证测试

#### 1. 本地回环测试 (验证极低延迟)
```bash
sudo ./go-ebpf tcpping 127.0.0.1:22 -c 3
```
**预期**: TOTAL 延迟应极低 (< 0.1ms)，且所有字段都有值。

#### 2. 远程网络测试 (验证物理延迟)
```bash
sudo ./go-ebpf tcpping baidu.com:80 -c 1
```
**预期**: DEV 字段将显示真实的物理网络往返时间（RTT）。

#### 3. 源地址绑定测试
```bash
# 指定监听在本地回环地址发起连接
sudo ./go-ebpf tcpping -s 127.0.0.1 127.0.0.1:22
```


## Socket/TCP 内存检查 (skcheck)

`skcheck` 功能移植自 SysAK，用于全面分析系统 TCP 内存开销并识别潜在的 Socket 泄漏。

### 核心功能

1. **TCP 内存概览**:
   - 从 `/proc/net/sockstat` 获取系统级 TCP 内存页使用情况。
   - 分析 TX/RX 队列的总量。
   - 识别消耗 TCP 队列内存最多的前几名进程。

2. **Socket 泄漏检测**:
   - 跨协议比对：遍历 `tcp`, `udp`, `unix`, `netlink`, `packet`, `raw` 等所有协议的激活 Inode。
   - FD 审计：扫描所有进程的 `/proc/<pid>/fd`，找出进程持有但内核协议栈中已不存在的“僵尸” Socket。
   - 过滤与去重：通过二次扫描降低误报。

### 使用方法

```bash
# 基本概览：显示系统 TCP 内存使用情况
sudo ./go-ebpf skcheck

# 启用泄漏检测：检查是否存在异常持有的 Socket
sudo ./go-ebpf skcheck -s

# 设置阈值：当进程持有超过 3000 个 Socket 或 1000 个疑似泄漏时报告
sudo ./go-ebpf skcheck -s -t 3000 -l 1000

# 输出 JSON 报告
sudo ./go-ebpf skcheck -j report.json
```

### 输出示例

```
memory overview:
tx_queue 128K rx_queue 64K queue_total 192K tcp_mem 4096K

task txrx queue memory:
task nginx ip:1.2.3.4  tcpmem 150K
task redis ip:1.2.3.4  tcpmem 42K

socket hold info:
nginx:1234 socketNum 2500 socketLeakNum 0
bad_app:5678 socketNum 600 socketLeakNum 550
```

### 验证与测试

#### 1. 验证内存采集
运行 `sudo ./go-ebpf skcheck`，对比 `cat /proc/net/sockstat` 中的 `TCP: mem` 值。注意输出已转换为 KB。

#### 2. 模拟泄漏测试
可以通过编写一个简单的程序，打开大量 Socket 后被 `kill -9`（有时能模拟出未及时释放的情景），或者在某些特殊场景下制造孤儿 Socket 来观察 `socketLeakNum`。

---

### eBPF 程序

该项目包含两个 eBPF 程序：

1. **helloworld.c** - 系统调用跟踪程序
   - 挂载到 `sys_enter_openat` tracepoint
   - 使用 hash map 统计调用次数

2. **reclaimhung.c** - 内存回收监控程序
   - 挂载到多个内存管理相关的 tracepoint
   - 跟踪内存回收、压缩和 cgroup 回收活动

3. **acltrace.c** - ACL跟踪监控程序
   - 挂载到 `__vfs_setxattr` 内核函数
   - 跟踪文件系统ACL设置活动，记录进程、文件名和ACL属性

4. **tracesig.c** - 信号跟踪监控程序
   - 挂载到 `__send_signal` 内核函数和 `sys_enter_kill` tracepoint
   - 跟踪进程间信号发送活动，记录发送者、接收者和信号信息

### Go 程序

主程序支持四种监控模式：
- **系统调用模式** - 实时显示系统调用统计
- **内存回收模式** - 在监控结束后显示完整的统计报告
- **ACL跟踪模式** - 监控文件系统ACL设置活动
- **信号跟踪模式** - 跟踪进程间信号发送活动

## 可用命令

```bash
make all      # 构建 BPF 程序和 Go 应用
make build    # 仅构建 Go 应用
make bpf      # 仅生成 BPF 字节码
make clean    # 清理构建文件
make test     # 运行测试
make deps     # 下载依赖
make run      # 构建并运行程序
```

## 注意事项

- 运行需要 root 权限或 CAP_BPF 能力
- 确保系统启用了 eBPF 支持
- 某些发行版可能需要安装内核头文件
- 内存回收监控需要较新的内核版本支持相关 tracepoint

## 扩展开发

要添加新的 eBPF 功能：

1. 在 `bpf/` 目录下创建新的 `.c` 文件
2. 在 `main.go` 中添加新的监控模式和加载逻辑
3. 更新 Makefile 中的构建规则
4. 重新构建项目

## 参考资源

- [cilium/ebpf 文档](https://github.com/cilium/ebpf)
- [eBPF.io](https://ebpf.io/)
- [Linux 内核 eBPF 文档](https://www.kernel.org/doc/html/latest/bpf/)
- [SysAK 项目](https://gitee.com/anolis/sysak) - 原始的 reclaimhung 工具来源