2022 年的总结

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 保存的链路是不变的)。这样或许可以提高一些性能。今年或许可以尝试一下。

做监控的时候也开源了一些项目:

  • promqlpy: 一个 Python 库,可以解析 MetricsQL/PromQL 的语法;
  • mepe: 一个命令行工具,可以 summary 应用暴露出来的 metrics,方便配置监控;
  • metrics-render: 一个 Python 服务,可以根据 url 渲染出来 metrics 的图标,GET 请求,返回 png,这个库还存在一些问题;
  • prometheus-http-sd: 一个给 Prometheus 的监控服务发现系统,支持 yaml/json,可用 Python 脚本方便地对接其他的系统;

这些完成的项目,没有完成的项目也有很多。反思这一年,我发现自己很大一个问题,就是学到什么东西之后急于投入使用,会有很多不成熟的想法,想实验一下行不行,于是会花很多时间做可行性调研,最后可能确定自己的想法是可行的,或者不可行的。但是已经并不重要了,自己这时基本上已经没有激情去实现了…… 这样就花了很多时间,但实际并没有什么产出。好处是可以有一些更有意思的想法,坏处是浪费时间。

所以今年就克制一下自己,除非工作必要,就不开新坑了。要学习的东西虚心去学习,不要急于卖弄学到的东西做出什么来证明自己的能力。

写到这里要穿帮一下,最近几年年终总结没有在年底准时写出来,是因为懒。今年是因为得了新冠。也不知道这几年在新加坡是怎么躲过去的,最近才得。今天(1月12日)终于算是没有症状了,于是开始继续写这篇文章。

对于去年的总结就到这里吧,新的一年,计划如下:

  1. 锻炼身体。年底回到新加坡之后买了两辆自行车跟太太一起到处骑,因为是折叠车,可以用公共交通蛙跳到各个地方去骑车,非常方便。新年就铁人三项:骑车、游泳、跑步,锻炼一个健康的身体吧。
  2. 打字训练:目前打字的速度是50 words per minute. 希望纠正自己的指法,速度提升到至少 70 words per minute.
  3. 学习:年底开始读一些 eBPF 的书,今年学习一下网络、Linux、CS 基础的内容,多总结,希望多写几篇博客。

最近有一个想法:假如喜欢编程这件事情并且想长久地坚持下去的话,比如 30 年,就会发现有些事情是不重要的,有些事情是重要的。比如一年工作的绩效考评,某一年的晋升,等等,放到30年里面,就不那么重要了。有一些事情是重要的,比如花1年时间熟练使用了一个高效的代码编辑器,比如提高代码的输入速度,比如掌握了画出精美的图片的技能,比如能写出通俗易懂的文档和博客的技巧,放到30年的编程生涯中,对于工作和个人的成长就很重要了。

这么一想,打算花 30 年去做一件事情,很多事情就会显的不那么急。我们就会有很多时间去寻找机会,也有很多时间去训练那种长远看来有益的事情。对于一些急功近利的事情也就看的不那么重要了。

说起来画图,我寻找合适的画图工具很多年了。尝试过 dot,(我还是 dot in Jupyter 的作者),OmniGraffle,D2,Mermaid, PlantUML 等等,还是没有一个满意的。就像一些数据库 ER 图 for dev, figma for design, 还缺少一个工具 for SRE. 对于我来说,这个工具应该是:

  1. 基于 text 的,text to diagram
  2. 命令式的,像编程语言一样描述动作。而不是声明式的
  3. 用户在使用的时候,应该快速的将所了解的事实通过这个语言表达出来,而不应该去考虑布局中每一个框的位置和排放,应该减少用户花在画图上的心智负担,将更多的精力放在所要表达的内容上面

过去一年也参考了很多其他的画图工具,也读了一些 DSL 设计有关的论文,今年看能不能把这个语言的设计实现出来。

就写这么多吧,杂七杂八写了很多不相关的东西。


2023年1月12日更新:上文中提到的这个 streaming aggregation metrics 的想法,生病期间朋友告诉我已经 VictoriaMetrics 官方已经实现了。

其他的年终总结列表:

  1. 2013年
  2. 2014年
  3. 2015年
  4. 2016年
  5. 2017年
  6. 2018年
  7. 2019年
  8. 2020年
  9. 2021年
  10. 2022年
  11. 2023年
  12. 2024年
 

记录一次问题排查的故事

今年工作中发生的一个问题,因为太简单了,觉得不值得记录。今天读 plantegg 的一篇文章,想起来这件事。技术上很简单,但是故事本身还是挺有意思的。这里尽量客观的记录一下事情经过,因为是当事人,就不做评论了。

故事的起因是,我们提供了一个 HTTP 服务,给不同于我们部门的团队使用,这个服务有些复杂,它本身提供的是 gRPC 服务,但是我们为了给外部不同技术栈的团队使用,做了一个 HTTP 转 gRPC,其他的团队通过公网调用这个 HTTP 服务。

HTTP 再前面就是公司的通用网关了,所以集团外其他用户访问我们的服务链路是 公网 -> 4层网关 -> 7层网关 -> HTTP 转 gRPC 服务 -> 服务本身。

然后有一个 BU,他们说调用我们的服务请求并发提不上去,原因是他们那边的 NAT 端口耗尽了。从他们那边访问这个服务的出口是 客户端 -> NAT 设备 -> 公网 -> … 因为我们只在公网上暴露了 2 个 IP,TCP 的五元组里面 4 个基本已经固定了,2IP+协议+目的端口,所以只有他们 NAT 的端口是一个变量,很快就到了瓶颈。

