收到一条告警，提示一个容器挂掉。

登录节点，使用dmesg确实发现了oom现象。

查看容器运行时长，确定了容器名称。

登录dcos mesos容器平台，确定容器名称。

之前同事使用UCloud的短信服务的SDK实现了业务程序调用发送短信的功能，可是最近老是发不出来了。经过检查，服务挂掉了，启动后并且做了uptime kuma监控。不过，运行一段时间后还是挂掉。尝试直接发送短信发现无法收到短信。后台直接显示发送失败。

查看失败原因，说是签名问题。


提了工单文明情况，工程师解释由于签名是英文的不合适。

申请了中文签名后，异常报错依旧。这次报错是“UT:0010”。

工程师说是“核实是关键词导致”。稍后，再次发送就可以了。

有这么一套测试系统，单机通过容器部署中间件以及一些java程序，空转的时候cpu也有70%左右。今早进行了cpu扩容，cpu从8C到16C，mem从28GB到32GB。扩容后，cpu使用率立马下来了。

fujifilm - 富士胶片

富士山、富士康、富士胶片，哎呀，这些个名字老是傻傻分不清。最近，同事说无法进行扫描了，总是报错，

经过重启、升级固件，都没有效果。后来发现连接的WiFi跟打印机不是直连，中间的小路由器做了NAT转换，可能打印机无法回传数据导致。

换成与打印机/扫描仪在同一个路由器下，IP地址可以互相直连ping通后，解决了。

参考：
https://blog.csdn.net/rtkj1122/article/details/131254118

业务越来越多，资源有点不够用了，而且最近还出现了因资源不足导致虚拟机工作异常，进而出现集群不稳定的问题，给日常的工作和摸鱼带来了很大的困扰。

升级。

手头有4根32GB内存条，有一根有问题，这次只更新3根。手头还有4片NVME256GB，但是工作站还剩余2槽PCI 16，也就升级2个吧。

（1）关机
打开proxmox，分别针对虚拟机进行shutodwn -h now。然后把proxmox也关闭。

（2）物理硬件更换

（3）长ping判断机器启动

（4）打开proxmox页面，开启虚拟机

（5）参考手册，根据没有启动的服务进行一一点射

收摊野餐~

平台分布式文件存储采用的是国内成熟的fdfs软件实现，由于物联网设备升级依赖http协议，所以在返回的升级文件协议中默认是http，不能是https。但是，时间到了2024年7月，https早已是成熟的技术并得到普遍的应用，而且微信小程序必须使用https以及域名验证才能获得webview打开下载。

这可如何是好。

本来架构就复杂，后端fdfs，前端nginx负载，为了方便apk分发，将一个一个apk采用 location的形式跳转到123pan，但是123pan无法实现文件验证。
想来想去，之前的域名是file，123pan使用的域名是filecdn，干脆使用file3固定在华为云来实现吧。

没想到，整个过程还真不难。华为云OBS新建一个桶，权限是全局读，开启域名加速也就实现了CDN功能。下载一个试试，还能跑到45Mbps左右。效果还不错呢。

周一一大早，有一条告警，提示kubesphere的vip地址的6443端口无法通信。经排查，原来是办公区有节点拿走了vip地址201的地址。这下导致发布也报错了。

紧急处理：

在发布机器里
arp -s 192.168.124.201 00:16:3e:16:fe:90

并且在dhcp分配里，静态分配地址192.168.124.201。

其实，这个地方的mac地址是假的。因为mac地址00:16:3e:16:fe:90已经分配给了vip所在的云主机了，而dhcp不允许一个mac地址有两个ip地址对应。

总结一下，当把服务器放在办公网的IP段后，就牵扯到一个管理的问题了，避免地址冲突是很重要的一项工作。

新加坡服务器94.74.82.232访问山东移动济宁120.224.58.239存在网络异常问题，主要表现在时断时续。



经过遥测发现，服务器到120.224.58.1网关一直正常。

在异常过程中，做了路由追踪图如下。

文字版如下：

[root@ecs-b125 ~]# traceroute -w 1 -d -n 120.224.58.239 -n | nali
traceroute to 120.224.58.239 [山东省 移动]  (120.224.58.239 [山东省 移动] ), 30 hops max, 60 byte packets
 1  10.22.135.97 [局域网 IP]   3.072 ms  3.306 ms  3.969 ms
 2  11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.297 ms 11.22.25.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.611 ms 11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.136 ms
 3  11.22.80.156 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.549 ms  4.405 ms 11.22.80.144 [美国俄亥俄州哥伦布市 DoD网络信息中心]   8.382 ms
 4  11.22.80.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   3.439 ms 11.22.80.141 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.211 ms 11.22.80.18 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.404 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  11.22.97.55 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.547 ms * 11.22.97.57 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.102 ms
