查看是否存在不正常的pod journalctl -u kubelet -f 查看kubelet,是否存在异常日志 kubectl logs pod/xxxxx -n kube-system 2) 2d14h kube-apiserver-k8s-master 1/1 Running 0 2d14h kube-controller-manager-k8s-master 1/1 Running 0 2d14h kube-flannel-ds-arm64-7cr2b 0/1 CrashLoopBackOff 629 2d12h kube-flannel-ds-arm64-hnsrv 0/1 CrashLoopBackOff 4 2d12h -1822-11ea-a1d9-70fd45ac3f1f ("kube-flannel-ds-arm64-7cr2b_kube-system(2eaa8ef9-1822-11ea-a1d9-70fd45ac3f1f
pod 处于以上情况,可通过kubectl describe pod -n<namepsaces> <podname> 查看对应event 展示信息,基于对应报错信息进行解决;
Image: nginx:latest Image ID: docker-pullable://nginx@sha256:0fb320e2a1b1620b4905facb3447e3d84ad36da0b2c8aa8fe3a5a81d1187b884 UUID: A84ED043-ECAE-46CE-BB9D-7BCF16C5C59E Boot ID: f8d75ea2- I0518 06:35:55.599976 1 server.go:113] FLAG: --v="2" I0518 06:35:55.599979 1 server.go:113 16.028669 10676 fs.go:117] Filesystem partitions: map[/dev/vda1:{mountpoint:/var/lib/docker/overlay2 :16 VM_0_10_centos kubelet[10676]: I0518 14:35:16.029405 10676 manager.go:198] Machine: {NumCores:2
2.Prometheus 针对云原生环境的独特设计。 得到上述指标后,便可灵活定义自己的业务和应用监控大盘: 我们也可以使用 PromQL,灵活定义告警规则,例如我们可以定义一个关于订单支付延时的告警: K8s 排障实践 接下来,我们将一起探讨常见的 Kubernetes 故障及其根因,并从具体案例出发,分析如何借助 Prometheus,对 K8s 进行全面排障。 排障案例 如果我们采访 K8s 运维工程师,问他们最常见、最头疼的 K8s 故障是啥,那么遥遥领先的必然是这俩: Pod 处于 pending 状态。 满足您全链路、端到端的统一监控诉求,提高运维排障效率,为业务的健康和稳定保驾护航。
我们以一些典型的场景为切入,来看看排障定位为什么会出现如此困境:01. 运维痛点——排障过程存在困境1)单点用户排障流程过去传统运维单点排障的工作实录:用户纷至沓来,客服电话被打爆,运维人员看看堆积如山的工单汗如雨下。只能一个个工单进行故障排查。 2)前端排障原理与流程当然,随着代码技术的不断演进,现在的程序员一般是不会一行一行的去排查代码的,不然动辄上万行的代码,如此去排障,运维人员、前后端人员早就“崩溃”了。 为防止前后端的“撕逼”,我们需要从什么角度去建立前端监控体系,保证前后端的工作定位准确,精准排障呢?03. 对症下药——跨越障碍实现精准排障从用户端来看,任何一个角度出现问题,都会导致用户的体验不佳,导致流失。
sort-rnnetstat-n|awk'/^tcp/{print$NF}'|sort|uniq-c|sort-rnnetstat-ant|awk'{print$NF}'|grep-v'[a-z]'|sort|uniq-c 2. "$2"."$3". uniq-c|sort-nr|head-10 cat access.log|awk'{counts[$(11)]+=1};END{for(urlincounts)printcounts[url],url}' 2. $10}END{printsum/1024/1024/1024}' 9.统计404的连接 awk'($9~/404/)'access.log|awk'{print$9,$7}'|sort 网站日分析2( Squid篇) 2.按域统计流量 zcat squid_access.log.tar.gz|awk'{print$10,$7}'|awk'BEGIN{FS="[/]"}{trfc[$4]+=$1}END
这时我们还是需要一个全面的排障流程,不能无厘头地进行优化;全面的排障流程可以帮助我们找到真正的根因和性能瓶颈,以及实施正确高效的优化方案。 这篇文章我们就从可能导致 Redis 延迟的方方面面开始,逐步深入排障深水区,以提供一个「全面」的 Redis 延迟问题排查思路。 排障事大,但咱也不能冤枉了Redis;首先我们还是应该把其它因素都排除完了,再把焦点关注在业务服务到 Redis 这条链路上。 导致 Redis Latency 的具体原因 如果使用我们的快速清单并不能解决实际的延迟问题,我们就得深入 redis 性能排障的深水区,多方面逐步深究其中的具体原因了。 总结 Redis 排障是一个循序渐进的复杂流程,涉及到 Redis 运行原理,设计架构以及操作系统,网络等等。
会不断监测系统并记录日志,因此有持续不断的IO,用Process Explorer可以清楚地观察到https://cloud.tencent.com/developer/article/2333826举例2:
以下是30个常用的排障命令 附带详细说明和一些用于华为网络设备的命令示例 以帮助小白网络工程师更好地理解: 1. Ping测试: • 方法:使用ping命令测试目标设备的连通性。 • 命令:在命令行界面中输入以下命令: ping 目标设备的IP地址或域名 • 示例:(假设目标IP地址为10.0.0.1) <华为设备> ping 10.0.0.1 2.
key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=1 max_threads=151 thread_count=2 mdcallag/b/orig811/bin/mysqld() [0x1ce5408] /home/mdcallag/b/orig811/bin/mysqld(log_flusher(log_t*)+0x2fb 这样当MySQL集群长时间压测后,产生的大量binlog会超额使用ephemeral-storage空间,最终kubernetes为了保证容器平台的稳定,会将该pod杀掉,当3节点MySQL集群中有2个
建设大模型训练排障平台是提升训练效率、降低运维成本、保障研发进度的关键基础设施。 以下是构建这样一个平台的系统化方案:一、核心建设目标故障快速定位:分钟级定位硬件/软件/算法故障根源训练过程透明化:实时监控千卡级集群训练状态智能预警:提前发现潜在故障风险(如梯度异常)知识沉淀:构建可复用的排障知识库二
现象:某个Node频繁出现“PLEG is not healthy: pleg was last seen active 3m46.752815514s ago; threshold is 3m0s”错误,频率在5-10分钟就会出现一次。
服务是预安装在公共镜像内部的,cloud-init安装的时候,python解释默认使用的是python2(即:/usr/bin/python 与 /bin/python 这两个软连是链接向 python2 Windows Cloud-Init 排障思路 确认Windows Server内部 cloudbase-init 服务是正常运行 1、登录虚拟机(如果忘记密码或者因为cloudbase-init 服务异常重置密码失败了 2)查看“登录身份”是否是“本地系统账户”,如果不是改为如下图所示。 image.png 4、打开“注册表”搜索并找到全部的“LocalScriptsPlugin”,确认其值是否为2,如果不是则改为2,如下图所示: image.png 5、确认 CD-ROM 的加载是否被禁用 详见“如何确认子机内部的 cloudbase-init 服务是正常运行的-> 步骤2”。
网络工程师经常接到各种求助电话,例如“电脑突然无法上网” 、“网页无法正常显示”、“游戏没法玩了”…… 报告故障:主动沟通确认 在电话里询问用户上面的内容,并记录在排障报告中。 逐一排查 在逐一排查阶段同样需要平衡解决问题的迫切性与引入新故障的风险性之间的矛盾。所以,应该明确告知用户排查工作可能带来的风险,并在得到许可的情况下才能执行操作。 有些情况下,通过逐一排查验证推断的过程涉及到网络变更,这时必须做好完善的应急预案和回退准备。 解决故障 如果通过逐一排查找到了故障的根本原因,并排除了故障,网络故障排除的流程就可以结束了。
/2 不在一个网段。 >rancher3 正常,但是 rancher3->rancher2 不正常。 挂的时候,traceroute rancher2->rancher3 正常,但是 rancher3->rancher2 不正常。 挂的时候,rancher3 同子网其他机器 ping rancher2 正常。 挂的时候,rancher1/2 etcd cluster-health 看到rancher3 unhealthy,rancher3 etcd cluster-health 看到 rancher1/2 dial
实战干货:编程严选网 1 排障过程 系统从圣诞节那天晚上开始,每天晚上固定十点多到十一点多这个时段,大概瘫痪1h左右,过这时段系统自动恢复。系统瘫痪时的现象就是,网页和App都打不开,请求超时。 找到了问题原因,做针对性的优化,问题很快解决: 2 如何避免悲剧重演 问题原因在于开发犯了错误,编写SQL没有考虑数据量和执行时间,缓存使用也不合理。 尽量注意不同事务对表操作的顺序一致,大事务其实也包含着批量操作的隐式事务,如一个update 影响100万行数据 见过的关于架构方面的慢SQL问题 1~数据量到达一定规模后,单机性能容易受限导致数据库响应慢;2~ 如IM或消息类等有实时性要求,可能2秒就算慢查询,但读从库做大数据分析场景,可能跑一个小时也不算慢。 可以打开代码层面的数据库模块的日志开关,如mybatis有拦截器可以记sql语句和数量,应该能根据sql语句看到异常的sql(首页请求没命中缓存)或选取2个时间段,一个有问题,一个没问题,把同类sql按总数量大小从大到小用表格比一下
网络无法通信通用排障流程 ✔ 基础连通性验证 1)ping 本机IP 2)ping 网关 3)ping 同网段设备 4)ping 其他网段 5)traceroute 跳点定位 判定逻辑: 能否 ping 问题 典型现象 水晶头歪斜 速度跌为10M、随机断链 光模块速率不匹配 单向链路Up/Down反复抖动 光功率过低(>-23dBm即危险) 帧错,丢包增大 双绞线过长 > 100m 速率自动降级 排障动作 排查 | show int g0/1 → CRC error持续上升 光功率 -24dBm(低于阈值) | 解决 | 更换光纤跳线 ➤ 延迟从1200ms降为3ms | 物理问题占故障总量的35%+ 2️⃣ 案例:公司办公网VLAN10/20跨楼层不通 | 检查第1层 | 物理OK | | 检查第2层 | VLAN 10未加入Trunk链路! switchport trunk allowed vlan add 10,20 5 秒全楼恢复 广播风暴 / 环路导致整网卡死 现象 ping随机丢包50%+ CPU升到80%以上 交换机流量飙到线速 核心排障
如etworkname.customer.alter.net 有时能够看到反解域名的明显变化: 4 te1-2-10g.ar3.DCA3.gblx.net (67.17.108.146)5 sl-st21 -ash-8-0-0.sprintlink.net (144.232.18.65) 有时能够看到DNS的某一部分变化: 4 po2-20G.ar5.DCA3.gblx.net (67.16.133.90 )5 cogent-1.ar5.DCA3.gblx.net (64.212.107.90) 当然有时DNS的信息根本没有用: 2 po2-20G.ar4.DCA3.gblx.net (67.16.133.82 2. 排队 当一个接口在被使用,下一个包必须排队等待被发送。通常来说,一个接口90%使用率等于将要转发的包90%都在排队。 5 cr2.wswdc.ip.att.net (12.122.3.38) [MPLS: Label 17221 Exp 0] 8ms 8ms 8ms6 tbr2.wswdc.ip.att.net (12.122.16.102
Redis 执行 GET、SET、DEL 命令耗时也很久为什么我的 Redis 突然慢了一波,之后又恢复正常了为什么我的 Redis 稳定运行了很久,突然从某个时间点开始变慢了这时我们还是需要一个全面的排障流程 ,不能无厘头地进行优化;全面的排障流程可以帮助我们找到真正的根因和性能瓶颈,以及实施正确高效的优化方案这篇文章我们就从可能导致 Redis 延迟的方方面面开始,逐步深入排障深水区,以提供一个「全面」的 当某进程又需要这些数据且OS发现还有空闲物理内存时,又会把SWAP分区中的数据交换回物理内存中,这个过程称为SWAP IN,详情可参考这篇文章redis 监控指标合理完善的监控指标无疑能大大助力我们的排障 系统引起的延迟比在物理机上也要高得多 结果就是,即使 Redis 在亚微秒的时间级别上能处理大多数命令,网络和系统相关的延迟仍然是不可避免的Redis实例所在的机器带宽不足 / docker网桥性能问题等排障事大 启用并使用 Redis 的延迟监控功能,更好的监控 Redis 实例中的延迟事件和原因导致Redis Latency的具体原因如果使用我们的快速清单并不能解决实际的延迟问题,我们就得深入 redis 性能排障的深水区
JVM 运维实用排障工具 1、jps 用来查看Java进程的具体状态, 包括进程ID,进程启动的路径及启动参数等等,与unix上的ps类似,只不过jps是用来显示java进程,可以把jps理解为ps的一个子集 Dignore.endorsed.dirs= -Dcatalina.base=/data0/tomcat -Dcatalina.home=/data0/tomcat -Djava.io.tmpdir=/data0/tomcat/temp 2、 JVM version is 25.91-b14 Non-default VM flags: -XX:CICompilerCount=2 -XX:CMSWaitDuration=1900 -XX:InitialHeapSize