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

[zhoudaiyu]

我们是公司的 K8s SRE 运维团队，近期发生了一次生产故障，一台机器上某 2 个 Pod 里面创建了很多线程，达到了宿主机的 pid_max 的阈值，机器上所有进程在某些达到阈值的时刻都无法创建新线程（ Pod 正常），导致了故障。
我们领导的想法是，他们线程创建过多了，并且是不应该创建这么多的（也得到了对方的认可），这是直接原因，我们设置 pid_max 较低（约 10 万），是间接原因。开会讨论我们要补齐相关告警，优化 pid_max 的配置，并从 kubelet 维度限制 Pod 的线程数。但是开发的领导说，这次是 pid_max 导致的，如果下次是别的内核参数不对出问题怎么办？我的领导说让我参考一下其他集群的相似的机器的内核参数（有多个生产集群，但是硬件配置，操作系统，内核，k8s 版本都不完全相同），修改出问题的机器的配置。
我部分赞同领导的想法，但是我也不能确保没出过问题的机器的内核参数配置就一定对，而且同步过来参数是不是一定适合这台机器，这也不好说。
我现在有疑虑的点就是，在我们的技术有限（运维经验都在 3 年以内），人力有限（ 3 个人运维 300 开发团队的应用）的条件下，如何能解决这种认知范围之外的问题（之前没有线程数监控，甚至排查的时候也花了较多时间才看到），因为操作系统实在是比较复杂，各类的内核参数、system service 配置等等实在是难以完全掌握，确实没有办法保证不会再出类似的问题。而且，为了控制成本，领导也不打算社招一些丰富经验的老运维去带带我们。

其实我们注意过内核参数里有个threads-max，当时也调了，但是想当然以为这个是限制线程的

[Aliencn]

团队技术能力不够，又无法扩招团队，那就通过外包形式来解决吧，比如买一些云的 K8S 服务

[zhoudaiyu]

@Aliencn 国企，我们是纯私有化部署的，不能上云

[qq135449773]

经典决策层之又不想花钱又想办事儿

[EastLord]

只能不断学习，比如 k8s/docker 官方文档，尝试问问 chatGPT ，当个参考不能全信，遇到问题来 v 站问问老哥

[zsc8917zsc]

国企的话，资源有限，那就发挥不怕苦不怕累的精神，一个参数一个参数的啃，没日没夜的反复验证，创造一个又一个可歌可泣的故事......

[defunct9]

你怎么可能提前预知哪些指标会超出阈值呢，只有出了事补足，补足，补足，3 年后，自然没啥大毛病了

[FrankAdler]

k8s 能限制 pod 资源除了 cpu 内存也没几项了，全部过一遍，设置下合理的值应该工作量不大，用的应该是 cgroups 能力？

[Aliencn]

@zhoudaiyu 云厂商也有私有化部署的服务，当然不一定非得买云厂商的，很多供应商可选择。


国企的话更要外包了，出了问题可以甩锅，也给民营企业一个挣钱的机会，哈哈哈。

[Makabaka01]

@zhoudaiyu 要么扛住压力，用公司的资源让自己进步，反正自己不是老板出问题亏的也不是自己；要么跑路

[opengps]

既然是能力之外的，那么这类故障有了这次也会有下次，只能减少不会杜绝。

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

举个我的例子：当年我人肉运维时候，就怕服务器端 socket 死掉，所以就自己写了个检测端口能否连上的程序，一个放在局域网，一个放在公网，当时真的出现了光纤被挖断的事故，两个报警都有效但内网的显然发不出来，幸好有放在外网的这一份报警程序凌晨 3 点把我吵醒起来运维，一个电话打给联通到凌晨 4 点就反馈说给解决了。然后过了几年，我听到了脉脉故障的故事（只有内网的监控，以至于官方自己没有第一时间发现故障，反倒通过市场客户反馈得知故障）

[xueling]

这种容器服务，如果没有太多经验，不踩坑是不可能的。可以用我的开源项目： https://github.com/xl-xueling/xl-lighthouse 。网络上搜集所有可能导致宿主节点宕机/故障的配置参数，然后开发一些数据上报脚本，建立全方位的统计监控体系。我的项目可以任意创建自定义统计监控指标，实现任意维度的数据监控，使用非常灵活，统计监控方面的功能比 Prometheus 那一类工具要强大的多。

[tool2dx]

@opengps 哈哈，我也是。上次遇上机房电源老化大维修，网络断了没及时恢复。还要自己打电话去机房问才知道。

只能依靠外部交叉报警。

[zhoudaiyu]

@qq135449773
@EastLord
@zsc8917zsc
@defunct9
@FrankAdler
@Aliencn
@willx12123
@opengps
@xueling 我在想要不要鼓弄领导买一套阿里云/腾讯云的服务（纯测试用不跑实际业务），然后把监控告警也买了，然后对着补齐？

[RainCats]

@zsc8917zsc 是不是还得来点什么重病奋战、什么老婆生孩子仍旧坚守岗位、什么家里人去世强忍悲痛奋战之类的

[isno]

如果下次是别的内核参数不对出问题怎么办？事实的做法是出了问题就修，没别的办法。

说点我的建议
1. 搞全链路测试、压测，提前找出问题。
2. 让开发也参与报警的设置，这次是线程数故障，下次如果是内存不够、带宽不够、业务接口不通呢？难道全你们设置
3. 买技术支持，参考 B 站大故障。。。

[isno]

[如何能解决这种认知范围之外的问题？]

来看看我写这篇文章。

https://www.thebyte.com.cn/Observability/Observability-vs-Monitoring.html

[yyttrr]

这种指标太多了，连接数，rss 内存，wss 内存，cpu throttled 啥的
遇到一次问题下次别再出就行

[Hopetree]

监控告警搞上去，Prometheus 有没有利用上

[mango88]

补齐监控指标，调低告警阈值，让业务开发团队配合压测，分配资源的时候多预留一些

[coderzhangsan]

又想马儿跑，又不想给马儿吃草。

[xueling]

@zhoudaiyu 光测试我倒觉得用处不大，很多线上环境中的问题，测试服务暴漏不出来。不要觉得云服务多么完善似的，人家只分配给你固定资源，不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题，如果只有你自己的服务出了问题，主要还得自己处理。就像你说的线上故障，本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因，云服务厂商有可能给你提供全方位的服务吗，毕竟对于云服务厂商来说，这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标，网络搜集就足够了，比如： https://cloud.tencent.com/document/product/457/39820 你自己网上找找，把这些云服务的监控指标汇总一下就 ok 了。

[guanzhangzhang]

每次发生生产故障，监控也很重要，有没有监控，没有就部署上，有监控没监控到，如何监控上。后续在考虑看看怎么限制