you are better than you think
主页
目录
标签
一 背景
客户反馈用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的
2022年终总结早就写了一部分,趁这两天头疼休息,把一些有意思的点,按照时间顺序整理到博客。
3款vpn客户端的容器化
解决客户端共享的问题
解决硬件绑定问题
解决验证码依赖
避免路由冲突
客户使用的vpn服务商各不相同;有些客户的vpn客户端再第一次登录后会绑定当前硬件;有些客户端除了用户名密码,还强制短信验证码登录。 随着客户越来越多,遇到路由冲突的可能性也会越来越高。
容器化之后,客户端全部扔到一起,每个容器只需要暴露一个端口做代理即可,浏览和登录都可以利用这个端口。
这里配合云厂商的数据热迁移,只用一台低配服务器就可以搞定。除了降本外,容器化客户端这里有个有意思的点,是如何解决只输入一次短信验证码?我的解决方案是通过tcp代理转到ssh 共享的session上。这里跟tcp转unix socket还有一些差异,还需要做一点特殊转换,利用转换就可以在其他机器上通过这个tcp代理登录了。转换细节后面再整理一篇博文介绍。
tcl脚本
支持proxy
支持relay
支持password
支持identity file
大概5年前也简单学习了tcl的语法,整理了一个脚本发布在公司wiki上。后面整理到博客了,见一份登录脚本 。 这次升级主要是配合vpn容器化,再加上重新整理,proxy/relay/password/identity file抽成单独的方法,并支持这些方式组合登录。留个坑,后面再发一遍博文单独介绍。