前段时间新开了 static-binaries 仓库基于 Alpine Linux aports repository 来静态编译日常开发调试过程中常用的命令行工具，计划在各个发行版的常见版本上测试编译结果能否正常运行，于是使用 libvirt 从各发行版官方提供的 cloud image 快速创建虚拟机作为测试环境。
使用 Debian 和 CentOS 的 cloud image 创建虚拟机的过程中遇到了多个问题，例如创建 debian12-amd64 虚拟机时的 cloud-init 参数不生效，创建 debian12-arm64 虚拟机时报错 /usr/share/libvirt/cpu_map/arm_Ampere-1.xml 文件不存在，还有创建的 centos7-arm64 虚拟机在启动时报错 Synchronous Exception，尝试寻找解决方案。

4.5

还是本地搭建的 tracing-benchmark 测试环境，测试过程中观察到 jaeger 在 v1 和 v2 不同版本下提供的 metrics 不同，且都包含关于 spans 数量的统计。
根据测试结果可知高负载环境下不同版本均会主动丢弃 spans，好奇丢弃 spans 的具体数量，丢弃行为发生在 client 端还是 server 端，以及能否设置为禁止丢弃。
因此将 otel trace 的主要逻辑提取出来并进行测试，顺便观察单个 span 从创建到保存的完整流程是什么样的。

本地使用 docker 来搭建 tracing-benchmark 的测试环境，在测试过程中观察到默认的 bridge 网络下 docker-proxy 进程的 CPU 使用率甚至会高于应用容器本身。
一方面不确定 docker-proxy 的高负载对应用容器的性能测试结果会有多大影响，另一方面则是觉得单纯的 TCP 端口转发功能不应该有这么高的 CPU 使用率。
因此计划模拟并测试 docker-proxy 在高网络负载下的具体表现，以及相关替代方案的实际优化效果。

3.5

使用 chroot 命令可以改变进程的可见根目录，创建出一个 chroot jail，限制对应进程可访问到的文件，降低程序的部分安全风险。
之前编写过一个文件分享 Web 应用 share-Go，在仓库的 README.md 中给出了 run with linux chroot 的简单示例，以避免非预期的文件访问。
偶然发现该 chroot 示例中存在几个隐藏问题，主要涉及到 Golang 程序的外部环境依赖，就顺便整理记录下来。

根据公司相关要求，把自己的主机换成了公司的笔记本。在 Windows 11 上测试了 Hyper-V 虚拟机和 WSL 2，感觉使用 vscode remote 搭建开发环境还是不太方便。
与相关部门进行沟通后，确认公司允许使用 Ubuntu Desktop 作为本地开发环境，于是将笔记本重装为 Kubuntu，期望能接近在 Arch Linux 上的 KDE 使用体验。
测试 Kubuntu 的过程中发现笔记本 CPU 的最大频率明显比 Windows 11 上的低，因此尝试排查具体原因，寻找解决办法。

新功能上线后 Nginx 的日志监控频繁上报某类请求 502 Bad Gateway，但在对应的 Golang 后端服务日志中却没有找到任何异常。
抓取请求参数在测试环境复现后，发现异常请求在 Golang 后端服务日志中会正常打印为 200 OK，与其他正常请求无区别。
根据 Nginx 日志中的请求时间推测，是 Golang 后端服务在请求超过 60 秒后主动关闭了连接，但并没有处理相关超时异常。

2.5

尝试将 struct 序列化为 json 后走 TCP 传输，在 bytes stream 上利用 json 实现 packets stream。
联系 WebSocket 很容易想到可以对 json 文本进行压缩来做传输优化，就选择了广泛使用的流式压缩 gzip 来对 json 进行处理。
写 Golang 测试的时候发现 gzip 压缩结果的 base64 编码中出现了大量重复的 AAAA，长度也比命令行中直接 echo RAW_JSON_TEXT | gzip | base64 得到的编码结果长了许多。
好奇是什么原因导致了 Golang 的 gzip 与命令行里的 gzip 压缩结果出现这种差异，也借这个机会顺便了解一下 gzip 相关的知识。