11  * * *
12  * * *
13  172.16.12.50 [局域网 对方和您在同一内部网]   34.897 ms 172.16.12.42 [局域网 对方和您在同一内部网]   36.166 ms 172.16.12.50 [局域网 对方和您在同一内部网]   34.878 ms
14  223.119.19.217 [香港 中国移动国际有限公司]   38.252 ms 223.119.19.221 [香港 中国移动国际有限公司]   41.198 ms 223.119.19.217 [香港 中国移动国际有限公司]   39.004 ms
15  223.120.3.89 [中国 移动]   37.124 ms 223.120.3.178 [中国 移动]   59.656 ms 223.120.3.182 [中国 移动]   78.404 ms
16  221.183.89.170 [广东省广州市 移动骨干网]   63.791 ms  62.432 ms  64.021 ms
17  * * 221.183.89.182 [广东省广州市 移动骨干网]   62.458 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@ecs-b125 ~]# traceroute -w 1 -d -n 120.224.58.1 -n | nali
traceroute to 120.224.58.1 [山东省 移动]  (120.224.58.1 [山东省 移动] ), 30 hops max, 60 byte packets
 1  10.22.135.65 [局域网 IP]   377.736 ms 10.22.135.97 [局域网 IP]   2.111 ms  5.245 ms
 2  11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.874 ms 11.22.25.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   6.613 ms 11.22.25.16 [美国俄亥俄州哥伦布市 DoD网络信息中心]   6.252 ms
 3  11.22.80.144 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.222 ms 11.22.80.146 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.187 ms 11.22.80.158 [美国俄亥俄州哥伦布市 DoD网络信息中心]   8.164 ms
 4  11.22.80.24 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.150 ms 11.22.80.18 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.978 ms  5.103 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * 11.22.97.61 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.417 ms *
11  * * *
12  * * *
13  172.16.12.50 [局域网 对方和您在同一内部网]   34.949 ms * 172.16.12.46 [局域网 对方和您在同一内部网]   39.795 ms
14  223.119.19.221 [香港 中国移动国际有限公司]   36.168 ms  40.160 ms 223.119.19.217 [香港 中国移动国际有限公司]   36.256 ms
15  223.120.3.89 [中国 移动]   35.585 ms  33.026 ms  35.657 ms
16  221.183.89.174 [广东省广州市 移动骨干网]   59.611 ms  62.659 ms 221.183.89.170 [广东省广州市 移动骨干网]   62.967 ms
17  221.183.89.178 [广东省广州市 移动骨干网]   63.071 ms 221.183.89.33 [广东省广州市 移动骨干网]   59.152 ms *
18  * 221.183.89.14 [广东省广州市 移动骨干网]   66.073 ms 221.183.89.46 [广东省广州市 移动骨干网]   74.578 ms
19  221.183.89.14 [广东省广州市 移动骨干网]   66.112 ms 221.183.136.157 [广东省广州市 移动骨干网]   78.909 ms  81.533 ms
20  221.183.40.82 [广东省广州市 移动骨干网]   87.655 ms 221.183.143.18 [广东省广州市 移动骨干网]   84.349 ms *
21  221.183.143.18 [广东省广州市 移动骨干网]   84.528 ms  84.879 ms *
22  120.222.48.142 [山东省 移动]   94.940 ms * 120.222.48.138 [山东省 移动]   104.946 ms
23  120.224.58.1 [山东省 移动]   90.051 ms  89.346 ms  89.011 ms
[root@ecs-b125 ~]#  

联系了移动技术员，没有回消息，想着这问题可能也不归他们管。尝试打了10086，可是需要手机号以及服务密码，可是我没有哦。然后就搜索了一下，找到了10080，一打感觉像是个投诉电话，赶忙解释，只是想优化一下网络，但是不知道找谁。对方也不错，耐心听取，然后说转接一个电话。电话转接后，客服记录了下问题以及我的电话，说稍后有人联系。大概过了一会儿，有一个本地的电话打来了，详细了解了一下问题现象。对方以为是我们访问国外网站不行，我做了解释，是我们面向东南亚客户在华为云购买了云服务器，但是与我们办公出口的公网地址通信有丢包或者中断，但是呢，从办公区访问那边确可以，而且根据遥测数据显示，从新加坡到我们办公网出口的网关之间是没有任何丢包的。对方表示去查一下。

