其实我们注意过内核参数里有个threads-max,当时也调了,但是想当然以为这个是限制线程的
1
Aliencn 142 天前
团队技术能力不够,又无法扩招团队,那就通过外包形式来解决吧,比如买一些云的 K8S 服务
|
3
qq135449773 142 天前
经典决策层之又不想花钱又想办事儿
|
4
EastLord 142 天前
只能不断学习,比如 k8s/docker 官方文档,尝试问问 chatGPT ,当个参考不能全信,遇到问题来 v 站问问老哥
|
5
zsc8917zsc 142 天前 1
国企的话,资源有限,那就发挥不怕苦不怕累的精神,一个参数一个参数的啃,没日没夜的反复验证,创造一个又一个可歌可泣的故事......
|
6
defunct9 142 天前
你怎么可能提前预知哪些指标会超出阈值呢,只有出了事补足,补足,补足,3 年后,自然没啥大毛病了
|
7
FrankAdler 142 天前 via Android
k8s 能限制 pod 资源除了 cpu 内存也没几项了,全部过一遍,设置下合理的值应该工作量不大,用的应该是 cgroups 能力?
|
8
Aliencn 142 天前
|
9
Makabaka01 142 天前
@zhoudaiyu 要么扛住压力,用公司的资源让自己进步,反正自己不是老板出问题亏的也不是自己;要么跑路
|
10
opengps 142 天前
既然是能力之外的,那么这类故障有了这次也会有下次,只能减少不会杜绝。
你有的监控的参数再多,也架不住有你不懂得地方,所以能做的就是多参考市面上的监控指标,有什么抄什么,等自身能力到一定数值之后可能就是你有什么市面上抄你什么。 举个我的例子:当年我人肉运维时候,就怕服务器端 socket 死掉,所以就自己写了个检测端口能否连上的程序,一个放在局域网,一个放在公网,当时真的出现了光纤被挖断的事故,两个报警都有效但内网的显然发不出来,幸好有放在外网的这一份报警程序凌晨 3 点把我吵醒起来运维,一个电话打给联通到凌晨 4 点就反馈说给解决了。然后过了几年,我听到了脉脉故障的故事(只有内网的监控,以至于官方自己没有第一时间发现故障,反倒通过市场客户反馈得知故障) |
11
xueling 142 天前 1
这种容器服务,如果没有太多经验,不踩坑是不可能的。可以用我的开源项目: https://github.com/xl-xueling/xl-lighthouse 。网络上搜集所有可能导致宿主节点宕机/故障的配置参数,然后开发一些数据上报脚本,建立全方位的统计监控体系。我的项目可以任意创建自定义统计监控指标,实现任意维度的数据监控,使用非常灵活,统计监控方面的功能比 Prometheus 那一类工具要强大的多。
|
13
zhoudaiyu OP @qq135449773
@EastLord @zsc8917zsc @defunct9 @FrankAdler @Aliencn @willx12123 @opengps @xueling 我在想要不要鼓弄领导买一套阿里云/腾讯云的服务(纯测试用不跑实际业务),然后把监控告警也买了,然后对着补齐? |
14
RainCats 142 天前
@zsc8917zsc 是不是还得来点什么重病奋战、什么老婆生孩子仍旧坚守岗位、什么家里人去世强忍悲痛奋战之类的
|
15
isno 142 天前
如果下次是别的内核参数不对出问题怎么办?事实的做法是出了问题就修,没别的办法。
说点我的建议 1. 搞全链路测试、压测,提前找出问题。 2. 让开发也参与报警的设置,这次是线程数故障,下次如果是内存不够、带宽不够、业务接口不通呢?难道全你们设置 3. 买技术支持,参考 B 站大故障。。。 |
16
isno 142 天前 1
[如何能解决这种认知范围之外的问题?]
来看看我写这篇文章。 https://www.thebyte.com.cn/Observability/Observability-vs-Monitoring.html |
17
yyttrr 142 天前
这种指标太多了,连接数,rss 内存,wss 内存,cpu throttled 啥的
遇到一次问题下次别再出就行 |
18
Hopetree 142 天前
监控告警搞上去,Prometheus 有没有利用上
|
19
mango88 142 天前
补齐监控指标,调低告警阈值,让业务开发团队配合压测,分配资源的时候多预留一些
|
20
coderzhangsan 142 天前
又想马儿跑,又不想给马儿吃草。
|
21
xueling 142 天前 2
@zhoudaiyu 光测试我倒觉得用处不大,很多线上环境中的问题,测试服务暴漏不出来。不要觉得云服务多么完善似的,人家只分配给你固定资源,不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题,如果只有你自己的服务出了问题,主要还得自己处理。就像你说的线上故障,本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因,云服务厂商有可能给你提供全方位的服务吗,毕竟对于云服务厂商来说,这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标,网络搜集就足够了,比如: https://cloud.tencent.com/document/product/457/39820 你自己网上找找,把这些云服务的监控指标汇总一下就 ok 了。
|
22
guanzhangzhang 141 天前
每次发生生产故障,监控也很重要,有没有监控,没有就部署上,有监控没监控到,如何监控上。后续在考虑看看怎么限制
|