Hi，欢迎来到 卡瓦邦噶！这里是一个 SRE 的博客，讨论的内容有：Linux, Vim, Tmux, NixOS, Python, Java, TCP/IP, Container, Docker, Ansible, Git, Graphviz, Redis, Prometheus, SSH, Shell, Bash, GNU, Github, C, C++, Unix, Nginx, Lua, Django, React 以及运维的方法论，编程的思考，工作的感悟。除了技术上的内容之外，这个博客还会分享一些读书感悟，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本站所有内容未加说明均为原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
今天线上发现了一个机器的子网掩码配置错了，其实问题比较简单，一开始没有想到会是这个问题，想了好久才想到这里。
我觉得网络有意思的地方就是在于这些网络协议要考虑的不仅仅是正常的情况，处理正常的情况很简单，而主要的设计其实都是针对不正常的情况如何处理的，比如处理网络中的错误、环路，错误的路由等等。但现实就是，各种各样奇怪的事情会发生，协议必须能处理好各种异常。
不妨拿这个问题来复习一下网络协议：如果子网掩码配置错了，那么两台机器能 ping 通吗？
这个问题看似比较简单，但是答案并不是一个简单的“是”或者“不是”，因为这分成好几种情况。
首先，我们明确这个子网掩码的作用，简单来说，就是判断目标地址和自己是否在同一个网络内：
即，这个判断是发生在本地的，是一台机器判断应该将数据包的目标地址设置成网关的 MAC（不在同一个子网），还是目的 IP 的 MAC（在同一个子网下）。
对于其他的计算机来说，他们不知道你设置的子网是什么，对于他们发送给你的数据包来说，无论你的子网设置成什么，只要 IP 设置对了，都可以收到。子网的设置只对 egress 流量有影响，对 ingress 流量没有影响（不考虑 ingress 依赖 ARP 这些的话）。下文中会用 “我” 来表示本地的机器。
首先看子网配置的范围比正确范围大的情况，比如我的 IP 本来应该是 1.1.3.2/24, 但是错误的配置成了 1.1.3.2/16.
可以从不同的目标地址来分析影响：
1.1.3.0/24 本来，这个范围和我是在同一个地址下面，现在由于我的子网配置的过大，那么现在，这个段还是跟我在同一个子网下面，所以我和它们之间的通讯丝毫不会收到影响；1.1.0.0/16 下面，不包含 1.1.3.0/24 的部分：本来，这部分不是跟我在同一个子网下面，现在由于我的子网配置过大，导致我认为它们跟我在一个子网下。那么，本来数据应该发往 router，现在由于我错误地认为这些目标和我在同一个子网，所以我现在会直接查询 ARP 表，通过 ARP 查到目的地址然后发出去。这显然是查询不到的，发出去的 ARP 也不会有响应的，故，这些 IP 是一定不可达。比如我的 IP 本来应该是 1.1.3.2/16, 但是错误的配置成了 1.1.3.2/24。
如上，首先，1.1.3.0/24 这个网段，在错误之前和之后都是和我在同一个网段，所以不会收到影响，能够正确路由。
然后下面就是有意思的部分了。
假设现在要发送到的一个目的地址是 1.1.4.3, 正确的话，这应该是和我在同一个子网，但是现在我的子网变小了，我会认为它不和我在同一个网络内，需要经过路由器转发，所以我会将要发给 1.1.4.3 的数据包的目标 MAC 地址设置成路由器，并且发给路由器。
现在又出现了两种情况，第一种比较简单，是路由器的 IP 地址和我也因为错误变成了不同的网段，比如 1.1.2.1, 那么我会直接认为是 Unreachable，ping 失败。
第二种情况比较有意思：如果我因为阴差阳错，即使子网掩码配置小了，但是依然幸运地和路由器处在同一个网络内呢？
上面已经分析过，这个时候我是可以 ping 通路由器的：
那么我能 ping 通 1.1.4.3 这个地址吗？
让我们一步一步分析一下。
按照上面的逻辑，我会把去往 1.1.4.3 的包丢给路由器，对于路由器来说，它遇到了一个奇怪的事情：这个家伙来自 1.1.3.2/16(路由器视角，路由器的子网配置是正确的)，然后要把这个包发送给 1.1.4.3/16, 这不是都在同一个网络 1.1.0.0/16 内吗？发给我干嘛，直接发给它呀！
这时候路由器会怎么做呢？
对于 ICMP 包来说，路由器还是会帮我把这个包转发到目的地址，即路由器通过这个 interface 收到我的包，一看，发现是目的同一个 network，它再从同一个 interface 发出去。
The gateway sends a redirect message to a host in the following situation.
A gateway, G1, receives an internet datagram from a host on a network
to which the gateway is attached. The gateway, G1, checks its routing
table and obtains the address of the next gateway, G2, on the route to
the datagram’s internet destination network, X. If G2 and the host
identified by the internet source address of the datagram are on the same
network, a redirect message is sent to the host. The redirect message
advises the host to send its traffic for network X directly to gateway
G2 as this is a shorter path to the destination. The gateway forwards
the original datagram’s data to its internet destination.
在路由器上抓包，也可以看到它产生的 Redirect message，里面有说，你应该直接去找 1.1.4.3 , 不要再来找我啦！
所以说，ping request 的包是可以发给目的地址的，只不过会多回复给发送这一个错误消息而已。
现在请求到了 ping reply 这边，reply 能成功发回去吗？
按理说前面提到过，对于其他人来说，正常发给我消息是没有问题的。但是这个回复有一个依赖，就是它要知道我的 MAC 地址，要知道我的 MAC 地址，就需要我来告诉它。
那么第二个有意思的问题就来了：如果我收到了一个 ARP 请求，和我不在同一个网段，但是询问的确实是我的 MAC 地址，我会回复吗？
这个是 Linux 配置参数，位置在 /proc/sys/net/ipv4/conf/eth0/arp_ignore 含义如下：
arp_ignore – INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 – (default): reply for any local target IP address, configured
on any interface
1 – reply only if the target IP address is local address
configured on the incoming interface
2 – reply only if the target IP address is local address
configured on the incoming interface and both with the
sender’s IP address are part from same subnet on this interface
3 – do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 – reserved
8 – do not reply for all local addressesThe max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}
因为默认值是 0, 所以是会回复的。通过 tcpdump 在 linux1 上抓包可以确认：
这时候 1.1.4.3 拿到了我的 MAC，就直接在二层把 ping 的 reply 发给我了。
如果在 Linux2 这台机器上，即 1.1.4.3 上，抓包，会发现一个有意思的现象：它从路由器 MAC 收到的 ping 包，回复给了另一个 MAC 地址。
这个奇怪的 ping 链路整体的数据流向如下：
所以说，这种情况下是可以 ping 通的。
最近有一个需求是这样的：Linux 机器上有多个网络的 interface，想要让其中的一个程序使用 eth1 而不是默认的 interface，不影响其他程序。
在 Linux 上发送 TCP 数据，是通过 kernel 提供的 syscall 将数据送给 kernel，然后 kernel 负责最后的发送。而到了 kernel 这一层，TCP 就是根据五元组来确认的了：来源端口，目的端口，来源IP，目的IP，以及协议类型。所以就让“按照进程转发”这个需求变得有些复杂。
Linux 提供了 SO_MARK 可以给流量“打标签”，然后针对打了标签的流量设置 route. 我们的思路是这样的：
0x10 mark 的流量通过 table 100 查找路由: ip rule add fwmark 0x10 table 100；table 100 中只有一条 default 路由规则，就是通过 eth1 出去: ip route add default dev eth1 table 100 scope global；SO_MARK 打标签。这样，就可以命中我们想要的路由了。
如何给这个流量打标签，变得有趣了起来。
如果应用使用的流量有明显的特征，就可以用这种方法。比如我们的流量都是去往 3306 的，就可以针对这个端口设置一条规则：
|
1 |
iptables -A PREROUTING -t mangle -i bond0 -p tcp --dport 3306 -j MARK --set-mark 0x01 |
但是话说回来，既然都知道端口了，可以直接把步骤 3 去掉，在步骤 1 让去往这个端口的流量直接命中 table 100(ip-route(8) 是支持端口的):
|
1 |
ip rule add pproto tcp dport 3306 lookup 100 |
所以这个方法感觉比较鸡肋。而且这种只支持程序的流量必须有一个固定的模式，假如程序请求很多其他网站并且 TCP 无法识别，就麻烦了。
使用这种方式，我们可以不修改程序的代码而又让进程的流量全部带上标记。
第一次见到 LD_PRELOAD 是在 jvns 的博客上，简直是一个颠覆世界观的东西，它这么简单，又这么有效！
它的原理是这样：dynamic link 的程序是在启动的时候寻找应该从哪里 load 一个 symbol 的，通过设置 LD_PRELOAD 给进程，就可以覆盖动态链接的符号的查找顺序。
ldd 展示动态链接的库：
|
1 2 3 4 5 6 7 |
$ ldd /usr/bin/nc linux-vdso.so.1 (0x00007ffd118ab000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f5a3fb99000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f5a3fb85000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a3f95d000) libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f5a3f950000) /lib64/ld-linux-x86-64.so.2 (0x00007f5a3fc45000) |
所以，当我们编译一个 .so 共享库，并且通过 LD_PRELOAD 设置成共享库的路径，那么在寻找符号的时候就会先寻找 .so 里面的，这样，我们就可以通过编写同名的函数来覆盖系统的函数。
如果你用过 proxychains ，那么你应该已经用过这个 feature 了。
proxychains 是一个代理软件，一般的软件使用代理都需要设置 http_proxy 等环境变量来告诉软件代理的地址。前提是这个软件支持读这些环境变量。但是，有了 Proxychains，你不需要软件自身支持，就可以让它走代理！原理就是，软件通过 proxychains 启动，而启动的时候，proxychains 会设置软件的 LD_PRELOAD 变量，然后去替换系统的 socket 函数，这样，任何调用都会走 proxychains 的代理！source code
所以，使用这种方法，我们只要替换程序的 socket 方法，在每次创建 socket 之后，调用 setsockopt(2) 去设置上 SO_MARK 就好了。
网上已经有一个程序 App-Route-Jail 做了这件事，它的使用方法如下：
1.clone 并且编译程序：
|
1 2 3 4 |
git clone https://github.com/Intika-Linux-Network/App-Route-Jail.git cd App-Route-Jail chown 755 make.sh ./make.sh |
2.启动程序的时候带上 LD_PRELOAD 变量，要设置什么 mark，通过 MARK 环境变量传入
|
1 |
MARK=10 LD_PRELOAD=./mark.so firefox |
它的程序很简单，就是用一个新的 socket 函数，替换原来的 socket 函数：在每次创建 socket 之后，调用 setsockopt(2) 设置 mark.
等下，那既然 mark.so 里面调用的也是 socket()，怎么避免 linker 再去找一遍这个函数在哪里，然后找到了自己，造成无限循环呢？
在 mark.c 的代码中，是用 dysym(3) 去 load 的 socket() 这个符号：
|
1 2 |
if (!_socket) _socket = (socket_t) dlsym(RTLD_NEXT, "socket"); |
RTLD_NEXT 就是让 dlsym 从下一个 .so 开始找：
RTLD_NEXT
Find the next occurrence of the desired symbol in the search order after the current object. This allows one to provide a wrapper around a function in another
shared object, so that, for example, the definition of a function in a preloaded shared object (see LD_PRELOAD in ld.so(8)) can find and invoke the “real” func‐
tion provided in another shared object (or for that matter, the “next” definition of the function in cases where there are multiple layers of preloading).
所以这里用的就是 glibc 提供的 socket 函数了。
这个方法也有缺点，就是它只对 dynamic link 的程序有效，像 golang 这种语言默认是全部静态编译的，连 glibc 都不用，LD_PRELOAD 自然就无效了。这种情况我们就只能修改程序的代码，让它自己标记自己的流量了。
我们需要手动创建 Dialer 来进行 tcp 连接。并且给这个 Dialer 设置一个 Control:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// setSocketMark sets packet marking on the given socket. func setSocketMark(fd, mark int) error { if err := syscall.SetsockoptInt(fd, syscall.SOL_SOCKET, syscall.SO_MARK, mark); err != nil { return os.NewSyscallError("failed to set mark", err) } return nil } // use this create a new dialer dialer := &net.Dialer{ Control: func(_, _ string, c syscall.RawConn) error { return c.Control(func(fd uintptr) { ex := setSocketMark(int(fd), 0x01) if ex != nil { fmt.Printf("net dialer set mark error: %s\n", ex) } }) }, } |
感觉使用这种方式在 Chaos Engineering 方面也会很有用，我们一直苦于如何有效对 HTTP(S) 流量进行注入而不影响其他机器的进程。使用 SO_MARK 或许可以解决。
2023年3月1日更新：这篇文章发出之后，网友评论了更多有用和有趣的方法。
最先是在 twitter 上看 @Sleepy93216599 介绍的。不过没尝试过，就不详细展开介绍了。
iptables 居然支持直接按照 uid 来匹配，之前一直不知道这个。这样的话只要给进程分配一个单独的 user 来运行就好了。
此外，还支持 gid, pid, sid, cmd owner 来匹配：
–uid-owner userid
Matches if the packet was created by a process with the given effective user id.
–gid-owner groupid
Matches if the packet was created by a process with the given effective group id.
–pid-owner processid
Matches if the packet was created by a process with the given process id.
–sid-owner sessionid
Matches if the packet was created by a process in the given session group.
–cmd-owner name
Matches if the packet was created by a process with the given command name. (this option is present only if iptables was compiled under a kernel supporting this feature)
这个方法简直惊为天人。
本文评论里介绍了 gg 这个工具，可以用来 hook golang 写的程序，感觉很神奇，但是没看懂怎么实现的，只有 FAQ 里面提过一次 ptrace，然后灵光一闪发现可以用 ptrace 搞事情。
后来看到 graftcp 这个工具，文档和代码写的都很好，看的让人拍大腿。简单来说，就是程序启动的时候，通过 ptrace(2) 进行跟踪，然后当程序开始创建 tcp 的时候，拦截 connect(2) 调用，获取目标地址，然后给这个程序修改成自己的地址，欺骗程序，自己拿到了真正的地址。然后恢复执行。后面程序成功创建了 tcp 连接，但是却是到代理的 tcp 连接，而不是真正到目标地址的链接。这样，代理就在这之间工作了。而这对程序是无感的。
文档还提到一个有趣的点，就是为什么不直接去 hook write(2) 和 read(2)呢？ 原因有2：
connect(2)) 是通过 PIPE 把地址告诉代理进程。connect(2) 的参数是在寄存器，安全的多)。这几天做了一个集群的迁移，我们搭建了一个新的集群，然后更新了 DNS 让域名访问新的集群，准备给老集群下线。下线的时候发现仍然有一部分请求到了老集群。看来是它们用了长链接，并没有根据新的 DNS 记录将请求发给新的地址。找到这些发送请求的客户端是谁，费了一番功夫，这里记录一下。
我们的架构如下：
LVS 是一个四层代理，将请求转发到 Nginx，一个七层代理，然后转发给后端应用。
现在的情况是：
但是我们有了 IP，有了 Header，只要通过 tcpdump -A host <ip> 就可以将用户请求的 HTTP 内容全部打印出来，也就包括 header，就能知道是谁了。
这里有一个问题，就是 Nginx 在 LVS 后面，我们在 Nginx 上面进行 TCP dump，看到的是 LVS 的地址，而不是用户的真实地址。
LVS 里面使用了一个模块，叫做 TOA, TCP_option_address. 即 LVS 进行转发的时候，会将用户的真实 IP 写在 TCP 的 option 字段中。如果要根据真实地址进行 tcpdump，我们要过滤的是这个字段而不是原生的 host 地址。
注意这个 TOA 只会在 SYN 握手阶段设置，然后双方会把这个信息记录在内存里面，后面的 TCP 通讯就不会一直带上这个信息了。所以，要找到用户的真实 IP，必须过滤 TCP 的 SYN 包。
现在需求就变成了：用 tcpdump 在 Nginx 上，filter 出来 IP 为 A 的请求的 HTTP header，以便根据 header 中的信息找到调用来源的团队，和他们沟通重建连接的问题。
通过阅读 TOA 的源代码可以发现，代码中还原用户真实的 IP 地址的方式：遍历 TCP Option 字段，直到找到 option code 为 254(TCP option 254 是一个实验字段，RFC3692-style Experiment 2 (also improperly used for shipping products)， opsize 固定为 8 的 option，就读 16 bit load成端口，读 32 bit load 成 IP.
所以只要针对这个 tcp option filter 即可。
需要注意的是，tcpoption 对于 tcpdump 来说不被理解，所以需要转成 hex 来匹配。我在 xbin 上面放了几个工具：
匹配 IP 是 120.120.111.111 的话可以用下面的语句：
|
1 |
tcpdump 'tcp[tcpflags] & tcp-syn != 0 and tcp[24:4]=0x78786F6F' |
其中：
tcp[tcpflags] & tcp-syn != 0是取 SYN 的 flag 为 1，即只抓取 SYN 包;tcp[24:4]=0x78786F6F 是匹配 tcp option 字段中的 IP如果要匹配 port 的话，就偏移两位即可：
|
1 |
tcpdump 'tcp[tcpflags] & tcp-syn != 0 and tcp[24:2]=0xacb0' |
这样做其实还有一些问题：
tcp[24:4]。一个解决方法是把可能的都 dump 下来，然后用 wireshark 过滤，wireshark 支持搜索全部 TCP 包内容包含某个 hex value。比如：tcp.options contains fe:08:78:78:6f:6f.最近在学习 BPF，这是一种目前比较流行的动态追踪技术，简单来说，它允许我们在不中断目前正在运行的程序的情况下，插入一段代码随着程序一起执行。比如你想知道某一个函数每次 return 的值是什么，就可以写一段 BPF 程序，把每次 return 的值给打印出来；然后把这个函数 hook 到函数调用的地方，这样，程序在每次调用到这个函数的时候都会执行到我们的 BPF 程序。
这种不终止程序，能去观测程序的运行时的技术是很有用的。
credit: https://www.brendangregg.com/ebpf.html
它的原理大致上是：
int3，即一个 break，把原来应该执行的指令保存起来；例子：这行程序可以把系统中所有执行的命令打印出来 bpftrace -e 'tracepoint:syscalls:sys_enter_execve { join(args->argv); }'. 原理就是，每次执行 execve 的时候都会执行到我们定义的 join (print).
bpftrace exmaple
bpftrace 是一个命令行程序，它的语法类似 awk，做的事情就是：将我们写的程序（这里的程序指的是 bpftrace 定义的语法，而不是 BPF 程序）编译成 BPF 程序，然后 attach 到相应的事件上。
通过上面的描述可以看出，使用这个方法来追踪程序所需要的必备条件是：
像 Python 这种解释型语言，binary 其实是一个解释器，解释器里面才是运行的 Python 代码。如果按照上述方法，追踪的其实是解释器的代码而不是我们的 Python 应用的代码。
Python Interpreter
一个解决方法是使用 USDT 追踪。
USDT 全称是 User-level statically defined tracing. 是在程序的用户态定义的追踪点。Python 解释器为我们提前定义好了一些追踪点（可以叫做 probe，或者 marker），这些追踪点默认是不激活的，所以对性能丝毫没有影响。要追踪的时候可以激活其中的几个追踪点，然后将其提供的 arguments 打印出来。
能够使用 USDT 有几个前提：
首先需要安装 bpftrace. 安装说明可以参考这里。
通过这个命令可以列出 binary 中的 USDT markers: bpftrace -l 'usdt:/usr/bin/python3:*'
可以看到目前支持的 markers 不多，一共也就 8 个。
先拿一个来试一下：执行这个命令可以打印出来 Python 每次函数调用的时间、源代码的地址，函数名字，和行号：
bpftrace -e 'usdt:/usr/bin/python3.10:function__entry {time("%H:%M:%S"); printf(" line filename=%s, funcname=%s, lineno=%d\n", str(arg0), str(arg1), arg2);}' -p 15552
其中，-p 15552 是正在运行的 Python 程序的 pid，-e 后面跟的就是 bpftrace 的代码，很像 awk，第一个是 probe，{} 里面是代码，主要要两行，第一行打印出来时间，第二行打印出来 function__entry 这个 probe 提供的三个参数。（需要稍微注意的是，字符串参数需要用 bpftrace 内置的 str() 函数打印出来字符串，否则的话打印出来的是 char * 的地址；另外要注意虽然 Python 文档中说的这三个参数是 $arg1 $arg2 $arg3，但是实际打印的时候，应该使用的是 arg0, arg1, arg2.）
效果如下：
其他的几个 marker 作用是：
sys.audit 调用的时候触发可以看到，当前支持的并不多，而且从这几个 marker 可以看出，大部分的作用是让你知道 Python 解释器正在干啥，而不是 debug。如果遇到性能问题的话可以通过这个解决，但是如果遇到逻辑错误，帮不上太大的忙。比如你无法通过 usdt 看到某一个变量在某个时刻的值。
USDT 工作的原理和上文提到的 uprobe 差不多，激活的时候会改变原来执行的指令，插入 int3 去执行我们的 handler.
Seeing is believing.
我们可以通过一些工具来观察它执行的原理。
以 function__entry 为例，我们先找到它在 Binary 中的 marker， 在 .note.stapsdt 里面：
可以看到我们刚刚使用的 function__entry 的位置是 0x000000000005d839.
然后我们找到这个位置的指令。
gpb -p 17577 去 attach 到正在运行的这个 pid 上。然后运行 info proc mappings dump 出来地址，可以看到 Offset 0x0 的位置是 0x55bfcc88d000.
那么 function__entry 的位置应该是 0x000000000005d839 + 0x55bfcc88d000.
下面用 disas 命令可以 dump 出来这段地址的指令：
|
1 2 |
>>> hex(0x000000000005d839 + 0x55bfcc88d000) '0x55bfcc8ea839' |
查找 0x55bfcc8ea839 这个地址的指令：
发现是一个 nop，即什么都不做。所以这就是为什么上文说，在 usdt 不开启的时候，对性能是完全没有损失的。只是多了个一个什么都不做的占位指令而已。
下面使用之前的命令去 attach 这个 usdt probe：
然后重新看一下 0x55bfcc8ea839 这个位置的指令：
可以看到这个位置的指令已经变成了 int3. 当程序（解释器）执行到这里的时候，kernel 就会执行用 usdt 提供的变量去执行我们的 BPF 程序。当 BPF probe 退出的时候，int3 会被恢复成 nop.
在网上查询和 Python 有关的 BPF 内容大部分都是“如何通过 Python（BCC）来使用 BPF”，而不是“如何用 BPF 去 profile Python 代码”，可能在解释型语言方面用的不多吧。
USDT 有很大的局限，就是只能使用 Python 解释器定义的几种 probes, 目前能做到的基本上是看看解释器正在干嘛，而不能看到一些具体的变量的参数，解释器的状态等等。如果要做到更加精细的动态追踪，目前有两个想法：
PyObject 指针，需要了解解释器的工作原理，比较复杂；
2022 年终于过去了，对于大多数人来说是糟心的一年，但我觉得也有一些指的记录的地方。
今年完成的最大的事情是10月份举办了婚礼。前前后后几乎策划了一年多，所幸举办的还算圆满。办完之后又办了很多手续，飞回新加坡回到工作中，本来是年底旅游的好日子，却几乎没出去旅游，躺平休息了 2 个多月。（办完婚礼之后觉得工作简直太轻松了）今后有了另一个身份，做一个好丈夫！
今年做的一些 side projects: 首先是 xbin.io, 时间太长，我都以为是去年做的东西了。这个项目的初衷是满足我自己的一些需求，现在看目的也达到了，个人对现在的形态比较满意，使用率也还可以。在新加坡使用 xbin 的 latency 是 5ms (ping RTT)，如果不是在国外公司，自己是不会有这个想法做这么个东西的。
iredis 在今年几乎没有什么大的改变，只是在处理一些用户的 issue 和 bug. iredis 一直有一个问题，就是所有命令的补全都是我自己编入的，每一次 redis-server 有什么 command 的变更，我都要跟进，否则的话自动补全和校验系统就识别不出来新的命令，或者同一个命令的新的语法。我一直想把它替换成根据 redis-doc 中的文档自动补全的。现在这个文档已经越来越规范了，也许现在是时候迁移到自动生成的补全系统了。下一年花一些时间钻研一下语法树和补全系统，争取能完成这个。
监控系统。做 SRE 的这段时间或多或少都在和监控系统打交道，今年为了解决我们团队遇到的问题，我从头搭建了一套监控系统，基于 VictoriaMetrics 上的，花了很多时间阅读他们的文档，也提交了一些 PR。今年还在 PromCon 上面分享了我们的一些经验。大部分的使用问题已经解决了，还有一个长久以来一直没有解决的问题：大规模的 recording rules, 比如，计算所有容器的 CPU 使用率。本质上，监控系统的数据是一个 OLTP 的问题，大部分场景只需要看到实时的数据就足够了，而且，也很少需要看到所有的 labels 加在一起的维度（只是看某一个 application）。但是我们有一些场景是需要对整个 AZ 做聚合，这有点像 OLAP 了。目前的解决方案是简单地作为一个客户端，去已有的数据里面查出来，然后做整体的计算，存储新的值。这样有很多问题：速度慢；占用太多资源。这个链路是有一些浪费的，raw metrics 首先被收集起来，然后存储到磁盘中，聚合进程再查出来，通过网络拿回来，再进行计算，一来一回消耗了很多磁盘、网络和 CPU 的资源。我在想能否直接让采集端发送 metrics 到聚合段，跳过读写磁盘的逻辑（原来 raw metrics 保存的链路是不变的）。这样或许可以提高一些性能。今年或许可以尝试一下。
做监控的时候也开源了一些项目：
这些完成的项目，没有完成的项目也有很多。反思这一年，我发现自己很大一个问题，就是学到什么东西之后急于投入使用，会有很多不成熟的想法，想实验一下行不行，于是会花很多时间做可行性调研，最后可能确定自己的想法是可行的，或者不可行的。但是已经并不重要了，自己这时基本上已经没有激情去实现了…… 这样就花了很多时间，但实际并没有什么产出。好处是可以有一些更有意思的想法，坏处是浪费时间。
所以今年就克制一下自己，除非工作必要，就不开新坑了。要学习的东西虚心去学习，不要急于卖弄学到的东西做出什么来证明自己的能力。
写到这里要穿帮一下，最近几年年终总结没有在年底准时写出来，是因为懒。今年是因为得了新冠。也不知道这几年在新加坡是怎么躲过去的，最近才得。今天（1月12日）终于算是没有症状了，于是开始继续写这篇文章。
对于去年的总结就到这里吧，新的一年，计划如下：
最近有一个想法：假如喜欢编程这件事情并且想长久地坚持下去的话，比如 30 年，就会发现有些事情是不重要的，有些事情是重要的。比如一年工作的绩效考评，某一年的晋升，等等，放到30年里面，就不那么重要了。有一些事情是重要的，比如花1年时间熟练使用了一个高效的代码编辑器，比如提高代码的输入速度，比如掌握了画出精美的图片的技能，比如能写出通俗易懂的文档和博客的技巧，放到30年的编程生涯中，对于工作和个人的成长就很重要了。
这么一想，打算花 30 年去做一件事情，很多事情就会显的不那么急。我们就会有很多时间去寻找机会，也有很多时间去训练那种长远看来有益的事情。对于一些急功近利的事情也就看的不那么重要了。
说起来画图，我寻找合适的画图工具很多年了。尝试过 dot，（我还是 dot in Jupyter 的作者），OmniGraffle，D2，Mermaid, PlantUML 等等，还是没有一个满意的。就像一些数据库 ER 图 for dev, figma for design, 还缺少一个工具 for SRE. 对于我来说，这个工具应该是：
过去一年也参考了很多其他的画图工具，也读了一些 DSL 设计有关的论文，今年看能不能把这个语言的设计实现出来。
就写这么多吧，杂七杂八写了很多不相关的东西。
2023年1月12日更新：上文中提到的这个 streaming aggregation metrics 的想法，生病期间朋友告诉我已经 VictoriaMetrics 官方已经实现了。
往年的总结：