企业数通网络用到多种设备类型,设备之间使用多种物理链路连接,同时为了准确的完成数据包的转发,网络设备运行了多种网络协议。 网络设备,线缆、以及网络协议都有可能产生网络故障,如何快速完成故障处理是一个高级网络工程师的基本素养。 什么是网络故障 网络故障是指由于某种原因而使网络丧失规定功能并影响业务的现象。 网络工程师经常接到各种求助电话,例如“电脑突然无法上网” 、“网页无法正常显示”、“游戏没法玩了”…… 报告故障:主动沟通确认 在电话里询问用户上面的内容,并记录在排障报告中。 逐一排查 在逐一排查阶段同样需要平衡解决问题的迫切性与引入新故障的风险性之间的矛盾。所以,应该明确告知用户排查工作可能带来的风险,并在得到许可的情况下才能执行操作。 有些情况下,通过逐一排查验证推断的过程涉及到网络变更,这时必须做好完善的应急预案和回退准备。 解决故障 如果通过逐一排查找到了故障的根本原因,并排除了故障,网络故障排除的流程就可以结束了。
根据百度百科定义,Traceroute是一种电脑网络工具,它可显示数据包在IP网络经过的路由器的IP地址。 Traceroute有三大特点: 跨平台。 现代商业网络运行情况良好。 大部分ISP NOC甚至是专业的网络工程师也难以解释一个复杂的路由;有非常多的误判报告充斥着世界各地NOC;高误判率导致几乎无法从这些报告中判断出真正最根本的网络问题。 帮助你理解网络互联的节点。 四、网络延时 三种主要网络延时: 串行延时。该延时是路由器或交换机发送数据包的时间,串行延时=包大小(bits)/传输速率(bps); 排队延时。
网络无法通信通用排障流程 ✔ 基础连通性验证 1)ping 本机IP 2)ping 网关 3)ping 同网段设备 4)ping 其他网段 5)traceroute 跳点定位 判定逻辑: 能否 ping 问题 典型现象 水晶头歪斜 速度跌为10M、随机断链 光模块速率不匹配 单向链路Up/Down反复抖动 光功率过低(>-23dBm即危险) 帧错,丢包增大 双绞线过长 > 100m 速率自动降级 排障动作 switchport trunk allowed vlan add 10,20 5 秒全楼恢复 广播风暴 / 环路导致整网卡死 现象 ping随机丢包50%+ CPU升到80%以上 交换机流量飙到线速 核心排障 是神器 A traceroute B 失败 B traceroute A 成功 → 说明回程路由缺失 修复: ip route add 192.168.1.0/24 via 192.168.2.1 4️⃣ /proc/sys/fs/file-nr SYN flood 攻击 netstat -ant grep SYN_RECV 完整修复: ulimit -n 65535 sysctl net.ipv4.
以下是30个常用的排障命令 附带详细说明和一些用于华为网络设备的命令示例 以帮助小白网络工程师更好地理解: 1. Ping测试: • 方法:使用ping命令测试目标设备的连通性。 SSH):在命令行界面中输入以下命令: ssh 用户名@目标设备的IP地址或域名 • 示例:(假设用户名为admin,目标IP地址为10.0.0.1) <华为设备> ssh admin@10.0.0.1 4. 抓包分析: • 方法:使用Wireshark等抓包工具捕获和分析网络数据包。 • 命令:下载并安装Wireshark,然后运行应用程序并选择网络接口开始抓包。 性能监控: • 方法:使用监控工具(如eSight)监视网络设备和服务的性能。 • 无特定命令,使用监控工具来监视性能。 10. MTU大小检查: • 方法:检查网络设备的最大传输单元(MTU)设置,确保它们匹配。 • 示例:查看接口MTU配置。
CrashLoopBackOff 629 2d12h kube-flannel-ds-arm64-hnsrv 0/1 CrashLoopBackOff 4 container=kube-flannel pod=kube-flannel-ds-arm64-7cr2b_kube-system(2eaa8ef9-1822-11ea-a1d9-70fd45ac3f1f)" 4 中执行命令拷贝到命令行之后可以正常执行,这个时候就不知所以然了,直到我发现有时pod会提示; kube-flannel-ds-arm64-hnsrv 0/1 OOMKilled 4 NET_ADMIN"] 3)ImagePullBackOff 异常解决 一般出现这个异常大多以下两个原因造成的: 镜像名称无效-例如,你拼错了名称,或者 image 不存在 你为 image 指定了不存在的标签 4) 网络插件kube-flannel无法启动问题 一般情况下是因为网络插件flannel下载问题,默认的网络插件下载地址是quay.io/coreos/flannel,但是这个地址国内网络无法直接访问到,这个时候我们需要从
此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间, Waiting (等待) Pod 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作。
针对网络丢包监测,以及找运营商报障,步骤如下: 1. 用户提供 本地客户端 到服务器 双向 ping 测试截图,双向MTR 测试截图,以及本地客户端公网出口IP 截图。 2. 提交这些截图通过工单的形式联系腾讯云侧帮忙向运营商报障,或者如果客户有本地运营商联系途径,可以直接拿这些测试截图直接找运营商报障(效率比较快一点) 因为大多数用户不太清楚MTR 工具的使用,所以为了方便用户操作 ,腾讯云侧专门自研了自动化网络排障工具,用户只要下载自动化工具,在本地 或者 服务器执行start 操作,该工具就会自动执行 Ping 检测 MTR 检测 TRACERT 检测,本地出口IP 检测,并自动把这些信息上传到腾讯云后台 sign=f1b91fc24225d448b2ff280ce9f26bb4 Linux:wget -O tool.zip http://49.234.16.249/auto/download/tool sign=f1b91fc24225d448b2ff280ce9f26bb4 注:这里的正向可以是 本地到服务器的检测,也可以是服务端到本地的检测,如果正向是 本地 到服务器的检测 ,那反向就是 服务器到本地的检测
一、网络工程师基础排障思路1. 排障核心原则(3 大思维)原则 说明 示例 由外到内从最外层(用户端)到最核心 常见排障方法方法 思路 场景举例 分层法按 OSI 模型逐层排查 链路层看 MAC,网络层看 IP,传输层看端口 标准排障流程(6 步)确认故障现象收集用户反馈、错误信息、日志定位故障范围单用户 / 多用户单 VLAN / 多 VLAN检查物理层端口状态(up/down)、网线、光纤、模块检查链路层VLAN 配置、 Trunk、MAC 地址表检查网络层IP 地址、网关、路由表、ACL验证与恢复解决问题后验证网络恢复,记录原因 二、常用排障命令速查表1.
3/3 Running 0 40m 172.16.0.2 10.0.0.10 l7-lb-controller-2881622555-0v0p4 2217866662 Controlled By: ReplicaSet/nginx-2217866662 Containers: nginx: Container ID: docker://4fb98d7d4241f908695181b124096025d1bc6ba4f74065519c82b86ea8bd635d 1453632Ki pods: 110 System Info: Machine ID: f9d400c5e1e8c3a8209e990d887d4ac1 : A84ED043-ECAE-46CE-BB9D-7BCF16C5C59E Boot ID: f8d75ea2-2f4e kubectl -n kube-system logs $PODNAME -c kubedns I0518 06:35:55.598577 1 dns.go:48] version: 1.14.3-4-
得到上述指标后,便可灵活定义自己的业务和应用监控大盘: 我们也可以使用 PromQL,灵活定义告警规则,例如我们可以定义一个关于订单支付延时的告警: K8s 排障实践 接下来,我们将一起探讨常见的 Kubernetes 故障及其根因,并从具体案例出发,分析如何借助 Prometheus,对 K8s 进行全面排障。 常见原因: 网络插件故障: 使用的网络插件(如 Calico、Flannel)出现问题,导致网络不通。 排障案例 如果我们采访 K8s 运维工程师,问他们最常见、最头疼的 K8s 故障是啥,那么遥遥领先的必然是这俩: Pod 处于 pending 状态。 满足您全链路、端到端的统一监控诉求,提高运维排障效率,为业务的健康和稳定保驾护航。
我们以一些典型的场景为切入,来看看排障定位为什么会出现如此困境:01. 运维痛点——排障过程存在困境1)单点用户排障流程过去传统运维单点排障的工作实录:用户纷至沓来,客服电话被打爆,运维人员看看堆积如山的工单汗如雨下。只能一个个工单进行故障排查。 2)前端排障原理与流程当然,随着代码技术的不断演进,现在的程序员一般是不会一行一行的去排查代码的,不然动辄上万行的代码,如此去排障,运维人员、前后端人员早就“崩溃”了。 为防止前后端的“撕逼”,我们需要从什么角度去建立前端监控体系,保证前后端的工作定位准确,精准排障呢?03. 对症下药——跨越障碍实现精准排障从用户端来看,任何一个角度出现问题,都会导致用户的体验不佳,导致流失。
之前反复看了好久电视盒子,最高看到像冥王峡谷 S922芯片的怪兽,奈何钱包羞涩,最终还是选了比较成熟的中档 S905x3的系列,有很多选择,最终买的是 MECool KM1 4G 内存的版本。 之前用着一直没什么问题,最近总是出现一个系统提示 Wifi 已连接但无法访问互联网,实际上基础网络访问是没问题的,像腾讯视频之类的,但 youtube 就无法打开,奇怪的是同一路由下不管是手机还是电脑都能正常播放
"$4}'|sort|uniq-c|sort-nr|head-20 6.根据端口列进程 netstat -ntlp|grep 80|awk'{print$7}'|cut-d/-f1 网站日志分析篇1( uniq-c|sort-nr|head-20 3.列出传输最大的几个exe文件(分析下载站的时候常用) cat access.log|awk'($7~/\.exe/){print$10""$1""$4" "$7}'|sort-nr|head-20 4.列出输出大于200000byte(约200kb)的exe文件以及对应文件发生次数 cat access.log|awk'($10>200000&&$7~ sort 网站日分析2(Squid篇) 2.按域统计流量 zcat squid_access.log.tar.gz|awk'{print$10,$7}'|awk'BEGIN{FS="[/]"}{trfc[$4]
在上一篇文章的故障处理中【网络故障排除的举例【网络排障连载03】】已保证PC1和SW3之间无故障,Server6和SW5之间无故障。 邻居关系建立失败的原因有: Router ID冲突 区域ID不匹配 网络掩码不匹配 MTU不一致 MA网络中,所有设备的DR优先级设置为0 认证密码不匹配 接口被设置为silent-interface [R2]display telnet server status TELNET IPV4 server :Enable TELNET IPV6 server [R2-ui-vty0-4]display this user-interface vty 0 4 authentication-mode aaa protocol inbound ssh 修改R2 <R2>display isis interface Interface information for ISIS(1) Interface Id IPV4.State MTU Type DIS GE0
拓扑如下,管理员将防火墙配置为对内部服务器 1 和服务器 2 进行 NAT,以便为 Internet 用户 (R1) 提供服务。并且服务器 1 被允许访问互联网,但服务器 2 不被允许。配置完成后,admin发现server 1和server 2都可以上网。
2020年即将结束,网络工程师或管理员也将迎来崭新的年度。那么,奋战在网络维护一线的小伙伴们应该掌握什么样的软件才能真正搞好网络维护,让网络正常运营呢? 网络抓包 从网络抓包就可以分析出很多东西,其中一项就是用来做排错。 为对运营商网络中不同类型的业务流进行准确的流量和流向分析与计量,首先需要对网络中传输的各种类型数据包进行区分。 由于IP网络的非面向连接特性,网络中不同类型业务的通信可能是任意一台终端设备向另一台终端设备发送的一组IP数据包,这组数据包实际上就构成了运营商网络中某种业务的一个Flow。 ,以识别并快速解决网络问题。
①安装微软Sysmon并启用 analytic and debug logging
这时我们还是需要一个全面的排障流程,不能无厘头地进行优化;全面的排障流程可以帮助我们找到真正的根因和性能瓶颈,以及实施正确高效的优化方案。 这篇文章我们就从可能导致 Redis 延迟的方方面面开始,逐步深入排障深水区,以提供一个「全面」的 Redis 延迟问题排查思路。 排障事大,但咱也不能冤枉了Redis;首先我们还是应该把其它因素都排除完了,再把焦点关注在业务服务到 Redis 这条链路上。 导致 Redis Latency 的具体原因 如果使用我们的快速清单并不能解决实际的延迟问题,我们就得深入 redis 性能排障的深水区,多方面逐步深究其中的具体原因了。 总结 Redis 排障是一个循序渐进的复杂流程,涉及到 Redis 运行原理,设计架构以及操作系统,网络等等。
异常网络引起的问题 之前使用redis-operator在kubernetes中部署了一套Redis集群,可测试的同事使用redis-benchmark随便一压测,这个集群就会出问题。 经过艰苦的问题查找过程,终于发现了问题,原来是两个虚拟机之间的网络存在异常。 经验教训,在测试前可用iperf3先测试下node节点之间,pod节点之间的网络状况,方法如下: # 在某台node节点上启动iperf3服务端 $ iperf3 --server # 在另一台node iperf3相关pod的podIP $ kubectl get pod -o wide # 在某个iperf3 client的pod中执行iperf3命令,以测试其到iperf3 server pod的网络状况 unsigned char*, unsigned long)+0x3d) [0x1b1461d] /home/mdcallag/b/orig811/bin/mysqld(handle_fatal_signal+0x4c1
建设大模型训练排障平台是提升训练效率、降低运维成本、保障研发进度的关键基础设施。 以下是构建这样一个平台的系统化方案:一、核心建设目标故障快速定位:分钟级定位硬件/软件/算法故障根源训练过程透明化:实时监控千卡级集群训练状态智能预警:提前发现潜在故障风险(如梯度异常)知识沉淀:构建可复用的排障知识库二 全域数据采集层数据类型采集方式采样频率GPU指标(显存/利用率)DCGM/NVML1秒级网络流量RDMA计数器+交换机SNMP5秒级分布式框架日志PyTorch/TF的NCCL日志实时流采集算法指标训练脚本标准输出 可视化控制台三维集群视图:物理机架/逻辑拓扑双模式切换动态通信热力图:实时显示AllReduce通信延迟梯度分布雷达图:多维度对比各层梯度分布故障溯源时间线:自动关联异常事件链4.