一次生产故障引发的一些思考与问题,请大大们帮忙分析

143 天前
 zhoudaiyu
我们是公司的 K8s SRE 运维团队,近期发生了一次生产故障,一台机器上某 2 个 Pod 里面创建了很多线程,达到了宿主机的 pid_max 的阈值,机器上所有进程在某些达到阈值的时刻都无法创建新线程( Pod 正常),导致了故障。
我们领导的想法是,他们线程创建过多了,并且是不应该创建这么多的(也得到了对方的认可),这是直接原因,我们设置 pid_max 较低(约 10 万),是间接原因。开会讨论我们要补齐相关告警,优化 pid_max 的配置,并从 kubelet 维度限制 Pod 的线程数。但是开发的领导说,这次是 pid_max 导致的,如果下次是别的内核参数不对出问题怎么办?我的领导说让我参考一下其他集群的相似的机器的内核参数(有多个生产集群,但是硬件配置,操作系统,内核,k8s 版本都不完全相同),修改出问题的机器的配置。
我部分赞同领导的想法,但是我也不能确保没出过问题的机器的内核参数配置就一定对,而且同步过来参数是不是一定适合这台机器,这也不好说。
我现在有疑虑的点就是,在我们的技术有限(运维经验都在 3 年以内),人力有限( 3 个人运维 300 开发团队的应用)的条件下,如何能解决这种认知范围之外的问题(之前没有线程数监控,甚至排查的时候也花了较多时间才看到),因为操作系统实在是比较复杂,各类的内核参数、system service 配置等等实在是难以完全掌握,确实没有办法保证不会再出类似的问题。而且,为了控制成本,领导也不打算社招一些丰富经验的老运维去带带我们。
2329 次点击
所在节点    程序员
22 条回复
Aliencn
143 天前
团队技术能力不够,又无法扩招团队,那就通过外包形式来解决吧,比如买一些云的 K8S 服务
zhoudaiyu
143 天前
@Aliencn 国企,我们是纯私有化部署的,不能上云
qq135449773
143 天前
经典决策层之又不想花钱又想办事儿
EastLord
143 天前
只能不断学习,比如 k8s/docker 官方文档,尝试问问 chatGPT ,当个参考不能全信,遇到问题来 v 站问问老哥
zsc8917zsc
143 天前
国企的话,资源有限,那就发挥不怕苦不怕累的精神,一个参数一个参数的啃,没日没夜的反复验证,创造一个又一个可歌可泣的故事......
defunct9
143 天前
你怎么可能提前预知哪些指标会超出阈值呢,只有出了事补足,补足,补足,3 年后,自然没啥大毛病了
FrankAdler
143 天前
k8s 能限制 pod 资源除了 cpu 内存也没几项了,全部过一遍,设置下合理的值应该工作量不大,用的应该是 cgroups 能力?
Aliencn
143 天前
@zhoudaiyu 云厂商也有私有化部署的服务,当然不一定非得买云厂商的,很多供应商可选择。


国企的话更要外包了,出了问题可以甩锅,也给民营企业一个挣钱的机会,哈哈哈。
Makabaka01
143 天前
@zhoudaiyu 要么扛住压力,用公司的资源让自己进步,反正自己不是老板出问题亏的也不是自己;要么跑路
opengps
143 天前
既然是能力之外的,那么这类故障有了这次也会有下次,只能减少不会杜绝。

你有的监控的参数再多,也架不住有你不懂得地方,所以能做的就是多参考市面上的监控指标,有什么抄什么,等自身能力到一定数值之后可能就是你有什么市面上抄你什么。

举个我的例子:当年我人肉运维时候,就怕服务器端 socket 死掉,所以就自己写了个检测端口能否连上的程序,一个放在局域网,一个放在公网,当时真的出现了光纤被挖断的事故,两个报警都有效但内网的显然发不出来,幸好有放在外网的这一份报警程序凌晨 3 点把我吵醒起来运维,一个电话打给联通到凌晨 4 点就反馈说给解决了。然后过了几年,我听到了脉脉故障的故事(只有内网的监控,以至于官方自己没有第一时间发现故障,反倒通过市场客户反馈得知故障)
xueling
143 天前
这种容器服务,如果没有太多经验,不踩坑是不可能的。可以用我的开源项目: https://github.com/xl-xueling/xl-lighthouse 。网络上搜集所有可能导致宿主节点宕机/故障的配置参数,然后开发一些数据上报脚本,建立全方位的统计监控体系。我的项目可以任意创建自定义统计监控指标,实现任意维度的数据监控,使用非常灵活,统计监控方面的功能比 Prometheus 那一类工具要强大的多。
tool2dx
143 天前
@opengps 哈哈,我也是。上次遇上机房电源老化大维修,网络断了没及时恢复。还要自己打电话去机房问才知道。

只能依靠外部交叉报警。
zhoudaiyu
143 天前
@qq135449773
@EastLord
@zsc8917zsc
@defunct9
@FrankAdler
@Aliencn
@willx12123
@opengps
@xueling 我在想要不要鼓弄领导买一套阿里云/腾讯云的服务(纯测试用不跑实际业务),然后把监控告警也买了,然后对着补齐?
RainCats
143 天前
@zsc8917zsc 是不是还得来点什么重病奋战、什么老婆生孩子仍旧坚守岗位、什么家里人去世强忍悲痛奋战之类的
isno
143 天前
如果下次是别的内核参数不对出问题怎么办?事实的做法是出了问题就修,没别的办法。

说点我的建议
1. 搞全链路测试、压测,提前找出问题。
2. 让开发也参与报警的设置,这次是线程数故障,下次如果是内存不够、带宽不够、业务接口不通呢?难道全你们设置
3. 买技术支持,参考 B 站大故障。。。
isno
143 天前
[如何能解决这种认知范围之外的问题?]

来看看我写这篇文章。

https://www.thebyte.com.cn/Observability/Observability-vs-Monitoring.html
yyttrr
143 天前
这种指标太多了,连接数,rss 内存,wss 内存,cpu throttled 啥的
遇到一次问题下次别再出就行
Hopetree
143 天前
监控告警搞上去,Prometheus 有没有利用上
mango88
143 天前
补齐监控指标,调低告警阈值,让业务开发团队配合压测,分配资源的时候多预留一些
coderzhangsan
143 天前
又想马儿跑,又不想给马儿吃草。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1054840

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX