记录一次问题排查的故事

Posted on by 6 Comments

今年工作中发生的一个问题，因为太简单了，觉得不值得记录。今天读 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

Posted on by 3 Comments

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

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

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

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

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

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

 

 

PromCon 2022 演讲：Alerting with Confidence

Posted on by Leave a comment

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

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

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

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

 

没来的请举手

Posted on by 2 Comments

我们需要在一个 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
 

婚礼回顾和一些经验分享

Posted on by 26 Comments

我在国庆完成了和老婆的婚礼，这件人生大事从计划到完成花费了至少1年的时间，牵扯了上百人的精力，值得记录一下自己的感受。

一场婚礼是非常耗费精力的事情，涉及到两大家族长时间的准备。一个家族内部之间的矛盾可能在这个过程被激发出来，鸡毛蒜皮的事情可能会导致出来一些纷争，牵扯出很久时间之前的恩怨；两个家族之间的价值观也会受到考验。事后来看，有些人之间的感情会更好，因为一起经历过了这件大事，有些人的感情可能会变差——由于有些地方事情办得不好。

家庭和亲戚们不是人能选择的，所以协调这样一个团队去完成一个大项目，本身就是一件很复杂的事情。

首先趁着记忆总结一下办一场尽量完美的婚礼的一些经验：

  1. 所有能提前做的事情都从确定结婚时间开始就准备，至少需要3个月的时间。包括：
    1. 拍婚纱照（需要预约档期）
    2. 定制西装（一般需要一个月）
    3. 租用婚纱（或者购买，也需要提前）
    4. 预定酒店（良辰吉日需要提前至少半年）
    5. 确定摄影跟拍、录像、司仪、跟妆的档期
    6. 找一个靠谱的婚庆
    7. 等等，只要现在具备了开始做的条件，就立即开始动手去做，不要说“这件事等提前一个月准备”就够了，能现在完成的事情就现在完成
  2. 确定整体的流程，要有一个在线的文档，跟所有的参与人员同步信息，就像项目管理一样。比如每一个时间该做什么事情，需要什么物件/物料，主要负责人是谁，联系电话等。
  3. 婚礼流程事无巨细落实，比如改口茶在哪里做，谁在场，杯子准备好了没，茶准备好了没，要说什么，要做什么，这个环节的负责人是谁，等等。
  4. 每一件事必须安排给一个负责人，不能是多个。比如签到处，可以安排3个人，包括引导员（入座），负责收红包记录礼金（很重要，千万不能收到无名红包），替班（不能只安排一个人让签到处没时间上厕所）等等。但是必须有一个签到处负责人，有事情打负责人电话，安排给负责人。告诉他他的职责。如果没有一个明确的负责人，很多任务无法落实。现场团队也必须有一个负责人，现场任何问题都直接找他，比如有客人临时参加没有位置，要现场负责人来解决。负责人一定要找靠谱、办事认真的人，否则一定会乱套。同步给所有准备婚礼的人，哪一个环节出了问题要找谁。
  5. 座位问题：邀请人参加婚礼，一旦确定客人要参加，一定问清楚是会来多少人，如果带小孩，小孩几岁。（酒店一般免费加宝宝椅但是不能加座位）。极力避免有客人来了没有找到自己的座位，或者到了之后发现自己的座位被占用的尴尬情况。（很尴尬我们就遇到了有客人没有位置吃饭的尴尬情况）
  6. 婚礼执行过程遇到任务不要抱怨，遇到问题只去想怎么能够解决。遇到一些有任务的人丢了东西，忘了流程，很正常，发火、抱怨没有用。我知道这些事之后从没有埋怨人，马上开始重新做补救措施。
  7. 预留充足的时间，因为整个流程完全按照计划发展几乎不可能（我们就取消了外景拍摄环节才让其他环节都顺畅）
  8. 摆正心态，这场婚礼最重要的是谁，是给谁办的，想明白这个问题，然后其他的问题都以这些人会不会高兴为准。
  9. 七大姑八大姨的“风俗”都去掉。这个博客的读者肯定不会认为“新娘的脚一旦落地”会让新人不幸福吧？按照我帮忙别人准备婚礼和我自己的婚礼的经验，每一次婚礼都会有 N 多人中间调出来说“哎呀你们没按规矩办啊！新娘不能xxx，新娘不能xxx” “发车时间得是几点几分”，“婚房外人不能进啊，摄影师拍摄也不能进！”。这些人就和恐怖分子一样来破坏婚礼，我在我们村随便拉一个大妈她都能我们全家说出来一些谁都没见过听过的习俗，这些习俗不知道也就罢了，知道了你不按照这些人说的办还心里膈应。所以，我的建议是，回到8，不是给这些亲戚或者外人办的，是给双方父母和我老婆（对我来说）办的，这些习俗对他们重要吗？重要，那就严格遵守；如果不重要，这些人爱咋说咋说。要和家人沟通好，任何中间跳出来的风俗习惯，就当听不见。
  10. 来帮忙的人不是越多越好，多给靠谱的人安排工作，不要不好意思，事后谢礼到位就行，记着人家的人情。不靠谱的人不如不来。
  11. 作为东道主，远道而来的客人需要好好招待。
  12. 婚庆的质量决定了整场婚礼的质量。一定要好好找，但是这个行业我觉得水很深，好在我的叔叔是做这一行的，我的婚礼是他操办的，非常成功。
  13. 敢于下判断，很多问题是能用钱解决的，不要过于纠结和花费过多精力。比如有临时客人来参加婚宴，现在看来位置不够直接加一桌要比重排座位要好。

其实无论是谁，第8个问题的答案一定是自己的爱人。这个很重要。

婚礼涉及的事情太多了，双方家庭一定会有在某些事情上不一致的地方，这对两个家庭的结合来说就是考验，对小夫妻也是考验，看能否协调好双方家庭。刚办完婚礼的我觉得如果婚礼能和谐地办好，那么以后幸福过日子不成问题。

婚礼看似费神费力，我的心态是，抱着享受过程的心态去准备每一件事，去体验。是一个和自己的兄弟们加深感情的机会（得请大家帮忙，团队合作），是一个双方家庭融合的机会，是一个考验小夫妻和双方父母三观的机会，也是你去认识对方家庭成员的机会，更是一个和自己的妻子加深感情的机会。

无论婚礼办成什么样子，只要第8个问题的答案这些人满意，那就是成功的。

我对自己的婚礼还是很满意的，虽然很累，但是办下来让我觉得很满足，这场婚礼也提醒了我有那么多关心我的人，让我知道这一切是多么来之不易。还认识了很多办事靠谱的人。比如我们的化妆师，从凌晨2点开始几乎没吃过东西，在最后婚礼上敬酒环节（最后一个环节，马上就结束了）依然一丝不苟的化妆，最后一次化妆间就和第一次化妆的细致程度一样，让我顿时觉得我也得成为这样对工作一丝不苟的人）。

最后，结婚旅行也是一个不错的选择。祝各位读者幸福！