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

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

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

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

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


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

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

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

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

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

    来看看我写这篇文章。

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