2024年5月

早上看到一个粗看起来很简单的问题，“如何在crontab中增加每7分钟循环执行的任务”，下意识想不就是 */7。这么简单的问题怎么一堆回答。
先上结论，比如每7分钟，我10:40分添加的，

  • 第一次执行是在10:42，而不是下意识的10:47
  • 10:56最后一次执行，下一次执行是在11:00，而不是想象中的11:03

cron.jpg
也就破坏了需求中“每7分钟”，解决办法是每分钟执行，在脚本中判断当前时间

# 获取当前时间的分钟数
current_minute=$(date +"%M")

# 判断分钟数是否是7的倍数
if (( current_minute % 7 == 0 )); then
  # 如果是7的倍数，执行任务
  echo $(date +"%Y-%m-%d %H:%M:%S") >> /tmp/timestamp.txt
fi

背景：

我们有一款私有化部署系统，服务于用户购买的智能终端（简单理解为顺丰小哥手持的扫码枪）。周六接到端开发工程师反馈，此批设备续航异常，理论数据两周，但实际只有三至四天。
经过监测电量、抓包手段，电流的峰谷交替约为20秒电量消耗.jpg
端上抓包也显示每20秒收到来自服务器的keepalive报文，此原因导致设备无法休眠！

排查过程：

  1. 首先去服务端抓包，很清晰也能看到每20秒。当我看到抓包结果时，马上自信的答复，这是端上发来的keepalive包呀，肯定端上问题，不查端查服务器干嘛- -！keepalive包.jpg
  2. battle，端开发工程师回怼，“我抓包是从服务器端返回的”，仔细一看还真是。这时候懵圈，证据显示都是对方发来的，且正确响应
  3. 没头绪时，在想经历的中间环节。智能终端---aws NLB---mqtt服务器，NLB配置了标准的tls，卸载证书后转发到mqtt，功能测试都正常，且NLB用了这么久，不应该有问题
  4. 难道是运营商或者网络设备发送？想想不可能，tcp无法伪造IP，持续没头绪
  5. 中间环节只有NLB，进一步排查发现aws的NLB有区别于其他云的独特“机制”aws机制.jpg
  6. 接下来就是验证EIP直接暴露，问题消失。问题确认

总结：

aws NLB产品如果配置了tls监听，会主动20秒为周期发送keepalive！！！

客户端发送Keep-Alive包
AWS NLB行为时间线

时间点行为描述
第0秒客户端发送Keep-Alive包，NLB接收到并立即返回。
第20秒NLB发送Keep-Alive包到前端和后端。
第40秒NLB再次发送Keep-Alive包到前端和后端。
第60秒客户端再次发送Keep-Alive包，NLB接收到并重置计时。
第80秒NLB发送Keep-Alive包到前端和后端。
...重复每20秒发送Keep-Alive包的过程，直到客户端停止发送。

阿里云NLB行为时间线

时间点行为描述
第0秒客户端发送Keep-Alive包，NLB接收到并保持连接。
第60秒客户端再次发送Keep-Alive包，NLB接收到并保持连接。
第120秒客户端再次发送Keep-Alive包，NLB接收到并保持连接。
...重复每60秒发送Keep-Alive包的过程，直到客户端停止发送。

客户端不发送Keep-Alive包
AWS NLB行为时间线

时间点行为描述
第0秒客户端与NLB建立连接。
第350秒没有数据包发送，NLB关闭连接并发送TCP RST包。
第351秒连接关闭，客户端无法继续发送数据。

阿里云NLB行为时间线

时间点行为描述
第0秒客户端与NLB建立连接。
第900秒没有数据包发送，NLB关闭连接。
第901秒连接关闭，客户端无法继续发送数据。

在上一篇文档中实现了检查单台服务器故障的典型排错场景。此次我们加大难度
一、排查链路中故障，识别南北向流量走向并给出排查结果

  • 难点

    • 模型无法理解私有环境
    • 给出的建议具备安全风险

  • 思路

    • 结合提示词，使用function call功能来准确获取配置
    • 新增the_supervisor角色，对planer的建议安全过滤

二、与真实用户交流，给出域名申请建议并检测是否可用

  • 难点

    • 引导用户使用合规的子域名

  • 思路

    • 提示词约定规范，使用socket库来判断可用性

整体难点，多agent执行顺序，“技能绑定”，来看效果。图1为用户与gatekeeper探讨需求pic1.jpg
图2为agent建议用户使用的解析记录pic2.jpg
图3为正确路由南北向流量问题，并使用对应function判断pic3.jpg

关键代码片段
pic4.jpg