一 背景

偶尔看到其他机器人有很多插件，有个看图猜成语的很有意思。连续一段时间都在处理客户的问题，刚好周五晚上，顺道做个适合当前框架的插件。

看图猜成语是一个适合群聊的游戏，它是通过调用api实现的。这个api会返回一个图片链接和对应的成语, 再没有回答对正确答案之前，会逐渐做出提示。

一 背景

客户反馈用categraf的snmp插件采集交换机出现数据断点，检查了categraf日志，发现里面有大量超时

categraf: 2023/09/22 08:45:16 instances.go:180: agent udp://1.2.3.4:161 ins: gathering table bgp error: performing bulk walk for field peer_addr: request timeout (after 0 retries)
...

手工用snmpwalk命令跑是正常的。作为对比，准备了一个脚本如下， 每1分钟请求一遍用户配置的oid。看categraf报超时的时刻，脚本是否也超时。最终发现categraf日志中出现超时，脚本正常采集。

#!/bin/sh

while true
do
    cat oids   | while read oid
    do
         echo "$(date) oid: ${oid}"
         snmpwalk -v2c -c public  1.2.3.4   ${oid}
    done >>debug.log 2>&1
sleep 60s
done

之前社区也提了一个issue ,反馈v0.3.27版本采集snmp出现断点，v0.3.25 却没有问题。 https://github.com/flashcatcloud/categraf/issues/639

对比v0.3.25到v0.3.27 的代码，v0.3.27 给snmp 增加了一个snmp_up 指标。 代码见 https://github.com/flashcatcloud/categraf/pull/618/files。 为了快速上报up指标，将snmp_up和其他oid放到了两个goroutine中。

一 背景

商业客户反馈用categraf的net_response插件配置了udp探测, 遇到报错了，如图

udp是无连接的，无法用建立连接的形式判断端口。 插件最初的设计是需要配置udp的发送字符，并且配置期望返回的字符串，

[[instances]]
targets = [
      "127.0.0.1:161",
]

protocol = "udp"

## string sent to the server
  send = "hello"
## expected string in answer
  expect = "hello"

通过返回字符与期望字符是否相等，来判断端口是否连通。用户随即发了另一张图 ，用ncat 来探测端口是ok的