业务使用华为云，牵扯到北京和新加坡节点，而北京也承担了监控系统的重任。最近三天，时常网络中断，导致新加坡云主机上报categraf信息到北京节点失败，告警不断。昨天整理了相关信息，今天提了华为云工单。

对方也有排查流程，主要是

mtr x.x.x.x --report

拿到信息后，对方排查了几个回合，定位到当前北京和新加坡节点均有EIP流量超量告警。

果不其然，也没有收到过邮件告警，但是确实是有。

处理了一下过多的流量之后，近一个小时已经没有了告警。但是问题依旧存在。

于是，再次反馈工单。并且，尝试使用一些拨测平台进行测试，发现全球访问均正常，只是部分地址访问异常。

提交两张图片之后，怀疑是华为云或者其他机构在网络中的安全设备影响。对方再次核查中。

简单梳理一下，在流量超量之后，会造成网络访问丢包、卡顿，但是不会是中断，比如如下情况：

当天晚上，接到华为云的电话，大概分析了一下，对方也承认可能并不是因为超限造成，而且也联系了运营商进行优化。但是，问题依旧。考虑到晚上了，等明天再说吧。

第二天，对方说观测到还是有丢包。索性直接将流量带宽提升到100Mbps，这下没有丢包了。对方也不再说什么，继续排查。

与此同时，通过traceroute进行正反测试，包括正常情况与异常情况。

补充材料，从bj ping sg的190.92.221.0/24，.25是不通的，但是24和26是通的。

目前看，sg到bj 走的是联通骨干，但是到联通海淀可能有问题；bj到sg走的是电信，福建电信到电信骨干没问题，但是出海就有问题了。详情见如下四图。

稍后，对方又说已经联系了运营商进行了调整。可是，问题依旧。

17:00左右，云计算那边应该是被工单搞的不行了，毕竟24小时没有解决。对方打来电话，说了一下进展，对方将该IP地址出口从国际链路与电信链路之间进行切换，都是好一会儿然后就异常，还是无法正常使用。无奈，只能将问题归咎于国墙了。

然后就是扫尾工作。
（1）从华为云上购买一枚新的EIP地址，解绑老地址，绑定新地址。收到告警，新加坡主机监控上线。
（2）打开阿里云，针对每个域名搜索190地址，将解析改成新地址。
（3）修改监控系统nagios，通过sed批量修改成新地址并重启。
（4）修改堡垒机中关于该服务器的地址。

检查：

（1）nagios监控正常。
（2）夜莺监控中该主机监控数据恢复正常。

事毕。

不出意外还是出意外了。没有经过检验的结果是靠不住的。过了一小会儿，问题又出现了。
经过之前的反复排查，大胆的做了一个测试，将北京云主机的服务端口17000挂到了该区域的ELB上面，没想到通了，而且状态稳定。

另外，也做了一个从新加坡云主机到UCloud云ULB的长ping，没想到一晚上一个丢包也没有。

而从华为云新加坡到华为云北京四的ecs的eip，确实不通，或者时断时续。

26号一大早，提了工单，可是测试sg到ecs的eip居然没有问题了？搞的工单里面赶紧跟人说目前良好，无法复现。稍后，华为云电话也打来了，希望可以开会讨论。可是，我说目前现象已不能复现，等等再看吧。于是，关闭了工单。

就这样，过了一会儿之后，看着绿色的连通性能，心中在想到底是咋回事儿呢？

于是，分别在sg和bj的ecs里面进行路由追踪，看下图：

居然改到联通了！！！

之前，sg到bj之间走的是电信线路，现在走的是联通线路。

上午，一位同事过来说USB设备工作异常，提示“USB端口上的电涌”。

这种情况，看起来像是USB设备的问题，可以通过使用后板USB插口，或者避免一些非U盘、键鼠等设备的插入。而同事还有一个USB设备的风扇。

拔掉USB风扇后，工作正常。

记得以前在数据中心的时候，空调的电源是独立的，因为其是柔性负载，尤其注意在使用发电车的时候不能接入空调负载。

https://blog.csdn.net/anlr2020/article/details/119205844