#BPF

最近做了一些 TCP 连接观测相关的项目，又到了一个节奏点上了。这里趁着这个机会，做一些总结，同时描述一下 tcp close 过程中的一些疑惑。

在一些场景下，对服务的调用观测是很有价值的。笔者最近实践了使用tcp_close对服务主被调信息的观测，在这里作一下记录。

BPF 技术看起来还有很多不易察觉的缺陷。最近又踩了一个坑。记录下。

LRU_HASH_MAP 在实现的时候，出现了不符合预期的数据驱逐问题：设定一个 512 大小的LRU_HASH_MAP，很可能出现在40-50个key的时候，之前的key就被覆盖。在一段时间未更新时，重新更新也可能会出现异常。总结就是，执行了写入操作，很可能没有写入。这个问题在Elements incorrectly evicted from eBPF LRU hash map有较为详细的描述。

搞项目。

观测服务的请求调用需求是客观存在的。一般是需要观测服务的主动发起的调用信息，但是偶尔也会遇到需要观测服务被调用信息的需求。但是一般待采集的服务都是挂载在LVS下面的。这就势必涉及到LVS预设的工作模式下，一般都是FULLNET，需要的real client ip的信息获取方式。
笔者通过调研，实现了一种通过BPF来观测挂载在LVS下的RS被调用TCP连接信息的方式。本文中关于toa的操作及代码定义均引用自Huawei/TCP_option_address。

2023年就要结束了，算起来距离上一次更新也有很久了。搜肠刮肚，总得在23年结束前再搞两篇总结，算是有始有终。总结今年，总还是绕不过 BPF，golang。既然如此，就对BPF观测golang这个话题再往下挖掘下，先做第一篇文章。下旬如果有时间并且顺利的话，希望能把BPF的原理总结完成。

在无侵入观测服务拓扑四元组的一种实现中，笔者有提到追踪golang处理过程的两个无法解决的问题是golang里的channel处理以及goroutine pool。再深究下，这两个问题实际上都可以归纳到对channel的处理，因为很多goroutine pool都离不了channel的使用，比如Jeffail/tunny这个库。
本文将会构建一个channel的追踪的方案。

不出意外的，之前提到的 ELF 文件解析内容又拖延了。目前还不知道什么时候有时间能够把希望完成的几篇文章给搞完。翻一翻目前的博客，已经有很久没有更新了。那就水一篇文章吧。目前算是项目里的低谷期，希望能够重拾程序员的意义。

在bpftrace 无侵入遍历golang链表里，笔者展示了使用bpftrace来遍历golang链表的方法。由于go-17和go-16的函数调用规约存在不同，因此bpftrace 无侵入遍历golang链表并不适用于go-17。其实这个问题在go-1.17+ 调用规约已经提到了解决方案。本文给一个实例，算是更进一步的延伸这个话题，希望能够起到一些效果。