首页
提效神器
常用运维脚本汇总
电子书阅读
推荐
电子书阅读
事物管理
Search
1
安装docker时报错container-selinux >= 2:2.74
185 阅读
2
rsync命令(可替代rm删除巨量文件)
147 阅读
3
docker 镜像加速器配置,daemon.json文件详解
138 阅读
4
kubernetes集群各组件安装过程汇总
107 阅读
5
使用国内镜像地址拉取k8s安装需要的images
97 阅读
运维
自动化运维
数据库
容器与k8s
环境
云计算
脚本
ai
登录
/
注册
Search
标签搜索
命令
nginx
zabbix
Mingrui
累计撰写
99
篇文章
累计收到
8
条评论
首页
栏目
运维
自动化运维
数据库
容器与k8s
环境
云计算
脚本
ai
页面
提效神器
常用运维脚本汇总
电子书阅读
推荐
电子书阅读
事物管理
搜索到
75
篇与
的结果
2025-09-09
服务器故障的一般排查流程
当服务出现故障时,比如服务不可达,无法远程访问,应用程序报错等故障时,常用的排查思路整理如下。确定故障和检查硬件当发现服务器出现故障时,应详细记录故障发生的具体情况。包括:故障发生时间,故障发生规律,故障是否具有规律性等故障的具体表现,如服务器无法连接,应用程序报错,端口未开放等故障发生前是否有特殊操作,如系统更新,软件安装,修改配置等如果使用的不是云服务器而是自有硬件,还需要检查硬件设置状态查看服务器电源指示灯是否正常,硬盘指示灯是否有异常闪烁,cpu风扇是否正常运转,是否有异响或异味。检查交换机、路由器等常用网络设备是否存在异常,检查网络设备的指示灯状态,确认网线连接是否牢固。若服务器配备硬件监控系统,登录查看硬件健康状态报告,排查是否有硬盘故障,内存报错,电源问题等。验证是否存在网络问题本地网络测试:在服务器本地使用ping命令测试与网关、DNS服务器的连通性,检查防火墙。远程连接测试:从客户端尝试ping服务器ip,使用traceroute命令追踪路由,判断故障节点。端口状态检查:在服务器上使用netstat或者ss命令查看端口的监听状态,确认应用程序所需端口是否正常开放。查看、分析日志查看系统生成的各种日志文件,定位故障发生的原因,比如/var/log/messages(系统通用日志),/var/log/auth.log(认证相关日志)等,使用grep筛选关键词(如error、fail)快速定位问题。针对服务器上运行的应用程序(如web服务,数据库。中间件等),查看其专属日志。如,web服务,Nginx日志通常在/var/log/nginx/access.log和error.log,apache日志在/var/log/apache2/目录下。或者去配置文件中查看日志路径,在对日志文件进行排查。数据库,mysql日志包括错误日志,慢查询日志等。尝试重启服务或设备重启服务:若定位到某一服务异常,先尝试重启该服务观察是否恢复正常。重启服务器:排除掉硬件故障风险后,可以尝试重启服务器,在重新启动服务来观察是否恢复正常。(需提前通知相关用户,避免数据丢失)。
2025年09月09日
19 阅读
0 评论
0 点赞
2025-09-09
解决磁盘空间不足报错的常用方法
在收到磁盘空间不足的警报时,在不能对存储空间扩容的情况下,通常可以使用以下两种方式解决。方法一使用 df -h 命令查看磁盘空间的使用情况,确定哪个目录占用的磁盘空间过高;确定目录后,使用 du -h 命令进行逐级定位,找到占用空间最大的大文件;查看文件内容,确认是否需要保留。如果保留就压缩导出,不保留就直接删除。方法二使用find命令查找目录下的大文件,如大于500M的文件,然后根据实际情况判断是否需要删除或导出。注意:使用df -h命令有时并不能发现大文件,可能的原因是文件已被删除,但是进程仍然在调用这个文件。此时可以通过 lsof | grep delete 命令找到占用的进程,把这个进程kill掉然后重启服务即可。
2025年09月09日
11 阅读
0 评论
0 点赞
2025-09-09
zabbix实现自动修复
核心逻辑zabbix的“监控-触发-动作”联动机制核心原则只处理“原因明确、修复方式固定、重复执行无副作用”的问题,目的是减少人工的重复劳动,而非代替人工决策。适用场景服务/进程异常:服务意外停止(如nginx、mysql进程消失)→ 自动重启;进程资源占用过高(内存/cpu超限)→自动重启释放资源资源阈值超标:磁盘空间满(如日志占满)→ 自动清理旧文件\日志;非核心进程资源超限→自动杀死异常进程网络/端口问题:关键端口未监听(如80,3306)→ 自动重启对应服务;临时网络抖动导致断开→ 自动重连服务配置文件/权限异常:服务配置文件误改→ 自动覆盖为备份文件;目录/文件权限错误→ 自动修正权限不适用的场景复杂故障:数据损坏、硬件故障(如硬盘坏道);业务逻辑错误,代码bug需人工判断的情况:业务流量突增;多原因导致的同一现象高风险操作:删除数据库表、修改核心配置;可能引发连锁故障的操作
2025年09月09日
7 阅读
0 评论
0 点赞
2025-09-01
Linux常用系统监控工具介绍
在服务器管理和系统运维的日常工作中,实时监控系统资源使用情况是一项基础且关键的任务。除了比较基础的top命令外,比较常用的还有以下这些:htop:top命令的增强版glances:提供更全面的系统监控,包括网络、磁盘IO等atop:专注于长期性能监控和记录btop++:htop的现代替代品,提供更华丽的界面和更多功能iotop:专门监控磁盘IO使用情况nmon:IBM开发的系统监控工具,提供更多性能数据下面重点介绍一下htop命令。htop是一款功能强大且易于使用的Linux系统监控工具,它通过直观的界面和丰富的交互功能,大大提升了系统管理员监控和管理进程的效率。从基本的系统资源监控到复杂的进程管理,从简单的排序过滤到自定义显示配置,htop几乎能满足所有与进程监控相关的需求。在日常运维工作中,掌握htop的使用技巧不仅能帮助你快速定位系统问题,还能提高工作效率,减少排障时间。无论是处理高CPU负载、内存泄漏,还是需要快速终止失控进程,htop都能提供直观且高效的解决方案。htop界面详解运行htop时会看到一个分为上下两个部分的界面。顶部区域顶部区域显示系统的整体资源使用情况,包括:CPU使用率 每个CPU核心都有独立的使用率条,不同颜色代表不同类型的进程蓝色:低优先级进程绿色:普通用户进程红色:内核进程黄色/橙色:IRQ时间洋红色:软中断时间灰色:IO等待时间内存使用情况 显示物理内存和交换空间的使用百分比和具体数值绿色:已使用内存蓝色:缓冲区黄色/橙色:缓存负载平均值 显示1分钟、5分钟和15分钟的系统负载平均值正常运行时间 系统启动至今的运行时间任务统计 显示总进程数、运行中的进程数等信息底部区域底部区域显示系统中运行的进程列表,默认按CPU使用率排序。每个进程显示以下信息:PID:进程IDUSER:进程所有者PRI:进程优先级NI:nice值VIRT:虚拟内存大小RES:常驻内存大小SHR:共享内存大小S:进程状态(R=运行,S=睡眠,Z=僵尸等)CPU%:CPU使用百分比MEM%:内存使用百分比TIME+:进程运行时间Command:命令名称和参数htop操作技巧基本操作上下左右键:在进程列表中导航F5:切换树形视图,显示进程父子关系F6:选择排序字段F9:向进程发送信号(如终止进程)F10或q:退出htop进程管理htop最强大的功能之一是其直观的进程管理能力:终止进程:选中进程后按F9,然后选择要发送的信号(如SIGTERM或SIGKILL)调整进程优先级:选中进程后按F7(降低nice值)或F8(提高nice值)追踪进程系统调用:选中进程后按s,启动strace(需要安装strace工具)查看进程打开的文件:选中进程后按l,启动lsof(需要安装lsof工具)搜索功能在htop中,按下/键可以搜索特定进程。输入关键字后,htop会高亮显示匹配的进程。这在系统运行大量进程时特别有用。过滤功能 按下\键可以激活过滤功能,输入过滤条件后,htop只会显示符合条件的进程。例如,输入"apache"将只显示与apache相关的进程。自定义显示列 htop允许你自定义显示哪些进程信息列:按F2进入设置菜单选择"Columns"选项使用空格键选择或取消选择要显示的列F10保存并退出设置自定义配色方案如果你不喜欢默认的颜色方案,可以在设置菜单中进行更改:按F2进入设置菜单选择"Colors"选项选择预设的配色方案或自定义各元素的颜色F10保存并退出设置使用示例场景一:系统资源异常高,定位问题进程 当服务器CPU或内存使用率异常高时,可以通过以下步骤快速定位问题:启动htop,查看顶部的CPU和内存使用情况按F6,选择按CPU%或MEM%排序观察排在顶部的进程,这些通常是资源消耗最大的如果发现异常进程,可以进一步分析或终止它场景二:监控多核CPU的负载均衡情况在多核服务器上,理想情况下工作负载应该均匀分布在各个CPU核心上:启动htop,观察顶部的CPU使用率条检查各个核心的使用率是否平衡如果发现某个核心长期满负荷而其他核心空闲,可能表明应用程序不支持多线程或存在配置问题场景三:内存泄漏排查对于疑似内存泄漏的情况,可以使用htop进行初步排查:启动htop,按F6选择按MEM%排序记录可疑进程的内存使用情况定期观察这些进程的内存使用是否持续增长而不释放如果确认某进程存在内存泄漏,可以重启该进程作为临时解决方案,并进一步分析根本原因
2025年09月01日
6 阅读
0 评论
0 点赞
2025-04-28
PV与PVC之subPath(容器根目录设置)
在某些应用中,同一个Volume可能会被多个Pod或者一个Pod中的多个容器共享。此时可能存在个应用需要不同子目录的需求,可以通过Pod中volumeMounts定义的subPath字段进行设置。通过对subPath的设置,容器将以subPath设置的目录而不是Volume中提供的默认根目录作为根目录。subPath中的路径名称不能以“/”开头,需要使用相对路径的形式。如果希望通过环境变量的形式来设置subPath路径,可以通过subPathExpr字段来实现。subPath和subPathExpr字段是互斥的,不能同时使用。示例{tabs}{tabs-pane label="subPath"}--- apiVersion: v1 kind: Pod metadata: name: mysql spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD volue: "rootpassword" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persitentVolumeClaim: claimName: site-data-pvc{/tabs-pane}{tabs-pane label="subPathExpr"}--- apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: - name: containers1 image: busybox command: ["sh","-c","sleep 6000"] env: - name: POD_NAME volueFrom: fieldRef: apiVersion: v1 FilePath: metadata.name volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME) restartPolicy: Never volumes: - name: workdir1 hostpath: path: /var/log/pods {/tabs-pane}{/tabs}
2025年04月28日
48 阅读
0 评论
0 点赞
1
...
3
4
5
...
15