you are better than you think
主页
目录
标签
自动化还是自动化
周五下午跟客户开完例会,稍微梳理了一下这周的需求,发现本周开源版和企业版都发布了很多版本。这里面包含我一直拖着没做的自动化环节。模块发布流程:
打tag -> 触发github action -> goreleaser -> github scm / docker hub;
镜像也是需要上传到国内公有云镜像市场的,方便交付同事交付;
二进制包需要上传到公有云存储,方便交付客户和国内社区用户下载。
这里第一步完全是自动化的,第二步之前也是goreleaser来做得,但是呢github推镜像到国内的云镜像市场,那个时间瞬间就是小时起步了。通过测试发现办公网推国内的镜像市场非常快, 那就从免费的github runner 迁移到办公网内的台式机上。这一步其实需要很扎实的网络来保证跟github的通信, 不过这个改造后步骤1的时间降到了8分钟, 那这些工作就很值了。为了避免直接物理机上做一些骚操作,搞了一个runner的容器镜像。 如何构建镜像见https://github.com/kongfei605/github-runner
一 背景
客户反馈用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的