于是他们工单给我们,要求我们在公网上暴露第二个 IP,以便可以支持更多的 TCP 连接。我们内部讨论之后拒绝了,要求他们使用 HTTP 长链接来调用,而不是短连接。因为他们是作为客户端连续并发调用多次请求,完全是长链接的场景。

第一天,他们测试使用长链接,但是 QPS 高不上去,甚至比原来还低。然后他们让我查一下这个链路上支持不支持长链接,是不是我们的配置有问题。我明确回复支持。

然后他们要求我抓一下网关的包,确认可以支持长链接。我拒绝了。表示对方要先证明不支持长链接,我再去排查。

然后他们继续找经过的中间件团队,要求他们挨个检查是否中间有丢失信息。群里已经有20多个人了,包括对方自己的 NAT 团队,我们的网关团队,我们的 gRPC 团队和服务团队。

第二天,依然要求我们这边去抓包。我依然拒绝在对方没有证明我们这边存在问题的情况系去帮忙排查。然后提供了一个 curl,这个 curl 可以使用同一个 tcp 连接发送 3个请求,可以明确证明链路上都是支持长连接的。命令和输出大体如下:

但是并没有人去运行,这个群里多了很多级别更高的人物。

第三天一早,群里就要开会,拉了很多大佬,要求我加入帮忙排查,我依然拒绝了,我已经证明我们这边是没有问题的,如果要我排查我们的问题,需要对方先证明我们这边存在问题。然后让对方跑一下我昨天发的 curl ,看一下长连接到底可以不可以用。

有人去他们的程序运行的环境中跑了一下,从这个结果可以证明,所有的中间件都没有问题,大概率是他们的程序代码有问题。

下午,定位到 HTTP SDK 的客户端的参数用错了,程序会频繁关闭 TCP 连接。

 

pngpaste – | tesseract stdin stdout

总是有人喜欢贴截图而不是文字,我的工作又经常要求跟客户要他们的 trace id 来排查问题。为了可以少说几句话节省时间,可以用下面的 alias:

pngpaste 的作用是把剪切板的内容输出到 stdout 中。

tesseract 的作用是识别 stdin 中的图片并且输出到 stdout 中。

使用方法是,将图片右键复制到剪切板,然后到终端上执行命令 pocr

识别率非常高,并且 pocr | grep abc 可以接后续的命令来处理图片中的文字。

二者在 Mac 上都可以通过 brew 安装。

 

 

PromCon 2022 演讲:Alerting with Confidence

我从 2018 年就在做和监控告警相关的工作,到现在已经有差不多5年了。之前几年集中在报警的自动化处理上,后来发现这样做效果太少,治标不治本,后面在 Shopee 主要关注提高 Alert 的设置准确性和处理流程上面,我认为这样可以从根本上解决问题。

今年在 PromCon 上做了一个演讲,介绍了从 Alert 的配置,到触发,最后 Review 的一些经验。

演讲是英文的(虽然我的口语也不太好),视频已经上传到了 Youtube:https://www.youtube.com/watch?v=OWZU3S44ss0

Slides 地址:https://github.com/laixintao/alerting-with-confidence

 

没来的请举手

我们需要在一个 VPC 网络环境中采集一些服务的 metrics,TSDB 存储在中心机房中,存储节点、中心节点和采集端的网络是不通的,要访问的话必须开通防火墙配置。网络架构大体如下:

直接从 central 去访问应用的 metrics 暴露端口采集数据,肯定不显示,这样的话要开通的防火墙太多了,也就失去了防火墙的意义。

怎么才能尽可能少的开通防火墙,又保证数据采集呢?

最直观的方法是,直接用 vmagent 部署在 VPC 本地采集数据,采集之后将数据发送到 central 机房。

那么又有了一个问题:监控的监控。我们怎么去监控采集端 vmagent 的健康呢?简单的方法是,直接开一个双向的防火墙白名单,我们从 central 直接去监控 vmagent。但是我想到一个方法,可以免掉这个防火墙。

第一步,我们将 vmagent 的采集 target 加入到它自己的采集列表中,即,让它自己收集它自己的 metrics,然后发送到 central。

然后我们再配置 alert,难点就在这里。

Prometheus 触发 alert 的规则是:

  • 如果表达式的 evaluate 结果是 null,说明不满足条件,不 fire
  • 如果表达式的 evaluate 结果有值,说明满足设定的条件,fire

我们用如上的模式采集 vmagent 的 metrics,就会有这个问题:假如 vmagent 挂了,那么不会有人把 metrics 发回来,也就不会有 prometheus 的 up metric, 如果我们设置一个 alert rule: up < 1 , 也就不会 fire。就遇到了这个问题:没来的请举手。

解决方法是,既然已经确定这个 target 必然会存在,可以将默认值设置为 0,如果有值的话,会被 overwrite 成1.

PromQL 原生的表达式:

MetricsQL:

这样,只有确定采集端 vmagent 是 up 的时候,才不会触发 alert。

这个查询表达式对 Push 到 Prometheus 的模式也同样适用。

另外还有一个方法可以解决这个问题,就是在 VPC 中搭建两个 vmagent,互相采集对方的 metrics,发送回来。这样有一个缺点,就是如果中间的网络有问题,那么两个 vmagent 就会一起挂掉了,不会有 metrics,也就不会触发 alerts。

参考:

  1. https://nklya.medium.com/promql-how-to-return-0-instead-of-no-data-9e49f7ccb80d