V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
zhoudaiyu
V2EX  ›  程序员

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

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

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

    22 条回复    2024-07-05 11:26:31 +08:00
    Aliencn
        1
    Aliencn  
       173 天前
    团队技术能力不够,又无法扩招团队,那就通过外包形式来解决吧,比如买一些云的 K8S 服务
    zhoudaiyu
        2
    zhoudaiyu  
    OP
       173 天前 via iPhone
    @Aliencn 国企,我们是纯私有化部署的,不能上云
    qq135449773
        3
    qq135449773  
       173 天前
    经典决策层之又不想花钱又想办事儿
    EastLord
        4
    EastLord  
       173 天前
    只能不断学习,比如 k8s/docker 官方文档,尝试问问 chatGPT ,当个参考不能全信,遇到问题来 v 站问问老哥
    zsc8917zsc
        5
    zsc8917zsc  
       173 天前   ❤️ 1
    国企的话,资源有限,那就发挥不怕苦不怕累的精神,一个参数一个参数的啃,没日没夜的反复验证,创造一个又一个可歌可泣的故事......
    defunct9
        6
    defunct9  
       173 天前
    你怎么可能提前预知哪些指标会超出阈值呢,只有出了事补足,补足,补足,3 年后,自然没啥大毛病了
    FrankAdler
        7
    FrankAdler  
       173 天前 via Android
    k8s 能限制 pod 资源除了 cpu 内存也没几项了,全部过一遍,设置下合理的值应该工作量不大,用的应该是 cgroups 能力?
    Aliencn
        8
    Aliencn  
       173 天前
    @zhoudaiyu 云厂商也有私有化部署的服务,当然不一定非得买云厂商的,很多供应商可选择。


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

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

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

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

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

    来看看我写这篇文章。

    https://www.thebyte.com.cn/Observability/Observability-vs-Monitoring.html
    yyttrr
        17
    yyttrr  
       173 天前
    这种指标太多了,连接数,rss 内存,wss 内存,cpu throttled 啥的
    遇到一次问题下次别再出就行
    Hopetree
        18
    Hopetree  
       173 天前
    监控告警搞上去,Prometheus 有没有利用上
    mango88
        19
    mango88  
       173 天前
    补齐监控指标,调低告警阈值,让业务开发团队配合压测,分配资源的时候多预留一些
    coderzhangsan
        20
    coderzhangsan  
       173 天前
    又想马儿跑,又不想给马儿吃草。
    xueling
        21
    xueling  
       173 天前   ❤️ 2
    @zhoudaiyu 光测试我倒觉得用处不大,很多线上环境中的问题,测试服务暴漏不出来。不要觉得云服务多么完善似的,人家只分配给你固定资源,不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题,如果只有你自己的服务出了问题,主要还得自己处理。就像你说的线上故障,本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因,云服务厂商有可能给你提供全方位的服务吗,毕竟对于云服务厂商来说,这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标,网络搜集就足够了,比如: https://cloud.tencent.com/document/product/457/39820 你自己网上找找,把这些云服务的监控指标汇总一下就 ok 了。
    guanzhangzhang
        22
    guanzhangzhang  
       172 天前
    每次发生生产故障,监控也很重要,有没有监控,没有就部署上,有监控没监控到,如何监控上。后续在考虑看看怎么限制
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3034 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 14:14 · PVG 22:14 · LAX 06:14 · JFK 09:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.